To respond to Henry (…I guess)
I wrote:
> Swift boasts a me-too *dictionary* à-la Python, but I've never found a
use for it.
I need to eat my words. I may indeed have an important use for *Dictionary* in
Swift.
I'm just about to implement syntax coloring in j901 for iOS (and – no I
can't use Qt / Cairo because it won't get past App Store review). How about
storing the different-colored J words in dictionaries, one for each color?
Otherwise I'll need to implement the defaulted x-argument of Words (;:) in
Swift using nested case-statements, stepping thru the J script
line-by-line, then character by character. I shy away from doing this
because Swift's implementation of colored characters (so-called "attributed
strings") is so head-banging I expect it to be s-l-o-w.
I already have an implementation in J, but there are one or two gotchas
which Swift handles as a matter of course. As ever, the devil is in the
detail. Things like: what if the J user wants to preserve redundant spaces?
Or have strings or comments in Arabic, or embedded emojis? If you're
writing an IDE, as distinct from a domain-specific app, you really have to
field whatever the user throws at you – or recover gracefully.
My test-piece is stdlib.ijs (2658 lines) or maybe dissect.ijs (17068
lines). The editor should color the entire script in under 2 seconds. My
solution will be based not only on which technique is fastest, but which
requires the fewest patchups and special cases.
The speed of the *Dictionary* solution will boil down to hashing, as I
think Henry is predicting. Have the Apple gnomes done the job thoroughly
and implemented hashing for Arabic keys, or whatever global writing system
Unicode supports? I'll soon find out.
On Tue, 1 Feb 2022 at 17:33, 'Pascal Jasmin' via Programming <
programm...@jsoftware.com> wrote:
> unique keys is a pretty important aspect of dictionaries.
>
> It permits SET (or Alex's merge) functionality to determine whether it is
> an update or an append. Where users appreciate this "auto-functionality".
> Without unique keys, the user must determine if they want update vs append,
> and if it is update "1 record" have a means to select (somehow) which of
> the duplicate keyed records they want to update.
>
> without duplicate keys, this is an associative array. ie 2 unrestricted
> regular J arrays.
>
>
>
>
> On Tuesday, February 1, 2022, 10:19:50 a.m. EST, Henry Rich <
> henryhr...@gmail.com> wrote:
>
>
>
>
>
> This discussion is important. I'd like to continue from this post.
>
> To respond to Ian, who asked Who really needs this anyway? I say that I
> got great use from C++ classes for ordered_map and unordered_map. The
> operations can be done in J, but the speed advantage of hashing for
> lookups is so significant as to make the difference between tolerable
> and intolerable performance.
>
> I would change the definition to:
>
> A Dictionary is a collection of key/value pairs, where the keys and
> values can have any type and shape. Keys are not necessarily unique.
> Keys and values may be given as unboxed but they will be boxed
> immediately before going into the Dictionary.
>
> Supported operations:
>
> Dic =: ~. Dic discard kvs for duplicate keys
> Dic =: Dic , k,v add a KV
> k { Dic read value[s]
> Dic =: v k} Dic replace kv
> k e. Dic How many times does key exist?
> {."1 Dic list of all keys
> {:"1 Dic list of all values
>
> ?? delete key
>
> Rob: what needs to be added to make the dictionary type as useful as it
> is in K?
>
> Henry Rich
> > To answer Henry's questions:
> >
> > My definition of a dictionary is:
> > A collection where data is organized by key, where keys can be symbols,
> > strings, or numbers (or possibly other data types) and values can be
> > arbitrary J data.
> >
> > Essential dictionary operations are:
> > - create/read/update/delete by key
> > - query if key exists
> > - enumerate all keys (returns an array of boxed keys)
> > - enumerate all values (returns an array of boxed values)
> > - merge two dictionaries e.g. (Z=: X merge Y) and if X and Y share any
> key,
> > then Z gets the key/value pair from Y
> >
> > Nice features to have, but not necessary:
> > - keys are stored in J's sorting order
> > - dictionaries can be serialized/deserialized for persistent disk storage
> > or for sending to other processes
> >
> >
>
>
> --
> 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
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
