25

$number = 3000/365*365-3000
echo $number

Output:
4,54747350886E-13

No, Just No. I really like you PHP but thats supposed to be zero. I don't got time for your Tantrum's. I got work to do!

PS: Does anyone know why this happens? Solved it by rounding on 10 decimals but prefer it would just answer 0 instead of me having to force it back.

Comments
  • 5
    in java it gives -80.
  • 1
    @kimailis and with floats?
  • 6
    so write it like this
    (3000/365)*365-3000
    and you will be fine?!
  • 2
    My guess is that it rounds at certain amount of decimals halfway. Which should be solved if you write 3000*365/365-3000 which is the same.
  • 3
    @aronmik without floats, if number declared as int, with floats it gives the same answer the you get. from what i understand it's a screwup with the binary counting system because 3000/365*365 gives 3000.00000000000005 or something like that so it has to be round down. i guess most math engines do the round down or round up like google, it gives 0.
  • 1
    @kimailis Yeah just found it out myself.
  • 2
    @elDeth I even tried this:

    $number = 3000/365;
    echo $number;
    $number = $number*365;
    echo $number;
    $number = $number-3000;
    echo $number;

    Output:
    8,21917808219
    3000
    4,54747350886E-13
  • 2
    @ctrlz That worked :) But formulas are user input. Would have to make a lot of changes to force that or sort that.
  • 2
    In that case just do a round of the result. Should not matter at all. Im guessing you do not need 14 decimals. @aronmik
  • 3
    Just to be sure... you probably know but that E-13 means *10^-13. So this basically is 0.00000000000000456355
  • 2
    @ctrlz Yeah, prob. Maybe the analist don't agree. But then they should find more budget/time for it. But it makes you wonder. Which other code that I wrote has this problem. Before this I did not know this was possible.
  • 2
    @aronmik i definitely understand the confusion. I love php but things like this make it hard to defend everything about it. Although apparently java isnt consistent either. Good luck with it!
  • 2
    learn a bit about the standard used to encode decimal numbers... (double précision floating point)
    It's because of an approximation of representation (we can't represent exactly all the decimal numbers in binary)
  • 3
    I tried with my Android's calculator, it gave 5,00000000E-13...
  • 4
    @Lenka my android calculator result for 3,000÷365×365-3,000 is: 0
  • 4
    @corscheid: your Android is better than mine 🤔
  • 5
    Its based on data types and how computers process those numbers. This same problem exists in most languages.
  • 1
    Idk how mine did that without reproducing the issue. I'm using the default calculator app on the LG G4. *shrug*
  • 1
    neat, it does it on my android and windows also. if you're really concerned about something like this you could use

    round (3000/365*365-3000,10)

    it's dirty but it should work and shouldn't effect any real calculations.
  • 0
    @jckimble I already did That. Like I said in the rant. But thanks for the tip ^^
  • 1
    @aronmik look up IEEE 754 format for floating point numbers. The way they are stored and represented introduces these small errors.
  • 1
    @thmnmlst
  • 1
    Ooh I had already forgot this one :) Dirty round() trick is still doing the trick.
Add Comment