On Sat, 15 Apr 2023 at 22:39, aw <aw.phone.00...@gmail.com> wrote: > >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.
That is quite a strong requirement. I guess the programmer needs to build a program that ignores what the user actually types in and instead understands what they want some other way (psychically?). That way the user can call any functions with any arguments but the program will always do what the user wanted it to do regardless of what code they entered. Seriously though, floating point is not something where responsibility can be *entirely* outsourced at *any* level. Anyone who wants to use floating point types/routines directly or indirectly needs to have some level of understanding of what the implications are even if that is as basic as just knowing that rounding errors can happen and knowing which operations might be affected by them. Explicitly mixing or converting between precisions as in these examples requires more care and understanding and it is just not possible for the "programmer" to eliminate that responsibility from the "user" altogether. > 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 That is what happens except that it happens in binary rather than decimal floating point. Binary floating point means that 13/10 in RealField(12) is already not exactly 1.3 which is why padding it with zero bits also gives something that is not exactly 1.3. The most accurate representation of 13/10 in RealField(18) is not just a zero-padded version of the result from RealField(12) so the conversion to higher precision does not recover the accuracy that is already lost: sage: RealField(12)(13/10) 1.30 sage: RealField(12)(13/10).as_integer_ratio() (1331, 1024) sage: 1331./1024 1.29980468750000 sage: RealField(18)(RealField(12)(13/10)) 1.2998 sage: RealField(18)(RealField(12)(13/10)).as_integer_ratio() (1331, 1024) Notice as_integer_ratio gives the same result for the number in RealField(18) as in RealField(12). They are both the exact same number but they display differently because the decimal display representation depends on the precision of the field. -- Oscar -- 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/CAHVvXxRjwYBAYRQW8kXHAY5QRO_uUcZjL4n0-tpACfWEjnZrUA%40mail.gmail.com.
