maxima-discuss — Maxima discussion list

[Maxima-discuss] Error

[Justin S. <jus...@gm...>]

The command

integrate(sqrt(1+tan(x)),x);

produces

Maxima encountered a Lisp error:
  The value
    1
  is not of type
    LIST
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.

-- 
"As long as you are not aware of the continual law of Die and Be Again,
you are merely a vague guest on a dark Earth."
     --- Johann Wolfgang von Goethe
Homepage: http://www.five-dimensions.org

Re: [Maxima-discuss] dead links on the Related Projects page

[ehm <eri...@gm...>]

On Sat, 2025-12-06 at 22:18 -0800, Robert Dodier wrote:
> 
> From what I gather, Taboola has something to do with web ads, but I
> can't tell what the effect of the above line would be. If it's
> actually needed we can restore it.

Interesting, I didn't notice that. I just saved the web page as is and
edited it in emacs. I wonder how it got in there in the first place. I
just checked the other pages and they are all free of Taboola.

> On Sun, 2025-12-07 at 11:29 +0000, Jaime Villate wrote:
>  
> Hello,
>  
> Thank you for your contribution. The page is much better now. We now
> have to update the Spanish, Portuguese, Russian and Turkish versions.
> I wonder whether we should eliminate the link to other languages when
> a page is updated, leaving instead a comment that older versions
> exist in other languages and should be re-linked once they are
> updated.

Thank you. I'll keep an eye on that in the future and leave a comment.

-Eric

Re: [Maxima-discuss] dead links on the Related Projects page

[Jaime V. <vi...@fe...>]

Hello,

Thank you for your contribution. The page is much better now. We now 
have to update the Spanish, Portuguese, Russian and Turkish versions. I 
wonder whether we should eliminate the link to other languages when a 
page is updated, leaving instead a comment that older versions exist in 
other languages and should be re-linked once they are updated.

I find it strange that I didn't get a copy of either the message with 
the ProjectsRelatedtoMaxima_ehm.html page or the commit done by Robert.

Regards,

Jaime

