8
kiki
94d

Let's admit that the idea of stacking emojis together to make other emojis was stupid. It was never gonna work. Now, when you see an emoji, you don't know how many bytes you need to store it.

Comments
  • 3
    I am grateful I am not working on code for that right now.
  • 7
    To be fair, it’s not just emojis.
    For example: e + ` = è
    And utf-8 has variable length characters so you never know how many bytes you need.
  • 4
    If this is the problem you struggle with, I'm not sure if I should feel happy or sorry for you. Either happy for not having more difficult problems or sorry for struggling with a simple thing.
  • 7
    Allow me to introduce you to "timezones".
  • 0
    @atheist oh yes, everything was much easier before timezones /s
  • 2
    @atheist timezones are actually not that hard if we handle them correctly.
    Don’t ever include timezone info when you store dates or send dates via an API. Always use UTC for that.
    Only when you display the date to the enduser in the frontend, you should take the UTC date and format it into a local time string using system SDKs.
    When you send dates from the frontend to the backend, convert the local time to UTC before sending.
    That’s it.
    This covers 99% of all use cases.

    If you don’t have system SDKs for that, it means that you are using a clown language like JS. In that case, I’m sorry for you.
  • 2
    Imagine dealing with relativistic time like in GPS.

    Yes, the speed of the satellites is such that their local time is infinitesimally slower than ours, but enough to ruin the whole sync needed for you to be able to triangulate position.
  • 1
    @CoreFusionX just figure out the Lorentz factor and multiply the time deltas by that value. No biggie 😂
  • 2
    @Lensflare

    Sure.

    I think it doesn't evade you the inherent difficulty in calculating the Lorentz factor for those speeds with enough precision so the resulting time derived error falls within acceptable ranges for GPS to work.

    It just so happens that derived magnitude measurement errors when divisions are included tend to explode *really* fast.

    So yeah, it's *very* difficult. Lorentz transformation itself, even if mostly valid for this scenario, is still at best a "suppose the cow is spherical" scenario.
  • 3
    For another take on what I mean, take aiming the James Webb space telescope to some target several millions of light-years away.

    If you nudge the telescope one micrometer, you might thing "no biggie, what's a micrometer compared to the size of the telescope?".

    But suddenly, you are seeing some place hundreds of light years away from your intended target...
  • 0
    @CoreFusionX sure but gps satellites don’t change altitude or speed so once you have found a good approximation you can keep it as a constant for decades.
    Or am I missing something?

    Also, unlike in your example with the telescope, there should not be the problem of errors adding up over time.
  • 1
    @Lensflare their orbits do decay though. Not sure if they have active "orbit" correction for that. Like they can adjust orbit with thrusters.
  • 1
    @Lensflare

    You are missing something it seems.

    In every measurement, there's systematic error (which you may know as bias) which is very hard to detect (especially in this particular scenario) and is usually taken as a given.

    And then there is random error, which comes from the fact that at the end of the day, even a random neutrino can flip a bit.

    Those apply to *direct* measurements. Velocity, concretely, can not be measured directly because relativity (Galilean relativity, not general/special).

    Whenever your desired target calculation depends on other directly measured magnitudes, there are formulas to calculate the derived error, based on the random error of the direct measurements.

    Whenever that calculation contains a division, the formula is rather unforgiving, depending on the square of the derivative of the divisor.

    That's what I tried to illustrate with my telescope example. A tiny random error at the direct measurement (position and angle of the telescope)
  • 0
    Can easily lead to many orders of magnitude errors in the result.

    And my example is trivial to demonstrate just using paint, and seeing how a tiny difference in position and angle results in a huge difference between expected and obtained results.
  • 1
    @Demolishun

    And no. Satellites don't pack active thrusters. That would mean packing fuel, and then you fall into rocket efficiency equations which are a lost cause.

    Orbits do decay (this doesn't necessarily mean crashing into earth) due to minute changes because earth is not perfectly spherical, and the moon does a non negligible amount of contribution.

    The effects are surely small, but again, as I said, when they impact your direct magnitude measurements even slightly, they can impact your indirect results *greatly*
  • 2
    @Lensflare

    This answer https://physics.stackexchange.com/q...

    explains in a more mathy way.

    It's immediate to see that in any measurement where division is involved, and the errors may seem tiny, the derived error formula turns it around (common sense really, small differences in sub-1 denominators cause big deviations).

    Errors *do* add and *do* multiply.

    The misconception is people thinking the measurement will be wrong by x.

    The measurement will be wrong. Period.

    Thing is, does it fall between our range of acceptance (for whatever application we are talking about. In the case of GPS, it's really tight), based on the estimated error of our direct measurements?
  • 3
    Start of this discussion: emoji are badly designed
    End of this discussion: experiment errors are hard to quantify and can invalidate the results.

    If I had a nickel for each relevant topic I have a degree in, I'd have 2 nickels. Which isn't a lot, but it's weird that it happened twice.
Add Comment