Re: [Sbcl-help] [Maxima-discuss] Maxima numerics

[Stavros Macrakis]

Is there any way to take advantage of IEEE float NaN boxing in SBCL?

              -s

[Douglas Katzman via Sbcl-help]

On Sun, Nov 7, 2021 at 8:59 PM Stavros Macrakis <macr...@alum.mit.edu> wrote:

Is there any way to take advantage of IEEE float NaN boxing in SBCL?

What information would you want to put in the box?

 

[Stavros Macrakis]

Hi, Doug,

There's been a discussion on the Maxima group about how to better integrate extended number types (like Maxima's bigfloats or intervals or bigfloat complex...) into the codebase.

Currently, Maxima objects are either atoms or their caar tells you their type. So you see code like this:

    (cond ((atom ex)

           (cond ((numberp ex) ...)   ; handle machine numbers

                   ...))

          ((eq (caar ex) 'bigfloat) ...) ; handle Maxima bigfloats

It was proposed that stashing bigfloats as a pointer in the NaN box of a float could make this simpler, but no one seems to have a concrete idea of how this would work with CL.

Would they be signalling NaNs which would dispatch to an extended arithmetic routine? Would this somehow be integrated with CLOS? etc.

That being said, it's not at all clear to me that this would simplify our code. For one thing, we would have to review all existing code for assumptions it makes (e.g., numberp implies realp, which isn't even true for CL numbers; trichotomy: not true for complexes and intervals) and tease out the exception cases. There are still parts of the Maxima code which don't accept bigfloats as numbers -- almost 50 years after bigfloats were added to the system!

So it would be interesting to know what has already been done with NaN boxing in CL in general and SBCL in particular.

               -s

[Douglas Katzman via Sbcl-help]

I can't see getting much mileage out of taking an abstraction like vanilla lisp and expecting to get much mileage out of Nan boxing as the storage mechanism for application-specific data types.

If you wanted to be unportable, it's unclear to me why NaN-boxing is relevant at all. You'd just want to extend the Lisp implementation to support more numeric types by properly integrating them into both the type system and the primitive object representation via additional tags.  The notion that you would have, let's say, a double-float primitive object which holds a NaN be treated as some other subtype of number seems absurd to me given that you could just define the other type of number as having a different bit pattern that meshes well with the lisp implementation.  Not to mention, using the available bits of a NaN as a container for pointer data would need proper support in the GC anyway.

If, on the other hand, portability is required, then you're going to have a bad time for other reasons, as people have pointed out.

I understand that Javascript engines use NaN boxing, but Javascript is the implementation of the VM analogously to what SBCL is; so its picks its representations for things, and it happens to have picked the machine's double-float for most things (if not everything), and it likes to pack bits in there to represent strings and integers, and that's fine, because it also implements its own GC.  So the _implementation_ of that is unportable, but only the implementers care.

We had a similar-feeling question asked about whether webassembly should do <X> because Lisp, and as before my answer is that it depends on which hat you're wearing: language implementor, or language consumer.

[Stavros Macrakis]

On Mon, Nov 8, 2021 at 1:56 PM Douglas Katzman <do...@google.com> wrote:

I can't see getting much mileage out of taking an abstraction like vanilla lisp and expecting to get much mileage out of Nan boxing as the storage mechanism for application-specific data types.

I completely agree. I just wanted to make sure that there wasn't some clever idea or implementation out there that I hadn't considered.

This whole thread seems to me like a solution chasing a problem = because-it's-there'ism.

I'll write a separate answer to the Maxima-discuss group, with Doug on CC.

                 -s