Awesome, let's talk about floating point semantics. There are two main kinds, that I can see.
One is "ordinary person" semantics, the other is IEEE-like semantics. Ordinary-person semantics is what you learned in grade school. In grade school, suppose we want to add 1.1 to 2.8324, using pencil & paper. Here's what we do: 1.1000 + 2.8324 -------------- = 3.9324 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". IEEE-like semantics is a bit different. There, the interpretation of "1.1" is something like: 1.1000000 * 10^0 where the digits in the mantissa beyond the shown ones are unspecified and the general expectation is that for real-world quantities coming from physical measurements, those digits will be random-ish, especially once you get past the first unspecified one. Ok, so when a user enters the expression 2*1.1 into Sage, which semantics do they want? I claim that almost every user entering that expression wants the ordinary-person semantics, where 1.1 is a shorthand for 1.10000000... =11/10, exactly. I claim those users continue to want the ordinary-person semantics even in expressions with transcendental quantities like e or pi. When they type e^1.1, they expect the 1.1 to be exactly 11/10, and if they ask for the value of e^1.1 to 500 decimal places, they expect every digit given to be correct. I claim those users continue to want the ordinary-person semantics even in expressions where some other quantity has an inexact IEEE-type floating point value coming from a physical measurement, eg x=3.437621 * 10^-8. When they type 1.1*x, they are thinking of the 1.1 as exactly 11/10, but they also know the value of 1.1*x will be in IEEE floating point because x is, and of course the answer should be in the less precise format. To meet the semantic expectations of the vast majority of users (I would guess well over 99%), Sage should interpret float literals using ordinary-person semantics, ie as rationals. 1.1 should mean 11/10, unless the user wants to override that by explicitly requesting the value to be an IEEE float or some other kind of float. This is not some fancy technical issue, it's just common sense. Remember that a big chunk of your users are beginners or students. The default behavior of Sage should be designed for them, not for experts. Experts can easily override default behavior to get whatever they want; beginners or students don't know how to do that, so the default semantics should be exactly what *they* expect. Wolfram Alpha also has beginners and students as a big chunk of its user base, and they get the default semantics exactly right. If you enter "100 digits of 1.1" into Alpha, the answer is the list [1,1,0,0,0,...,0], all zeros after the 1,1. That's the ordinary-person semantics. i'm going to quote your own marketing materials back at you: from: https://www.sagemath.org/library-stories.html "Success Stories and Testimonials" "SAGE is doing remarkably well at keeping a balance between ease-of-use for beginners and high-end users. -David Kohel, 2008-11-03" RealField is not doing this well. When a beginner wants to know e^1.1 to many decimal places, they enter something like this: RealField(200)(e^1.1) and they get this: 3.0041660239464333947978502692421898245811462402343750000000 where everything past the 16th digit is junk, crap, nonsense, not true. Why aren't you embarrassed that for years you've been giving beginners and students these junk digits, looking for all the world as if they are the right ones? Those people put their trust in you to always give them the right answer, and here you are betraying that trust. You don't need to change the semantics for your IEEE-type floats. You just need to acknowledge and respect the ordinary-person semantics for strings like "1.1" that users type in themselves. One way to do that would be to adjust the pre-processing of Sage args to represent float literals like 1.1 as rationals like 11/10, unless overridden by the user. I have a lot more to say on this topic, but for now I'll end there. -aw On Saturday, April 15, 2023 at 5:57:20 PM UTC-6 William Stein wrote: > On Sat, Apr 15, 2023 at 4:25 PM Michael Orlitzky <mic...@orlitzky.com> > wrote: > > > > On Sat, 2023-04-15 at 18:20 -0400, David Roe wrote: > > > I agree with William that you should refrain from insulting the Sage > > > developers, especially when the underlying problem comes from your > > > misunderstanding of how floating point arithmetic works. > > > > I was given this response many times, and I think it's condescending > > (no offense). > > I agree with you that it's best to assume that the original poster "aw" > does > understand the semantics of floating point numbers in Sage, and just > doesn't > like them. I think you also understand the semantics of floating point in > Sage as well, and you also don't like them. > > We are definitely not changing these semantics. If you have questions about > how to use Sage's various floating point models as they are to solve > problems, > we would be happy to answer them. However, insulting the sage developers > and demanding that the semantics change is not appropriate for this > mailing list. > Such comments would be appropriate and welcome at > > https://groups.google.com/g/sage-flame > > -- William > > > -- > William (http://wstein.org) > -- 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/13b268f5-e2aa-400d-9d7f-3345ecbef836n%40googlegroups.com.
