Thank you Eric, that makes a lot of sense.
On Mon, 2 Aug 2021, Eric Iverson wrote:
bit data type:
It is partly an issue of resources and how to spend them. Adding a bit data
type is a large amount of work. And at least so far we have found better
areas to work on. Also the playing field for those old arguments have
changed and continue to change. APL already has them and it should keep
them. J doesn't have them and so far doesn't miss them except for some
academic arguments. In the early APL days memory space was critical and
they also allowed some fast algos. Memory is much less important now and
new hardware allows many fancy tricks.
For J, we have decided they are not worth the effort of complexity it would
add to the JE.
On Mon, Aug 2, 2021 at 4:01 PM Elijah Stone <[email protected]> wrote:
Apologies if this is the wrong place for this.
First: what's the deal with bitarrays? I have heard APL implementors
state with great conviction that they are worthwhile and have led to great
performance increases; and I have heard J implementors state with equal
conviction that they are not worth their while at all. I don't know whom
to believe!
Second: is it worth it to add padding for >1-rank arrays? It seems
convenient for major cells (and perhaps more minor cells as well) to be
aligned, and I know of at least one high-performance in-place high-rank
transposition algorithm which requires some degree of padding/alignment.
J's array structure doesn't seem to make any allowance for more than one
shape. Has this approach been tried and found lacking, or is it just
untrodden ground?
-E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