On 12/7/25 06:18, Robert Dodier wrote:
> On Sat, Dec 6, 2025 at 8:34 AM ehm<eri...@gm...> wrote:
>
>> I updated the page and added maxima-on-wasm.
>>
>> I have attached the updated html file if someone wants to merge it.
> Thanks, Eric. I have committed ProjectsRelatedtoMaxima_ehm.html as
> relatedprojects.html with a couple of changes. One was to replace
> external linkshttps://maxima.sourceforge.io/... with just the ... to
> make a relative link. The other is that I omitted a line which
> mentioned Taboola,
>
> <style>:is([id*='google_ads_iframe'],[id*='taboola-'],.taboolaHeight,.taboola-placeholder,#top-ad,#credential_picker_container,#credentials-picker-container,#credential_picker_iframe,[id*='google-one-tap-iframe'],#google-one-tap-popup-container,.google-one-tap__module,.google-one-tap-modal-div,#amp_floatingAdDiv,#ez-content-blocker-container)
> {display:none!important;min-height:0!important;height:0!important;}</style></head>
>
>  From what I gather, Taboola has something to do with web ads, but I
> can't tell what the effect of the above line would be. If it's
> actually needed we can restore it.
>
> best,
>
> Robert
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss

Re: [Maxima-discuss] dead links on the Related Projects page

[Robert D. <rob...@gm...>]

On Sat, Dec 6, 2025 at 8:34 AM ehm <eri...@gm...> wrote:

> I updated the page and added maxima-on-wasm.
>
> I have attached the updated html file if someone wants to merge it.

Thanks, Eric. I have committed ProjectsRelatedtoMaxima_ehm.html as
relatedprojects.html with a couple of changes. One was to replace
external links https://maxima.sourceforge.io/... with just the ... to
make a relative link. The other is that I omitted a line which
mentioned Taboola,

<style>:is([id*='google_ads_iframe'],[id*='taboola-'],.taboolaHeight,.taboola-placeholder,#top-ad,#credential_picker_container,#credentials-picker-container,#credential_picker_iframe,[id*='google-one-tap-iframe'],#google-one-tap-popup-container,.google-one-tap__module,.google-one-tap-modal-div,#amp_floatingAdDiv,#ez-content-blocker-container)
{display:none!important;min-height:0!important;height:0!important;}</style></head>

>From what I gather, Taboola has something to do with web ads, but I
can't tell what the effect of the above line would be. If it's
actually needed we can restore it.

best,

Robert

Re: [Maxima-discuss] New installation and updates

[Robert D. <rob...@gm...>]

On Sat, Dec 6, 2025 at 6:29 PM Raymond Toy <toy...@gm...> wrote:

> There is support for patches, but it looks like almost no one (including me) ever looks there since there are quite a few outstanding patches some of which are over ten years old. 😦
>
> I find this a bit unfortunate since I think people are used to pull/merge requests to propose changes to projects. AFAIK, sourceforge doesn't really provide that feature.

For the record, in addition to the patch tracker, there is also a
feature called the merge request, which is not too different (only a
little bit less convenient) from a pull request.

My own feeling is that it is not so much a technical issue as it is
sociological -- the Maxima developers would do well to encourage
actual and potential collaborators by, well, spending some time
reviewing and therefore accepting at least some of the proposed
changes.

I am as guilty as anyone, but anyway I think it's in the interest of
the project for the regular developers to spend some time reviewing
patches and merge requests.

Robert

Re: [Maxima-discuss] New installation and updates

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

On 12/6/25 3:34 PM, Robert Dodier wrote:

> On Fri, Dec 5, 2025 at 4:31 PM Greg Bennett<gwb...@gm...> wrote:
>
>> Is there a maxima-approved way to merge this change on my own (compiled)
>> copy of maxima ?
> Greg, thanks for your interest in Maxima. The best way to keep up to
> date with development changes is to clone the Git repo from
> Sourceforge and pull commits as desired. The master branch is almost
> always a workable version -- the project does not have any separate
> process for posting, vetting, and merging changes.

There is support for patches 
<https://sourceforge.net/p/maxima/patches/>, but it looks like almost no 
one (including me) ever looks there since there are quite a few 
outstanding patches some of which are over ten years old. 😦

I find this a bit unfortunate since I think people are used to 
pull/merge requests to propose changes to projects. AFAIK, sourceforge 
doesn't really provide that feature.

> best,
>
> Robert
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
&#8203;

[Maxima-discuss] Use of cl:pi in numeric code

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

In a discussion with Barton and Stavros, it came up that ecl was getting 
some type errors in running the testsuite. In particular, |elliptic_e| 
and |lambert_w| were producing long-float values.

In maxima, float values are always supposed to be double-floats. 
However, in ecl and clisp, |cl:pi| is a long-float because both ecl and 
clisp have a long-float type separate from double-float.

This means any code that uses |cl:pi| causes the use of long-floats. 
That's not want we want to happen.

I'm not sure what the best solution is, but we do have |bigfloat:%pi| to 
return a value of pi of the appropriate type. However, that's a method 
so there's some cost to using this. I'm not sure if a compiler macro 
could be written to remove the cost.

An alternative is to change |bigfloat:%pi| to be a function. Then I can 
definitely write a compiler macro to return the appropriate type if the 
arg has a known value. A quick grep shows that currently |bigfloat:%pi| 
is always called with a variable instead of a constant.

There are also quite a few places where we do |(coerce pi 'flonum)| and 
|(float pi 1e0)|. These should be updated to use |bigfloat:%pi| if we 
choose to do this.

This might be ok. I'll do some experimentation.

​

Re: [Maxima-discuss] New installation and updates

[Robert D. <rob...@gm...>]

On Fri, Dec 5, 2025 at 4:31 PM Greg Bennett <gwb...@gm...> wrote:

> Is there a maxima-approved way to merge this change on my own (compiled)
> copy of maxima ?

Greg, thanks for your interest in Maxima. The best way to keep up to
date with development changes is to clone the Git repo from
Sourceforge and pull commits as desired. The master branch is almost
always a workable version -- the project does not have any separate
process for posting, vetting, and merging changes.

best,

Robert

Re: [Maxima-discuss] scale-float with sbcl & ccl

[Richard F. <fa...@gm...>]

I'm thinking mostly of trap and exception handling by interrupts not being
uniform in language implementation.  No specific items at the moment.


On Sat, Dec 6, 2025, 8:47 AM Stavros Macrakis <mac...@gm...> wrote:

> RJF,
>
> Agreed that the Common Lisp spec didn't specify the behavior of floats
> completely, leaving it to the underlying implementation.
> I'd hope that denormalized 64-bit IEEE 754 floats are implemented
> correctly and consistently on common modern processors (x86, ARM).
> Are you claiming that there are "nuances" in the spec or implementation of *scale-float
> *that mean that it can't be consistent across Common Lisp + CPU
> combinations?
>
>           -s
>
> On Fri, Dec 5, 2025 at 6:52 PM Richard Fateman <fa...@gm...> wrote:
>
>> There are nuances in the IEEE standard that are not widely used and
>> sometimes
>> were left out of the software support (for laziness, lack of
>> understanding, uncertainty
>> of whether this would catch on?) and
>> were, certainly in the past, left out of some hardware. (vendors would
>> say they support
>> the IEEE format, not mentioning lack of support of some operations.)
>> Denormalized numbers are certainly in the category of not-widely-used.
>> Common Lisp Standard support for floats was deliberately underspecified
>> -- IEEE floats
>> were new at the time.
>>
>> Curious --  is there a call for this in some important place, say in a
>> math library routine??
>>
>> RJF
>>
>> On Fri, Dec 5, 2025 at 3:39 PM Raymond Toy <toy...@gm...> wrote:
>>
>>>
>>> On 12/5/25 3:24 PM, David Scherfgen wrote:
>>>
>>> This is a known bug in SBCL:
>>> https://bugs.launchpad.net/sbcl/+bug/2000178
>>>
>>> Almost 3 years old.  I guess it's not important enough to anyone.
>>>
>>>
>>> Raymond Toy <toy...@gm...> schrieb am Fr., 5. Dez. 2025, 16:00:
>>>
>>>>
>>>> On 12/5/25 10:21 AM, Barton Willis via Maxima-discuss wrote:
>>>>
>>>>
>>>> For subnormal floats,  the SBCL CL function scale-float is possibly
>>>> buggy:
>>>>
>>>> SBCL 2.4.7:
>>>>
>>>> Define Maxima function that calls the CL function scale-float
>>>>
>>>> (%i1) :lisp(defun $scale_float (x m) (scale-float x m))
>>>>
>>>> (%i1) x : 2.0^(-1024);
>>>> (%o1)                       5.562684646268004e-309
>>>>
>>>> This is a SBCL bug, I think:  surely scaling by zero should be an
>>>> identity?
>>>>
>>>> (%i2) scale_float(x,0);
>>>> (%o2)                       2.7813423231340017e-308
>>>>
>>>> (%i3) x : 2.0^(-1023);
>>>> (%o3)                       1.1125369292536007e-308
>>>>
>>>> This is kinda surprising.  Cmucl gets this right.  So does ecl.  Kinda
>>>> funny too; it's not obvious what's happening here.  `integer-decode-float`
>>>> for the scaled result is `#x14000000000000` and an exponent of -1074,
>>>> instead of the expected `#x10000000000000` with exponent -1076.
>>>>
>>>>
>>>> _______________________________________________
>>>> Maxima-discuss mailing list
>>>> Max...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>>>
>>>
>>>
>>> _______________________________________________
>>> Maxima-discuss mailing list
>>> Max...@li...
>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>

Re: [Maxima-discuss] scale-float with sbcl & ccl

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

RJF,

Agreed that the Common Lisp spec didn't specify the behavior of floats
completely, leaving it to the underlying implementation.
I'd hope that denormalized 64-bit IEEE 754 floats are implemented correctly
and consistently on common modern processors (x86, ARM).
Are you claiming that there are "nuances" in the spec or
implementation of *scale-float
*that mean that it can't be consistent across Common Lisp + CPU
combinations?

          -s

On Fri, Dec 5, 2025 at 6:52 PM Richard Fateman <fa...@gm...> wrote:

> There are nuances in the IEEE standard that are not widely used and
> sometimes
> were left out of the software support (for laziness, lack of
> understanding, uncertainty
> of whether this would catch on?) and
> were, certainly in the past, left out of some hardware. (vendors would say
> they support
> the IEEE format, not mentioning lack of support of some operations.)
> Denormalized numbers are certainly in the category of not-widely-used.
> Common Lisp Standard support for floats was deliberately underspecified --
> IEEE floats
> were new at the time.
>
> Curious --  is there a call for this in some important place, say in a
> math library routine??
>
> RJF
>
> On Fri, Dec 5, 2025 at 3:39 PM Raymond Toy <toy...@gm...> wrote:
>
>>
>> On 12/5/25 3:24 PM, David Scherfgen wrote:
>>
>> This is a known bug in SBCL: https://bugs.launchpad.net/sbcl/+bug/2000178
>>
>> Almost 3 years old.  I guess it's not important enough to anyone.
>>
>>
>> Raymond Toy <toy...@gm...> schrieb am Fr., 5. Dez. 2025, 16:00:
>>
>>>
>>> On 12/5/25 10:21 AM, Barton Willis via Maxima-discuss wrote:
>>>
>>>
>>> For subnormal floats,  the SBCL CL function scale-float is possibly
>>> buggy:
>>>
>>> SBCL 2.4.7:
>>>
>>> Define Maxima function that calls the CL function scale-float
>>>
>>> (%i1) :lisp(defun $scale_float (x m) (scale-float x m))
>>>
>>> (%i1) x : 2.0^(-1024);
>>> (%o1)                       5.562684646268004e-309
>>>
>>> This is a SBCL bug, I think:  surely scaling by zero should be an
>>> identity?
>>>
>>> (%i2) scale_float(x,0);
>>> (%o2)                       2.7813423231340017e-308
>>>
>>> (%i3) x : 2.0^(-1023);
>>> (%o3)                       1.1125369292536007e-308
>>>
>>> This is kinda surprising.  Cmucl gets this right.  So does ecl.  Kinda
>>> funny too; it's not obvious what's happening here.  `integer-decode-float`
>>> for the scaled result is `#x14000000000000` and an exponent of -1074,
>>> instead of the expected `#x10000000000000` with exponent -1076.
>>>
>>>
>>> _______________________________________________
>>> Maxima-discuss mailing list
>>> Max...@li...
>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>>
>>
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] dead links on the Related Projects page

[ehm <eri...@gm...>]

I updated the page and added maxima-on-wasm.

I have attached the updated html file if someone wants to merge it.

-EM

On Sat, 2025-12-06 at 07:28 -0800, Raymond Toy wrote:
>  
> 
>  
>  
> On 12/6/25 7:19 AM, Stavros Macrakis wrote:
>  
>  
> >   
> >    Maybe list them in a separate "history" section? 
> >  
> >  
> >  
> >  
>  
> That makes sense to me.
>  
> And we should probably add the [maxima-on-wasm
> website](https://maxima-on-wasm.pages.dev/), a full Maxima running in
> a browser, including plotting.
>  
> >  
> >   
> >   On Sat, Dec 6, 2025, 09:29 ehm <eri...@gm...> wrote:
> >  
> >  
> > > There are several dead links on the related projects page.
> > > Perhaps they
> > >  should be considered for removal.
> > >  
> > >  Euler
> > >  WIMS
> > >  Jacomax
> > >  Interactive Demos of Mathematical Computations
> > >  
> > >  Also, some very old projects that might be considered for
> > > removal.
> > >  
> > >  Symaxx2 - no updates for 25 years, and no recent downloads
> > >  Symbolic Equation Manipulator - no updates for 20 years, no
> > > downloads
> > >  MaximaPHP - no updates for 14 years, no downloads
> > >  
> > >  -EM
> > >  
> > >  
> > >  _______________________________________________
> > >  Maxima-discuss mailing list
> > >  Max...@li...
> > >  https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> > >  
> > > 
> >  
> >  
> >  
> >  
> >  
> >   
> >   
> > _______________________________________________
> > Maxima-discuss mailing list
> > Max...@li...
> > https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> >  
>  
>  
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss

Re: [Maxima-discuss] scale-float with sbcl & ccl

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

On 12/5/25 5:43 PM, Raymond Toy wrote:

>
> On 12/5/25 3:51 PM, Richard Fateman wrote:
>> There are nuances in the IEEE standard that are not widely used and 
>> sometimes
>> were left out of the software support (for laziness, lack of 
>> understanding, uncertainty
>> of whether this would catch on?) and
>> were, certainly in the past, left out of some hardware. (vendors 
>> would say they support
>> the IEEE format, not mentioning lack of support of some operations.)
>> Denormalized numbers are certainly in the category of not-widely-used.
>> Common Lisp Standard support for floats was deliberately 
>> underspecified -- IEEE floats
>> were new at the time.
>
> I think it's safe to say that any x86 or arm processor supports 
> IEEE-754.  Handling of NaN was never well-specified.  (Agner Fog has 
> an excellent article about this.)
>
I should have included a link to Agner Fogs article 
<https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf>.

Sorry about that.

&#8203;

Re: [Maxima-discuss] dead links on the Related Projects page

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

On 12/6/25 7:19 AM, Stavros Macrakis wrote:
> Maybe list them in a separate "history" section?

That makes sense to me.

And we should probably add the [maxima-on-wasm 
website](https://maxima-on-wasm.pages.dev/), a full Maxima running in a 
browser, including plotting.

>
> On Sat, Dec 6, 2025, 09:29 ehm <eri...@gm...> wrote:
>
>     There are several dead links on the related projects page. Perhaps
>     they
>     should be considered for removal.
>
>     Euler
>     WIMS
>     Jacomax
>     Interactive Demos of Mathematical Computations
>
>     Also, some very old projects that might be considered for removal.
>
>     Symaxx2 - no updates for 25 years, and no recent downloads
>     Symbolic Equation Manipulator - no updates for 20 years, no downloads
>     MaximaPHP - no updates for 14 years, no downloads
>
>     -EM
>
>
>     _______________________________________________
>     Maxima-discuss mailing list
>     Max...@li...
>     https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss

[Maxima-discuss] dead links on the Related Projects page

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

Maybe list them in a separate "history" section?

On Sat, Dec 6, 2025, 09:29 ehm <eri...@gm...> wrote:

> There are several dead links on the related projects page. Perhaps they
> should be considered for removal.
>
> Euler
> WIMS
> Jacomax
> Interactive Demos of Mathematical Computations
>
> Also, some very old projects that might be considered for removal.
>
> Symaxx2 - no updates for 25 years, and no recent downloads
> Symbolic Equation Manipulator - no updates for 20 years, no downloads
> MaximaPHP - no updates for 14 years, no downloads
>
> -EM
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

[Maxima-discuss] dead links on the Related Projects page

[ehm <eri...@gm...>]

There are several dead links on the related projects page. Perhaps they
should be considered for removal.

Euler
WIMS
Jacomax
Interactive Demos of Mathematical Computations

Also, some very old projects that might be considered for removal.

Symaxx2 - no updates for 25 years, and no recent downloads
Symbolic Equation Manipulator - no updates for 20 years, no downloads
MaximaPHP - no updates for 14 years, no downloads

-EM

Re: [Maxima-discuss] scale-float with sbcl & ccl

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

On 12/5/25 3:51 PM, Richard Fateman wrote:
> There are nuances in the IEEE standard that are not widely used and 
> sometimes
> were left out of the software support (for laziness, lack of 
> understanding, uncertainty
> of whether this would catch on?) and
> were, certainly in the past, left out of some hardware. (vendors would 
> say they support
> the IEEE format, not mentioning lack of support of some operations.)
> Denormalized numbers are certainly in the category of not-widely-used.
> Common Lisp Standard support for floats was deliberately 
> underspecified -- IEEE floats
> were new at the time.

I think it's safe to say that any x86 or arm processor supports 
IEEE-754.  Handling of NaN was never well-specified.  (Agner Fog has an 
excellent article about this.)

Some older (and newer?) x86 chips had really awful performance with 
denormals, but I think this is mostly fixed.  I understand arm is quite 
good and operations with denormals are about twice the cost of normal 
floats.

>
> Curious --  is there a call for this in some important place, say in a 
> math library routine??

I don't know, but if you poke around fdlibm, you can see the code 
handles denormals.  Presumably other math libraries also handle 
denormals; I haven't checked those.


>
> RJF
>
> On Fri, Dec 5, 2025 at 3:39 PM Raymond Toy <toy...@gm...> wrote:
>
>
>     On 12/5/25 3:24 PM, David Scherfgen wrote:
>>     This is a known bug in SBCL:
>>     https://bugs.launchpad.net/sbcl/+bug/2000178
>     Almost 3 years old.  I guess it's not important enough to anyone.
>>
>>     Raymond Toy <toy...@gm...> schrieb am Fr., 5. Dez. 2025,
>>     16:00:
>>
>>
>>         On 12/5/25 10:21 AM, Barton Willis via Maxima-discuss wrote:
>>>
>>>         For subnormal floats,  the SBCL CL function scale-float is
>>>         possibly buggy:
>>>
>>>         SBCL 2.4.7:
>>>
>>>         Define Maxima function that calls the CL function scale-float
>>>
>>>         (%i1) :lisp(defun $scale_float (x m) (scale-float x m))
>>>
>>>         (%i1) x : 2.0^(-1024);
>>>         (%o1)                       5.562684646268004e-309
>>>
>>>         This is a SBCL bug, I think:  surely scaling by zero should
>>>         be an identity?
>>>
>>>         (%i2) scale_float(x,0);
>>>         (%o2)                       2.7813423231340017e-308
>>>
>>>         (%i3) x : 2.0^(-1023);
>>>         (%o3)                       1.1125369292536007e-308
>>         This is kinda surprising.  Cmucl gets this right. So does
>>         ecl.  Kinda funny too; it's not obvious what's happening
>>         here.  `integer-decode-float` for the scaled result is
>>         `#x14000000000000` and an exponent of -1074, instead of the
>>         expected `#x10000000000000` with exponent -1076.
>>
>>         _______________________________________________
>>         Maxima-discuss mailing list
>>         Max...@li...
>>         https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>     _______________________________________________
>     Maxima-discuss mailing list
>     Max...@li...
>     https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

[Maxima-discuss] New installation and updates

[Greg B. <gwb...@gm...>]

I have a new machine with linux mint 22.2 and sbcl-2.5.10.

From  a previous machine with mint 21 I have Robert Dodier's recipe for 
cloning maxima
and thence installing it. I am quite comfortable with this sort of 
thing, so I intend to use
it on the new machine.

Then I'll get wxMaxima as a gui too.

If there are any caveats about the current release or this process I 
would be grateful to learn of them.

 From time to time on this list I see notes from one of the maintainers, 
to whom I am
very grateful, of the sort:
If there is no objection  I'll merge this soon.

Is there a maxima-approved way to merge this change on my own (compiled) 
copy of maxima ?
I am aware that .fasls from different sbcl's don't play together; I do 
update my sbcl fairly regularly.

I don't mind fetching from github, compiling, slotting into an 
appropriate fasl slot, but that is with my own stuff; maxima presumably 
keeps a
'record' of what's where and I need to more careful with merges.

Thanks for the great software and, in advance, for any advice and 
assistance.

Cheers
Greg Bennett

Re: [Maxima-discuss] scale-float with sbcl & ccl

[Richard F. <fa...@gm...>]

There are nuances in the IEEE standard that are not widely used and
sometimes
were left out of the software support (for laziness, lack of understanding,
uncertainty
of whether this would catch on?) and
were, certainly in the past, left out of some hardware. (vendors would say
they support
the IEEE format, not mentioning lack of support of some operations.)
Denormalized numbers are certainly in the category of not-widely-used.
Common Lisp Standard support for floats was deliberately underspecified --
IEEE floats
were new at the time.

Curious --  is there a call for this in some important place, say in a math
library routine??

RJF

On Fri, Dec 5, 2025 at 3:39 PM Raymond Toy <toy...@gm...> wrote:

>
> On 12/5/25 3:24 PM, David Scherfgen wrote:
>
> This is a known bug in SBCL: https://bugs.launchpad.net/sbcl/+bug/2000178
>
> Almost 3 years old.  I guess it's not important enough to anyone.
>
>
> Raymond Toy <toy...@gm...> schrieb am Fr., 5. Dez. 2025, 16:00:
>
>>
>> On 12/5/25 10:21 AM, Barton Willis via Maxima-discuss wrote:
>>
>>
>> For subnormal floats,  the SBCL CL function scale-float is possibly buggy:
>>
>> SBCL 2.4.7:
>>
>> Define Maxima function that calls the CL function scale-float
>>
>> (%i1) :lisp(defun $scale_float (x m) (scale-float x m))
>>
>> (%i1) x : 2.0^(-1024);
>> (%o1)                       5.562684646268004e-309
>>
>> This is a SBCL bug, I think:  surely scaling by zero should be an
>> identity?
>>
>> (%i2) scale_float(x,0);
>> (%o2)                       2.7813423231340017e-308
>>
>> (%i3) x : 2.0^(-1023);
>> (%o3)                       1.1125369292536007e-308
>>
>> This is kinda surprising.  Cmucl gets this right.  So does ecl.  Kinda
>> funny too; it's not obvious what's happening here.  `integer-decode-float`
>> for the scaled result is `#x14000000000000` and an exponent of -1074,
>> instead of the expected `#x10000000000000` with exponent -1076.
>>
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] sometimes 1//2 =/= 1/2

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

On 12/5/25 3:41 PM, Richard Fateman wrote:
> (fppi) returns the insides of bigfloat %pi to the current bigfloat 
> precision.  If you want the
> whole number with the precision encoded, then use bcons.
>
> :lisp (setf $mypi (bcons (fppi)))
>
> sets the maxima variable mypi  to a bigfloat pi  which in the default 
> precision prints as
> 3.141592653589793b0
>
> The lisp programs (of which there are lots of examples) generally do 
> calculations on the "insides"  with
> the precision understood, and presumed (required) to be the same for 
> all bigfloat insides in the calculation.
>
> One could relax that understanding and instead insist that each number 
> has the header, so
> instead of just (say) adding two bigfloats insides by (fpplus a b),
> we could convert a to current precision, b to current precision, add 
> them producing a result (with header)
> specifying the current precision.  This is what bfloat(a+b) does.
>
> (fppi) returns the lisp list (56593902016227522 2)
> $mypi in lisp is ((bigfloat simp 56) 56593902016227522 2)
>
> I hope this helps if someone decides to read/extend/improve/replace 
> this code.

The bigfloat package is intended to hide these implementation details 
while still using the original algorithms from float.lisp so that there 
are no weird and very hard to debug regressions in bfloat arithmetic.  
It won't be as fast as using the bare code from float.lisp, but 
hopefully it's a lot less error-prone and easier to write and debug.  If 
someone really, really needs that speed boost, they can still get down 
and dirty with the original code.

Re: [Maxima-discuss] sometimes 1//2 =/= 1/2

[Richard F. <fa...@gm...>]

(fppi) returns the insides of bigfloat %pi to the current bigfloat
precision.  If you want the
whole number with the precision encoded, then use bcons.

:lisp (setf $mypi (bcons (fppi)))

sets the maxima variable mypi  to a bigfloat pi  which in the default
precision prints as
3.141592653589793b0

The lisp programs (of which there are lots of examples) generally do
calculations on the "insides"  with
the precision understood, and presumed (required) to be the same for all
bigfloat insides in the calculation.

One could relax that understanding and instead insist that each number has
the header, so
instead of just (say) adding two bigfloats insides by (fpplus a b),
we could convert a to current precision, b to current precision, add them
producing a result (with header)
specifying the current precision.  This is what bfloat(a+b) does.

(fppi) returns the lisp list (56593902016227522 2)
$mypi in lisp is ((bigfloat simp 56) 56593902016227522 2)

I hope this helps if someone decides to read/extend/improve/replace  this
code.
RJF


On Fri, Dec 5, 2025 at 1:49 PM Raymond Toy <toy...@gm...> wrote:

>
> On 12/5/25 10:41 AM, Robert Dodier wrote:
>
> On Fri, Dec 5, 2025 at 4:58 AM Barton Willis via Maxima-discuss<max...@li...> <max...@li...> wrote:
>
> Another thing:  Although bfhalf automatically updates when  fpprec changes, some special variables defined in globals.lisp do not.
>
> I wonder if any specific bigfloat values should be functions instead
> of constants, so that changing fpprec causes a different value to be
> returned. Or maybe baking the prevailing fpprec into the symbol name,
> something like BIGFLOAT-%PI-FOR-DEFAULT-FPPREC or whatever.
>
> I agree on adding functions.  We already have `fppi` that returns a
> bigfloat pi for the current fpprec. But `fppi` returns a bfloat object sans
> bfloat marker.   And `fppi` is memoized.  I think if you use the bigfloat
> package, you get `(bigfloat:%pi num)` where `num` is only used to figure
> out what kind of result to return (single, double, big float).  Similarly
> for `bigfloat:%e`.
>
> Speaking strictly for myself, I can't keep it straight in my head when
> some constant is no longer valid in some context ... if developers are
> supposed to "just know", then it's likely that I'll mess it up at some
> point. YMMV as always.
>
> I don't think it's just you.
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] scale-float with sbcl & ccl

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

On 12/5/25 3:24 PM, David Scherfgen wrote:
> This is a known bug in SBCL: https://bugs.launchpad.net/sbcl/+bug/2000178
Almost 3 years old.  I guess it's not important enough to anyone.
>
> Raymond Toy <toy...@gm...> schrieb am Fr., 5. Dez. 2025, 16:00:
>
>
>     On 12/5/25 10:21 AM, Barton Willis via Maxima-discuss wrote:
>>
>>     For subnormal floats,  the SBCL CL function scale-float is
>>     possibly buggy:
>>
>>     SBCL 2.4.7:
>>
>>     Define Maxima function that calls the CL function scale-float
>>
>>     (%i1) :lisp(defun $scale_float (x m) (scale-float x m))
>>
>>     (%i1) x : 2.0^(-1024);
>>     (%o1)                       5.562684646268004e-309
>>
>>     This is a SBCL bug, I think:  surely scaling by zero should be an
>>     identity?
>>
>>     (%i2) scale_float(x,0);
>>     (%o2)                       2.7813423231340017e-308
>>
>>     (%i3) x : 2.0^(-1023);
>>     (%o3)                       1.1125369292536007e-308
>     This is kinda surprising.  Cmucl gets this right.  So does ecl. 
>     Kinda funny too; it's not obvious what's happening here. 
>     `integer-decode-float` for the scaled result is `#x14000000000000`
>     and an exponent of -1074, instead of the expected
>     `#x10000000000000` with exponent -1076.
>
>     _______________________________________________
>     Maxima-discuss mailing list
>     Max...@li...
>     https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] scale-float with sbcl & ccl

[David S. <d.s...@go...>]

This is a known bug in SBCL: https://bugs.launchpad.net/sbcl/+bug/2000178

Raymond Toy <toy...@gm...> schrieb am Fr., 5. Dez. 2025, 16:00:

>
> On 12/5/25 10:21 AM, Barton Willis via Maxima-discuss wrote:
>
>
> For subnormal floats,  the SBCL CL function scale-float is possibly buggy:
>
> SBCL 2.4.7:
>
> Define Maxima function that calls the CL function scale-float
>
> (%i1) :lisp(defun $scale_float (x m) (scale-float x m))
>
> (%i1) x : 2.0^(-1024);
> (%o1)                       5.562684646268004e-309
>
> This is a SBCL bug, I think:  surely scaling by zero should be an
> identity?
>
> (%i2) scale_float(x,0);
> (%o2)                       2.7813423231340017e-308
>
> (%i3) x : 2.0^(-1023);
> (%o3)                       1.1125369292536007e-308
>
> This is kinda surprising.  Cmucl gets this right.  So does ecl.  Kinda
> funny too; it's not obvious what's happening here.  `integer-decode-float`
> for the scaled result is `#x14000000000000` and an exponent of -1074,
> instead of the expected `#x10000000000000` with exponent -1076.
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] scale-float with sbcl & ccl

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

