Interesting. The two inputs have different types type(RR(11/10))
<class 'sage.rings.real_mpfr.RealNumber'> type(RR(1.1)) <class 'sage.rings.real_mpfr.RealLiteral'> Then from the documention at https://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_mpfr.html *class *sage.rings.real_mpfr.RealLiteral Bases: RealNumber <https://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_mpfr.html#sage.rings.real_mpfr.RealNumber> Real literals are created in preparsing and provide a way to allow casting into higher precision rings. Shouldn't RR(11/10) have the same fate? Emmanuel El lun, 17 abr 2023 a las 13:13, John Cremona (<john.crem...@gmail.com>) escribió: > Even in the light of the detailed explanations already given, I do find it > hard to see how these outputs are so different: > > sage: RealField(200)(RR(11/10)) > 1.1000000000000000888178419700125232338905334472656250000000 > sage: RealField(200)(RR(1.1)) > 1.1000000000000000000000000000000000000000000000000000000000 > > You can increase 200 to 1000: the second one gives all zeros (hooray!) > while the first one gives those extra digits which are exactly 1/(5 * > 2^51). Both RR(11/10) and RR(1.1) have parent Real Field with 53 bits of > precision, where they compare equal, but pushing them into RealField(200) > gives different results. And the "better" result (all 0s) somes from the > input with the literal 1.1, not from the "rational" input 11/10. To me, > that is mysterious. Can someone explain? > > John > > PS It is a red herring to give examples using the equality relation ==, as > that is a separate issue. In Python == is not even associative. > > On Sat, 15 Apr 2023 at 22:39, 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 >> <https://groups.google.com/d/msgid/sage-devel/83acb2d5-5210-4151-b5a1-826cdd6a6d05n%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/CAD0p0K6weXE%3DrWaAcQ_Z-KAWxOKHpw%2BPU946R0UNjjNSZV9ipg%40mail.gmail.com > <https://groups.google.com/d/msgid/sage-devel/CAD0p0K6weXE%3DrWaAcQ_Z-KAWxOKHpw%2BPU946R0UNjjNSZV9ipg%40mail.gmail.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/CAC2RnLqYFL2wn0b7REPMLG1Kd1XTRJp1LDqFJipMsv1J6-xSNw%40mail.gmail.com.
