[Maxima-bugs] [maxima:bugs] #4642 sign(1.0e-310*%i) gives error because 1e-310*x/1e-310 fails

[Barton W. <wil...@us...>]

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.