maxima-bugs — Reports from the SF bug-tracking system

[Maxima-bugs] [maxima:bugs] #4641 is does not work

[David S. <tom...@us...>]

- **status**: open --> not-a-bug



---

**[bugs:#4641] is does not work**

**Status:** not-a-bug
**Group:** None
**Created:** Mon Dec 01, 2025 04:03 PM UTC by dan hayes
**Last Updated:** Mon Dec 01, 2025 04:10 PM UTC
**Owner:** nobody


build_info()  or bug_report()
"branch_5_44_base_231_g5c411f69f",timestamp="2021-01-12 23:51:42",host="x86_64-w64-mingw32",lisp_name="SBCL",lisp_version="2.0.0",maxima_userdir="C:/Users/zmth1/maxima",maxima_tempdir="C:/Users/zmth1/AppData/Local/Temp",maxima_objdir="C:/Users/zmth1/maxima/binary/branch_5_44_base_231_g5c411f69f/sbcl/2_0_0",maxima_frontend="wxMaxima",maxima_frontend_version="20.12.2-DevelopmentSnapshot_MSW_OpenMP201511+Locks")

(t:matrix([1],[2]),t,t[2],is( t[2]>0));   

and it comes back with unknown



---

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.

[Maxima-bugs] [maxima:bugs] #4638 cabs/carg/polarform overflow and underflow

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

The `carg(1.0E-310 * %i + 1.0E-310)` bug is due in part to a bug in the sign code:
~~~
(%i14) csign(1.0E-310 * %i + 1.0E-310);
1 Call   csign [1.0E-310 %i + 1.0E-310]
Maxima encountered a Lisp error:

 FLOATING-POINT-OVERFLOW detected
performing / on (1.0 1.0E-310)
~~~



---

**[bugs:#4638] cabs/carg/polarform overflow and underflow**

**Status:** open
**Group:** None
**Labels:** cabs carg 
**Created:** Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
**Last Updated:** Mon Dec 01, 2025 06:01 PM UTC
**Owner:** nobody


``cabs`` and ``carg`` on complex floats overflow and underflow even when the result is perfectly representable:
<pre>
cabs(1e-170 + %i*1e-170) => 0.0
but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
cabs(1e170 + %i*1e+170) => overflow
but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
carg(1e170 + %i*1e+170)) => overflow
but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
carg(1e-310 + %i*1e-310) => overflow
but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
polarform(1e170 + %i*1e+170) => overflow
</pre>

Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel


---

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.

[Maxima-bugs] [maxima:bugs] #4638 cabs/carg/polarform overflow and underflow

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

Likely my code should have a trap for re = 0 and im = 0.


---

**[bugs:#4638] cabs/carg/polarform overflow and underflow**

**Status:** open
**Group:** None
**Labels:** cabs carg 
**Created:** Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
**Last Updated:** Mon Dec 01, 2025 05:50 PM UTC
**Owner:** nobody


``cabs`` and ``carg`` on complex floats overflow and underflow even when the result is perfectly representable:
<pre>
cabs(1e-170 + %i*1e-170) => 0.0
but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
cabs(1e170 + %i*1e+170) => overflow
but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
carg(1e170 + %i*1e+170)) => overflow
but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
carg(1e-310 + %i*1e-310) => overflow
but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
polarform(1e170 + %i*1e+170) => overflow
</pre>

Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel


---

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.

[Maxima-bugs] [maxima:bugs] Re: #4638 cabs/carg/polarform overflow and underflow

[Raymond T. <rt...@us...>]

Nice!  Easy to understand and won't overflow unless the result does.  (I think.)


---

**[bugs:#4638] cabs/carg/polarform overflow and underflow**

**Status:** open
**Group:** None
**Labels:** cabs carg 
**Created:** Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
**Last Updated:** Mon Dec 01, 2025 05:49 PM UTC
**Owner:** nobody


``cabs`` and ``carg`` on complex floats overflow and underflow even when the result is perfectly representable:
<pre>
cabs(1e-170 + %i*1e-170) => 0.0
but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
cabs(1e170 + %i*1e+170) => overflow
but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
carg(1e170 + %i*1e+170)) => overflow
but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
carg(1e-310 + %i*1e-310) => overflow
but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
polarform(1e170 + %i*1e+170) => overflow
</pre>

Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel


---

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.

[Maxima-bugs] [maxima:bugs] Re: #4638 cabs/carg/polarform overflow and underflow

[Raymond T. <rt...@us...>]

Your example of `cabs(x+1e200+%i)` is nice and is only a problem if the result is expanded.  I don't have an example off the top of my head that would be a problem.

I'm somewhat opposed to converting to bfloats because we don't do that anywhere else, but I believe people have proposed this before.

