> > It's reasonable to expect that multiplying by one won't cause a viable > alternative to Mathematica et al. to go bonkers. I haven't declared a > float variable, and I haven't type-cast anything to float. The > expression "0.5" is, a priori, quite equal to 1/2. Mathematica knows > it >
I believe you misunderstand Mathematica semantics. Mathematica 12.0.0 Kernel for Mac OS X x86 (64-bit) Copyright 1988-2019 Wolfram Research, Inc. In[1]:= 2*0.5 === 1 Out[1]= False In[2]:= 2*1/2 === 1 Out[2]= True In[3]:= 2*0.5 == 1 Out[3]= True In[4]:= 3004166023946433/10^15 == E^1.1 Out[4]= True Wolfram Alpha also has beginners and students as a big chunk of its user > base, and they get the default semantics exactly right. > Do they? https://www.wolframalpha.com/input?i=100+digits+of+e%5E1.1 https://www.wolframalpha.com/input?i=100+digits+of+e%5E%2811%2F10%29 On Sun, Apr 16, 2023 at 6:45 PM Nils Bruin <nbr...@sfu.ca> wrote: > On Sunday, 16 April 2023 at 14:31:43 UTC-7 aw wrote: > > Awesome, let's talk about floating point semantics. [...] > We zero-pad the 1.1 to whatever length is needed to match the other number. > Because we see 1.1 as a shorthand for 1.1000000000000.... (infinitely > many zeros) > > > That's the ordinary-person semantics of the string "1.1". > > > That's not floating-point semantics. That's just a funny way of writing > 11/10. Those are also not the semantics that scientific calculators use (or > excel for that matter), so I suspect that "ordinary persons" are already > quite used to 1.1 not meaning an exact rational number but a possible > approximation to something quite close to 11/10. In fact, I've seen people > use this as an argument why standard units are more precise than metric: > one would talk about 5/16 in, but that is only approximately 0.79375 cm > (I'm not saying I'm convinced by the argument, but it is a good > illustration that ordinary people are quite aware of rounding errors in > decimal fraction notation) > > The fact that computers often don't use base-10 floating point but base-2 > floating point is a more subtle trap, but once you're realizing that doing > floating point arithmetic quickly leads to not all your digits being > accurate, those difference tend to only be in digits that you shouldn't be > trusting anyway. > > Perhaps you're interested in exploring RealLazyField. It actually attempts > to provide a framework to compute with (some) real numbers exactly. I don't > think it's ready to be the default just yet, if ever. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/03e8ce36-52e5-44b3-986d-984c5ae9ef6fn%40googlegroups.com > <https://groups.google.com/d/msgid/sage-devel/03e8ce36-52e5-44b3-986d-984c5ae9ef6fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x7w-PMFhV3t4Pfz-EKzqEQcTSTMQsMqVZED3ECbTRa5_w%40mail.gmail.com.