On 12/5/25 10:21 AM, Barton Willis via Maxima-discuss wrote:
>
> For subnormal floats,  the SBCL CL function scale-float is possibly buggy:
>
> SBCL 2.4.7:
>
> Define Maxima function that calls the CL function scale-float
>
> (%i1) :lisp(defun $scale_float (x m) (scale-float x m))
>
> (%i1) x : 2.0^(-1024);
> (%o1)                       5.562684646268004e-309
>
> This is a SBCL bug, I think:  surely scaling by zero should be an 
> identity?
>
> (%i2) scale_float(x,0);
> (%o2)                       2.7813423231340017e-308
>
> (%i3) x : 2.0^(-1023);
> (%o3)                       1.1125369292536007e-308
This is kinda surprising.  Cmucl gets this right.  So does ecl. Kinda 
funny too; it's not obvious what's happening here. 
`integer-decode-float` for the scaled result is `#x14000000000000` and 
an exponent of -1074, instead of the expected `#x10000000000000` with 
exponent -1076.

Re: [Maxima-discuss] sometimes 1//2 =/= 1/2

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

On 12/5/25 10:41 AM, Robert Dodier wrote:
> On Fri, Dec 5, 2025 at 4:58 AM Barton Willis via Maxima-discuss
> <max...@li...> wrote:
>> Another thing:  Although bfhalf automatically updates when  fpprec changes, some special variables defined in globals.lisp do not.
> I wonder if any specific bigfloat values should be functions instead
> of constants, so that changing fpprec causes a different value to be
> returned. Or maybe baking the prevailing fpprec into the symbol name,
> something like BIGFLOAT-%PI-FOR-DEFAULT-FPPREC or whatever.
I agree on adding functions.  We already have `fppi` that returns a 
bigfloat pi for the current fpprec. But `fppi` returns a bfloat object 
sans bfloat marker.   And `fppi` is memoized.  I think if you use the 
bigfloat package, you get `(bigfloat:%pi num)` where `num` is only used 
to figure out what kind of result to return (single, double, big 
float).  Similarly for `bigfloat:%e`.
>
> Speaking strictly for myself, I can't keep it straight in my head when
> some constant is no longer valid in some context ... if developers are
> supposed to "just know", then it's likely that I'll mess it up at some
> point. YMMV as always.
I don't think it's just you.

