• (nodebb)

    Wait, how "2.5000" correct? It should have been "2.500".

    And does Andy actually know the manager said it? What if the sales manager lied about getting Andy's approval for the change?

    Also, Andy didn't point out (at least from the text of the article) the technical limitation precluding the writing out of the tons to the sales manager. That would be a good argument to use to push back at the request, if Andy had the opinion that the change is not warranted.

  • WTFGuy (unregistered)

    I thought the very last sentence was going to read "... and reached for the nearest bottle of booze".

    I suppose the real point of this story is that ignorant PHBs are at least 40 years old in IT.

  • Foo AKA Fooo (unregistered) in reply to Mr. TA

    Of course, it all was discussed back in 2012. TL/DR, Andy is TRWTF, adding three 0s is BS (European or not), and how they put fractional values in a 16 bit int is just as unexplained as why the editors chose this one of all the articles.

  • (author) in reply to Foo AKA Fooo

    The real reason: I pick classics by hitting "Random" until an article that seems fun pops up.

  • Dvon E. (unregistered) in reply to Remy Porter

    That seems a most reasonable solution. You are a suitable approximation for the average jaded developer who posts here so your selection should work for most of those who might complain, and using random pick will help avoid an ever-decreasing personal list of "stories I can stand to see again." The fun filter also auto-adjusts to guarantee a solution in the available runtime.

  • Nick (unregistered) in reply to Remy Porter

    Ah, “Classic” in the “we’ve seen this before” sense, rather than “This is an archetype of its class and will stand the test of time” sense…

  • (nodebb) in reply to Foo AKA Fooo

    how they put fractional values in a 16 bit int

    To be fair, even in 1982 I'm more worried about them using assembler for reports. Or was that normal at the time?

    For me it sounds like maintaining a legacy code base with odd choices, that may go back to extremely limited resource constraints and/or lack of understanding of maintainability concerns, that really aren't THAT much of a WTF given the year it happened.

  • (nodebb) in reply to R3D3

    The story seems to involve a Commodore PET 4032 used to print invoices back in 82. Assembly seems like a proper choice for that time and the type of machine. Not many compilers were available that could fit the machine's resources and were actually affordable. If a company would have invested in a C/Pascal/Fortran compiler, they would probably not have been using a PET to begin with.

  • Tinkle (unregistered) in reply to Foo AKA Fooo

    They probably had the values stored as floating point = 16 bit mantissa and (probably) 8 bit exponent. When converting to strings they would normalise the exponent to 0 and the mantissa would overflow if greater than 65535.

    Converting floating point numbers to strings is hard.

  • (nodebb) in reply to Ralf

    BASIC was available on a 4032 for free. They could easily have written the invoice printing code in BASIC.

  • (nodebb)

    Integers are exact. Floating point numbers are inexact especially the 24 bit versions with a 16 bit mantissa. That means tha once one value is about 32000 times another, adding or subtracting the smaller value has no effect .. as abused in some rounding based frauds back in the day..

    So the decision to store scaled integers makes sense.

  • (nodebb) in reply to mike_james

    So the decision to store scaled integers makes sense.

    And then comes along hyperinflation and breaks the limits of "cents stored as int64".

    tried to make a point of using dedicated data types over plain integers in a reddit thread, pointing out that there are various use-cases where decimal cents are used (e.g. instantaneous value of a single paper of some investment -- I've seen it with one decimal digit, but apparently some fields use two), so you need a decimal type of some sort.

    When I commented that int64 could be occasionally exceeded by weird accounting hiccups, that, while corrected still need to be recorded, trying to make a point for using some form of "bigint" as underlying datastructure, but thought that it is more of a "better safe than sorry" situation, someone pointed out Zimbabwe's hyperinflation situation, where the inflationg reached a devaluation of the currency by 28 orders of magnitude, exceeding even int64 limits. If it had gone any longer, it would have exceeded even int128 limits.

    Bottom line... If you can write it down as a decimal number, no matter how many digits on either side of the point, it needs to be representable by your currency data type. Anything else is just Dates and Times again.

  • BOFH (unregistered)

    Fixed point math, 16bit "upper" and 16bit "lower" part. It was popular even on 90's when processors with fp were not so common/affordable.

Leave a comment on “Classic WTF: Wordy Invoice”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article