I have a putative fix--it puts a trap near the top of the function `sign1` for the complex
binary64 numbers (including the pure real case). Running the testsuite, it catches about 70,000 cases early--I think that's a win.
Likely it doesn't fix all bugs with the sign of mixed binary64 numbers and symbolic expressions, but I think it's an improvement.
---
**[bugs:#4642] sign(1.0e-310*%i) gives error because 1e-310*x/1e-310 fails**
**Status:** open
**Group:** None
**Labels:** sign splitprod floating point
**Created:** Tue Dec 02, 2025 07:59 PM UTC by Stavros Macrakis
**Last Updated:** Tue Dec 02, 2025 07:59 PM UTC
**Owner:** nobody
As observed in https://sourceforge.net/p/maxima/bugs/4638/#2782:
`sign(1.0e-310*%i)` gives an overflow error.
This comes from `splitprod` trying to remove a common factor using `div`, but
``1e-310*x/1e-310`` => overflow, because 1/1e-310 is not representable.
I tried the quick and dirty hack of replacing ``div`` with ``remove``, but that was never going to work in general....
I don't think we can or should fix ``1e-310*x/1e-310`` -- Maxima's notion that `x/y == x*(1/y)` is too deeply ingrained. But I wonder whether it is worth fixing `splitprod`.
---
Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
