Dictionaries in q/k are actually a core part of the language, not just a tool
or package.
Dictionaries are the tool behind namespaces.
Dictionaries are also the ‘items’ in the table data structures.
If you have a list of dictionaries of keys and equal length values, then in the
special case:
Flip (or transpose) of the Dictionary _automatically_ converts to a
Table (from which the user can Select …)
I don’t wish to present examples in this email, but instead attach a ‘brief’
sample of q from a paper I wrote “A Taste of Q” (about 120 lines of session
output)
(I am very happy the full PDF paper to anyone who wishes a copy, it is about 23
pages that showcases q).
The sample is all about q dictionaries to understand how they extend to become
the building blocks of Tables (and although not shown here, namespaces).
A dictionary is a list of Key ! Value pairs, but as a basic data type that also
allows indexing, assignment and assignment by key (eg name).
They are an incredibly powerful part of q and also very elegantly implemented.
Symbols and Symbol lists are also a core requirement (not quoted strings which
might make things difficult in J).
Building a dictionary as a data structure will deliver half the potential of
dictionaries, but to deliver the full potential I would argue for a primitive
implementation on which other primitives can apply.
I agree with Eric, it should be modelled, and anyone involved in that should
closely study the q implementation of dictionaries and how this core data
structure underpins such a large part of q (and helped to make the interpreter
as small and powerful as it is… and in this regard I can see Henry wincing,
making dictionaries a core part of J is likely not feasible, but at least a
full understanding of q might help to pave the way as a key datatype.
If I can find the time I’d be happy to help on the model… sample file attached
as a .txt file… note the q) commands may all be typed into a q session to play.
You can download a free copy of q for personal use from www.kx.com
<http://www.kx.com/>.
Regards Rob
> On 1 Feb 2022, at 5:27 am, Henry Rich <henryhr...@gmail.com> wrote:
>
> I have looked into this quite a bit. I am not convinced that Dictionary is a
> fundamental datatype like number or letter, or that the current symbol
> support is deficient. That makes the first questions What is a Dictionary?
> and Where can a Dictionary be used in J?
>
> The use case that would be important to me is a key-value store, aka
> associative memory, where the Dictionary remember keys and values and later
> returns a value when presented with the key. This feels to me like a package
> written in J rather than a J primitive. A Dictionary would be a numbered
> locale. The place where I could see added support inside J would be in
> adding to and deleting from hashtables, specifically ones created/used by
> m&i. .
>
> I invite proposals on what a Dictionary package needs to do. I have done
> this before, and Jan-Pieter Jacobs responded with a package. Quoting from
> his message of 20210327:
>
> *** QUOTE
>
> install'github:jpjacobs/types_dict@main'
>
> (except on (my) android, where github installs don't seem to work, neither
> in the Gui version JA nor on the commandline via termux)
>
> It is pretty simple in use, you just use:
> d=: dict keys;vals
> for creating the dictionary, which is a OOP object, having the following
> methods:
> get, set, map, sort, destroy, whose documentation is contained in
> help_pdict_
>
> For performance, the create verb precomputes the lookup for the get verb,
> both forward get (key->value) and backward get inv (value->first key) upon
> object creation.
>
> *** END QUOTE
>
> I have not looked into this package, but it seems to me to have the right
> entry points. Can we take that as a starting point to see what needs to be
> added? The first step of course would be to put the addon under Package
> Manager.
>
> Henry Rich
>
>
>
> On 1/31/2022 12:58 PM, Elijah Stone wrote:
>> I agree with Eric regarding the challenges of adding dictionaries.
>>
>> One issue: I think a necessary prerequisite is improved symbols.
>>
>> On Mon, 31 Jan 2022, Alex Shroyer wrote:
>>
>>> I agree with Raoul that competing with Python is not a good idea.
>>> But J can learn from Python's decisions (good and bad) to grow and improve.
>>> In my opinion, numpy is Python's "killer app" because it brings reasonable
>>> performance without much conceptual overhead.
>>> The feature of Python that enabled numpy is its extensibility, down to the
>>> C layer.
>>>
>>> There are other good features of Python that J could copy, in particular
>>> the 'dictionary' data type.
>>> The array language K has dictionaries, so J might take some inspiration
>>> from there for integrating them into the language.
>>>
>>> Cheers,
>>> Alex
>>>
>>>
>>> On Mon, Jan 31, 2022 at 5:30 AM Raoul Schorer <raoul.scho...@gmail.com>
>>> wrote:
>>>
>>>> Just my 2c, but I think that competing with python in general is somewhat
>>>> delusional. I think the key point for expanding J use to have a "killer J
>>>> app". For example, an improved clone of or excellent plugin for VisiData (
>>>> https://www.visidata.org/) is my idea of a killer app. But someone here
>>>> may
>>>> have a better idea?
>>>>
>>>> Cheers,
>>>> Raoul
>>>>
>>>> Le lun. 31 janv. 2022 à 03:49, Ric Sherlock <tikk...@gmail.com> a écrit :
>>>>
>>>> > Yes from a data structure point of view, inverted tables get you a lot of
>>>> > the way (note they're also available in the 'general/misc' addon - load
>>>> > 'general/misc/inverted' ) and I've used them to good effect in my
>>>> > 'data/struct' addon (https://github.com/tikkanz/data_struct).
>>>> > I agree that J's arrays are more general, flexible & powerful. But when
>>>> > you're dealing with a tabular data set there is an overhead to keeping
>>>> the
>>>> > fields in a table in sync that dataframes can help with. Perhaps it's
>>>> > something abstracting the structure so you don't have to deal so much
>>>> with
>>>> > the mechanics of manipulating it? At least for me :)
>>>> >
>>>> > On Mon, Jan 31, 2022 at 3:28 PM Elijah Stone <elro...@elronnd.net>
>>>> wrote:
>>>> >
>>>> > > https://code.jsoftware.com/wiki/Essays/Inverted_Table, perhaps?
>>>> > >
>>>> > > That said, I think a great strength of j is that data are _not_
>>>> > explicitly
>>>> > > tabular. The associations are defined in an ad-hoc manner as needed by
>>>> > > the programmer. This is also an essential difference between the array
>>>> > > paradigm and the relational paradigm (cf SQL): in the former, pointers
>>>> > > come with implicit context; in the latter, that context must be
>>>> explicit.
>>>> > >
>>>> > > -E
>>>> > >
>>>> > > P.S. regarding analysis/optimization: I would love to see it, but for
>>>> > some
>>>> > > reason everybody is scared of building a compiler because of the
>>>> parsing
>>>> > > problem.
>>>> > >
>>>> > > On Mon, 31 Jan 2022, Ric Sherlock wrote:
>>>> > >
>>>> > > > Yes, I've been thinking that a Dataframes equivalent in J would be
>>>> > > useful.
>>>> > > > Most things are already possible with J's arrays, but conceptually
>>>> > > > DataFrames are well understood by many now, and they make it easy to
>>>> > work
>>>> > > > with datasets as named fields.
>>>> > > > I've spent a reasonable amount of time working with Pandas, but have
>>>> > > > recently been using Polars (Rust backend with Python bindings) which
>>>> > > really
>>>> > > > shines for larger datasets. Performance (especially read/write) is
>>>> > > awesome,
>>>> > > > and the LazyFrames which optimise your query/analysis plan make a big
>>>> > > > difference too.
>>>> > > > I haven't taken enough time to explore it, but maybe Jd is the
>>>> starting
>>>> > > > point in this space for J?
>>>> > > >
>>>> > > >
>>>> > > > On Mon, Jan 31, 2022 at 9:01 AM Michail L. Liarmakopoulos <
>>>> > > > m.l.liarm...@gmail.com> wrote:
>>>> > > >
>>>> > > >> Hello all,
>>>> > > >>
>>>> > > >> I find any parallels between python and J pretty interesting, being
>>>> a
>>>> > > >> person with some python experience and an interest of the
>>>> applications
>>>> > > of
>>>> > > >> both python and J in mathematical modelling, analytics,
>>>> computational
>>>> > > math
>>>> > > >> and perhaps computational physics too.
>>>> > > >>
>>>> > > >> If you'd like to bring some features from the python math/analytics
>>>> > > >> libraries/ecosystem in J, I'd suggest you to look at the features of
>>>> > > three
>>>> > > >> libraries:
>>>> > > >>
>>>> > > >> - numpy (I believe most features are already covered from the built
>>>> in
>>>> > > >> features of an array language such as J)
>>>> > > >>
>>>> > > >> - pandas ( a nice library for manipulating csv files within python
>>>> as
>>>> > > >> dataframe objects -- see the dataframes from the R language)
>>>> > > >>
>>>> > > >> - scipy (a collection of methods and functions ranging from solving
>>>> > > >> numerically: differential equations, evaluating definite integrals,
>>>> > > >> constrained and unconstrained optimization, and I believe statistics
>>>> > > too)
>>>> > > >>
>>>> > > >> There is also out there an amazing python library for symbolic
>>>> > > calculations
>>>> > > >> (like the ones you can do with Mathematica or WolframAlpha: symbolic
>>>> > > >> evaluation of definite and indefinite integrals, symbolic solutions
>>>> of
>>>> > > >> diff. equations, symbolic solutions of algebraic and Diophantine
>>>> > > equations
>>>> > > >> etc...). It's called sympy.
>>>> > > >>
>>>> > > >> But I'm not sure if you'd like J to include symbolic computations
>>>> too
>>>> > > or if
>>>> > > >> the aim of the language is to excel only in numerics, data
>>>> analytics,
>>>> > > >> stats, whatever can be quantified pretty much.
>>>> > > >>
>>>> > > >> My few cents as food for thought.
>>>> > > >>
>>>> > > >>
>>>> > > >> Best regards,
>>>> > > >>
>>>> > > >> ---
>>>> > > >> Michail L. Liarmakopoulos, MSc
>>>> > > >>
>>>> > > >> On Sun, Jan 30, 2022, 20:39 R.E. Boss <r.e.b...@outlook.com> wrote:
>>>> > > >>
>>>> > > >> >
>>>> > > >> >
>>>> > > >> > I copied the first chapter of the book A Journey to Core Python
>>>> (in
>>>> > > >> >
>>>> > > >>
>>>> > >
>>>> >
>>>> https://drive.google.com/file/d/1p1uIANh-LFniNNRqjDeeWWd4_-ddEZmz/view?usp=sharing
>>>>
>>>> > > >> )
>>>> > > >> > and have the question: do we want that J is competitive with
>>>> Python?
>>>> > > >> >
>>>> > > >> > If the answer is yes, the next question is: what is the to do list
>>>> > to
>>>> > > be
>>>> > > >> > competitive and how long will it take?
>>>> > > >> >
>>>> > > >> > (And then the unavoidable question: WHY?)
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > > >> > Personally I think we must aim on the niches in the market, as
>>>> there
>>>> > > are
>>>> > > >> > the mathematical oriented people, e.g. the broad scientific
>>>> > community.
>>>> > > >> >
>>>> > > >> > Then all people experienced in Excel or other spreadsheets or
>>>> > > calculation
>>>> > > >> > tools.
>>>> > > >> >
>>>> > > >> > Schools and universities. Financial and statistical oriented
>>>> people.
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > > >> > What we should do, IMHO, is
>>>> > > >> >
>>>> > > >> > - to emphasize the strengths of J,
>>>> > > >> >
>>>> > > >> > - to improve (considerably) the error handling of J,
>>>> > > >> >
>>>> > > >> > - to admit the steep learning curve,
>>>> > > >> >
>>>> > > >> > - to facilitate the use of mnemonics instead of primitives (I
>>>> tried
>>>> > > this
>>>> > > >> > afternoon the primitives.ijs for half an hour, but was not capable
>>>> > of
>>>> > > use
>>>> > > >> > any mnemonic, not even with
>>>> > > >> > https://code.jsoftware.com/wiki/Primitives_to_Mnemonics)
>>>> > > >> >
>>>> > > >> > - to decide which of the features, benefits or applications (of
>>>> > > Python)
>>>> > > >> we
>>>> > > >> > want J to have.
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > > >> > Just my 2 cents.
>>>> > > >> >
>>>> > > >> > R.E. Boss
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > ----------------------------------------------------------------------
>>>> > > >> > 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
>>>> > > ----------------------------------------------------------------------
>>>> > > 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
>>>>
>>> ----------------------------------------------------------------------
>>> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
