I disagreed with 'symbols' in 1
Roger Hui writes:
Premature optimization is said to be the root of all evil in programming
[Knuth 1974, p.671], but premature generalization is worse. Premature
optimizations can at least be backed off
If we start with only symbols as dictionary keys, then i
Another model to think about here is K's implementation, where the symbol
table is a tree, and thus supports contexts which do not have equal length
columns.
--
Raul
On Mon, Jan 31, 2022 at 9:54 PM Ric Sherlock wrote:
> > otoh, we already have a binding to R where you can deal
> > with datafra
I think I agree with all your statements, but you are not responding to
my questions, which will help focus the discussion:
1. What is a Dictionary, EXACTLY?
2. What operations can be performed on a Dictionary?
Henry Rich
On 2/1/2022 12:04 AM, 'Pascal Jasmin' via Programming wrote:
The simp
I disagreed with 'symbols' in 1 and I didn't understand 2:
>> At least: domain (new primitive) index transpose amend apply-at-rank
filter indices. From rank follows any rank-0 operation. Maybe: key
catenate shape reshape nub index-of tally reduce.
Please: when I was younger, I might have sa
The simplest dictionary is a table with 2 columns. First named k(ey), other
named v(alue)
A J locale is also a simple dictionary. Keys are limited to legal names, but
values are independently typed. It is difficult to find keys by value, whereas
it is simpler in the 2 column table concept.
Can you clarify what you disagree with and what you don't understand?
1. A Dictionary is an array some of whose axes are indexed by
non-numeric value; that is, the index is not an integer.
1. I assume fractional and complex numbers are allowed too?
2. Is the array still rectangular? [propose
A good start. You give two sentences, one of which I disagree with and
the other I can't understand at all. I would say:
1. A Dictionary is an array some of whose axes are indexed by
non-numeric value; that is, the index is not an integer.
2. The Dictionary supports the following operations
On Mon, 31 Jan 2022, Henry Rich wrote:
Many ideas have been aired. But please, every now and again address the
questions I need answers for:
I gave one answer to this earlier:
1. What is a Dictionary, EXACTLY?
An array some of whose axes are indexed by a set of symbols rather than
a rang
Many ideas have been aired. But please, every now and again address the
questions I need answers for:
1. What is a Dictionary, EXACTLY?
2. What operations can be performed on a Dictionary?
Henry Rich
On 1/31/2022 11:09 PM, 'Pascal Jasmin' via Programming wrote:
I forgot to mention that th
I forgot to mention that the GET/SET interface can be applied to basic arrays
and matrices and would mirror functionality of primitives such as { i.
Independently, of whether data structures have a backend that syncs them to
disk for permanence, they all have get/set/append/delete processing fu
> otoh, we already have a binding to R where you can deal
> with dataframes easily – do we want to “compete” here, too?
>
> In terms of whether to just adopt/use one of R's/Pandas'/Polars'/Julia's
dataframes rather than reinventing the wheel - I think for me that if it
were possible to use J primit
Yes that lines up with my thoughts on how this could work. As has already
been suggested this is essentially the structure used by
'general/misc/inverted' which then already models how some of the J
primitives would operate on it.
The bit that is missing, as you point out is the toolset to elegantl
I hope you find me an idiot, but isn't that what a DBMS does? Maybe the
DBMS in J could be extended a little to do all this.
On Mon, Jan 31, 2022, 6:22 PM 'Pascal Jasmin' via Programming <
programm...@jsoftware.com> wrote:
> Beyond dictionaries is a "generic data structure" construct, and a large
Here is my proposed semantics: currently an array is a function N_n0 *
N_n1 * N_n2 ... -> A. A is some atomic type; n0 n1 n2 ... are the shape
of the array; N_n denotes the set of non-negative numbers less than n.
Adding dictionaries means extending the potential domain of an array to
include
On Mon, 31 Jan 2022, Raul Miller wrote:
It was overtake along the dimension indexed by symbols that I
anticipated problems.
Ah, I see. I do not think take should be specified in such cases, let
alone overtake. I do not think keys should be ordered, either.
Really, there are two issues to
Beyond dictionaries is a "generic data structure" construct, and a large
extended family of data structures that can respond to the following commands
GET SET UPSERT APPEND DELETE INSERTafter(item) INSERTbefore(item) WHEREget
CONVERTtoJnativearray UPSERTfromJnativearray
in addition to dictionar
On Mon, 31 Jan 2022, Vanessa McHale wrote:
q/k is faster, I think because it’s ordered by default - maybe something
like ordered dataframes could be implemented in J?
What do you mean by ordered? Sorted? I know some versions of k will
track when an array is sorted. But at the volumes they
I also long time wanted to try it.
I had no urgent need of it, so time just went by …
boxed list of columns if we want mixed datatypes which
would be necessary for a drop-in replacement of dataframes
the list of column names imo should not be separated
but those are implementation concerns
otoh,
On Mon, Jan 31, 2022 at 4:26 PM Elijah Stone wrote:
> Obviously such arrays would have to be rectangular, that is homogenous.
> So for instance, if I have a rank 2 array where the first axis is integral
> and the second is symbolic, every row will have the same set of keys. So
> I think overtake
I think a dataframe, in J would basically be a boxed list of columns,
and some associated list of column names.
It's the toolset we would build up to work with such a thing that
would make it useful.
(And maybe Jd is such a toolset? I do not know -- I have not motivated
myself to try Jd yet...)
I would not worry too much about "the J way of thinking" -- J is a
tools, but it's not the only tool.
Setting aside a bit of time -- maybe half an hour a day, several days
a week -- is good for picking up the skills involved with using a
tool. In the context of J that would be time spent working t
I’ve tried Jd, it’s equivalent to pandas I think (and about as performant)
though it’s persistent (being a database).
q/k is faster, I think because it’s ordered by default - maybe something like
ordered dataframes could be implemented in J?
Cheers,
Vanessa McHale
> On Jan 30, 2022, at 8:21 PM
I’d rather have the shape with respect to the topmost other kind.
First axis numeric:
the numeric shape below which the first symbolic one occurs
first axis symbolic:
vice versa
you may need to check the return value of the adjusted implementation
of the datatype primitive for those “other kind”
Let's talk about the spec, not the implementation.
Henry Rich
On 1/31/2022 4:49 PM, Raoul Schorer wrote:
If I'm not mistaken though, J symbols are not garbage collected, are they?
Wouldn't that be a problem for dictionaries with symbol keys doing a lot of
insertions/deletions?
Sorry if I misse
If I'm not mistaken though, J symbols are not garbage collected, are they?
Wouldn't that be a problem for dictionaries with symbol keys doing a lot of
insertions/deletions?
Sorry if I missed something I. The docs about that.
Cheers,
Raoul
Le lun. 31 janv. 2022 à 21:40, greg heil a écrit :
> i
On Mon, 31 Jan 2022, Elijah Stone wrote:
I think it makes most sense to make symbolic axes positive, same as normal axes.
Non-negative, of course!
A question is what the shape of a partly symbolic array should be.
(Or completely symbolic; I just meant not completely numeric.)
-E
---
https://www.jsoftware.com/papers/array1.htm#5 relevant.
Permitting multidimensional dictionaries--or arrays some of whose axes are
indexed by symbols--is interesting, and I had not thought of it (though it
is somewhat obvious).
Obviously such arrays would have to be rectangular, that is homo
Well Brian that is my motivation for J too, but so far I have not been able
to make any significant progress into the J way of thinking.
I'm nearly on the point of admission defeat here.
Cheers
Steven.
On Tue, 1 Feb 2022 at 06:52, Brian Schott wrote:
> One of the main reasons I have continued
That's a good point.
Conceptually, a "dictionary" is an implementation which supports indexing
along the lines of (ref i. names) { values
And, an array where at least one dimension is symbols instead of integers
would be in the right ballpark.
That said, this would share some aspects with sparse
i just want to reiterate
the point Alex Shroyer made
about k dictionaries
i found them extremely useful
and upon occasion
groused about not having them in J
i used them to represent
an (English) dictionary
very facile efficient and fast
the fact is our world
is (mostly) filled
with ragged object
One of the main reasons I have continued to use J has been because of all
the powerful primitives and because of the mental challenge of using the
primitives effectively. For me I imagine J is almost like a video game for
the younger generation: it is a challenge with great rewards and unmatched
co
Dear J enthusiasts,
As a newly joint J enthusiast and the programmer that have worked in many
environments/technologies I would say J should definitely not mimic python
or compete with it directly (of course it could take good bits from it and
learn hard lessons there) but focus even more on the n
Quite right. Jan-Pieter has at least a good start on the model. What I
am suggesting is that the 'more integrated implementation' might not
need to be much more integrated than the J script. Searching and
sorting are already J primitives.
The deficiency in J is that m&i. gives you a hashtab
A good and complete model is the first step. Then it is a matter of how
much it is used and what drawbacks it might have that would be addressed by
a more integrated implementation.
On Mon, Jan 31, 2022 at 1:27 PM Henry Rich wrote:
> I have looked into this quite a bit. I am not convinced that
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 i
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)
It seems to me that the big distinction between J and python where J falls
far short is not in the core language but in the addon libraries. I
encourage J fans to work away at adding important addons to J!
On Mon, Jan 31, 2022 at 11:27 AM Eric Iverson
wrote:
> A J dictionary type is a good idea
A J dictionary type is a good idea and it has been kicked around many times
before. The hard part is not implementing it, but doing a careful and
thorough spec that is backed by a complete model written in J.
Presented with a full spec that had community buy in, would probably be
followed by imple
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 n
What does "competing with python" mean?
(I suspect that we must "compete" in some contexts, but I also imagine that
"competition" would be irrelevant in many, many contexts. But.. as a
programming exercise, I don't know how to conceptualize these distinctions.)
Thanks,
--
Raul
On Mon, Jan 31,
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
41 matches
Mail list logo
