Menu
▾
▴
maxima-bugs
|
From: Stavros M. <mac...@us...> - 2025-11-29 07:18:13
|
--- **[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. |
|
From: Barton W. <wil...@us...> - 2025-12-01 14:21:15
|
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. |
|
From: Raymond T. <rt...@us...> - 2025-12-01 16:02:59
|
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. |
|
From: Stavros M. <mac...@gm...> - 2025-12-01 16:56:06
|
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
>
|
|
From: Stavros M. <mac...@us...> - 2025-12-01 16:56:17
|
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. |
|
From: Stavros M. <mac...@gm...> - 2025-12-01 17:21:17
|
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 > |
|
From: Barton W. <wil...@us...> - 2025-12-01 17:18:49
|
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. |
|
From: Raymond T. <rt...@us...> - 2025-12-01 17:50:38
|
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. |
|
From: Stavros M. <mac...@us...> - 2025-12-01 17:21:19
|
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. |
|
From: Raymond T. <rt...@us...> - 2025-12-01 17:49:23
|
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. |
|
From: Barton W. <wil...@us...> - 2025-12-01 18:01:57
|
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. |
|
From: Barton W. <wil...@us...> - 2025-12-01 20:39:45
|
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. |
|
From: Stavros M. <mac...@us...> - 2025-12-02 20:00:59
|
See https://sourceforge.net/p/maxima/bugs/4642/ for the csign problem. --- **[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:** Tue Dec 02, 2025 06:41 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. |
|
From: Barton W. <wil...@us...> - 2025-12-02 15:16:41
|
**proposal** Attempt to detect a floating point overflow, and when it is detected, return an `abs` nounform. Examples (done with experimental code) ~~~ (%i40) cabs(2/3 +%i*x); (%o40) sqrt(x^2+4/9) (%i41) cabs(2.3 +%i*x); (%o41) sqrt(x^2+5.289999999999999) (%i42) cabs(2.3e100 +%i*x); (%o42) sqrt(x^2+5.2899999999999995e200) ~~~ Examples of floating point overflow ~~~ (%i43) cabs(2.3e170 +%i*x); floating point overflow detected (%o43) abs(%i*x+2.3e170) (%i44) cabs(2.3 +%i*x*1.8e200); floating point overflow detected (%o44) abs(1.8e200*%i*x+2.3) ~~~ I'm not sure that this will work with all Lisp varieties. --- **[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 08:39 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. |
|
From: Stavros M. <mac...@us...> - 2025-12-02 18:41:48
|
In addition to the 0.0/-0.0 case that you mention
(hypotenouse-binary64 1e-170 0.0) => 0.0 -- should be 1e-170
it isn't right for denormalized numbers:
(hypotenouse-binary64 1e-323 1e-323) => 3.1467296279827185e-308
(* 1e-323 (sqrt 2.0)) => 1.4821969375237396e-323
PS By the way, although I appreciate the spelling *hypotenouse* as being more faithful to the Greek (ὑποτείνουσα), that's not the usual English spelling.
---
**[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:** Tue Dec 02, 2025 03:16 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. |
|
From: Barton W. <wil...@us...> - 2025-12-03 00:08:37
|
Maybe Clozure CL doesn't use denormalized floats and SBCL does? ~~~ (%i6) cabs( 1e-323 + %i* 1e-323); 0> Calling (HYPOTENUSE-BINARY64 1.0E-323 1.0E-323) <0 HYPOTENUSE-BINARY64 returned 0.0 (%o6) 0.0 ~~~ I'll fix this up and switch to the English spelling. Thanks for catching these errors. --- **[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:** Tue Dec 02, 2025 08:00 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. |
Thanks for helping keep SourceForge clean.
X