• Prime Mover (unregistered)

    So:

        var digits = 0;
    while (num >= 1)
    {
        digits++;
        num /= 10;
    }

    should be:

        var digits = strlen (toString (num));

    for appropriately defined strlen and toString, whatever they need to be in whatever appalling language this is written in.

    ... amirite?

  • LCrawford (unregistered) in reply to Prime Mover

    var digits = strlen (toString (num));

    What about var digits = strlen (toString (34.6883374));

    The other WTF is dealing with floating point numbers with integer constants in code.

  • TheCPUWizard (unregistered)

    "he curvature is different depending on your latitude".... Well the earth is not a sphere, so the curvature depends on so many things. But the angular (from center of earth) measurement of two points that are a given distance at seal level is not directly tied to latitude... Of course, the difference in longitudinal measurements is mathematically relatable to latitude....but that is something completely different than what is written.

  • NoKul (unregistered)

    Also, some parts of Germany are in 25833.

  • Oliver Jones (github)

    If this code had been deployed in the USA, it would have never worked. Each state has one or more of its own coordinate projection systems, known as State Plane systems. Regions having north-south orientation use transverse Mercator systems. They basically project the earth onto a piece of tape wrapped around it from pole to pole.

    Regions with east-west orientation use Lambert conformal conic projections. (They're useful because great circle routes are straight lines). And when you cross a state line or the boundary between regions, the coordinates shift dramatically. But the number of digits in the coordinates don't always shift.

    https://en.wikipedia.org/wiki/State_Plane_Coordinate_System

  • DutchGeoGuy (unregistered)

    Is it realistic that someone would make a coordinate system that ranges between 100,000 and 999,999 and never leaves that range? Of course not.

    Ehm... that is wrong. For localized national coordinate reference systems, such constraints are actually common. The one I know best is EPSG:28992, and it does exactly what you say. In that (projected) coordinate system, the Y-Ordinate will always be a larger value than the X-Ordinate, and their ranges are between 300000-625000 and 0-280000 respectively. The definition of the 0,0 location has been shifted on purpose so the above constraints would always be true for the EU Netherlands. Originally this was done to benefit manual calculations, every coordinate would always be a positive value, and X and Y could easily be distinguished. So not only could it be realistic, it's actually (granted, with different values) in use (and has been for a long time).

  • Jim Jam (unregistered)

    God bless Gauss–Krüger coordinate system where you know (almost for sure) which zone you are operating with just by glancing at first digits of X coordinate. Most of the other CSs I used to deal with were by far more ambiguous.

  • (nodebb) in reply to Oliver Jones

    If this code had been deployed in the USA, it would have never worked. Each state has one or more of its own coordinate projection systems, known as State Plane systems. Regions having north-south orientation use transverse Mercator systems. They basically project the earth onto a piece of tape wrapped around it from pole to pole.

    Yes, sounds like my place of work. Everyone looks at a small dataset and decides that everything is simple and every operation is reversible. Then, instead of doing two extra minutes of work and storing the needed metadata, they justify that we don't need to because we can "always figure it out". This includes situations where we (should) know the answer, like the fact that you can't decompose a full name into parts reliably, or that you can't reverse an uppercased string, or that you can't infer a time zone.

    So, we save the two minutes of up front work. Then, we end up needing to create sixty thousand two minute workarounds for the problems that come up. Eventually, we get into a situation where there is no way to go forward other than to start over from a better base.

  • (nodebb)

    Haha, this is the EPSG version of someone not using UTC for timestamps. Ah, the classic mistake and it always begins with someone not reading the manual or standard but look at a limited set of numbers and makes conclusions.

    Plus this seems to be C# and it really hurts that they don't use the highly optimized value Math.Log10() which ends up to be six CPU cycles (2 extra for the double to int conversation) vs the dozens wasted on the iteration plus the boilerplate setup.

  • xtal256 (unregistered) in reply to Jaime

    I've lost count of the number of times I've seen that happen.

  • (nodebb) in reply to MaxiTB

    The equivalent of using UTC for all timestamps would be to first convert all co-ordinates into the one system before passing them around. What they've done here is the equivalent of not storing the timezone information with the data. At least (I hope) co-ordinates for one system don't refer to different locations 6 months out of every year, in some places.

  • (nodebb) in reply to MaxiTB

    You'd need to be careful / give more than two seconds' thought about how to use Math.Log10(x) to get the right answer, and I'm not sure the original author would have done that. Log10(100) is 2, but it's three digits. You have to use (int)Math.Log10(x) + 1. You could also use (int)Math.Log10(x * 10).

    Not sure how you'd handle any systems (should they exist) which put co-ordinates as values between 0 and 1, but then again, this was entirely the wrong approach to the problem to begin with.

  • MaxiTB (unregistered) in reply to prueg

    You are 100% correct I forgot the increment. The additional inc is another additional CPU cycle.

  • MaxiTB (unregistered) in reply to prueg

    Yeah, that is my point. In persostent storage you should one unit system and if you merge two former independent one you merge to one. Only on the presentation/export areas you should convert to various systems and for import you do it reverse where you usually have tons of validations & unit testing anyway. The whole rest of the business logic can happily use the same system. In return you don't get billion dollar unit convertion mistakes spread across your code base, inconsistent data in your presistent storage and you save a ton of performance on convertion before each operation you want to do with the data. And the beauty is it doesn't matter which system you are using as long as it is consistent. Obviously for some the choice is super easy, the metric system is used by everyone in the world, UTC is another example when it comes to time, other systems are obviously more fragmented and it always best to either pick the globally most common one if there isnt an international standard or otherwise the one that covers all your business needs (and if they are 100% the same, its time to undust the D20).

  • MaxiTB (unregistered) in reply to prueg

    Wah, I forgot Unicode. I guess these days young devs in the age of UTF-8 would consider using code pages something only a crazy person would do and rightfully so. It was a crazy mess back then :-)

  • TheCPUWizard (unregistered)

    @MaxiTB -- I am still working with MBCS <grin/groan>

  • (nodebb) in reply to Oliver Jones

    Regions with east-west orientation use Lambert conformal conic projections. (They're useful because great circle routes are straight lines).

    That means they're (parts of) a stereographic projection. Those are wonderful provided you don't need too much of the globe at once.

  • (nodebb) in reply to LCrawford

    Pretty sure the frist comment was not entirely serious. Apart from the "Amirite", any function that converts a number into a string representation in base 10, is going to be doing something very similar to that while loop.

  • (nodebb)

    For everybody who is saying just use Math.Log10 as an alternative, I remind you that floating point is not accurate for such tasks. In JavaScript you have these beautiful results.

    Math.log10(1_000_000_000_000_000) = 15

    Math.log10( 999_999_999_999_999) = 15

  • MaxiTB (unregistered) in reply to David Koblas

    That's JavaScript, it is just a scripting language and is not designed for type safe operations. In C# you had a build in high precision floating point type called decimal which would work fine in your example (which is way beyond what the article was about anyway and would never occur with the int used in the example).

  • Officer Johnny Holzkopf (unregistered)
    Comment held for moderation.
  • eric bloedow (unregistered)
    Comment held for moderation.

Leave a comment on “Projection Your Failures”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article