0.1 + 0.2 == 0.3

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

>>59903227

This is why you need fixed point number primitives.

{} + [] != 0

>>59903212
This hurts my head, WHY THE FUCK WOULD ANYONE DO THIS?

>>59903310
Do demonstrate that floats are evil

>>59903227
>goldberg

https://www.destroyallsoftware.com/talks/wat

>>59903384
gold(((berg))))

>>59903212
What's wrong? it makes sense.

File: 1489861258225.png (2KB, 141x32px) Image search: [Google]

2KB, 141x32px

>>59903710

>>59903737
So? that also makes sense.
Never heard of floating point arithmetic? This isn't a javascript only thing.

>>59903754

Name another language which has only floats.

>>59903774
?
What fucking point are you trying to make? now you're just completely moving the goalposts.

d = 0.0001
((0.1 + 0.2 < 0.3+d) + (0.1 + 0.2 > 0.3-d)) == 0

File: js-1.jpg (60KB, 550x370px) Image search: [Google]

60KB, 550x370px

>>59903269
>>59903774
It isn't actually a problem when using integral values, though, since floats can exactly represent those.

It's not like 1 + 2 == 3 returns false in JS.

It's not so hard to find real things to complain about with JavaScript that you have to make a fool out of yourself to. Pic related.

>>59903863
>array() == false is true
?
>"foo" == 0 is true
???

>>59903737

[~]$ js                                                                                                                       
> 1.0 + 2.0 == 3.0
true

seems fine to me

>>59903863

are you sure that table isn't for PHP or some other silly language?

>>59903929
x == false = x !== true ?

>>59903956
>t. either stubid and/or needs glasses

>>59903863
>"foo" == 0
>0 == false
>false != "foo"

wut?

>>59903956
It's only when you do mathematics with floats that can't be represented in binary.

0.1 + 0.2 becomes 0.30000000000000004

>>59903792
>What fucking point are you trying to make?
A floating point.

>>59903863
javascript has === so you can distinguish "1.3" and 1.3

>>59904299
>you need new operator to fix that retardation

File: okay-1.gif (916KB, 245x285px) Image search: [Google]

916KB, 245x285px

>>59904299
So it has a useful operator added on afterwards since == was broken. Great language then, I guess.

>>59904299
True.

And most JS code conventions don't even allow the use of "evil twins", exactly because they are so fucked up.

== is for noobs.
=== is for professionals.

>>59903863

That table has some errors in it.

For example:

$ node
> "1.3" == "1.30"
false
> 

>>59904320
>>59904334

I agree it was a dumb idea.
But at least they fixed it.

File: 1467710122247.jpg (33KB, 294x405px) Image search: [Google]

33KB, 294x405px

>>59904263

File: a.png (64KB, 305x330px) Image search: [Google]

64KB, 305x330px

>>59904337
>=== is for professionals.
>professionals
>javascript

>>59904337
Both are nigger tier, watch this:

if(!(a > b) && !(a < b)){
    console.log("Yes");
}

>>59904320
>>59904334
>>59904337
Have none of you ever made programs before?
It is a clear separation.
Input fields will always be strings, if the user is expected to input a value, you can compare the string to a value, it is not fucking magic.

>>59903212
In class they always taught us to take into account float precision when comparing them. So always doing something like this

eps = 1E-6
if (abs(x-y) <= eps) {
    //do something
}

>>59904416
That's very funny, senpai. Pray tell what kind of comparisons this is useful for that my pitiful self have yet to encounter. Is it when the user is supposed to enter "1.30" as a password, so you can directly compare his input with 1.3 for equality without having to use a string literal?

In the real world where I'm at, if a user is supposed to enter a floating-point value, we'd normally like to actually parse his string input and convert it to a floating-point value and do further processing on that, but I guess checking input validity and such trifles before using a value is a sign of immaturity.

>>59903825
>>59904428
It isn't very good to just assume some epsilon comparison for floating-point equality, though. More often, you should question why you even want to compare floats for equality to begin with; it seldom yields any useful results.

See eg. http://stackoverflow.com/a/77735/134252 for further reading.

>>59904379
It's easy money.
70 to 90 euro's per hour.

>>59904416
I do a lot more than just sanitize input fields.

>>59904481
I don't make webapps, I mainly write C++ and there we use operator overloads all the time.
It is convenient because you can make readable code.

>>59904670
It is difficult to believe that you're overloading the == operator to compare strings and floats directly, though.

>>59904697
I don't personally do that, no.
But javascript is meant for web applications, so maybe there is situations where you need stuff like that.
I don't have much to do with user interfaces in general.

>>59903929
>"foo" == 0 is true
That's a string you idiot

>>59904817
then "0" == "1" is true because they are both strings.
Oh wait, that's not the case

>>59903863
that shit is for php, dumb ass
>http://www.blueshoes.org/en/developer/php_cheat_sheet/

File: shurg.jpg (266KB, 512x512px) Image search: [Google]

266KB, 512x512px

>>59903212

PROGRAM    FLOATYMCFLOATFACE
  IMPLICIT NONE
  WRITE(*,*) 0.1+0.2,  0.3,  0.1+0.2 == 0.3
ENDPROGRAM FLOATYMCFLOATFACE

  0.300000012      0.300000012     T

>>59903956
> uses javascript
Anon...

File: 1489045058607.jpg (49KB, 279x307px) Image search: [Google]

49KB, 279x307px

>>59905039
Dont bully javascript
I will fite you

>>59903774
Traditional BASIC dialects had floats and strings as the only built-in data types. However, a language having ONLY floats is really not relevant, because even in languages like C or Java there are cases when code requires the use of floating-point, even if integer data types are available.

>>59903212

CL-USER> (= (+ 0.1 0.2) 0.3)
T