I answered too quickly. Thanks for your diagnostic example. So what do we think? Should Maxima should try to normalize -0.0 to 0.0 so that atan2(0.0,-1.0)=atan2(-0.0,1.0)? What about bfloats? Bfloats don't have a negative zero, but atan2(0.0b0,-1.0b0) gives -3.14...
Kris, thanks for checking. I should have mentioned in my original note that I was running on SBCL on Mac, but I don't know what version of Maxima (failure in basic bug reporting hygiene!). As I said, I didn't find any problems in SBCL, but we might want to add some test cases to ensure that all this works across implementations. My current installation (5.49 on SBCL 2.6.0 on WIndows 11) actually gives {0.0,-0.0} => {0.0}, but I couldn't find any anomalies with set operations, where 0.0 is treated...
Barton's new-time-info is much better. "SEC" is just redundant noise. Rounding to three digits is sensible.
Same in the slightly older release Maxima 5.48.1 SBCL 2.5.7
That isn't correct because, for example, cc: sin(%pi - %i * log(sqrt(2) + 1)) => %i, so abs(cc)=1. Use this to simplify to %i: ratsimp(exponentialize(cc)) => %i
(I am still having trouble posting to the Sourceforge bug) How is Maxima supposed to know that 2.1 is intended to represent the rational 21/10? After all, its actual value is 21/10+1/(2^515), and it may have been the result of some long calculation, not from the input string "2.1". The exact, mathematically correct value of mod(10^100,2.1) is actually float(mod(10^100,rationalize(2.1))) = 1.43... By using rationalize*, we're using the exact rational value of 2.1. Large numbers aren't even necessary...
For some reason, sourceforge is unresponsive although other sites are fine (I'm on airplane wifi). Anyway, I think what Pellegrini is looking for is float(mod(10^100,rat(2.1))). Having mod automagically use bfloat or rat arithmetic for bignum args would suggest that we do the same thing for all float arithmetic, which we're clearly not going to do. We could introduce an "exact float" type, say 123.45x01, which would denote the rational 1234/10. But what is sqrt(123.45x01) or sin(3.14x0)?
Floating point arithmetic is "contagious". That is, mod(10^100,2.1) is equivalent to mod(float(10^100),2.1). But neither 10^100 nor 2.1 is represented exactly as a floating point number: rationalize(float(10^100))-10^100 => ~10^83 rationalize(2.1)-21/10 => ~10^-16. To get an exact answer, use mod(10^100,21/10) => 19/10. Note that rationalize converts a floating point number to the exact rational it represents, e.g., rationalize(0.1) => 3602879701896397/36028797018963968 and rationalize(0.1)-1/10...