Re: [Maxima-discuss] sometimes 1//2 =/= 1/2

[Richard F. <fa...@gm...>]

Having written the bigfloat code about 50 years ago, I'm probably to blame
for such things.
Resetting the global bf values for one, zero, half   are cheap.  Values for
e and pi and other
constants may not be so cheap.   I think some computations are done by
bumping up the
precision slightly and then rounding down, so re-doing e,pi, etc at each
change may not
be a great idea. But if they are memoized, maybe it doesn't matter, and it
doesn't matter if
functions producing the values are used in places, instead of the values
themselves being stored.

Note that the precision used for a bigfloat op like fpplus is the global fp
precision, and is NOT
governed by precision of the arguments.  Also there is a Maxima variable
$fpprec , initially 16,
supposed to be number of decimal digits,  and a lisp variable  ?fpprec,
initially 56, the corresponding
number of binary bits in the "fraction" part of the bigfloat.

Whether it is a feature or a defect, it is unclear:  since there is no
limit on the value of the exponent,
"underflow"  or "overflow"  by exceeding that range is not possible, and so
bigfloats do not
have NaN  (Not a Number) as do IEEE754 standard floats.  Maxima has inf,
und, ind, which might
be "allowed" as bigfloats, if someone cared to do that, figured out the
consequences, and it was acceptably fast.

RJF




On Fri, Dec 5, 2025 at 10:41 AM Robert Dodier <rob...@gm...>
wrote:

> On Fri, Dec 5, 2025 at 4:58 AM Barton Willis via Maxima-discuss
> <max...@li...> wrote:
> >
> > Another thing:  Although bfhalf automatically updates when  fpprec
> changes, some special variables defined in globals.lisp do not.
>
> I wonder if any specific bigfloat values should be functions instead
> of constants, so that changing fpprec causes a different value to be
> returned. Or maybe baking the prevailing fpprec into the symbol name,
> something like BIGFLOAT-%PI-FOR-DEFAULT-FPPREC or whatever.
>
> Speaking strictly for myself, I can't keep it straight in my head when
> some constant is no longer valid in some context ... if developers are
> supposed to "just know", then it's likely that I'll mess it up at some
> point. YMMV as always.
>
> Robert
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>