maxima-discuss — Maxima discussion list

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
>

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

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

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] scale-float with sbcl & ccl

[Barton W. <wi...@un...>]

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 also wrong:

(%i4) scale_float(x,0);
(%o4)                       3.337610787760802e-308

(%i5) x : 2.0^(-1022);
(%o5)                       2.2250738585072014e-308

Finally this is OK:

(%i6) scale_float(x,0);
(%o6)                       2.2250738585072014e-308

With CCL 1.13

(%i1) :lisp(defun $scale_float (x m) (scale-float x m))


This is a recently  reported CCL bug
(%i1) x : 2.0^(-1024);

Maxima encountered a Lisp error:

 FLOATING-POINT-OVERFLOW detected
performing * on (1.3407807929942597E+154 1.3407807929942597E+154)

A silly workaround for this bug:

(%i2) x : 2.0^(-1023)/2;
(%o2)                       5.562684646268003E-309

OK:

(%i3) scale_float(x,0);
(%o3)                       5.562684646268003E-309

OK:

(%i4) x : 2.0^(-1023);
(%o4)                       1.1125369292536007E-308

OK:

(%i5) scale_float(x,0);
(%o5)                       1.1125369292536007E-308

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

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

On 12/5/25 4:55 AM, Barton Willis wrote:

> Another thing: Although |bfhalf| automatically updates when |fpprec 
> |changes, some special variables defined in |globals.lisp| do not. 
> Examples:
>
> (%i1) :lisp(print bigfloat%pi)
>
> ((BIGFLOAT SIMP 56) 56593902016227522 2)
> ((BIGFLOAT SIMP 56) 56593902016227522 2)
>
> (%i1) fpprec : 57$
>
> (%i2) :lisp(print bigfloat%pi)
>
> ((BIGFLOAT SIMP 56) 56593902016227522 2)
> ((BIGFLOAT SIMP 56) 56593902016227522 2)