I agree that for numeric values we should do a good job.  Matching existing libraries is pretty hard.  Take a look at [fdlibm hypot](https://www.netlib.org/fdlibm/e_hypot.c).  It's fairly complicated and not even correctly rounded.  The ones that do correctly rounded results like [core-math hypot64](https://gitlab.inria.fr/core-math/core-math/-/blob/master/src/binary64/hypot/hypot.c) are even more complicated.

FWIW, several years ago I translated lots of [fdlibm C  routines to Javascript ](https://github.com/rtoy/fdlibm-js) (to get Chrome to fix it's broken trig functions!)  We couldn't really do this in a portable way in Lisp.  We have to figure out for each lisp how to get the actual bits of a float64 out.


---

**[bugs:#4638] cabs/carg/polarform overflow and underflow**

**Status:** open
**Group:** None
**Labels:** cabs carg 
**Created:** Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
**Last Updated:** Mon Dec 01, 2025 05:18 PM UTC
**Owner:** nobody


``cabs`` and ``carg`` on complex floats overflow and underflow even when the result is perfectly representable:
<pre>
cabs(1e-170 + %i*1e-170) => 0.0
but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
cabs(1e170 + %i*1e+170) => overflow
but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
carg(1e170 + %i*1e+170)) => overflow
but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
carg(1e-310 + %i*1e-310) => overflow
but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
polarform(1e170 + %i*1e+170) => overflow
</pre>

Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel


---

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.

[Maxima-bugs] [maxima:bugs] Re: #4638 cabs/carg/polarform overflow and underflow

[Stavros M. <mac...@us...>]

On Mon, Dec 1, 2025 at 11:03 AM Raymond Toy via Maxima-bugs <
max...@li...> wrote:

> Here's one way for doing cabs(x+%i*y), where x is a number. Divide by the
> arg by sqrt(x) to get cabs(sqrt(x)+%i*y/sqrt(x)) = sqrt(y^2/x+x). The
> final answer will be sqrt(x)*sqrt(y^2/x+x). Something similiar if y is a
> number.
>
I don't know how to do this if both x and y are more complicated
> expressions composed of numbers + variables.
>
Can you give some examples? Are you thinking of, say, cabs((x+1e200)+%i)?
That only overflows if you expand the result.... And I agree that basic
*cabs* shouldn't worry about cases like this.

> One alternative is to convert the floats to bfloats if we get an overflow.
> We don't normally do that anywhere else, so this would be very odd.
>
I agree that this would be odd, but maybe we should consider it. After all,
we *do* currently convert floats to rats in some cases. For example,
*keepfloat* doesn't prevent *solve* from rationalizing, so that
*solve(x^2+1e200*x-1)
*doesn't overflow -- it returns rationals. I don't love that behavior, but
generalizing the classic Forsythe paper
<http://i.stanford.edu/pub/cstr/reports/cs/tr/66/40/CS-TR-66-40.pdf> for
the general case of *solve* seems hard....

> I don't think a nounform would be a bad answer, if we printed a warning
> that there would be a potential overflow when computing the result. I
> personally think if a user is doing numerical stuff, it's his responsiblity
> to deal with numerical issues that might arise. We'll be careful to limit
> overflows, but we can't solve all the potential numerical issues that might
> arise.
>
For the purely numeric case, we should do as well as existing purely
numeric libraries, which are pretty good at *cabs, *etc.


> ------------------------------
>
> *[bugs:#4638] <https://sourceforge.net/p/maxima/bugs/4638/>
> cabs/carg/polarform overflow and underflow*
>
> *Status:* open
> *Group:* None
> *Labels:* cabs carg
> *Created:* Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
> *Last Updated:* Mon Dec 01, 2025 02:21 PM UTC
> *Owner:* nobody
>
> cabs and carg on complex floats overflow and underflow even when the
> result is perfectly representable:
>
> cabs(1e-170 + %i*1e-170) => 0.0
> but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
> cabs(1e170 + %i*1e+170) => overflow
> but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
> carg(1e170 + %i*1e+170)) => overflow
> but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
> carg(1e-310 + %i*1e-310) => overflow
> but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
> polarform(1e170 + %i*1e+170) => overflow
>
> Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel
> ------------------------------
>
> 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.
> _______________________________________________
> Maxima-bugs mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-bugs
>



---

**[bugs:#4638] cabs/carg/polarform overflow and underflow**

**Status:** open
**Group:** None
**Labels:** cabs carg 
**Created:** Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
**Last Updated:** Mon Dec 01, 2025 05:18 PM UTC
**Owner:** nobody


``cabs`` and ``carg`` on complex floats overflow and underflow even when the result is perfectly representable:
<pre>
cabs(1e-170 + %i*1e-170) => 0.0
but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
cabs(1e170 + %i*1e+170) => overflow
but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
carg(1e170 + %i*1e+170)) => overflow
but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
carg(1e-310 + %i*1e-310) => overflow
but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
polarform(1e170 + %i*1e+170) => overflow
</pre>

Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel


---

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.

Re: [Maxima-bugs] [maxima:bugs] Re: #4638 cabs/carg/polarform overflow and underflow

[Stavros M. <mac...@gm...>]

On Mon, Dec 1, 2025 at 11:03 AM Raymond Toy via Maxima-bugs <
max...@li...> wrote:

> Here's one way for doing cabs(x+%i*y), where x is a number. Divide by the
> arg by sqrt(x) to get cabs(sqrt(x)+%i*y/sqrt(x)) = sqrt(y^2/x+x). The
> final answer will be sqrt(x)*sqrt(y^2/x+x). Something similiar if y is a
> number.
>
I don't know how to do this if both x and y are more complicated
> expressions composed of numbers + variables.
>
Can you give some examples? Are you thinking of, say, cabs((x+1e200)+%i)?
That only overflows if you expand the result.... And I agree that basic
*cabs* shouldn't worry about cases like this.

> One alternative is to convert the floats to bfloats if we get an overflow.
> We don't normally do that anywhere else, so this would be very odd.
>
I agree that this would be odd, but maybe we should consider it. After all,
we *do* currently convert floats to rats in some cases. For example,
*keepfloat* doesn't prevent *solve* from rationalizing, so that
*solve(x^2+1e200*x-1)
*doesn't overflow -- it returns rationals. I don't love that behavior, but
generalizing the classic Forsythe paper
<http://i.stanford.edu/pub/cstr/reports/cs/tr/66/40/CS-TR-66-40.pdf> for
the general case of *solve* seems hard....

> I don't think a nounform would be a bad answer, if we printed a warning
> that there would be a potential overflow when computing the result. I
> personally think if a user is doing numerical stuff, it's his responsiblity
> to deal with numerical issues that might arise. We'll be careful to limit
> overflows, but we can't solve all the potential numerical issues that might
> arise.
>
For the purely numeric case, we should do as well as existing purely
numeric libraries, which are pretty good at *cabs, *etc.


> ------------------------------
>
> *[bugs:#4638] <https://sourceforge.net/p/maxima/bugs/4638/>
> cabs/carg/polarform overflow and underflow*
>
> *Status:* open
> *Group:* None
> *Labels:* cabs carg
> *Created:* Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
> *Last Updated:* Mon Dec 01, 2025 02:21 PM UTC
> *Owner:* nobody
>
> cabs and carg on complex floats overflow and underflow even when the
> result is perfectly representable:
>
> cabs(1e-170 + %i*1e-170) => 0.0
> but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
> cabs(1e170 + %i*1e+170) => overflow
> but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
> carg(1e170 + %i*1e+170)) => overflow
> but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
> carg(1e-310 + %i*1e-310) => overflow
> but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
> polarform(1e170 + %i*1e+170) => overflow
>
> Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel
> ------------------------------
>
> 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.
> _______________________________________________
> Maxima-bugs mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-bugs
>

[Maxima-bugs] [maxima:bugs] #4638 cabs/carg/polarform overflow and underflow

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

For the pure binary64 complex float case, my favorite method scales the real and imaginary parts by powers of two (no rounding errors).  
~~~
(defun hypotenouse-binary64 (re im)
  (flet ((binary64-exponent (x) (nth-value 1 (decode-float x))))
    (let ((m (- (max (binary64-exponent re) (binary64-exponent im)))))
      (setq re (scale-float re m)
            im (scale-float im m))      
      (scale-float (sqrt (+ (* re re) (* im im))) (- m)))))
~~~


---

**[bugs:#4638] cabs/carg/polarform overflow and underflow**

**Status:** open
**Group:** None
**Labels:** cabs carg 
**Created:** Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
**Last Updated:** Mon Dec 01, 2025 04:02 PM UTC
**Owner:** nobody


``cabs`` and ``carg`` on complex floats overflow and underflow even when the result is perfectly representable:
<pre>
cabs(1e-170 + %i*1e-170) => 0.0
but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
cabs(1e170 + %i*1e+170) => overflow
but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
carg(1e170 + %i*1e+170)) => overflow
but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
carg(1e-310 + %i*1e-310) => overflow
but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
polarform(1e170 + %i*1e+170) => overflow
</pre>

Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel


---

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.

[Maxima-bugs] [maxima:bugs] Re: #4638 cabs/carg/polarform overflow and underflow

[Stavros M. <mac...@us...>]

We should be able to do this right. The classic algorithms for complex
numbers are well documented (and pretty simple).
For more complicated things like say Z: 1e140*x + %i*1e+170, cabs(Z), it's
not much more complicated. It goes something like this:
risplit(Z) => [1e140*x, %i*1e+170]; map('numericcoeff,%%) => [1e140,
1e170]... and then
Something like cabs(multthru(1e-155*Z))*1e155 does the trick.


On Mon, Dec 1, 2025 at 11:03 AM Raymond Toy via Maxima-bugs <
max...@li...> wrote:

> Here's one way for doing cabs(x+%i*y), where x is a number. Divide by the
> arg by sqrt(x) to get cabs(sqrt(x)+%i*y/sqrt(x)) = sqrt(y^2/x+x). The
> final answer will be sqrt(x)*sqrt(y^2/x+x). Something similiar if y is a
> number.
>
> I don't know how to do this if both x and y are more complicated
> expressions composed of numbers + variables.
>
> One alternative is to convert the floats to bfloats if we get an overflow.
> We don't normally do that anywhere else, so this would be very odd.
>
> I don't think a nounform would be a bad answer, if we printed a warning
> that there would be a potential overflow when computing the result. I
> personally think if a user is doing numerical stuff, it's his responsiblity
> to deal with numerical issues that might arise. We'll be careful to limit
> overflows, but we can't solve all the potential numerical issues that might
> arise.
> ------------------------------
>
> *[bugs:#4638] <https://sourceforge.net/p/maxima/bugs/4638/>
> cabs/carg/polarform overflow and underflow*
>
> *Status:* open
> *Group:* None
> *Labels:* cabs carg
> *Created:* Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
> *Last Updated:* Mon Dec 01, 2025 02:21 PM UTC
> *Owner:* nobody
>
> cabs and carg on complex floats overflow and underflow even when the
> result is perfectly representable:
>
> cabs(1e-170 + %i*1e-170) => 0.0
> but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
> cabs(1e170 + %i*1e+170) => overflow
> but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
> carg(1e170 + %i*1e+170)) => overflow
> but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
> carg(1e-310 + %i*1e-310) => overflow
> but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
> polarform(1e170 + %i*1e+170) => overflow
>
> Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel
> ------------------------------
>
> 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.
> _______________________________________________
> Maxima-bugs mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-bugs
>



---

**[bugs:#4638] cabs/carg/polarform overflow and underflow**

**Status:** open
**Group:** None
**Labels:** cabs carg 
**Created:** Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
**Last Updated:** Mon Dec 01, 2025 04:02 PM UTC
**Owner:** nobody


``cabs`` and ``carg`` on complex floats overflow and underflow even when the result is perfectly representable:
<pre>
cabs(1e-170 + %i*1e-170) => 0.0
but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
cabs(1e170 + %i*1e+170) => overflow
but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
carg(1e170 + %i*1e+170)) => overflow
but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
carg(1e-310 + %i*1e-310) => overflow
but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
polarform(1e170 + %i*1e+170) => overflow
</pre>

Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel


---

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.

Re: [Maxima-bugs] [maxima:bugs] Re: #4638 cabs/carg/polarform overflow and underflow

[Stavros M. <mac...@gm...>]

We should be able to do this right. The classic algorithms for complex
numbers are well documented (and pretty simple).
For more complicated things like say Z: 1e140*x + %i*1e+170, cabs(Z), it's
not much more complicated. It goes something like this:
risplit(Z) => [1e140*x, %i*1e+170]; map('numericcoeff,%%) => [1e140,
1e170]... and then
Something like cabs(multthru(1e-155*Z))*1e155 does the trick.


On Mon, Dec 1, 2025 at 11:03 AM Raymond Toy via Maxima-bugs <
max...@li...> wrote:

> Here's one way for doing cabs(x+%i*y), where x is a number. Divide by the
> arg by sqrt(x) to get cabs(sqrt(x)+%i*y/sqrt(x)) = sqrt(y^2/x+x). The
> final answer will be sqrt(x)*sqrt(y^2/x+x). Something similiar if y is a
> number.
>
> I don't know how to do this if both x and y are more complicated
> expressions composed of numbers + variables.
>
> One alternative is to convert the floats to bfloats if we get an overflow.
> We don't normally do that anywhere else, so this would be very odd.
>
> I don't think a nounform would be a bad answer, if we printed a warning
> that there would be a potential overflow when computing the result. I
> personally think if a user is doing numerical stuff, it's his responsiblity
> to deal with numerical issues that might arise. We'll be careful to limit
> overflows, but we can't solve all the potential numerical issues that might
> arise.
> ------------------------------
>
> *[bugs:#4638] <https://sourceforge.net/p/maxima/bugs/4638/>
> cabs/carg/polarform overflow and underflow*
>
> *Status:* open
> *Group:* None
> *Labels:* cabs carg
> *Created:* Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
> *Last Updated:* Mon Dec 01, 2025 02:21 PM UTC
> *Owner:* nobody
>
> cabs and carg on complex floats overflow and underflow even when the
> result is perfectly representable:
>
> cabs(1e-170 + %i*1e-170) => 0.0
> but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
> cabs(1e170 + %i*1e+170) => overflow
> but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
> carg(1e170 + %i*1e+170)) => overflow
> but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
> carg(1e-310 + %i*1e-310) => overflow
> but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
> polarform(1e170 + %i*1e+170) => overflow
>
> Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel
> ------------------------------
>
> 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.
> _______________________________________________
> Maxima-bugs mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-bugs
>

[Maxima-bugs] [maxima:bugs] #4641 is does not work

[Raymond T. <rt...@us...>]

With your example `t[2]` is `[2]`, a 1x1 matrix. (Well, a list of one element).  I think `unknown` is a good answer.  Perhaps you really wanted `is(t[2][1]>0)`.  This returns `true`.


---

**[bugs:#4641] is does not work**

**Status:** open
**Group:** None
**Created:** Mon Dec 01, 2025 04:03 PM UTC by dan hayes
**Last Updated:** Mon Dec 01, 2025 04:03 PM UTC
**Owner:** nobody


build_info()  or bug_report()
"branch_5_44_base_231_g5c411f69f",timestamp="2021-01-12 23:51:42",host="x86_64-w64-mingw32",lisp_name="SBCL",lisp_version="2.0.0",maxima_userdir="C:/Users/zmth1/maxima",maxima_tempdir="C:/Users/zmth1/AppData/Local/Temp",maxima_objdir="C:/Users/zmth1/maxima/binary/branch_5_44_base_231_g5c411f69f/sbcl/2_0_0",maxima_frontend="wxMaxima",maxima_frontend_version="20.12.2-DevelopmentSnapshot_MSW_OpenMP201511+Locks")

(t:matrix([1],[2]),t,t[2],is( t[2]>0));   

and it comes back with unknown



---

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.

[Maxima-bugs] [maxima:bugs] #4641 is does not work

[dan h. <zm...@us...>]

---

**[bugs:#4641] is does not work**

**Status:** open
**Group:** None
**Created:** Mon Dec 01, 2025 04:03 PM UTC by dan hayes
**Last Updated:** Mon Dec 01, 2025 04:03 PM UTC
**Owner:** nobody


build_info()  or bug_report()
"branch_5_44_base_231_g5c411f69f",timestamp="2021-01-12 23:51:42",host="x86_64-w64-mingw32",lisp_name="SBCL",lisp_version="2.0.0",maxima_userdir="C:/Users/zmth1/maxima",maxima_tempdir="C:/Users/zmth1/AppData/Local/Temp",maxima_objdir="C:/Users/zmth1/maxima/binary/branch_5_44_base_231_g5c411f69f/sbcl/2_0_0",maxima_frontend="wxMaxima",maxima_frontend_version="20.12.2-DevelopmentSnapshot_MSW_OpenMP201511+Locks")

(t:matrix([1],[2]),t,t[2],is( t[2]>0));   

and it comes back with unknown



---

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.

[Maxima-bugs] [maxima:bugs] Re: #4638 cabs/carg/polarform overflow and underflow

[Raymond T. <rt...@us...>]

Here's one way for doing `cabs(x+%i*y)`, where `x` is a number.  Divide by the arg by `sqrt(x)` to get `cabs(sqrt(x)+%i*y/sqrt(x))` = `sqrt(y^2/x+x)`.   The final answer will be `sqrt(x)*sqrt(y^2/x+x)`.    Something similiar if `y` is a number.

I don't know how to do this if both `x` and `y` are more complicated expressions composed of numbers + variables.  

One alternative is to convert the floats to bfloats if we get an overflow.  We don't normally do that anywhere else, so this would be very odd.

I don't think a nounform would be a bad answer, if we printed a warning that there would be a potential overflow when computing the result.  I personally think if a user is doing numerical stuff, it's his responsiblity to deal with numerical issues that might arise.  We'll be careful to limit overflows, but we can't solve all the potential numerical issues that might arise.


---

**[bugs:#4638] cabs/carg/polarform overflow and underflow**

**Status:** open
**Group:** None
**Labels:** cabs carg 
**Created:** Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
**Last Updated:** Mon Dec 01, 2025 02:21 PM UTC
**Owner:** nobody


``cabs`` and ``carg`` on complex floats overflow and underflow even when the result is perfectly representable:
<pre>
cabs(1e-170 + %i*1e-170) => 0.0
but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
cabs(1e170 + %i*1e+170) => overflow
but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
carg(1e170 + %i*1e+170)) => overflow
but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
carg(1e-310 + %i*1e-310) => overflow
but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
polarform(1e170 + %i*1e+170) => overflow
</pre>

Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel


---

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.

[Maxima-bugs] [maxima:bugs] #4638 cabs/carg/polarform overflow and underflow

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

I have an experimental way to fix the `cabs` overflow case for complex binary64 numbers, but mixed binary64 & symbolic cases can still fail: Example

OK:
~~~
(%i10) cabs(5.0e154 + %i);
float-float case (debug message)
(%o10)                              5.0e154
~~~
Still overflows
~~~
(%i11) cabs(5.0e154 + %i*x);
Maxima encountered a Lisp error:
 arithmetic error FLOATING-POINT-OVERFLOW signalled
~~~
Returning a `cabs` nounform isn't an option for `cabs(5.0e154 + %i*x)`, I think, so I'm stuck. 


---

**[bugs:#4638] cabs/carg/polarform overflow and underflow**

**Status:** open
**Group:** None
**Labels:** cabs carg 
**Created:** Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
**Last Updated:** Sat Nov 29, 2025 07:18 AM UTC
**Owner:** nobody


``cabs`` and ``carg`` on complex floats overflow and underflow even when the result is perfectly representable:
<pre>
cabs(1e-170 + %i*1e-170) => 0.0
but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
cabs(1e170 + %i*1e+170) => overflow
but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
carg(1e170 + %i*1e+170)) => overflow
but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
carg(1e-310 + %i*1e-310) => overflow
but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
polarform(1e170 + %i*1e+170) => overflow
</pre>

Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel


---

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.

[Maxima-bugs] [maxima:bugs] #4636 signum(ind) is an error

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

Fixed by [7a7b1a] (HEAD, master)

This fix is a minimal fix to  `signum(ind) --> error` bug. Additionally it appends the overflow and underflow examples in this thread.

Maybe it's OK to close this ticket?


---

**[bugs:#4636] signum(ind) is an error**

**Status:** open
**Group:** None
**Labels:** extended real signum limit 
**Created:** Thu Nov 27, 2025 12:41 PM UTC by Barton Willis
**Last Updated:** Sun Nov 30, 2025 08:15 PM UTC
**Owner:** nobody


Either a  `signum` nounform or `ind` is a better result than an error:
~~~
(%i4)	signum(ind);
sign: sign of ind is undefined.
~~~
Should the general simplifier, or the one‑argument limit function, handle` F(extended-real)`? We’ve discussed this—do we have a consensus?



---

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.

[Maxima-bugs] [maxima:bugs] #4640 Erroneos result of funcsolve

[Daniel V. <dan...@us...>]

---

**[bugs:#4640] Erroneos result of funcsolve**

**Status:** open
**Group:** None
**Created:** Mon Dec 01, 2025 07:40 AM UTC by Daniel Volinski
**Last Updated:** Mon Dec 01, 2025 07:40 AM UTC
**Owner:** nobody


With the following lines:

eq:(n+1)*f(n)-(n-1)*f(n-1)=(n+1)/(n-1);
funcsolve(eq,f(n));

I get the following result:

(n+1)*f(n)-f(n-1)*(n-1) = (n+1)/(n-1)
f(n) = (%0*n^2+%1*n+%2)/((n-1)*(n+1))

Which contain %0, %1, %2. This solution is bogus.

Barton Willis suggested using trace(solve);
before the command funcsolve to get:

Barton Willis wrote:

Here solve returns the empty list, but it goes ahead and returns a bogus solution:

%i3) funcsolve((n+1)*f(n)-(n-1)*f(n-1)=(n+1)/(n-1),f(n));
1" Enter "solve" "[[%1-%0-1,2*%2-2*%1+4*%0-1,-%2+3*%1-5*%0,4*%0-%1,-%0],[%2,%1,%0]]

1" Exit  "solve" "[]

(%o3) f(n)=(%0*n^2+%1*n+%2)/((n-1)*(n+1))

Daniel Volinski


---

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.

[Maxima-bugs] [maxima:bugs] Re: #4636 signum(ind) is an error

[Raymond T. <rt...@us...>]

This should probably be a new issue or a discussion on the mailing list.  Like the rest of Maxima, I didn't write any design docs.  :-( The only documentation is the code and comments in src/numeric.lisp.  However the general idea with the functions in the bigfloat package is to mimic what CL does, except when one (or more) operands are bfloats, in which case the result is a bfloat.  Also `bigfloat:to` returns a numeric type.  If the arg is a CL type, that's what you get.  If it's a bfloat, you get a bigfloat object.

By doing it this way, you could write one function that would handle CL numeric types or bfloats without changing the function.  Of course, if speed mattered, you'd write a special double-float version.  But the bfloat version could very possibly be identical, if some care is taken to compute an epsilon value appropriately.

So in your example of `(bigfloat::expt (bigfloat:to 4) (bigfloat:to '((rat) 1 2)))`, the args are a CL fixnum and a CL ratio.  By the rules of CL, the result is a single-precision result.

(I don't remember exactly where the `to` name came from, but there was a Maxima function `to` that did something similar.)

You've probably forgotten that 1e0 and 1f0 are the same precision.

I should probably convert some of the comments in to docstrings so you can easily look up what they do via `cl:describe`.


---

**[bugs:#4636] signum(ind) is an error**

**Status:** open
**Group:** None
**Labels:** extended real signum limit 
**Created:** Thu Nov 27, 2025 12:41 PM UTC by Barton Willis
**Last Updated:** Sun Nov 30, 2025 02:27 PM UTC
**Owner:** nobody


Either a  `signum` nounform or `ind` is a better result than an error:
~~~
(%i4)	signum(ind);
sign: sign of ind is undefined.
~~~
Should the general simplifier, or the one‑argument limit function, handle` F(extended-real)`? We’ve discussed this—do we have a consensus?



---

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.

[Maxima-bugs] [maxima:bugs] Re: #4636 signum(ind) is an error

[Stavros M. <mac...@us...>]

I was concerned by bigfloat:to, not bigfloat:signum because I assumed that
it converted all numbers to bigfloats, and consing up and normalizing a
bigfloat is not free. But that isn't what it does. Very confusing name! Is
it naive of me to think that something named bigfloat:to converts its
argument to a bigfloat?

I see that the bigfloat class also supports complex number objects, which
is great ... although I'm not sure how you use that from Maxima (maybe a
future extension to translate?). For existing Maxima numeric types
(integer, rat, float, bigfloat), I'd have thought that addk, timesk,
exptrl would
handle most cases (though the names are terrible).

By the way, it appears that bigfloat:to allocates a new bigfloat in the
*current *fpprec rather than preserving the precision of the argument; so I
am confused again about the specs of this package. Of course, this is
irrelevant for signum.

As for efficiency, I agree that no one cares about a 10x efficiency loss in
signum on numbers. But if this style is used as a model for other
calculations, it could be a problem.

Is there a reference manual that explains how the package is intended to be
used, its design rationale, and some usage examples? I don't understand
this, for example:

(bigfloat::expt (bigfloat:to 4) (bigfloat:to '((rat) 1 2)))

    => 1.414f0

Is this as designed, or a bug? For this case, I'd have thought that the
result would be one of:

   - 2 -- standard Maxima semantics as returned by exptrl (but what about
   2^(1/2) -- presumably in purely numeric calculations you don't want the
   symbolic result as given by exptrl)
   - 1.414e0 -- default float type
   - 1.414b0 -- since the class is called *bigfloat*

I'm sure I'm missing something basic....

            -s

On Sun, Nov 30, 2025 at 5:27 PM Raymond Toy <rt...@us...>
wrote:

> bigfloat:signum doesn't do anything special. It just checks the sign of
> the arg and returns 1, -1, or 0. That should be pretty easy to do.
>
> But does the factor of 10 really matter? Are people doing zillions of
> bigfloat signums where this really matters?
> ------------------------------
>
> *[bugs:#4636] <https://sourceforge.net/p/maxima/bugs/4636/> signum(ind) is
> an error*
>
> *Status:* open
> *Group:* None
> *Labels:* extended real signum limit
> *Created:* Thu Nov 27, 2025 12:41 PM UTC by Barton Willis
> *Last Updated:* Sun Nov 30, 2025 10:59 AM UTC
> *Owner:* nobody
>
> Either a signum nounform or ind is a better result than an error:
>
> (%i4)   signum(ind);
> sign: sign of ind is undefined.
>
> Should the general simplifier, or the one‑argument limit function, handle
> F(extended-real)? We’ve discussed this—do we have a consensus?
> ------------------------------
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/maxima/bugs/4636/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>



---

**[bugs:#4636] signum(ind) is an error**

**Status:** open
**Group:** None
**Labels:** extended real signum limit 
**Created:** Thu Nov 27, 2025 12:41 PM UTC by Barton Willis
**Last Updated:** Sun Nov 30, 2025 02:27 PM UTC
**Owner:** nobody


Either a  `signum` nounform or `ind` is a better result than an error:
~~~
(%i4)	signum(ind);
sign: sign of ind is undefined.
~~~
Should the general simplifier, or the one‑argument limit function, handle` F(extended-real)`? We’ve discussed this—do we have a consensus?



---

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.

[Maxima-bugs] [maxima:bugs] Re: #4636 signum(ind) is an error

[Raymond T. <rt...@us...>]

`bigfloat:signum` doesn't do anything special.  It just checks the sign of the arg and returns 1, -1, or 0.  That should be pretty easy to do.  

But does the factor of 10 really matter?  Are people doing zillions of bigfloat signums where this really matters?


---

**[bugs:#4636] signum(ind) is an error**

**Status:** open
**Group:** None
**Labels:** extended real signum limit 
**Created:** Thu Nov 27, 2025 12:41 PM UTC by Barton Willis
**Last Updated:** Sun Nov 30, 2025 10:59 AM UTC
**Owner:** nobody


Either a  `signum` nounform or `ind` is a better result than an error:
~~~
(%i4)	signum(ind);
sign: sign of ind is undefined.
~~~
Should the general simplifier, or the one‑argument limit function, handle` F(extended-real)`? We’ve discussed this—do we have a consensus?



---

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.

[Maxima-bugs] [maxima:bugs] Re: #4636 signum(ind) is an error

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

**To clarify:** I'm not the right person to alter the big float package code.  Handing off the numerical work to the big float package indeed has a speed penalty of a factor of 10 or so.  Fixing the speed issue by passing the big float package isn't terribly hard, I think.




---

**[bugs:#4636] signum(ind) is an error**

**Status:** open
**Group:** None
**Labels:** extended real signum limit 
**Created:** Thu Nov 27, 2025 12:41 PM UTC by Barton Willis
**Last Updated:** Sat Nov 29, 2025 01:40 PM UTC
**Owner:** nobody


Either a  `signum` nounform or `ind` is a better result than an error:
~~~
(%i4)	signum(ind);
sign: sign of ind is undefined.
~~~
Should the general simplifier, or the one‑argument limit function, handle` F(extended-real)`? We’ve discussed this—do we have a consensus?



---

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.

[Maxima-bugs] [maxima:bugs] #4639 dim-%antideriv: a partial fix for a bug in widths

[Eduardo O. <edu...@us...>]

---

**[bugs:#4639] dim-%antideriv: a partial fix for a bug in widths**

**Status:** open
**Group:** None
**Created:** Sun Nov 30, 2025 01:38 AM UTC by Eduardo Ochs
**Last Updated:** Sun Nov 30, 2025 01:38 AM UTC
**Owner:** nobody
**Attachments:**

- [with-setq-width.png](https://sourceforge.net/p/maxima/bugs/4639/attachment/with-setq-width.png) (25.7 kB; image/png)
- [without-setq-width.png](https://sourceforge.net/p/maxima/bugs/4639/attachment/without-setq-width.png) (25.8 kB; image/png)


These are the messages M1 and M2, about "dim-%antideriv":

M1: <https://sourceforge.net/p/maxima/mailman/message/59178281/>
M2: <https://sourceforge.net/p/maxima/mailman/message/59266596/>

M1 is by Robert Dodier, in which he sent the code for
"dim-%antideriv", and M2 is by me, in which I showed that by adding
one line to Robert's code we can make it calculate the width correctly
in most - but not all - cases.

Robert asked me to send the code and the screenshots to the bug
tracker, so here it goes. The code is below, with the "setq" that I
added marked with ";; Edrx:", and with my tests in the comments at the
end. The screenshot named "without-setq-width.png" shows that the
widths were incorrect in all the four tests - o1, o2, o3, and o4 - and
the screenshot named "with-setq-width.png" shows that after my fix the
tests o1, o2, and o4 are good, but the width in o3 still has a one-off
error.


--snip--snip--
~~~
(if (not (fboundp 'display2d-unicode-enabled))
    (defun display2d-unicode-enabled () nil))


(defun dim-%antideriv (form result)

  (unless (= (length (cdr form)) 4)
    (return-from dim-%antideriv (dimension-function form result)))

  (let*
    ((args (rest form))
     (expr (first args))
     (my-var (second args))
     (lower-val (third args))
     (upper-val (fourth args))
     (lower-eqn (list '(mequal) my-var lower-val))
     (upper-eqn (list '(mequal) my-var upper-val))
     (vertical-bar-char (if (display2d-unicode-enabled)
                            at-char-unicode
                          (car (coerce $absboxchar 'list))))
     vertical-bar
     expr-result  
     lower-result
     upper-result
     expr-w  expr-h  expr-d
     lower-w lower-h lower-d
     upper-w upper-h upper-d)
    (declare (ignorable expr-w expr-h expr-d
                        lower-w lower-h lower-d
                        upper-w upper-h upper-d))

    (setq expr-result (dimension expr nil 'mparen 'mparen nil 0)
          expr-w width
          expr-h height
          expr-d depth)

    (setq lower-result (dimension-infix lower-eqn nil)
          lower-w width
          lower-h height
          lower-d depth)

    (setq upper-result (dimension-infix upper-eqn nil)
          upper-w width
          upper-h height
          upper-d depth)

    (setq vertical-bar (list 'd-vbar
                             (1+ (max expr-h upper-d))
                             (max (1+ expr-d) lower-h)
                             vertical-bar-char))

    (setq result (append (list (append (list (- lower-w) (max expr-h upper-d)) upper-result)
                               (append (list 0 (- (max (1+ expr-d) lower-h))) lower-result)
                               vertical-bar
                               (append (list 0 0) expr-result))
                         result))

    (setq height (+ 1 (max expr-h upper-d) upper-h)
          depth (+ (max (1+ expr-d) lower-h) lower-d))

    ;; Edrx:
    (setq width (+ expr-w 1 (max upper-w lower-w)))

    (update-heights height depth)

    result))

(setf (get '%antideriv 'dimension) 'dim-%antideriv)
(setf (get '$antideriv 'dimension) 'dim-%antideriv) ; Edrx

#|
• (eepitch-maxima)
• (eepitch-kill)
• (eepitch-maxima)
load ("dim-antideriv.lisp");
mybox(o) := [box(o)];

o1 : antideriv (F(u), u, a, b);
o2 : antideriv (F(u[k]), u[k], a[k], b[k]);
o3 : antideriv (a+b, u, z^2^n+y[k], x^2-z[k]);
o4 : antideriv (a+b, u, z^2^n+y[k], x^2-z[k[l[u]]]);

mybox(o1);
mybox(o2);
mybox(o3);
mybox(o4);

|#
~~~
--snip--snip--


  Cheers,
    Eduardo Ochs
    https://anggtwu.net/eev-maxima.html
    http://anggtwu.net/MAXIMA/dim-antideriv.lisp.html



---

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.

[Maxima-bugs] [maxima:bugs] Re: #4636 signum(ind) is an error

[Stavros M. <mac...@us...>]

Really? That seems like a sledgehammer for a tiny nut. Classical numerical
techniques are simple and effective.

Just because machines are 1000x faster now doesn't mean we should make our
code 10x slower when there is a food alternative.

On Sat, Nov 29, 2025, 17:40 Barton Willis via Maxima-bugs <
max...@li...> wrote:

> The current signum(2.3) => 1.0 behavior comes from a call to the bigfloat
> code:
>
>  (maxima::to (bigfloat::signum (bigfloat::to x)))))
>
> I'm not the right person to alter this code.
> ------------------------------
>
> *[bugs:#4636] <https://sourceforge.net/p/maxima/bugs/4636/> signum(ind) is
> an error*
>
> *Status:* open
> *Group:* None
> *Labels:* extended real signum limit
> *Created:* Thu Nov 27, 2025 12:41 PM UTC by Barton Willis
> *Last Updated:* Sat Nov 29, 2025 07:05 AM UTC
> *Owner:* nobody
>
> Either a signum nounform or ind is a better result than an error:
>
> (%i4)   signum(ind);
> sign: sign of ind is undefined.
>
> Should the general simplifier, or the one‑argument limit function, handle
> F(extended-real)? We’ve discussed this—do we have a consensus?
> ------------------------------
>
> 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.
> _______________________________________________
> Maxima-bugs mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-bugs
>



---

**[bugs:#4636] signum(ind) is an error**

**Status:** open
**Group:** None
**Labels:** extended real signum limit 
**Created:** Thu Nov 27, 2025 12:41 PM UTC by Barton Willis
**Last Updated:** Sat Nov 29, 2025 01:40 PM UTC
**Owner:** nobody


Either a  `signum` nounform or `ind` is a better result than an error:
~~~
(%i4)	signum(ind);
sign: sign of ind is undefined.
~~~
Should the general simplifier, or the one‑argument limit function, handle` F(extended-real)`? We’ve discussed this—do we have a consensus?



---

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.

[Maxima-bugs] [maxima:bugs] Re: #4636 signum(ind) is an error

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

The current `signum(2.3) => 1.0` behavior comes from  a call to the bigfloat code:

~~~
 (maxima::to (bigfloat::signum (bigfloat::to x)))))
~~~

I'm not the right person to alter this code.


---

**[bugs:#4636] signum(ind) is an error**

**Status:** open
**Group:** None
**Labels:** extended real signum limit 
**Created:** Thu Nov 27, 2025 12:41 PM UTC by Barton Willis
**Last Updated:** Sat Nov 29, 2025 07:05 AM UTC
**Owner:** nobody


Either a  `signum` nounform or `ind` is a better result than an error:
~~~
(%i4)	signum(ind);
sign: sign of ind is undefined.
~~~
Should the general simplifier, or the one‑argument limit function, handle` F(extended-real)`? We’ve discussed this—do we have a consensus?



---

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.

[Maxima-bugs] [maxima:bugs] #4638 cabs/carg/polarform overflow and underflow

[Stavros M. <mac...@us...>]

---

**[bugs:#4638] cabs/carg/polarform overflow and underflow**

**Status:** open
**Group:** None
**Labels:** cabs carg 
**Created:** Sat Nov 29, 2025 07:18 AM UTC by Stavros Macrakis
**Last Updated:** Sat Nov 29, 2025 07:18 AM UTC
**Owner:** nobody


``cabs`` and ``carg`` on complex floats overflow and underflow even when the result is perfectly representable:
<pre>
cabs(1e-170 + %i*1e-170) => 0.0
but float(cabs(bfloat(1e-170 + %i*1e-170))) => 1.414213562373095e-170
cabs(1e170 + %i*1e+170) => overflow
but float(cabs(bfloat(1e170 + %i*1e170))) => 1.4142135623730952e170
carg(1e170 + %i*1e+170)) => overflow
but float(carg(bfloat(1e170 + %i*1e+170))) => 0.7853981633974483
carg(1e-310 + %i*1e-310) => overflow
but carg(1b-310 + %i*1b-310) => 7.853981633974483b-1
polarform(1e170 + %i*1e+170) => overflow
</pre>

Tested in Maxima 5.48.1 SBCL 2.5.7 MacOS Intel


---

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.

[Maxima-bugs] [maxima:bugs] Re: #4636 signum(ind) is an error

[Stavros M. <mac...@us...>]

I agree with Ray. I don't see what we gain by having signum(2.3)=>1.0. (I may have argued the opposite in the past...?)


---

**[bugs:#4636] signum(ind) is an error**

**Status:** open
**Group:** None
**Labels:** extended real signum limit 
**Created:** Thu Nov 27, 2025 12:41 PM UTC by Barton Willis
**Last Updated:** Sat Nov 29, 2025 12:21 AM UTC
**Owner:** nobody


Either a  `signum` nounform or `ind` is a better result than an error:
~~~
(%i4)	signum(ind);
sign: sign of ind is undefined.
~~~
Should the general simplifier, or the one‑argument limit function, handle` F(extended-real)`? We’ve discussed this—do we have a consensus?



---

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.