1 == 0,9999999999999999

Comparing floats badly*
Sure smells of newbie coder ITT

>writing expressions that rely on knowing operator priorities without knowing operator priorities.

< and > are comparisons.

>1 == 0,99999999999999999
False.
>1==0.9999....
True.

>1==0.9999....
>True
lol, no it isn't, you stupid nigger

Wrong!
You got a meth degree, and I, the true mathematician got a phd.

It's a byproduct of our notation system. A glitch. A flaw.

The two separate numbers are not actually equal, it's just a necessary calibration to make our system line up with the real world.

What a sad state of this board where people don't know basic math.

Literally everything you said is wrong.

Infinite vs a few nines, I wonder which one can make the full number.

There are two distinct issues going on here, you troglodytes.

1. Never test floats for equality.
2. 0.999... = 1

It's as if you people failed both data structures and real analysis.

is correct.

Hint: the problem is not the operator priority.

>It's as if you people failed both data structures and real analysis
Judging by this thread people here failed primary school. Because that's where fractions are taught.

>1 == 0,9999999999999999
>1 == 0,99999999999999999

hmm weird I just tried this and it gave me syntax errors for both lines

Try;
e=1; s=0.9999999999999999
e=1; s=0.99999999999999999

Hahaha, fucking idiot.

Don't be so hard on them, fractions are taught in fourth grade. The average Jow Forums user hasn't gotten there yet.

Let me guess, you were only pretending to be retarded, so I'm an idiot for believing you?

Feed the trolls.

Attached: check them.jpg (500x499, 114K)

Nah

Remind me again what digit 0.999... ends with?

Okay, now what digit does 1.000... end with?

Notice how those aren't the same? When two numbers aren't the same, it means they aren't the same number. Asymptotic approach does not and never has meant "equals", but again, we have to do that little calibration fix or our notation doesn't work in the real world.

They don't end, can't end.
Opinion=wrong.

>The thing is, with 64 bits you can precisely calculate significantly larger numbers than in the OP's example
large numbers != precision.

Yeah, the "lol" part should've made it clear to you, user.

Name one number between 0.999.... and 1.

If you're right, there should be infinitely many of them, so this should be easy.

>large numbers=precision.
Correct.

And the final digit is still 9 for 0.999..., while the final digit is still 0 for 1.000...

All of the digits are 9 or 0.

And before someone does that 1/3 + 1/3 + 1/3 "proof":
1/3 does not equal 0.333...
We just treat them as equal to, again, make our notation align with the real world.

There isn't one. They're adjacent. Two residences as part of a duplex aren't one residence - it's two residences immediately adjacent to each other.

You can't use the 1.000...
optOut=wrong

>0.333...
33.333... can complete the 99.999...=99

>using a language that can't tell the difference
Looks like you enjoy being a cuck
fn main()
{
let op_penis_size : f32 = 0.1;
println!("Is OP gay? {}",if op_is_a_fag(op_penis_size) {"OP is indeed a fag"}else{"OP is a fag regardless."});
}
fn op_is_a_fag(penis_size:f32)->bool
{
if 0.3 + penis_size == 0.4
{
true
}
else
{
true
}
}

>not using R
Cuck.

>not being a cuck
R

>They're adjacent
Ah, so you did fail real analysis.

I don't see the problem. The computer didn't make a mistake, they're the same number

0.999999999999999 = 0x3FEFFFFFFFFFFFFF

0.9999999999999999 = 0x3FF0000000000000

1.0 = 0x3FF0000000000000

>"priorities", not using the correct term precedence

The proof is like 3 lines you fucking jackass
1/3 = .333...
1/3 * 3 = .333 * 3
1 = .999...

Second line should read
1/3 * 3 = .333... * 3

3 * 1/3 = 0.999...

Yes, also known as 1.

If they are not equal then what's 1-0.9999... equals to? No treating infinities like finite numbers please.

you should read up on what floating point numbers are
they effectively decouple the 'largeness' of a number with their accuracy

kek, go back to school code-monkey