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
