• John (unregistered)

    Probably a bad example as 10.5 is a number that is exactly representable in standard floating point representations.

  • my name is missing (unregistered)

    Doing math with floating point representations of money makes you lose what little cents you had to start with,

  • (nodebb)

    Yeah, working for doctors. It's difficult enough when you're doing stuff where they're expert. It's even worse when you do stuff where they THINK they're expert and they aren't. Dunning - Kruger effect. If you interview for a job working for a doctor try to get a sense of that. Maybe you should directly ask, "how do you handle technical advice from programmers? If I have such advice, what's the best way to present it?"

    If the answer is "I'm always right," run, don't walk, away from the job.

  • Avris (unregistered)

    To be the devil's advocate: PHP does have a good packaging system, and right now the best practice is to use one of those packages that implements the integer mathematics approach: https://packagist.org/packages/moneyphp/money

  • (nodebb)

    Do you think we can get Congress to outlaw PHP?

  • Little Bobby Tables (unregistered)

    "The other programmers won't understand this!" the boss cried. "It's too complicated. Why are you changing it? It works, just leave it alone!"

    ... and that's the point where I will be dusting off my CV again.

  • bvs23bkv33 (unregistered)

    everyone can put together extensive, well-architected applications in their sleep — but morning allways comes

  • Christof (unregistered)

    "it's actually fairly difficult to include external libraries in PHP"

    Yeah... No, it's not.

  • Brandon (unregistered)

    To be fair, i have worked with plenty of degreed programmers who barely grasp the basics.

  • Brian (unregistered)

    Oh, the joys of floating-point money. I used to work for a fintech startup, which meant not only dealing with their own money but with other people's as well. And of course all the math was floating-point (double precision, but still...). I suggested converting to fixed-point math instead, but the answer I got was that it's not important because the numbers we're dealing with are small enough. Guess it's a good thing they folded before the customer base scaled up enough to start using big numbers.

  • (nodebb)
  • (nodebb)

    Held for moderation because I did links? Sigh. Just search "PHP decimal" like I did.

  • Dave (unregistered) in reply to OllieJones

    Ffs, the DK effect is a joke. Originally it was just about a statement of the completely obvious - 'the wise man is he who knows how little he knows' - but now part of the joke is when people display DK behaviour by citing it as if it was a serious paper.

  • Scott (unregistered) in reply to Little Bobby Tables

    While we have to be careful not to over-architect and solve problems which don't actually exist, this is not one of those cases.

    It gets me down when people obstinately refuse to move forward, especially when the technology being introduced is totally standard and long-term stable. If the other developers don't understand it, hire smarter people and/or mentor the ones who show an interest in coming into the late 20th century.

  • Brian Boorman (google)

    Just take the fractions of a penny and send them to an offshore account. It's not stealing - it's like the "give a penny / take a penny" tray at the gas station. They're just pennies for everyone.

  • Kleyguerth (github) in reply to OllieJones

    I submitted this story (I checked the "use my real name", but they didn't, meh). The boss in this case wasn't the doctor, the doctor was the CEO, but the company has grown and he hired technical managers... The guy who said that gem about PHP not knowing how to "sum strings" has a developer background, worked some decades in COBOL before moving to that company.

    So his "I'm always right" was more like "I'm the senior guy, I know more than everyone below me"

  • Vilx- (unregistered)

    I second the use of fixed point (aka multiply by 100 and work in cents). However, if you know what you're doing, it is technically possible to make it with a floating point. You just need to put round()s in all the right places and make sure you're storing ALL of the floating point, not just truncated two decimal digits. Very easy to mess up though.

  • Kleyguerth (github) in reply to Brian Boorman

    Considering this happened in a country that has a very corrupt government, that would probably be a feature if we were working directly for the government. But the system was to prevent public-private partnership companies from stealing FROM the government.

  • Groz (unregistered)

    There are a number of gotchas that trip up new programmers:

    There are three things hard in Computer Science:

    • Dates
    • Naming things
    • Cache invalidation
    • Off-by-one errors
  • P (unregistered)

    There's always the bcmath extension. :-)

  • (nodebb) in reply to Groz

    There are three things hard in Computer Science:

    Dates Naming things Cache invalidation Off-by-one errors

    You forgot to list Scope Creep, though that's more of a thing in Software Engineering…

  • Alchemist (unregistered) in reply to bvs23bkv33

    Actually, one of the easiest ways to tell when you're dreaming is that technology usually doesn't work properly in dreams. It will appear to work right from a distance, like if you see a computer from across a room in a dream, the screensaver may be running, or an application will be running, but once you try to interact with it, everything goes cattywampus.

  • Ducky (unregistered) in reply to Vilx-

    No... With floating points, you'll always get precision errors. You can minimize it by adding all "similarly scaled" numbers together first, in order to lose as little as possible, but it's not possible to avoid it completely. Remember: Floating point is implemented by <integer> x <scale>, so you only get a fixed number of "significant" digits to work with.

    If you add a number whose scale is significantly bigger than the other one, you lose the digits for the smaller number.

  • Little Bobby Tables (unregistered) in reply to Kleyguerth

    Yep, that's the UK all right.

  • Alex K. (unregistered) in reply to Dave

    "Ffs, the DK effect is a joke... part of the joke is when people display DK behaviour by citing it as if it was a serious paper." -- Yes, this is a serious paper. Psychologists David Dunning and Justin Kruger (the two halves of "Dunning-Kruger") reported in various journals in 1999 (Journal of Personality and Social Psychology), 2003 (Current Directions in Psychological Science), and 2008 (Organizational Behavior and Human Decision Processes), found individuals with the lowest level of measured competence at a task would typically greatly over-estimate their performance before hand.

    A lot of psychological research has centered around confirming (or dis-confirming) "folk knowledge" of the sort you seem to believe Dunning-Kruger remains. However, self-assessment of competence must be derived from the standards of performance for an action; someone so unskilled in a task that even how to measure performance is unknown will be unable to estimate their own future performance. As stated by David Dunning himself, "The skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is." In this case, the aphorisms about wisdom and ignorance contained a nugget of truth--which we named after the scientists who confirmed it.

  • (nodebb) in reply to Brian Boorman

    Thank you for the "Office Space" reference

    For that - you get my "O" face. ;-)

  • SplatmanDeux (unregistered) in reply to Groz

    Maybe this goes with dates, but timezones... Oh god, timezones https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time

  • Hartmut Holzgraefe (unregistered)

    PHP has quite a few issues, but this one isn't really one of them.

    The bcmath extension has been bundled with the core code ever since PHP 4.0.4


  • Quirkafleeg (unregistered)

    "The other programmers won't understand this!" the boss cried. "It's too complicated. Why are you changing it? It works, just leave it alone!"


    "I don't understand this!" the boss thought. "It's too complicated. Why are you changing it? What I wrote 15 years ago is good enough, just leave it alone!"

  • Karl Bielefeldt (github) in reply to Quirkafleeg

    That's most likely, but without actually seeing the code changes in question, it's also quite possible to be a case of, "I learned about design patterns in school and now all the code needs my design pattern hammer."

  • Hasseman (unregistered) in reply to SplatmanDeux

    Yep, Date time and time zones are fun when you need computing dates and times from different time zones from the past. Riyadh had a difference by 3h07m for a few years in the 1980's. Line them up around the world has it's issues ...

  • (nodebb)

    Back in the 80s I ran into a floating point precision loss issue with an assignment the class had been given. (I was a lab assistant there, knowledgeable enough that I could answer their technical questions and a lot more available than the teacher.) Eventually I figured out that the teacher hadn't taught them anything about the limits of floating point and gave a problem with two basic solutions. Do it the lazy way and the errors would cancel out and it would work. Do it in the intelligent way and they wouldn't cancel and they were faced with a bug that was beyond their knowledge.

    The fallout of this was my astounding the whole department with 10 X = 3000000 20 X = X + 1 30 IF X + 1 > X GOTO 20 40 Print "X = X + 1"

    Everyone believed that would never terminate. Given the system in question the seed on line 10 made it run long enough to talk about it for a bit before the precision loss caused it to break out of the loop.

  • Perri Nelson (unregistered) in reply to Mr. TA

    A bad programmer can produce a WFT in any language. This is sort of like saying a good programmer can write PHP in any language. A bad programmer can write PHP in any language.

  • Gumpy_Gus (unregistered) in reply to Kleyguerth

    Well then, the COBOL guy is halfway right, COBOL is the only language I can think of that lets you add BCD fields. Which causes some amusing side-effects if the field has "overpunched" minus signs. Or at least that's what I recall from one horrid COBOL class, 40+ years ago.

  • dusoft (unregistered)

    concatinate = concatenate frist!

    There is composer for packaging, widely used, although not built-in.

    I don't think this has to do anything with the PHP representing numbers internally rather than a bug in the code. I have never see error in such a basic operation as summing or adding.

  • (nodebb) in reply to Gumpy_Gus

    Java BigDecimal class does BCD equivalent.

  • (nodebb)

    Money? Floating point? No problem. Use an IBM 1620. Works like a charm.

    Oh, you want a modern machine. Sorry doesn't work that well. I tried it once and when things went into the 1000's of $$, it all broke down. I did some fancy tap dancing and double precision (REAL*8) to get my thing to work.

    Yes, don't try this at home!

    Addendum 2019-02-20 23:40: Or work!!

  • Kleyguerth (github) in reply to dusoft

    It is about floating points, any language would show the same exact bug if you use floating points while expecting exact results. Try doing "0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1+ 0.1" with floats (not doubles) in any language. The result will not be 0.8.

    So is the problem how PHP represents numbers internally? Yes and no. It uses floats, but most languages do, the problem is a programmer using floats to do operations that are meant to be exact

  • Kleyguerth (github) in reply to Karl Bielefeldt

    The editor added that "design pattern" part, I didn't change existing code, I was doing a new page, with new features, and instead of adding stuff to the "God Object" they had, I made different classes for the different stuff I needed. Had to undo all that and just add the same functions I had in different classes to the god object, but prefixing them with whatever context they were meant to be used.

    At least they had code reviews I guess

  • Wumpusarama (unregistered) in reply to Alchemist

    That's weird. In my nightmares, the technology always works perfectly, and the users are completely sane. That what makes it a nightmare.

  • dusoft (unregistered) in reply to Kleyguerth

    Thanks for the explanation.

  • Dave (unregistered) in reply to Alchemist

    Dreams are best explained as a series of isolated images, which your brain (in dream state) tries to treat the same way it normally treats reality. That's not inconsistent with your observation.

  • Angela Anuszewski (google) in reply to Brian Boorman

    Perfect comment - happy 20th birthday, Office Space.

  • Adzy (unregistered)

    To be fair, Excel had or still has a floating point accuracy bugs as well as the infamous 65,535==100,000 issue (and that product is practically dedicated to dealing with money).

    JavaScript is even worse, as there is NO integer type at all. All numbers are 64 bit floating point numbers, so when you have source data that uses 64bit integer identifiers which actually use all the address space, these are sometimes rounded up or down, so you need to be careful to ensure they are handled as strings. As an added bonus you get cool little artefacts like -0 (which is not the same as zero).

  • Ben (unregistered)

    Integer or floating point expressions can cause exceptions (overflow, underflow, sqrt of a negate number, log of a negative number, etc...). Code like your mother's pacemaker depends on your app.

  • Martin Tilsted (unregistered) in reply to Alex K.

    I think the best way to illustrate the "Dunning-Kruger" effect is to look at the "X got talent" shows, or other tv shows where the people are there to sing. (Or just your local Karaoke bar)

    Most of the people who sing really bad, have know idea about how bad they sound, and how far off they are from even having a chance of sounding decent because they are tone deaf.

  • harrywwc (unregistered)

    many moons ago, when I was a trainee programmer (back in the days of "EDP"), I was shown two reports from two different systems that have a difference (over 10million dollars - a lot of money back then) of 2 cents.

    I was asked to find: a - which one was the actual correct value b - where the "wrong" report was getting its values and c - what needed to be done to make the two reports reconcile

    Now most of you know where this is going already ;) But as a trainee with all of about 6 weeks training (in COBOL) under my belt, and one of the systems written almost entirely in Fortran77, it was going to take me a while.

    Two weeks solid trawling through the two sets of code, and I came up with the solution, the code changes, the file changes, and the resulting code changes required from that, and booked a meeting with my supervisor and his manager.

    I laid it all out, with an estimate of the amount of effort required to make the changes and test them. The Fortran system was using floating points, and the COBOL system was using integer with assumed (V) decimal point. The Fortan system needed to be modified.

    They both laughed!

    They asked if I had learned anything? And I replied that using lots of maths, even simple addition and subtraction, on lots of floating points eventually led to rounding errors.

    So, I asked when we were going to change the Fortran system - and they laughed again.

    Apparently they had written off the 2cents months ago (I'd not really looked at the date the reports were generated), and kept the reports as a "training exercise" for their newbies.

    I learned some valuable lessons that day: floating points storing money values can be a pita; bosses can be like floating points. :)

  • Robert (unregistered) in reply to Groz

    What's so hard about dates?

    Begin by writing isLeapYear(y). Then write a daysInMonth(y,m) that calls it. Then write a dayOfYear(y,m,d) that calls that. Then count days since an epoch by counting completed leap years since that epoch, then adding 365 times the number of completed years since that epoch, then adding the result of dayOfYear() for the given date, then subtracting 1 to avoid an off-by-one error. This assumes that your epoch is January 1 of some year. If it isn't, then do the calculations using a January 1 epoch, then add or subtract a constant.

    Time zones, though, are something else. And Daylight Saving Time... the less said about that, the better.

  • Smikth (unregistered) in reply to Gumpy_Gus

    SQL also has BCD arithmetic. Seriously, it's there people - and used all the time!

    For SQL Server, decimal(..) and numeric(..) types are BCD.

    However, the 'money' (and 'smallmoney') types, at least in SQL Server, are actually fixed-point arithmetic, not BCD. (Dead obvious when the four-byte 'smallmoney' range is -214,748.3648 to 214,748.3647 (- (2^32 /2) through to ((2^32 /2) -1), divided by 10000 decimal).

    (for completeness, int and family are simple signed integers, and float and double are true floating point types.)

  • andrew (unregistered) in reply to harrywwc

    Fortran variables beginning with I, J, K, L, M or N are always integer. (Unless your system is 4k Fortran, in which case the variable names are only one letter long, but the same letters indicate integers).

    What do I do with with the Capcha if I am a robot?

Leave a comment on “What's The Floating Point?”

Log In or post as a guest

Replying to comment #503646:

« Return to Article