Hello Waldek, , > > And to coerce the Float to OutputForm convert(Float)@String is used. > > But with default settings the bits(n)$Float routine is used to change > > the precision in bits before performing the transformation to a string > > and it uses the mantissa which is for 8.5 (17 . -1) only 5 bits So > > when internal output routines do the string coercion digits() returns > > 1, this explains the rounding done above: > <snip> > > I do not know how that should be solved > > I am not sure what do you want to solve? Suppose that 'float(a, b)' > was purely internal and unavailable to users. Would you consider > behaviour of other functions to be a bug?
Yes, I agree, if it was purely internal that would not cause problems. The main point is that mathematically speaking, not computationally because of hardware limitations, a floating point number in base 2 can have probably an infinity of representations, but the output routine does take into account that. When it use bits/digits to coerce it to OutputForm it assumes its internal way of representing it, apparently, that is, the Float domain always uses the three args constructor and it is not internally similar to what can be done if you use yourself the two args float constructor. So what I consider problematic is: (1) -> mantissa 8.5 (1) 156797324626531188736 (2) -> float(17,-1) (2) 9.0 (3) -> %*2 (3) 17.0 (4) -> mantissa float(17,-1) (4) 17. (5) -> float(34,-2) (5) 9.0 (6) -> %*2 (6) 17.0 (7) -> mantissa float(34,-2) (7) 34 There was an interesting question of someone about bits used for floating point numbers in the flint-devel mailing list: https://groups.google.com/g/flint-devel/c/Qr3YGgQxE2o/m/YDlnWDeRAQAJ?utm_medium=email&utm_source=footer i.e. the number of bits used to store the mantissa for a given floating point number. For example, I would not be surprised if the MPFR library uses 17 as mantissa for 8.5. This is not the way the Float domain constructs floating point numbers, and, again, I agree that the two args float constructor, if it was not public, I would not have seen displayed: 9*2=17 :-) > > > Another point: > > > > It is possible to modify some parameters to Float output routines, > > what about returning the previous settings? For example > > outputSpacing(n) returns Void but if you want to temporarily modify > > this setting, in Spad for example, reverting to the user setting is > > not possible. I attached a proof of concept patch that implements > > this. In fact, even the macro 'separator ==> underscore()$Character' > > could also be parametrable, it is not in this diff though. > > Such change looks desirable. I will apply the patch after fixing > a few formatting issues. Ok, thanks, I think so. Best regards, - Greg. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dbgJ%3DVKjRZO0k4kP9ss%3DkDZYbv4D7gPJZp8K_yejzDCKA%40mail.gmail.com.
