https://github.com/sagemath/sage/blob/develop/CODE_OF_CONDUCT.md
On Sat, Apr 15, 2023 at 2:39 PM aw <aw.phone.00...@gmail.com> wrote: > > Guys, this is serious. Any dev who starts reading this, give it a hard look, > ok? > > Below I give some examples where Sage give the wrong answer, with no error > message or any indication that the answer is not correct. > > Probably the single most important rule in software is, never ever give users > the wrong answer. > > Either give them the right answer, or give them no answer along with an error > message explaining why the right answer can't be given. > > Why the heck is Sage not following this rule? > > After finding these examples, it's hard for me to trust any answer I get from > Sage, unless I check it against other software, like Wolfram Alpha. > > One possible response to my examples below is, I am not using Sage functions > in an approved way. > > But that's not a valid objection. A user should be able to send any argument > to a function, and it's the responsibility of the programmer to make sure one > of two things happen: > > (a) the user is given the right answer; > or (b) the user is given no answer and an error message. > > Sage is failing to do this. > > On to the examples. > > Example 1, straight from the sage RealField docs: > > RealField(120)(RR(13/10)) > 1.3000000000000000444089209850062616 > > RR has default 53 bits, so this is really: > > RealField(120)(RealField(53)(13/10)) > > Here's the same thing with less precision to make it clear that this has > nothing to do with Python's single or double precision floats: > > RealField(18)(RealField(12)(13/10)) (A) > > What should happen here is this: > RealField(12) should eval 13/10 as 1.30 > RealField(12) should pass to RealField(18) only those digits, 1.30 > RealField(18) should then zero-pad that to 18 bits, yielding 1.3000 > > Here's what sage does: > > RealField(18)(RealField(12)(13/10)) > 1.2998 > > Let's check the types of all args: > > type(13/10) > sage.rings.rational.Rational > > type(18) # type(12) is the same > sage.rings.integer.Integer > > All args to RealField in (A) are Sage types. > Hence everything in the calculation (A) is under the complete control of Sage. > Hence Sage could easily do the right thing here. > > But it doesn't. > > You might say, this is an artificial example, passing the output of one > RealField to another in a non-sanctioned way. > Ok then, let's just pass arguments to one RealField. > Can we get it to give wrong answers? > > Yes, very easily, by passing it an arithmetic expression. > > Sending in arithmetic expressions should be totally fine, because the > RealField docs say: "This is a binding for the MPFR arbitrary-precision > floating point library." > > The purpose of MPFR is to be able to do basic arithmetic in arbitrary > precision. > Basic arithmetic means any expression using the following ops (and maybe some > others): +, -, *, /, ^ > > So let's pass an arithmetic expression to RealField. > The whole point of MPFR is to always give the right answer for the value of > such an expression, for any expression and any requested precision. > The docs say RealField is a binding for MPFR. > So RealField should only give right answers. > But in fact it sometimes gives the wrong answer. > > Here's one: > > RealField(200)(2*1.1) > 2.2000000000000001776356839400250464677810668945312500000000 > > Let's check the types: > > type(2) > <class 'sage.rings.integer.Integer'> > > type(1.1) > <class 'sage.rings.real_mpfr.RealLiteral'> > > type(2*1.1) > <class 'sage.rings.real_mpfr.RealNumber'> > > Here the expression 2*1.1 is not only a Sage type, it's a Sage type designed > to work with MPFR. Hence passing 2*1.1 to RealField should yield the right > answer. > > But it doesn't. > > How the heck was this not noticed earlier? > > I think I have a workaround for expressions such as 2*1.1: enter the 1.1 as a > sage rational, 11/10: > > RealField(200)(2*11/10) > 2.2000000000000000000000000000000000000000000000000000000000 > > That works for this expression, but I worry that with other kinds of > expression I could still get wrong answers. > > By the way, in this example i used numbers where we know the answer in > advance, so it's easy to see that the answer given is wrong. > > Here's a very similar example where we don't know the answer in advance: > > RealField(200)(e^(1.1)) > 3.0041660239464333947978502692421898245811462402343750000000 > > RealField(200)(e^(11/10)) > 3.0041660239464331120584079535886723932826810260162727621298 > > Wolfram Alpha says the second one is correct. > > Let's check the types for the wrong one: > > type(e) > <class 'sage.symbolic.constants_c.E'> > > type(1.1) > <class 'sage.rings.real_mpfr.RealLiteral'> > > type(e^(1.1)) > <class 'sage.rings.real_mpfr.RealNumber'> > > All are sage types, and the expression as a whole is a sage type designed to > work with MPFR. Sage should give the right answer here, but it doesn't. > > I like the idea of Sage. And I know the Sage devs must be solid > professionals. But giving users junk answers makes Sage look bush-league. > > The MPFR devs would never allow their library to give a junk answer. > > Wolfram would never allow Mathematica or Alpha to give a junk answer. > > Why the heck are the Sage devs allowing Sage to give junk answers? > > -aw > > > -- > 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/83acb2d5-5210-4151-b5a1-826cdd6a6d05n%40googlegroups.com. -- 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/CACLE5GBm-_HXym4fA8qBP4YTYCw%2B3ooO4zXPeU2r%3Dfx%3D90Br%2BA%40mail.gmail.com.
