Re: [Maxima-discuss] numeric/bigfloat class WAS #4636 signum(ind) is an error

[Raymond T. <toy...@gm...>]

On 11/30/25 12:46 PM, Stavros Macrakis wrote:

> Agreed that discussion of numeric.lisp/bigfloat should be a new 
> thread. So here it is.
>
> You say:
>
>     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.
>
> OK, but those aren't the rules of Maxima...!

Yes, that was a conscious decision. The reason for bigfloat was to 
extend the CL arithmetic/special functions to support bigfloats (real 
and complex) while also still handling CL numbers according to CL rules. 
It was not intended to have Maxima semantics. By doing it this way, you 
would be able to take any numeric code using double-floats, and it would 
work with bigfloats automatically, mostly. You just had to take care of 
infinities (which don't exist in bfloats), and also any calculations 
with an epsilon value.

Anything else was beyond the scope of bigfloat.

Plus, I mostly got tired of writing bfloat arithmetic with fpadd, 
fpdifference, etc., because I could never remember the names themselves 
and whether the args included the bigfloat marker or not.

Hence, there are |to| functions to convert maxima numbers into CL 
numbers or bigfloat numbers. And a corresponding |to| function to 
convert them to Maxima numbers.

>     (I don't remember exactly where the |to| name came from, but there
>     was a Maxima function |to| that did something similar.)
>
> I'd think "to" means "convert-to", no?
>
>     You've probably forgotten that 1e0 and 1f0 are the same precision.
>
> The Maxima reader treats them as the same, but in this case, 
> single-precision was the /return value/, and they're not the same Lisp 
> type and don't print the same in Maxima:
>
>     (type-of 1.0f0) => SINGLE-FLOAT
>     (/ 1.0f0 3) => 0.33333334f0
>     ($print 1.0f0) => 1.0f0
>
>
>     (type-of 1.0e0) => DOUBLE-FLOAT
>
>     (/ 1.0e0 3) => 0.3333333333333333
>
>     ($print 1.0e0) => 1.0
>
That's because maxima sets |*read-default-float-format*| to 
|double-float|. I'm assuming you're running this in maxima. 1e0 is a 
single-float in CL with default settings.
>
>
> On Sun, Nov 30, 2025 at 11:15 PM Raymond Toy via Maxima-bugs 
> <max...@li...> wrote:
>
>     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] <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 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 <http://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-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
&#8203;