Pascal,
I have not yet had a chance to look at your proposed dictionary addon. But
I will. And it is nice that Raul is paying attention.
I want to strongly second your comment that locales are not at all
appropriate for this.
Locales are good for what they are good for. Using them for a serious
Right, it is the hyphen in pascal-j.
On Tue, Mar 15, 2022 at 10:35 AM bill lam wrote:
> the verb getscripts_j_ is used to resolve file in load/require. Maybe it is
> the hyphen in "pascal-j" .
>
> On Tue, Mar 15, 2022 at 10:25 AM Raul Miller
> wrote:
>
> > And... it looks like the answer to
the verb getscripts_j_ is used to resolve file in load/require. Maybe it is
the hyphen in "pascal-j" .
On Tue, Mar 15, 2022 at 10:25 AM Raul Miller wrote:
> And... it looks like the answer to "damaged system libraries" is:
> reinstall. I found that getpackageurl_jpacman had been damaged, I must
And... it looks like the answer to "damaged system libraries" is:
reinstall. I found that getpackageurl_jpacman had been damaged, I must
have fat fingered it. And, reinstalling the base library fixed it.
But I'm still puzzled by the question about the use of require. Why
doesn't
Ok, now I have some questions for the isi people, which I do not see
covered in https://code.jsoftware.com/wiki/Addons/Developers_Guide
(1) To test this addon, I did:
install'github:rdm/kv'
And that installed a copy of the addon at pascal-j/kv (and gave me a
message that it had done so). So,
On Mon, Mar 14, 2022 at 4:23 PM 'Pascal Jasmin' via Programming
wrote:
> I'll remind "the world" that a dictionary implementation has been published:
> https://github.com/Pascal-J/kv
I have sent you a pull request, which should enable installation of
pascal-j/kv as a github based addon.
(And,
I'll remind "the world" that a dictionary implementation has been published:
https://github.com/Pascal-J/kv
I'll defend it as being the most J friendly implementation for having
functional access + manipulation features, it further has, through the kvO
adverb, the ability to J-optimize access
On Mon, Mar 14, 2022 at 10:01 AM Michal Wallace
wrote:
> In j-kvm (that console library I've been working on), I implemented a
> simple verb that I really wish had a standard name in J:
>
> of =: {{ (x,'__y')~ [ y }}"1 0
Conceptually, the isi people have set things up so that people in the
It's true that dictionaries aren't really a "fundamental" data type, since
they're easy to implement atop arrays.
But I think for a lot of people, they've become a fundamental "thinking
type"...
I think jan-pieter's requirements list is a good start. I would add:
- nice syntax for constructing
I’ve successfully tested it on linux at least, looking through the source
though it looks like it only reads from parquet at the moment, I must not
have tested writing yet.
The bindings aren’t too complex though, it might be straightforward to add
a writeParquet verb if that functionality is
Thanks Aaron - that looks really promising. Will check it out & see if I
can get it to work.
On Wed, Feb 2, 2022 at 8:48 PM Aaron Ash wrote:
> There's also these J bindings that can be used to read/write parquet
> files directly from J: https://github.com/interregna/JArrow
>
> On Wed, Feb 2,
Thanks Stefan,
Had a quick look and liked the sound of being able to work with
larger-than-memory datasets by analysing streams from data sources, however
wasn't so impressed by the DuckDB showing (out-of-memory) on this benchmark
site https://h2oai.github.io/db-benchmark/ However it looks like
There's also these J bindings that can be used to read/write parquet
files directly from J: https://github.com/interregna/JArrow
On Wed, Feb 2, 2022 at 5:27 PM Stefan Baumann wrote:
>
> Ric, You might want to check out DuckDB (https://duckdb.org/), I recently
> used it for reading and writing
Ric, You might want to check out DuckDB (https://duckdb.org/), I recently
used it for reading and writing Parquet files.
It's similar to SQLite but intended to be used for analytics.
Stefan.
On Wed, Feb 2, 2022 at 5:29 AM Ric Sherlock wrote:
> I spend a fair bit of time wrangling data formatted
Hi Chris,
I haven't been using R much at all over the last few years, so haven't had
much to do with tibbles. Just looked them up now and they do seem more sane.
Most of my recent work has been with Polars Dataframes (
https://github.com/pola-rs/polars) which are based on Apache Arrow Columnar
Ric
For the dataframes equivalent, are you thinking of the more recent tibble
structure in tidyverse? This is easier to understand than the original
dataframes.
If so, this is a worthwhile addon for J. I worked on something similar
recently. If you or anyone else is interested, we could
One of the problems you're going to run into right away with making
dictionaries a core part of J is the concept of rank, which doesn't really
exist in K (everything is a rank 1 list, hooked together by dictionaries).
At the end of the day, what I think most people want from maps/dictionaries
is
You might search for "Beginner's Regatta" on the J wiki to see if the
beginner-oriented sections of our NYCJUG meetings are helpful.
On Mon, Jan 31, 2022 at 7:44 PM Raul Miller wrote:
> I would not worry too much about "the J way of thinking" -- J is a
> tools, but it's not the only tool.
>
>
OK that went through, anyone who wants a copy of the full PDF, please just
email me directly and I will share it.
Rob (email me directly at http://me.com/>> (no spaces)
> On 2 Feb 2022, at 12:22 am, 'Rob Hodgkinson' via Programming
> wrote:
>
> I did attach as a txt file in my sent email,
I did attach as a txt file in my sent email, but it seems to have
been stripped … (I thought .txt files were ok to the mailing list now ??).
I’ll try once more here, if not people can ask me and I’ll email them or put on
a google drive and share with whoever requests.
Thanks Rob, plain txt
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:
I would second looking at how k approaches dictionaries regarding
operations available and their domain. Uniformity between lists,
dictionaries and function calls is really elegant there too (although
likely out of reach - but maybe still having some parts of syntactic sugar
is possible - like
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
> 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
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
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
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
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
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
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
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”
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
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
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
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
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
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 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
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
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
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
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
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
Hello Elijah,
Yes, I believe you're right. I don't have much experience with them yet
though, so I cannot compare.
Best,
---
Michail L. Liarmakopoulos, MSc
On Sun, Jan 30, 2022, 21:04 Elijah Stone wrote:
> On Sun, 30 Jan 2022, Michail L. Liarmakopoulos wrote:
>
> > There is also out there an
On Sun, 30 Jan 2022, Michail L. Liarmakopoulos wrote:
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
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
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
Present: Art Anger, Will Gajate, Devon McCormick, Raul Miller, Bob Therriault
1) Will Gajate reported very good progress on the J playground with Joe Bogner
managing to get j903 working. Joe continues to do amazing work and is providing
a great contribution to the J community. The next step is
56 matches
Mail list logo
