There are a couple of type bits left. If we need more, I have a plan
for encoding the non-noun types in four bits.
Like you say, adding a new type is Big Deal, touching every primitive.
For example, Roger estimated 2 Roger-years of effort to implement
bit-booleans.
Henry Rich
On 11/1/2018 2:21 PM, Raul Miller wrote:
Conceptually speaking, this might be handled as a native J type (this
would require changing the C implementation of the J engine).
There are four issues that I can think of that would need to be dealt with:
[1] parsing support so that 1i2j3k4 (for example) could be recognized
as a quaternion.
[2] "display" support so that quaternions can be converted back into a
representative sequence of characters
[3] "type" support so that quaternions could be atoms in arrays.
[4] the implementation itself (currently represented in the
addons/math/mt/quatern.ijs, for the most part)
The first two could also be thought of as deserialization and
serialization (if you are inclined to do searches for analogous
implementations in other contexts).
One "tricky" issue is that we use a fixed width bitmask to represent
types in the context of verb domain. If I recall correctly (but it's
been probably a year since I spent any time looking at this), we had
maybe one bit left in a 32 bit representation. Conceptually speaking,
that maybe means we should extend type representation to be 64 bits
even on 32 bit machines (which might break some C code for 32 bit
machines...).
Another issue is that it might be fun for some people to play with
types in J (instead of in C). It might make sense to set aside one or
more types for such experimentation. Conceptually, a type would have
an identifying location in the type bitmask, an element size in arrays
of that type, a serialize routine, a deserialize routine, a conversion
routine (for quaternions, this would convert non-quaternion numbers to
quaternions), conversion priority for dyads (when adding a quaternion
and an extended precision number, or a quaternion and some other user
defined type number which one gets converted to what?), and finally,
for each supported operation a monad and a dyad definition.
(That's a lot of detail, but it also gives an idea of the scope of
work which has gone into building the engine. But it also hints at why
this kind of thing can easily break or maybe feel inadequate when it's
handled in some other way.)
Anyways... potentially a lot of work... but interesting to think about.
Thanks,
---
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
