>his programming language can't add up0.2+0.1
>>54687006
>his programming language doesn't follow the IEEE floating point standard
~ $ bpython3
bpython version 0.15 on top of Python 3.5.1+ /usr/bin/python3
>>> 0.2+0.1
0.30000000000000004
well
>>54687194
What's up with the extra 0.00000000000000004?
>>54687194
further~ $ perl
print(0.2+0.1)
0.3$ scala
Welcome to Scala version 2.11.6 (OpenJDK 64-Bit Server VM, Java 1.8.0_91).
Type in expressions to have them evaluated.
Type :help for more information.
scala> 0.2+0.1
res0: Double = 0.30000000000000004~ $ php
<?php
print (0.2 + 0.1)
?>
0.3
non-repl languages need not apply
>>54687006print(0.2+0.1)
0.3
0.3
0.3
0.3
that's probably how it'll go
>>54687260$ luadidn't specify what lang this was
>>54687205
floats are not stored as BCD, that number is the closest approximation to 0.3 as you can get
In the other languages posted here, it's probably the case that their interpreter truncates past a certain decimal point, which rounds the result to 0.3
>>54687289
Thanks.
>>54687289
IEEE754 actually allows base 10 exponents, but usually base 2 is used
>>54687006
>17.2/0.1
171.99999999999997
php > $s = .2 + .1;
php > var_dump($s);
float(0.3)
php 7.0.5
>>54687194
>>54687006
Python with decimal module
0.3000000000000000166533453694
kek.
>>54687328
lmaoperl -E 'say 17.2/0.1'
172
> ITT people who do not understand the basic idea of storing floating point numbers
embarassing
instead of printing this shit, you guys need to check if(0.2 + 0.1) == (0.3)
your print statement is probably truncating
>>54687006
>His programming language can't add numbers without performance issues
>>54687822CHICKEN
(c) 2008-2015, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 4.10.0 (rev b259631)
linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
compiled 2015-08-04 on yves.more-magic.net (Linux)
#;1> (= .3 .3)
#t
#;2> (+ .1 .2)
0.3
#;3> (= .3 (+ .1 .2))
#f
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
Prelude> 0.1 + 0.2
0.30000000000000004
(+ 1/10 2/10)
3/10
>Using inexact numbers
>>54687006λ 0.2+0.1 :: Rational
3 % 10
λ 0.2+0.1 :: CReal
0.3
λ 0.2+0.1 :: Double
0.30000000000000004
λ 0.2+0.1 :: Fixed E6
0.300000
λ
numbers sure are hard
>>54687902
>not caring about performance
double left = 0.2d;
double right = 0.1d;
(left + right).Dump();
>> 0.3
C# btw
>>54687959
WHAT?
>>54688065
Same in python desu senpai
>>54688065
>>54688119
>ITT: “programmers” who don't understand jackshit about how their computers work
>>54688130
(You)
>>54687959
Even if not exactly .3 shouldn't they have the same error and therefore be equal?
>>54688170
No.
>>54687017
IEEE can't do anything about the fact that a 32 bit float can't represent .1 accurately.
>>54688208
It is accurate though, it's just not exact
Gopackage main
import "fmt"
func main() {
fmt.Println(.1 + .2)
var a float64 = .1
var b float64 = .2
fmt.Println(a + b)
fmt.Printf("%.54f\n", .1 + .2)
}
/*
Outputs:
0.3
0.30000000000000004
0.299999999999999988897769753748434595763683319091796875
*/
Why does this happen?
>>54688622
Its not a programming language fault. It's the way the processors are built to operate. And the compiler that translates the code to the processor. So basically its intel's fault you cant do that.
>>54687822
>mfw>>> (0.2 + 0.1) == (0.3)
False
>>54688622
>Why does this happen?
The simplest way to explain it is that IEEE floats approximate fractions as a series of powers of two (since computers use a binary number system).
That's why they can encode numbers like 1/2 = 0.5, 1/4 = 0.25 or 1/8 = 0.125 in an exact way, but not 3/10 = 0.3.λ 0.1 + 0.2 == 0.3
False
λ 0.5 + 0.125 == 0.625
True
Note that this is entirely analogous to how humans represent numbers: Except we do it in base 10 instead of base 2. For us, we can perfectly represent something like 3/10 = 0.3 but meanwhile we fail hilariously on something coprime to 10 like 1/3 = 0.3333333333....
Since computer floats have some “fixed length” representation, a base 10 computer would have to cut this off at something like 10 digits (0.3333333333). So you will get “wrong” results such as:
1/3 + 1/3 + 1/3 = 0.999999999 != 1.0
Same thing is happening for the 0.1 + 0.2 == 0.3 test, except we don't “see” the truncation happening because 0.1 and 0.2 happen to be represented cleanly in base 10 (as opposed to base 2).
>>54688698
I knew it was the jews
It isn't always the jews lads
>>54687205
>>54687006
that extra 0.00000000000000004 is there just in case you need it
>>54687959
>>54688065
>>54688170
I'll tell you a secret, PI == 3.141592 is false too
>>54688926
WHAT
>>54688933
pi is irrational, 3.141592 is rational
3.141592 == 3141592 / 1000000
>>54688926
Also, 0.99999999.... (periodic 9) is equal to 1, true story
>>54689058
not this meme again
>>54689074
I didn't say anything wrong
>>54688208
>the background looks transparent
>it's just fucking blue
Why would you do this?
>>54689208
not like yours is much better
>>54689208
>>54689276
>shitposting
>on /g/
>in 2016
>>54689284
>tripfag
I shouldn't have trusted his lies
>>54689276
Yeah, my power level isn't high enough to undo that nonsense. Sorry.
If you can make a better copy, please go ahead.
>>54687818
I don't. Please explain.
Mech engineer here. Is it truncation errors from the way the numbers are stored?
Floating point can only accurately represent sums of fractions 1/2^n
>>54690076
Only for small enough n
>>54689809
>A floating-point number is a rational number, because it can be represented as one integer divided by another (...)
>Whether or not a rational number has a terminating expansion depends on the base. (...)
>For example, the decimal number 0.1 is not representable in binary floating-point of any finite precision; the exact binary representation would have a "1100" sequence continuing endlessly (...)
Source:
>https://en.wikipedia.org/wiki/Floating_point
>>54688170
It's not using decimal. Your number is stored as binary and then read back to you in decimal up from its location in memory.
>>54688155
He's right though.
If you know you're going to need exactly 0.3, you should probably just store ten times the value you need but as an int.
http://www.gnumeric.org/numerical-issues.html
>>54687818
Why do you need a float to store a definite and limited value like 0.3? No float needed.
it always amazes me how many non-programmers are on /g/. when is Hiroshima going make a consumer tech board so all the shitposters can move out?
>>54687289
I'm confused. I thought floating points were just an integer with a point somewhere on it. Like, part of the memory is reserved for the numerical value, and another one for the position of the point.
What the fuck is it doing that would require it to "approximate" a number?
>>54695283
You're thinking of fixed point.
>>54695307
Alright, so what's a floating point then? And why in hell is still being used?
a=$(bc<<<"0.1+0.2")
echo $a
.3
u mad actual-programming-language fags?
>>54695406echo $(bc<<<"0.1+0.2 == 0.3")
1
Shell scripting master race.
>>54687205
http://0.30000000000000004.com/
>>54695326
Floating point data types offer higher precision. Many processors have hardware dedicated specifically to make floating point work faster.
int a = 1;
int b = 2;
int c = a + b;
printf("0.%i + 0.%i = 0.%i", a, b, c);
>>54689208
that image predates yotsuba automatically putting the bgcolor on thumbnails with transparency
>>54695466
>no BASIC
Ree desu senpai
>>54695529
Got you covered anon. I just ran this in QBASIC in DOSBOX:IF .1 + .2 = .3 THEN
PRINT "Yes"
ELSE
PRINT "No"
END IF
You'll never guess the results.
[spoiler]It's "No".[/spoiler]
... and this is why you never use == to check for equality for floating point numbers. Thanks for the reminder!
>>54695613
What should we do if we must absolutely check that two floating points are equal?
>>54695639
Use a range then. Is your brain that small?
>>54695613
I alway compare like this:include RuleOfThumb
int a = 1;
int b = 2;
RuleOfThumb rlOfTh = new RuleOfThumb();
System.out.println( rlOfTh(a+b) ); // output: "about '0.3', I guess?"
>>54695639
fabs(a - b) < epsilon
>>54695692
I hope this is a prank
>>54695686
I'd ask you to specify but you visibly have a personality disorder making you unable to be helpful.
>>54695697
That sounds arbitrary and error-prone.
>>54695733
>Refuses to think
>Gets mad
>>54695639
>>54695697
I wrote a program with a lot of intense calculations that was supposed to neglect duplicates. I typecasted(long double)to(double)in the comparison expression. I figured that would truncate any last-few-bits weirdness. I don't know if this is correct but werks on my machine.
>>54695827
if you just need some limited number of digits of precision (e.g. if you're calculating dollars and cents in a transactional setting and NOT in something that involves interest or whatever), you could just work in pennies and use integers.
basically every programming language is crazy good at working with integers compared to floats and other stuff.
>>54687961
>not building hardware to handle inexact numbers
>all these programming language that don't have a decimal class
Once and for all, C# is master race again.
>>54687006
the only way you can accurately represent that is using a binary coded decimal abstraction.
>>54695890
And who uses that language?
>>54695890
>decimal
congrats you have a BCD typePython 3.5.1+ (default, May 9 2016, 11:00:17)
[GCC 5.3.1 20160429] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> print(Decimal('0.1') + Decimal('0.2'))
0.3
>>> (Decimal('0.1') + Decimal('0.2')) == Decimal('0.3')
True
>>>
>>54696084
People who are over the 90's.
>>54696134
That's the only way you should be storing numbers anyways. Everyone in this thread is wrong for using floating points unless they purposely want to be inaccurate.
>>54696084
Modern businesses making desktop applications.
I'm happily employed using C#.
>>54696134
Wat de fug, ladsPython 2.7.11 |Anaconda 4.0.0 (64-bit)| (default, Feb 16 2016, 09:58:36) [MSC v.1500 64 bit (AMD64)] on win32
>>> from decimal import *
>>> Decimal(0.1)+Decimal(0.2)==Decimal(0.3)
False
>>> Decimal('0.1')+Decimal('0.2')==Decimal('0.3')
True
>>54696425
BCDs are basically just strings anyhow.
In most implementations, anyhow.
when you give decimal a number, it is subject to the same inaccuracies.
>>54696425
I think your compiler is translating the decimal numbers you hardcode into it into floating points If you don't put them between quotes. Hence, 0.1 without quotes is being written into your executable as 0.10000000000000004 or something, then converted to a decimal.
>>54696425
0.1, 0.2, 0.3 are stored as floats, not BCD
#include <stdio.h>
int main(void)
{
float pc = 0.2;
float dc = 0.1;
float pd = dc + pc;
printf("Numbers are %.2f %.2f.\n", pc, dc);
printf("added gets %.2f.\n", pd);
return 0;
}
Microsoft (R) F# Interactive version 14.0.23413.0
Copyright (c) Microsoft Corporation. All Rights Reserved.
For help type #help;;
> 0.1 + 0.2 = 0.3;;
val it : bool = false
>>54695890
kek> 0.1M + 0.2M = 0.3M;;
val it : bool = true
>>54687961
>look at how fast I get the wrong answer
>>54687006
>not converting your floats to ints in order to save memory
You would get the correct result too.
>>(+ 2.0 1.0)
3
we did it reddit
nice thread, today i learned.
wow that was hard
Did I win?
>rust
>mozilla
>>54699221
whoopsie
>human
>programmer
>>54696424
>That's the only way you should be storing numbers anyways.
Topcuck, Microshill probably also thinks C# is the only way you should be programming, Windows is the only OS you should ever use and touch interfaces are sufficient for all of humanity.
>>54697482
>>not converting your floats to ints in order to save memory
>You would get the correct result too.
This is what the fourth variant in >>54687902 does.
Except since it's Haskell, it actually does it without getting in your way syntactically.
>>54699945
Sorry, meant to link to >>54687942
import std.stdio: writeln;
(0.2 + 0.1).writeln;
0.3
eat shit
>>54700022
And of course(0.2 + 0.1 == 0.3).writeln;
true
>>54695466
Go home, Go. You're drunk.
>>54687006
So proud of myself.
>>54687205
It's impossible to perfectly add up numbers.
You've got only 32 or 64 bit so they are always little bit fuzzy
>>54687289
Floats as BCD geez that would be overhead.
>>54688130
You mean python programmers? :^)
This is why /g/ hates python, the following is full of beginner or shitty programmers
>>54700122
senpai can't you read? It's 0.1+0.2 you tard
>Be me
>buy two products: One costing 10 cents, and another costing 20
>mfw i'm getting scammed by .00000000000000004
>mfw no face
Why is this allowed
>>54702087
Floating point invented by jews confirmed
