His programming language can't add up 0.2+0.1

>his programming language can't add up 0.2+0.1

Other urls found in this thread:

haskell.org/ghc/
en.wikipedia.org/wiki/Floating_point
gnumeric.org/numerical-issues.html
0.30000000000000004.com/
twitter.com/NSFWRedditGif

>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

What's up with the extra 0.00000000000000004?

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

0.3


non-repl languages need not apply

print(0.2+0.1)

0.3
0.3
0.3
0.3

that's probably how it'll go

$ lua didn't specify what lang this was

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

Thanks.

IEEE754 actually allows base 10 exponents, but usually base 2 is used

>17.2/0.1
171.99999999999997

php > $s = .2 + .1;
php > var_dump($s);
float(0.3)


php 7.0.5

Python with decimal module
0.3000000000000000166533453694

kek.

lmao

perl -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

>His programming language can't add numbers without performance issues

CHICKEN
(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: haskell.org/ghc/ :? for help
Prelude> 0.1 + 0.2
0.30000000000000004

(+ 1/10 2/10)
3/10

>Using inexact numbers

λ 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

...

>not caring about performance

double left = 0.2d;
double right = 0.1d;

(left + right).Dump();
>> 0.3


C# btw

WHAT?

Same in python desu senpai

>ITT: “programmers” who don't understand jackshit about how their computers work

(You)

Even if not exactly .3 shouldn't they have the same error and therefore be equal?

No.

IEEE can't do anything about the fact that a 32 bit float can't represent .1 accurately.

It is accurate though, it's just not exact

Go

package 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?

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.

>mfw

>>> (0.2 + 0.1) == (0.3)
False

>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).

I knew it was the jews

It isn't always the jews lads

that extra 0.00000000000000004 is there just in case you need it

I'll tell you a secret, PI == 3.141592 is false too

WHAT

pi is irrational, 3.141592 is rational
3.141592 == 3141592 / 1000000

Also, 0.99999999.... (periodic 9) is equal to 1, true story

not this meme again

I didn't say anything wrong

>the background looks transparent
>it's just fucking blue
Why would you do this?

not like yours is much better

>shitposting
>on Sup Forums
>in 2016

>tripfag
I shouldn't have trusted his lies

Yeah, my power level isn't high enough to undo that nonsense. Sorry.
If you can make a better copy, please go ahead.

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

Only for small enough n

>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:
>en.wikipedia.org/wiki/Floating_point

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.

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.

...

gnumeric.org/numerical-issues.html

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 Sup Forums. when is Hiroshima going make a consumer tech board so all the shitposters can move out?

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?

You're thinking of fixed point.

Alright, so what's a floating point then? And why in hell is still being used?

a=$(bc

echo $(bc

0.30000000000000004.com/

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);

that image predates yotsuba automatically putting the bgcolor on thumbnails with transparency

>no BASIC
Ree desu senpai

Got you covered user. 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!

What should we do if we must absolutely check that two floating points are equal?

Use a range then. Is your brain that small?

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?"

fabs(a - b) < epsilon

I hope this is a prank

I'd ask you to specify but you visibly have a personality disorder making you unable to be helpful.

That sounds arbitrary and error-prone.

>Refuses to think
>Gets mad

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.

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.

>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.

the only way you can accurately represent that is using a binary coded decimal abstraction.

And who uses that language?

>decimal

congrats you have a BCD type

Python 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
>>>

People who are over the 90's.

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.

Modern businesses making desktop applications.
I'm happily employed using C#.

Wat de fug, lads
Python 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

BCDs are basically just strings anyhow.
In most implementations, anyhow.

when you give decimal a number, it is subject to the same inaccuracies.

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.

0.1, 0.2, 0.3 are stored as floats, not BCD

#include
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

kek
> 0.1M + 0.2M = 0.3M;;
val it : bool = true

>look at how fast I get the wrong answer

>not converting your floats to ints in order to save memory
You would get the correct result too.