Wolfram seems to excel at so many things, but does anyone actually use it? https://www.wolframalpha.com
Only every high school and college student everywhere.
9999999999999999.0 – 9999999999999998.0
41–50 of 83 posts
Re: 9999999999999999.0 – 9999999999999998.0
#42Wolfram seems to excel at so many things, but does anyone actually use it? https://www.wolframalpha.com
[dead]
Re: 9999999999999999.0 – 9999999999999998.0
#43> That Go uses arbitrary-precision for constant expressions seems dangerous to me. I'm somewhat baffled by this statement. If a Go program compared a constant expression float against a runtime computed float, it could have unexpected results, but comparing floats in general is dangerous. I don't see how this language quirk increases that danger in a meaningful way.
It's one thing if a language outputs one, two, or zero for this expression. Two and zero are mathematically wrong, but at least they're predictable.
It's another thing if a language sometimes outputs two and sometimes outputs one depending on the syntax of the request. This is reasonable where that syntax change is not an explicit cast to double precision or single precision, but dangerous if it uses a behind-the-scenes default of arbitrary precision in compiled literals and a default of FP32 in implicitly typed literal assignments.
Re: 9999999999999999.0 – 9999999999999998.0
#44Wolfram seems to excel at so many things, but does anyone actually use it? https://www.wolframalpha.com
Almost every day for my 5+ years of college, and fairly regularly since (although I encounter the types of complex math problems it excels at far less frequently today). I think there are many others like myself who use it.
Re: 9999999999999999.0 – 9999999999999998.0
#45IEEE754 is always fun. 9007199254740993 is the first integer that cannot be represented as a double precision float. So in python: >>> 9007199254740993.0 9007199254740992.0 What's really surprising is that this number is only ~16 million in single precision floats.
> What's really surprising is that this number is only ~16 million in single precision floats
Half of all floats are in [-1, 1].
Re: 9999999999999999.0 – 9999999999999998.0
#46Wolfram seems to excel at so many things, but does anyone actually use it? https://www.wolframalpha.com
any time you want to do a bunch of unit conversions. I was doing some napkin math comparing Tadej Pogačar on a 1200 W e-bike to him on a gas dirtbike (gas dirtbike smokes e-bikes, btw) and it really helped with all the weights and powers being specified in different units between the two. Not just one conversion but when there are a bunch of steps that can introduce errors.
Re: 9999999999999999.0 – 9999999999999998.0
#47>>> from decimal import Decimal
>>> Decimal("9999999999999999.0") - Decimal("9999999999999998.0")
Decimal('1.0')
Re: 9999999999999999.0 – 9999999999999998.0
#48> That Go uses arbitrary-precision for constant expressions seems dangerous to me. I'm somewhat baffled by this statement. If a Go program compared a constant expression float against a runtime computed float, it could have unexpected results, but comparing floats in general is dangerous. I don't see how this language quirk increases that danger in a meaningful way.
One unexpected consequence is the behavior around negative zero. For example:
var d = -0.0
var d = 0.0
d = -d
Re: 9999999999999999.0 – 9999999999999998.0
#49haskell with default prelude is 2.0. Elm is 2 : Float.
Re: 9999999999999999.0 – 9999999999999998.0
#50The page never explicitly states what the right answer is, but based on the output of their suggested "correct" perl, we can infer that they expect 1. This is just me being idiosyncratic I guess, but if I see a number with a decimal place, I default to interpreting it as an fp64 unless otherwise specified - which yields a "correct" answer of 2.0 (which is not an answer I can get to in my head, admittedly) If the ques…
The pointing finger is not the moon... 1 is the mathematically correct answer, and the floating point behavior is a noisy approximation.