The point of my story about the rank-64 bug in IBM's APL of the 70s was that hacking the system was the only use I ever encountered for high-dimensional arrays. I have never used anything higher than rank 6 in actual code but that's over the past 50 years, so there's still time.
On Tue, Apr 6, 2021 at 10:30 AM Henry Rich <[email protected]> wrote: > Space saving. The V struct, describing a verb, fills 128 bytes, and I > need to add to it. If the maximum rank is reduced from 65535 to less > than 256, I can avoid requiring a third cacheline. > > Henry Rich > > On 4/6/2021 12:20 AM, Roger Hui wrote: > > I repeat my question, what are the benefits of restricting array rank to > be > > ≤ 63 ? > > > > > > > > On Mon, Apr 5, 2021 at 8:28 PM Henry Rich <[email protected]> wrote: > > > >> 'May be'. Have you actually implemented it? > >> > >> I find it very hard to believe that a J sparse array would be the best > >> choice for any database. It seems to me to: > >> > >> * take lots of memory per value > >> * have limited or inefficient queries > >> * be very slow for updates, as the entire table must be copied > >> > >> Please prove me wrong. > >> > >> Henry Rich > >> > >> On 4/5/2021 10:04 PM, Igor Zhuravlov wrote: > >>> On Sun, Apr 4, 2021, 11:52 PM Henry Rich <[email protected]> wrote: > >>>> I propose that the maximum value for a rank, whether of a verb or a > >>>> noun, will be 63. Minimum verb rank will be _63. > >>>> > >>>> You got a problem with that? > >>> A database in J may be implemented as a sparse boolean orthotope where > >> each > >>> axis corresponds to some attribute (field, column of relational table), > >> and > >>> value 1 ("true") marks tuple [1]. > >>> > >>> A restriction proposed will limit a number of attributes to <64 for > this > >>> application. It would be sad but not fatal. I'd prefer to have this > limit > >>> larger, say, O(1e5). > >>> > >>> References: > >>> [1] > http://www.jsoftware.com/pipermail/general/2000-February/003102.html > >>> Jforum: Sparse Array as Database ? > >>> Roger Hui > >>> Thu Feb 10 19:06:50 HKT 2000 > >>> > >> > >> -- > >> 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 > >> > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > -- > 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 > -- Devon McCormick, CFA Quantitative Consultant ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
