Conceptually, here, you're probably thinking about using hashes of
character strings as array indices.

A character string, in J, is either a boxed rank 1 list of characters
or a rank 1 member of a higher dimensional character array which has
been padded on the right hand side with spaces.

Since all of the current array index primitives throw an error when we
try to use characters to index them, I think that we would not need
any new primitives -- we would "only" need to characterize the
normalization process used to convert arbitrary character arrays or
boxed character arrays to array indices.

That said, these hashed arrays would also be sparse. And, it would be
desirable to support boxed items and boxed hashes. And that gets into
some issues which are ... rather involved, if we think about the
existing sparse array implementation.

So ... when estimating this task it might be best to think of it as
"re-implementing sparse arrays from the ground up"?

Thanks,

-- 
Raul

On Wed, Apr 14, 2021 at 10:24 AM Henry Rich <[email protected]> wrote:
>
> If we could come up with a good spec for hashing primitives, we could
> implement it.  JE does lots of hashing, notably in the i.-family, but
> the table is not exposed to the user.  When I have thought about hashing
> primitives, I have ended up deciding it could be done in an addon just
> as well as in a primitive.
>
> I agree we should find a solution to add hashing to the user's toolkit.
>
> Henry Rich
>
> On 4/14/2021 7:45 AM, Julian Fondren wrote:
> > The complaint isn't "a program like that can't be written", or the
> > argument would be that J isn't even Turing complete. The complaint
> > is "I can't write a program like that in the manner I'd like."
> >
> > Quotes:
> >
> >   * No non-array data structures: hash tables, trie, graphs, etc. This
> > is a show stopper because so many problems are easier to reason about
> > and to solve by picking a more suitable data structure.
> >
> >   I reason about those things in terms of mathematics and abstract
> > structures: I'd venture to say that's par for the course because its
> > easiest.
> >
> > Suppose you want to translate a program you've written in a non-APL
> > language into J. Much of the program can simply be transliterated,
> > page-into-sentence, without much concern for the overall design
> > of either program... unless a non-array data structure is very
> > important. Now you have to think about how precisely the original
> > program is using the data structure and how you can do that in some
> > other way in J.
> >
> > The same speedbump shows up if you're following a tutorial, or trying
> > to implement an algorithm according to a book or paper's description:
> > as soon as a non-array data structure's properties become important,
> > there's an abrupt increase in the difficulty of your task and of
> > the depth of understanding of the problem domain that's required of
> > you.
> >
> > The abruptness is off-putting all by itself. Imagine a language where
> > + - * are all available but % isn't and the response to wanting it is
> > 1. have you considered solving your problem without division? It's
> >    very expensive! With a constant denominator and fixed-width integers
> >    it's even possible to divide *with* multiplication by a magic number.
> > 2. you can implement it yourself (with unusually bad performance)
> > 3. you can get it from the FFI
> > 4. is this so weird? ARM processors don't have % instructions.
> >
> > Yeah, it's pretty weird. Not having hash tables has also become weird.
> >
> > On 2021-04-14 05:25, ethiejiesa via Programming wrote:
> >> It's not J, but FWIW Dyalog APL apparently can boast this realistic,
> >> immersive simulation of some piece of Finnish  coastline. The 3D
> >> engine is an external dependency, but supposedly everything else is
> >> straight APL:
> >>
> >> https://www.dyalog.com/case-studies/simulation.htm
> >>
> >> Since the core of that project is taking large amounts of data,
> >> scattered in lots of non-uniform formats, and munging it into a
> >> concrete realtime visualization, you might find it
> >> interesting/inspiring/helpful/whatever.
> >
> > ----------------------------------------------------------------------
> > 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to