Menu
▾
▴
maxima-discuss
|
From: Barton W. <wi...@un...> - 2025-12-05 18:21:59
|
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 |
|
From: Raymond T. <toy...@gm...> - 2025-12-05 21:59:13
|
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. |
|
From: David S. <d.s...@go...> - 2025-12-05 23:25:03
|
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 > |
|
From: Raymond T. <toy...@gm...> - 2025-12-05 23:39:37
|
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 > |
|
From: Richard F. <fa...@gm...> - 2025-12-05 23:52:15
|
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 > |
|
From: Raymond T. <toy...@gm...> - 2025-12-06 01:44:07
|
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 > |
|
From: Raymond T. <toy...@gm...> - 2025-12-06 16:31:01
|
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. ​ |
|
From: Stavros M. <mac...@gm...> - 2025-12-06 16:47:11
|
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
>
|
|
From: Richard F. <fa...@gm...> - 2025-12-06 18:04:18
|
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 >> > |
Thanks for helping keep SourceForge clean.
X