*PTSD kicks in* Hello darkness, my old friend... :')

At least after 5 years, this time it took me only few seconds, to locate the source of the problem, and fix it.

PS: fuck you javascript... STILL. FUCK. YOU!!!

Cmon, everyone knows you don’t work with floats in JS, unless you really know what you’re doing

Is that a real console ss ???!!
Why only on .14 ??

@MadMadMadMrMim http://adripofjavascript.com/blog/...

Wait what ! If that real its fucking idiots !

@jak645 No, it’s an official Standard which many other languages are also using. :)

@figoore that css doesn’t scale very well.. besides the actual problem ;p

@petergriffin yeah, aggree... that looks like tomorrow me's problem

I had something like this with java's double

That has nothing to do with JavaScript. This is a limitation of storing floating point numbers in binary.

binary numbers are represented as a sum of fractions. this is defined by the IEEE754 standard.

I will provide a simplified explanation of why you can't essentially get 0.14 exactly:

for example, you can represent the numbers 0 and 0.5 with a single bit

0 = nothing = 0

1 = 1 / (2^1) = 0.5

by adding more bits, you can represent more numbers!

00 = nothing = 0

10 = 1 / (2^1) = 0.5

01 = 1 / (2^2) = 0.25

11 = 1 / (2^1) + 1 / (2^2) = 0.75

so with 2 bits, we can represent whole 4 floating-point numbers!... but notice... that's not all of them!. you can keep adding bits and floating points are represented with 23 bits (the other 9 are reserved for the integer part and sign)

that's a whole lot of fractions you can represent with 23 bits! 8388608 to be precise... and 0.14 isn't one of them! but 0.14000000059604644775390625

[Continued]

[Continuation]

just for completion. JavaScript uses 64bit doubles there, not floats. As you can see in my previous comment, 23bits only amount to 0.1400000006!

but a 64bit double has 52bit fraction part, which allows it to go as precise as 0.140000000000000017763568394002504646778106689453125

which is rounded into 14.000000000000002 after multiplied by 100 because the computer is thinking, that the number is significant enough to show to the user in a print now... since you moved by 2 spaces when you multiplied by 100

but you need to keep in mind, that the number in the memory is *always* the long ugly unprecise number... the computer just conveniently ignored it for you when showing it to you.. but if you add 0.14 to 0.14, you're also adding all the fraction parts :)

You know I can’t tell you how familiar this post looks

Disgusting

It amazes me how I still see people shitting on JS for what is an IEEE 754 issue that happens in other languages too.

@amoux kinda is reminds me of asking about making a type of ram sub circuit that could just store shit in base 10 physically to stop dumb crap like this hehe

😵 I will be back in second!

I need to quickly check my last deployment of a feature "which calculates people's balance sheets for taxes"

Yikes!!

brb

@figoore suddenly *madness* for no apparent reason.

It's why I'll convert big decimals to strings, find the index of the peroid, and then slice the string, at say 8 decimal places, and convert back to a float after.

Saves so many headaches.

@Wisecrack nice, my mentees definitely want to know about this 😀
Thanks for the reminder Wisecrack

@figoore hey another option is to convert it to an integer and store it in a variable and then subtract the integer component from the original value and compare the result to some small floating point value depending on how much accuracy you need. If the result is less than or equal to the small floating point value then you can say it's an integer. I forgot what the the accuracy settings in the decimal module are called in the case of python but in any case.

@figoore I cant tell whether this is a genuine comment or tongue-in-cheek. GG figoore.