Yeah, this is confusing. I'm not sure what should happen here. But 
AFAICT, |bigfloat%pi| is only used in gamma.lisp, and it recomputes a 
value via |($bfloat '$%pi)|. Fortunately, that will use a memoized value 
if available.

Updating these constants when changing fpprec is potentially very 
expensive since computing pi, e, gamma, and log2 can be rather 
expensive, even if they are memoized.

On the other hand, the uses of pi, e, and gamma are always recomputed as 
needed so these special variables can probably be removed (for the 
best!). And |bigfloat_log2| doesn't seem to be used anywhere.

I'll file a bug on this.

> ------------------------------------------------------------------------
> *From:* Raymond Toy <toy...@gm...>
> *Sent:* Thursday, December 4, 2025 5:44 PM
> *To:* Barton Willis <wi...@un...>; 
> max...@li... 
> <max...@li...>
> *Subject:* Re: [Maxima-discuss] sometimes 1//2 =/= 1/2
>
> 	
> Caution: Non-NU Email
>
>
> On 12/4/25 8:51 AM, Barton Willis wrote:
>
>> I have tested changing (let ((1//2 ... to (let ((bfhalf ....  It 
>> fixes the trouble and eliminates the need for the macro half that is 
>> used in absarg.   I hope to commit this fix along with a few others 
>> in a few weeks.
>
> Hmm. float.lisp defines |bfhalf| spec var. And it's value is updated 
> whenever fpprec1 is called. Maybe you don't need that at all.
>
> And we should probably rename |bfhalf| to |*bfhalf*| along with the 
> other spec vars updated in fpprec1. And rename |1//2| to |*1/2*|. Or 
> make |1//2| a |defconstant|. But sbcl is really picky about what can 
> be a |defconstant|.
>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Raymond Toy <toy...@gm...> 
>> <mailto:toy...@gm...>
>> *Sent:* Thursday, December 4, 2025 10:28 AM
>> *To:* max...@li... 
>> <mailto:max...@li...> 
>> <max...@li...> 
>> <mailto:max...@li...>
>> *Subject:* Re: [Maxima-discuss] sometimes 1//2 =/= 1/2
>>
>> 	
>> Caution: Non-NU Email
>>
>>
>> On 12/4/25 5:43 AM, Barton Willis via Maxima-discuss wrote:
>>
>>> OK, maybe I found the culprit:
>>>
>>> (defun bfloat-erf (z)
>>>   ;; Warning!  This has round-off problems when abs(z) is very small.
>>>   (let ((1//2 ($bfloat '((rat simp) 1 2))))
>>>   ;; The argument is real, the result is real too
>>>     ($realpart
>>>       (mul
>>>         (simplify (list '(%signum) z))
>>>         (sub 1
>>>           (mul
>>>             (div 1 (power ($bfloat '$%pi) 1//2))
>>>             (bfloat-gamma-incomplete 1//2 ($bfloat (power z 2)))))))))
>>>
>>>
>>>
>>> And similarly for |complex-bfloat-erf| . Changing  1//2 to bfhalf in 
>>> this code didn't result in any testsuite failures, but I have a few 
>>> pending changes to the function |absarg.|
>> Nice bit of detective work! Yeah, renaming 1//2 to something else 
>> should take care of the problem.
>>>
>>> |Also, loading gamma.lisp gives the warning: (SBCL)|
>>>
>>>  in: DEFUN GAMMA-INCOMPLETE
>>> ;     (COND ((COMPLEXP MAXIMA::X) #C(0.0d0 0.0d0)) ((REALP 
>>> MAXIMA::X) 0.0d0))
>>
>> I think there are lots of these.
>>
>> The issue here is that the compiler doesn't know what X is, so the 
>> |cond| cases of |complexp| and |realp| covers the case of numbers, 
>> but there are lots of other types which aren't covered.
>>
>> This can be fixed in two ways. Add |(declare (number x))|. Add a |T| 
>> clause to |cond|. This should probably signal an error.
>>
>> Or maybe even replace the |cond| with |etypecase|?
>>
>> &#8203;
> &#8203;
&#8203;

Re: [Maxima-discuss] should hypotenuse-binary64 trust the compiler authors and dispatch abs?

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

On Thu, Dec 4, 2025, 19:32 Raymond Toy <toy...@gm...> wrote:

> On 12/4/25 9:00 AM, Barton Willis wrote:
>
> ...
>
> Last I knew, SageMath uses Maxima compiled with ECL, so I think we need to
> fix that bug too.
>
> You mean Stavros' test? He's using a really ancient version. I don't have
> that problem with 24.5.10....
>

I tested on the current Maxima On Android 3.2.1, ECL 16.1.3, Maxima 5.41.0.
Obviously we should build MOA with more recent versions.

Source is on GitHub -- last updated in 2019 and it is built using Android
Studio.

Does anyone know how to build it? I have no idea how hard that would be.

        -s

https://github.com/YasuakiHonda/Maxima-on-Android-AS

Readme says:

Development Environment of the author:

iMac with Mac OS 10.15
Android Studio 3.1.4
Up to date Android SDK
Android NDK r12
All the compiled binaries for maxima, gnuplot, and qepcad for ARM are
included in the asset folder.

This repository is provided in the hope that anyone can easily start the
development of Maxima on Android using Google's Android Studio.

> &#8203;
>
> &#8203;
>

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

[Barton W. <wi...@un...>]

Another thing:  Although bfhalf automatically updates when  fpprec changes, some special variables defined in globals.lisp do not. Examples:

(%i1) :lisp(print bigfloat%pi)

((BIGFLOAT SIMP 56) 56593902016227522 2)
((BIGFLOAT SIMP 56) 56593902016227522 2)

(%i1) fpprec : 57$

(%i2) :lisp(print bigfloat%pi)

((BIGFLOAT SIMP 56) 56593902016227522 2)
((BIGFLOAT SIMP 56) 56593902016227522 2)
________________________________
From: Raymond Toy <toy...@gm...>
Sent: Thursday, December 4, 2025 5:44 PM
To: Barton Willis <wi...@un...>; max...@li... <max...@li...>
Subject: Re: [Maxima-discuss] sometimes 1//2 =/= 1/2

Caution: Non-NU Email


On 12/4/25 8:51 AM, Barton Willis wrote:

I have tested changing (let ((1//2  ... to (let ((bfhalf ....  It fixes the trouble and eliminates the need for the macro half that is used in absarg.   I hope to commit this fix along with a few others in a few weeks.

Hmm. float.lisp defines bfhalf spec var. And it's value is updated whenever fpprec1 is called. Maybe you don't need that at all.

And we should probably rename bfhalf to *bfhalf* along with the other spec vars updated in fpprec1. And rename 1//2 to *1/2*. Or make 1//2 a defconstant. But sbcl is really picky about what can be a defconstant.


________________________________
From: Raymond Toy <toy...@gm...><mailto:toy...@gm...>
Sent: Thursday, December 4, 2025 10:28 AM
To: max...@li...<mailto:max...@li...> <max...@li...><mailto:max...@li...>
Subject: Re: [Maxima-discuss] sometimes 1//2 =/= 1/2


Caution: Non-NU Email


On 12/4/25 5:43 AM, Barton Willis via Maxima-discuss wrote:

OK, maybe I found the culprit:

(defun bfloat-erf (z)
  ;; Warning!  This has round-off problems when abs(z) is very small.
  (let ((1//2 ($bfloat '((rat simp) 1 2))))
  ;; The argument is real, the result is real too
    ($realpart
      (mul
        (simplify (list '(%signum) z))
        (sub 1
          (mul
            (div 1 (power ($bfloat '$%pi) 1//2))
            (bfloat-gamma-incomplete 1//2 ($bfloat (power z 2)))))))))



And similarly for complex-bfloat-erf .  Changing  1//2 to bfhalf in this code didn't result in any testsuite failures, but I have a few pending changes to the function  absarg.
Nice bit of detective work! Yeah, renaming 1//2 to something else should take care of the problem.

Also, loading gamma.lisp gives the warning: (SBCL)

 in: DEFUN GAMMA-INCOMPLETE
;     (COND ((COMPLEXP MAXIMA::X) #C(0.0d0 0.0d0)) ((REALP MAXIMA::X) 0.0d0))

I think there are lots of these.

The issue here is that the compiler doesn't know what X is, so the cond cases of complexp and realp covers the case of numbers, but there are lots of other types which aren't covered.

This can be fixed in two ways. Add (declare (number x)). Add a T clause to cond. This should probably signal an error.

Or maybe even replace the cond with etypecase?

&#8203;
&#8203;

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

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

On 12/4/25 8:51 AM, Barton Willis wrote:

> I have tested changing (let ((1//2 ... to (let ((bfhalf ....  It fixes 
> the trouble and eliminates the need for the macro half that is used in 
> absarg.   I hope to commit this fix along with a few others in a few 
> weeks.

Hmm. float.lisp defines |bfhalf| spec var. And it's value is updated 
whenever fpprec1 is called. Maybe you don't need that at all.

And we should probably rename |bfhalf| to |*bfhalf*| along with the 
other spec vars updated in fpprec1. And rename |1//2| to |*1/2*|. Or 
make |1//2| a |defconstant|. But sbcl is really picky about what can be 
a |defconstant|.

>
>
> ------------------------------------------------------------------------
> *From:* Raymond Toy <toy...@gm...>
> *Sent:* Thursday, December 4, 2025 10:28 AM
> *To:* max...@li... 
> <max...@li...>
> *Subject:* Re: [Maxima-discuss] sometimes 1//2 =/= 1/2
>
> 	
> Caution: Non-NU Email
>
>
> On 12/4/25 5:43 AM, Barton Willis via Maxima-discuss wrote:
>
>> OK, maybe I found the culprit:
>>
>> (defun bfloat-erf (z)
>>   ;; Warning!  This has round-off problems when abs(z) is very small.
>>   (let ((1//2 ($bfloat '((rat simp) 1 2))))
>>   ;; The argument is real, the result is real too
>>     ($realpart
>>       (mul
>>         (simplify (list '(%signum) z))
>>         (sub 1
>>           (mul
>>             (div 1 (power ($bfloat '$%pi) 1//2))
>>             (bfloat-gamma-incomplete 1//2 ($bfloat (power z 2)))))))))
>>
>>
>>
>> And similarly for |complex-bfloat-erf| . Changing  1//2 to bfhalf in 
>> this code didn't result in any testsuite failures, but I have a few 
>> pending changes to the function |absarg.|
> Nice bit of detective work! Yeah, renaming 1//2 to something else 
> should take care of the problem.
>>
>> |Also, loading gamma.lisp gives the warning: (SBCL)|
>>
>>  in: DEFUN GAMMA-INCOMPLETE
>> ;     (COND ((COMPLEXP MAXIMA::X) #C(0.0d0 0.0d0)) ((REALP MAXIMA::X) 
>> 0.0d0))
>
> I think there are lots of these.
>
> The issue here is that the compiler doesn't know what X is, so the 
> |cond| cases of |complexp| and |realp| covers the case of numbers, but 
> there are lots of other types which aren't covered.
>
> This can be fixed in two ways. Add |(declare (number x))|. Add a |T| 
> clause to |cond|. This should probably signal an error.
>
> Or maybe even replace the |cond| with |etypecase|?
>
> &#8203;
&#8203;

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

[Barton W. <wi...@un...>]

I have tested changing (let ((1//2  ... to (let ((bfhalf ....  It fixes the trouble and eliminates the need for the macro half that is used in absarg.   I hope to commit this fix along with a few others in a few weeks.


________________________________
From: Raymond Toy <toy...@gm...>
Sent: Thursday, December 4, 2025 10:28 AM
To: max...@li... <max...@li...>
Subject: Re: [Maxima-discuss] sometimes 1//2 =/= 1/2

Caution: Non-NU Email


On 12/4/25 5:43 AM, Barton Willis via Maxima-discuss wrote:

OK, maybe I found the culprit:

(defun bfloat-erf (z)
  ;; Warning!  This has round-off problems when abs(z) is very small.
  (let ((1//2 ($bfloat '((rat simp) 1 2))))
  ;; The argument is real, the result is real too
    ($realpart
      (mul
        (simplify (list '(%signum) z))
        (sub 1
          (mul
            (div 1 (power ($bfloat '$%pi) 1//2))
            (bfloat-gamma-incomplete 1//2 ($bfloat (power z 2)))))))))



And similarly for complex-bfloat-erf .  Changing  1//2 to bfhalf in this code didn't result in any testsuite failures, but I have a few pending changes to the function  absarg.
Nice bit of detective work! Yeah, renaming 1//2 to something else should take care of the problem.

Also, loading gamma.lisp gives the warning: (SBCL)

 in: DEFUN GAMMA-INCOMPLETE
;     (COND ((COMPLEXP MAXIMA::X) #C(0.0d0 0.0d0)) ((REALP MAXIMA::X) 0.0d0))

I think there are lots of these.

The issue here is that the compiler doesn't know what X is, so the cond cases of complexp and realp covers the case of numbers, but there are lots of other types which aren't covered.

This can be fixed in two ways. Add (declare (number x)). Add a T clause to cond. This should probably signal an error.

Or maybe even replace the cond with etypecase?

&#8203;

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

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

On 12/4/25 5:43 AM, Barton Willis via Maxima-discuss wrote:

> OK, maybe I found the culprit:
>
> (defun bfloat-erf (z)
>   ;; Warning!  This has round-off problems when abs(z) is very small.
>   (let ((1//2 ($bfloat '((rat simp) 1 2))))
>   ;; The argument is real, the result is real too
>     ($realpart
>       (mul
>         (simplify (list '(%signum) z))
>         (sub 1
>           (mul
>             (div 1 (power ($bfloat '$%pi) 1//2))
>             (bfloat-gamma-incomplete 1//2 ($bfloat (power z 2)))))))))
>
>
>
> And similarly for |complex-bfloat-erf| . Changing  1//2 to bfhalf in 
> this code didn't result in any testsuite failures, but I have a few 
> pending changes to the function |absarg.|
Nice bit of detective work! Yeah, renaming 1//2 to something else should 
take care of the problem.
>
> |Also, loading gamma.lisp gives the warning: (SBCL)|
>
>  in: DEFUN GAMMA-INCOMPLETE
> ;     (COND ((COMPLEXP MAXIMA::X) #C(0.0d0 0.0d0)) ((REALP MAXIMA::X) 
> 0.0d0))

I think there are lots of these.

The issue here is that the compiler doesn't know what X is, so the 
|cond| cases of |complexp| and |realp| covers the case of numbers, but 
there are lots of other types which aren't covered.

This can be fixed in two ways. Add |(declare (number x))|. Add a |T| 
clause to |cond|. This should probably signal an error.

Or maybe even replace the |cond| with |etypecase|?

​

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

[Barton W. <wi...@un...>]

OK, maybe I found the culprit:

(defun bfloat-erf (z)
  ;; Warning!  This has round-off problems when abs(z) is very small.
  (let ((1//2 ($bfloat '((rat simp) 1 2))))
  ;; The argument is real, the result is real too
    ($realpart
      (mul
        (simplify (list '(%signum) z))
        (sub 1
          (mul
            (div 1 (power ($bfloat '$%pi) 1//2))
            (bfloat-gamma-incomplete 1//2 ($bfloat (power z 2)))))))))



And similarly for complex-bfloat-erf .  Changing  1//2 to bfhalf in this code didn't result in any testsuite failures, but I have a few pending changes to the function  absarg.

Also, loading gamma.lisp gives the warning: (SBCL)

 in: DEFUN GAMMA-INCOMPLETE
;     (COND ((COMPLEXP MAXIMA::X) #C(0.0d0 0.0d0)) ((REALP MAXIMA::X) 0.0d0))
; --> IF
; ==>
;   NIL
;
; caught STYLE-WARNING:
;   This is not a NUMBER:
;    NIL
;   See also:
;     The SBCL Manual, Node "Handling of Types"

I think this should be fixed.


________________________________
From: Barton Willis via Maxima-discuss <max...@li...>
Sent: Thursday, December 4, 2025 7:08 AM
To: <max...@li...> <max...@li...>
Subject: [Maxima-discuss] sometimes 1//2 =/= 1/2

Caution: Non-NU Email

The file globals.lisp defines 1//2 as ((rat simp) 1 2).  However, when I run the testsuite, I find that 1//2 is sometimes equal to a  bigfloat 1/2.

Specifically, out of 59,014 calls to the function absarg, 13,691 times 1//2 is a bigfloat half.
I noticed this when I saw that rpart.lisp defines a macro half that returns 1/2.  This macro was introduced eight years ago by Andreas Eder with the following commit message:
backed out the change that necessitated to relax the rel-error bounds
for the erf inverse_erf tests at +/- 2b0 and +/-2b0+/-2b0%i in rtest_gamma.mac.
The problem arises in the function absarg in rpart.lisp. Reintroduced
the half macro again for this use. It should make no difference, but the
code at this point seems to be a bit subtle :-)
Anyway, whith the old half macro instead of the variable 1//2 the test
results are unchanged.

I suspect the subtle problem is that something is converting 1//2 into a bigfloat 1/2  (with various values of fpprec).
There are hundreds of uses of 1//2 in the Maxima code. Changing the value of 1//2 is surely a bug.
Guess:  Fixing this bug will cause at least a handful of testsuite cases to fail.



--Barton

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

[Barton W. <wi...@un...>]

The file globals.lisp defines 1//2 as ((rat simp) 1 2).  However, when I run the testsuite, I find that 1//2 is sometimes equal to a  bigfloat 1/2.

Specifically, out of 59,014 calls to the function absarg, 13,691 times 1//2 is a bigfloat half.
I noticed this when I saw that rpart.lisp defines a macro half that returns 1/2.  This macro was introduced eight years ago by Andreas Eder with the following commit message:
backed out the change that necessitated to relax the rel-error bounds
for the erf inverse_erf tests at +/- 2b0 and +/-2b0+/-2b0%i in rtest_gamma.mac.
The problem arises in the function absarg in rpart.lisp. Reintroduced
the half macro again for this use. It should make no difference, but the
code at this point seems to be a bit subtle :-)
Anyway, whith the old half macro instead of the variable 1//2 the test
results are unchanged.

I suspect the subtle problem is that something is converting 1//2 into a bigfloat 1/2  (with various values of fpprec).
There are hundreds of uses of 1//2 in the Maxima code. Changing the value of 1//2 is surely a bug.
Guess:  Fixing this bug will cause at least a handful of testsuite cases to fail.



--Barton

[Maxima-discuss] verbatimmatrix

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

Hi list,

I found a way to write the display code for `verbatimmatrix'es, that,
very roughly, are `matrix'es of strings without the outer brackets and
without interline spacings. My code is here,

  https://anggtwu.net/MAXIMA/dim-verbatimbox.lisp.html
  https://anggtwu.net/MAXIMA/dim-verbatimbox.lisp

and the part that is going to be more useful to other people is the
part of the comments that explain that in the display code lists like
these one

   ((3 0)
    (-2 -2 #\g)
    (-4 -1 #\f #\e)
    (0 0 #\d #\c #\b #\a))

are to be read by humans as:

  Start at (x,y)=(0,0). Typeset "abcd". Now (x,y)=(4,0).
  Move by x+=-4, y=-1. Now (x,y)=(0,-1). Typeset "ef". Now (x,y)=(2,-1).
  Move by x+=-2, y=-2. Now (x,y)=(0,-2). Typeset "g". Now (x,y)=(1,-2).
  Move by x+=3, y=0. Now (x,y)=(4,0), and we're after the "d" of the "abcd".

I'm attaching a screenshot and a copy of the current version of code
for reference, but the htmlized version in

  https://anggtwu.net/MAXIMA/dim-verbatimbox.lisp.html
  https://anggtwu.net/MAXIMA/dim-verbatimbox.lisp

is much better becase its Eduardisms are explained by hyperlinks.
Cheers =),
  Eduardo

[Maxima-discuss] maxima on the latest 32-bit Trixie doesn't work

[Henry B. <hb...@pi...>]

Due to the phasing out of 32-bit computers, this error is probably only of hysterical importance:

pi@rpi:~ $ maxima
The assertion !madvise(m,p2,MADV_HUGEPAGE) on line 67 of o/msbrk.c in function msbrk failed: Invalid argumentAborted

pi@rpi:~ $ cat /proc/version
Linux version 6.12.47+rpt-rpi-v6 (se...@ra...) (arm-linux-gnueabihf-gcc-14 (Raspbian 14.2.0-19+rpi1) 14.2.0, GNU ld (GNU Binutils for Raspbian) 2.44) #1 Raspbian 1:6.12.47-1+rpt1 (2025-09-16)

Re: [Maxima-discuss] The decimal float package

[Michel T. <ta...@lp...>]

Le 30/11/2025 à 18:48, Richard Fateman a écrit :
> oading decfloat  via load(decfp):
> the following commands work
> bfloat(%i)
> bfloat(3)
>   but
> bfloat(3*%i) fails.
> bfloat(3*x)  fails
> bfloat(3+x) fails
>
>
> The bug occurs inside a call to dectimesbigfloat, decaddbigfloat...
> There's a test to see if any of the parts of the product or sum are 
> not convertible to decimal, in
> which case the usual (binary) bigfloat is used.
> but it then fails since it apparently cannot be converted to a bigfloat.


Indeed this happens because in decfp-core.lisp, the lisp functions 
$bfloat , bigfloatp, etc. are redefined, thus there is no way to recover 
a clean state afterwards, and when encountering bfloat(3*%i) the program 
$bfloat tries to multiply bfloat(3) by bigfloatp(%i) which returns NIL, 
hence the error message. Any other symbol like "x" does the same as %i. 
Trying to force bigfloatp to return %i instead of NIL doesn't work 
because £bfloat expects to see a list representing a bigfloat and not a 
bare symbol. So the bug comes because $bfloat doesn't understand complex 
numbers. However in the same file decfp-core.lisp there is at the end 
something supporting complex numbers, and this works.

maxima
Loading /home/michel/.maxima/maxima-init.mac
Maxima 5.48.1 https://maxima.sourceforge.io
using Lisp SBCL 2.5.8
(%i1) load(decfp);
redefining bigfloat %TAN to also work for decimal bigfloat
redefining bigfloat %LOG to also work for decimal bigfloat
redefining bigfloat %SIN to also work for decimal bigfloat
redefining bigfloat %ATAN to also work for decimal bigfloat
redefining bigfloat %COS to also work for decimal bigfloat

(%o1) /usr/local/share/maxima/5.48.1/share/numeric/decfp.lisp
(%i2) :lisp(bigfloat::bigfloat #$1+3*%i$)

+1.0b0+3.0b0*%i

Note this is in a special package :bigfloat.  Thus i think that 
inserting a proper call to this function should solve the bug.But i 
don't see any hope that other float functions work correctly after 
having loaded decfp.



-- 
Michel Talon

Re: [Maxima-discuss] Fail to understand result of funcsolve

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

On Mon, Nov 24, 2025 at 12:15 PM Michel Talon <ta...@lp...> wrote:

> Package Zeilberger doesn't seem to allow to compute the sum.
>
> (%i16) GosperSum((%j+1)*(%j+2)/%j,%j,1,n-1);
> (%o16)                        NON_GOSPER_SUMMABLE

For the record, the package simplify_sum (which makes use of Gosper's
and Zeilberger's algorithms and others) returns the following result.

(%i2) load (simplify_sum) $
(%i3) sum ((%j+1)*(%j+2)/%j,%j,1,n-1);
(%o3) 'sum(((%j+1)*(%j+2))/%j,%j,1,n-1)
(%i4) simplify_sum (%);
(%o4) (n+(n-1)^2-1)/2+3*(n-1)+2*harmonic_number(n-1)

which seems plausible, although I didn't check it.

best,

Robert

Re: [Maxima-discuss] Fail to understand result of funcsolve

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

 Hi All,
I've opened a bug report: #4640 Erroneos result of funcsolve.
Daniel Volinski

    En lunes, 24 de noviembre de 2025, 22:17:31 GMT+2, Michel Talon <ta...@lp...> escribió:  
 
  
As a matter of fact the program bugs because at line 342 one has a division by zero due to the fact that product(%a, %l, lo, %n-1) vanishes since it is
 
the product of %l^2/(%l^2+2*l) starting from l=0.  The way to get out of this problem is to impose a condition such as f(1)=1, then the product starts at
 
%l=1.  This can be checked by inserting some prints.
 
 
solve_rec((n+1)*f[n]-(n-1)*f[n-1]=(n+1)/(n-1),f[n],f(1)=1);
 
yields after applying factor to the result:
 
f[n] = ('sum(((%j+1)*(%j+2))/%j,%j,1,n-1)+2)/(n*(n+1))$
 
Package Zeilberger doesn't seem to allow to compute the sum.
 
 
(%i16) GosperSum((%j+1)*(%j+2)/%j,%j,1,n-1);
 (%o16)                        NON_GOSPER_SUMMABLE
 
 
 Le 24/11/2025 à 17:06, Barton Willis via Maxima-discuss a écrit :product(%a, %l, lo, %n-1)
  
The share package solve_rec is also unable to handle your recursion:
 -- 
Michel Talon _______________________________________________
Maxima-discuss mailing list
Max...@li...
https://lists.sourceforge.net/lists/listinfo/maxima-discuss