Re: [Jprogramming] (A n) new train. was: more fun with parallelism
On Wed, Jan 11, 2023 at 1:15 PM 'Pascal Jasmin' via Programming
wrote:
> > I don't think there's a strong need to allow users to set flags on nouns.
> It's rather a dangerous thing to do, and you could instead just run the nouns
> through /:~ or ~.
>
> marked nouns would allow those functions to return identity (while retaining
> marking/annotation of sorted/unique)
Only in contexts where operations which retain those marks are the
only operations which have been performed since a seed noun was
marked.
And every operation that supports those marks becomes more complex
(and potentially slower, dealing with cases which retain vs. lose the
marks).
Meanwhile, conceptually, what we're doing here is eliminating code
that the programmer could have avoided or which the parser could have
treated differently.
Or: there are going to be situations where this is going to be a win
but there's also situations where this is going to be a loss. How do
we distinguish between these cases in a statistically significant
fashion?
Thanks,
--
Raul
>
> i. generates a sorted/unique list.
>
> functions marked as monotonic would preserve unique and sorted attributes.
>
> 7 (42)(]: i.~ *) i.8
>
> 6 NB. since * is monotonic, if y is sorted unique, then it may be
> appropriate to "binary search/try" elements of y out of order applying * to
> just the guesses.
>
> where x is a unique list then (2 3 +"0 1 i.5) has attribute "unique/sorted
> ByRow"
>
> which makes f"1 see unique and sorted. "Unique/sorted by column" would let
> f("1)@|: see unique/sorted data.
>
> In my dictionary implementation, https://github.com/Pascal-J/kv
>
> marking the whole structure as dictionary or raggedArray (unreleased
> implementation based on kv) might allow { } to natively understand dictionary.
>
> More importantly, the impementation treats updates as appends by default.
> get function uses i: to still access kv as if it were unique keyed.
> Advantage is faster appends, permitting undo update operation, or permitting
> multiple key,value pairs with the same key, allowing one to many relations
> for example, or using J's key function on data structure. The key/value
> lists are also order preserved if that is relevant to context used.
>
> There are operations to uniquify and sort the dictionary (by key). The usual
> J dataflow is to bulk append/manipulate data, then set it in access mode
> only. kv's design is to separate these steps.
> Some of the example KVs model attributes and DATA as special key containing
> value.
>
> Pyxs are probably better boxed than attributed, but might have some
> convenience with some extra attributes. Perhaps using them for hints as to
> when they might be complete, perhaps with code running inside a thread that
> updates % complete. OTOH, using pyx attributes would generally involve a
> system that can track attributes in its own data structures. Sorry if this
> is not useful.
>
>
>
>
>
> On Tuesday, January 10, 2023 at 09:48:17 p.m. EST, Elijah Stone
> wrote:
>
>
>
>
>
> I originally wanted just one adverb to indicate associativity. But then other
> things just started piling up. As yet, we have:
>
> - associativity
>
> - commutativity
>
> - identity
>
> - fixedpoint
>
> Commutativity enables a bit more flexibility wrt parallelism, and might have
> other uses (forget); identity plugs a long-standing hole, which is that +/''
> is 0, but user-defined u/'' is an error, and it also slightly simplifies some
> parallel pipelines; fixedpoint enables early-out in u/; all of these are
> useful and desirable. There could be more yet.
>
> I don't love naming them with strings, but I don't think names like ASSOC. are
> better. I would like to have one-character abbreviations for all or most,
> which is hopefully more palatable.
>
> For unset, I imagine saying u A: 'associative' is sugar for u A:
> ('associative';1); hence, you could say u A:('associative';1)
> A:('associative';0). That doesn't work for identity/fixedpoint; I guess you
> could add a layer of boxing, but that seems annoying. I don't think it's very
> important, but could surely be worked out. (I almost hesitate to say
> it--perhaps use _. to unset a noun attribute?)
>
> I don't think there's a strong need to allow users to set flags on nouns.
> It's rather a dangerous thing to do, and you could instead just run the nouns
> through /:~ or ~. (in the case of sorted/unique); the thing about functions is
> that rice's theorem is always waiting around the corner to screw you over the
> moment you try to do anything useful.
>
> On Wed, 11 Jan 2023, Hauke Rehr wrote:
>
> > Very interesting indeed, all of this thread.
> >
> > I think annotation both of nouns and verbs would be useful.
> > Do we also need a way of de-annotation?
> > Probably not but I haven’t thought it through.
> >
> > I don’t like the literal approach. I’d rather have J know about
> > constants ASSOC. and SORTED. and the like to be used for that
> > purpose
Re: [Jprogramming] (A n) new train. was: more fun with parallelism
not exactly what I had in mind so we don’t want no bloat, right how about simply assigning numbers? magic numbers are about as readable as magic letters we already define sugar in english.ijs so some name could be added for associativity which might be 2⁰=2¹-1 (all four currently known annotations? <:2^4) but before details of exposition to the user, implementation details should be settled on. Not that I’d deal with that but I wouldn’t take this discussion too far as long as we don’t know which limitations come up when trying to actually make it work. So I’ll silence myself for the time being. One question should be answered early on, though: I first thought we only want a couple of annotations pretty much set in stone, understood by the JE. The latest answers seem to suggest opening the mechanism up to arbitrary (ab)use by the user. Mostly @Jan, @Pascal, @Elijah: did you mean to • provide a means of user definable annotating or • have the foreigns/primitives in question inform the JE of a known set of annotations only? Hauke Am 11.01.23 um 21:43 schrieb Jan-Pieter Jacobs: ASSOC =: A: 'a' or ASSOC =: 'a' A: <1 -- -- mail written using NEO neo-layout.org -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jprogramming] Examples of u . v where u is not a w/
Thank you, Cliff! Those fractal examples are quite pretty! The operator in the first, #.@|:, is also fold, namely ([+2*])/, but the #.@|: expression is nicer and I like being able to use it rather than being forced to do ([+2*])/ as I would be in APL. The other examples are even better in that you can't get the early termination semantics of i.&0 or i.&1 with a / fold (you could with the new F. family, and those are also nice examples pointed out by Jan-Pieter). -- Omar -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jprogramming] (A n) new train. was: more fun with parallelism
I'd make A: a conjunction that, depending on u, returns a verb or an adverb:
If u is a verb, assume v are a set of properties to set, either binary (a
verb is commutative or not), or multi-valued with a defined default value.
If u is a noun, then treat it as a set of property "keys" (fretted, as for
s:, property names that can be identified by the shortest unique prefix,
preferably being a single character), and v as the corresponding boxed
values (or unboxed if only one or multiple compatible values) for
non-binary attributes, like identity. If a box is empty, it's treated as
for the case above, if u is shorter than the number of attributes in v,
it's overtaken, i.e. padded with empty boxes, triggering the behaviour
above for the corresponding attributes.
E.g. you'd say u A: 'a' or u 'a' A: <1 or u A: 'assoc'
As an added bonus, this way, a user could create cover names for the
resulting adverb for certain combinations of attributes as they fancy, like
Hauke's ASSOC =: A: 'a' or ASSOC =: 'a' A: <1 (used as u ASSOC).
This would limit the need for boxed values to only when non-default or
non-binary properties are set, and is also compatible with setting gerunds
for some (future) use. A possible use case for gerunds could be setting an
explicit derivative for a user-defined function using property 'diff' (as
was previously possible, but this disappeared together with D. ). This
attribute could then be consulted by the math/calculus addon. Perhaps
others would find different use cases for passing around things with verbs
as well...
Best regards,
Jan-Pieter
Op wo 11 jan. 2023 om 03:48 schreef Elijah Stone :
> I originally wanted just one adverb to indicate associativity. But then
> other
> things just started piling up. As yet, we have:
>
> - associativity
>
> - commutativity
>
> - identity
>
> - fixedpoint
>
> Commutativity enables a bit more flexibility wrt parallelism, and might
> have
> other uses (forget); identity plugs a long-standing hole, which is that
> +/''
> is 0, but user-defined u/'' is an error, and it also slightly simplifies
> some
> parallel pipelines; fixedpoint enables early-out in u/; all of these are
> useful and desirable. There could be more yet.
>
> I don't love naming them with strings, but I don't think names like ASSOC.
> are
> better. I would like to have one-character abbreviations for all or most,
> which is hopefully more palatable.
>
> For unset, I imagine saying u A: 'associative' is sugar for u A:
> ('associative';1); hence, you could say u A:('associative';1)
> A:('associative';0). That doesn't work for identity/fixedpoint; I guess
> you
> could add a layer of boxing, but that seems annoying. I don't think it's
> very
> important, but could surely be worked out. (I almost hesitate to say
> it--perhaps use _. to unset a noun attribute?)
>
> I don't think there's a strong need to allow users to set flags on nouns.
> It's rather a dangerous thing to do, and you could instead just run the
> nouns
> through /:~ or ~. (in the case of sorted/unique); the thing about
> functions is
> that rice's theorem is always waiting around the corner to screw you over
> the
> moment you try to do anything useful.
>
> On Wed, 11 Jan 2023, Hauke Rehr wrote:
>
> > Very interesting indeed, all of this thread.
> >
> > I think annotation both of nouns and verbs would be useful.
> > Do we also need a way of de-annotation?
> > Probably not but I haven’t thought it through.
> >
> > I don’t like the literal approach. I’d rather have J know about
> > constants ASSOC. and SORTED. and the like to be used for that
> > purpose (better response to misspellings and imo cleaner approach).
> >
> > What grammar should the query and set (and maybe unset) primitives have?
> > Hard to tell which approach would work out better.
> >
> > But I would favor such primitives – building corresponding
> > conjunctions should be fairly easy and might even be done
> > for all currently known decorations in a script distributed
> > but not loaded by default.
> > But maybe I missed a point why that new train actually
> > improves the situation here.
> >
> > Hauke
> >
> >
> > Am 10.01.23 um 19:10 schrieb 'Pascal Jasmin' via Programming:
> >> There is after all a Conjunction approach that permits ambivalent u
> verb,
> >> and so for attributes that current native J code could leverage, it
> would
> >> be possible to have full functionality of (A n) suggestion.
> >> Dn =: 2 : 'v u ]' NB. dyadic with x as n or monadic with [: as v
> >> +/"1 0 (Dn 2 3) i.5 NB. or natural xy order: 2 3 (+/"1 0 Dn ) i.5
> >> 2 3
> >>
> >> 3 4
> >>
> >> 4 5
> >>
> >> 5 6
> >>
> >> 6 7
> >>
> >> +/"0 1 Dn 2 3 ] i.5
> >> 2 3 4 5 6
> >>
> >> 3 4 5 6 7
> >>
> >>
> >>
> >>
> >> +/"0 1 Dn [: i.5
> >>
> >> 10
> >>
> >> this would let you/us decorate a verb as: (where Associative is an
> adverb)
> >> (Dn Associative)((Dn Associative) [:) NB. Monad only u Or ((Dn
> >> [:)Associative) or just Associative((u Dn) Associative) NB. ambivalent
Re: [Jprogramming] (A n) new train. was: more fun with parallelism
> I don't think there's a strong need to allow users to set flags on nouns.
It's rather a dangerous thing to do, and you could instead just run the nouns
through /:~ or ~.
marked nouns would allow those functions to return identity (while retaining
marking/annotation of sorted/unique)
i. generates a sorted/unique list.
functions marked as monotonic would preserve unique and sorted attributes.
7 (42)(]: i.~ *) i.8
6 NB. since * is monotonic, if y is sorted unique, then it may be appropriate
to "binary search/try" elements of y out of order applying * to just the
guesses.
where x is a unique list then (2 3 +"0 1 i.5) has attribute "unique/sorted
ByRow"
which makes f"1 see unique and sorted. "Unique/sorted by column" would let
f("1)@|: see unique/sorted data.
In my dictionary implementation, https://github.com/Pascal-J/kv
marking the whole structure as dictionary or raggedArray (unreleased
implementation based on kv) might allow { } to natively understand dictionary.
More importantly, the impementation treats updates as appends by default. get
function uses i: to still access kv as if it were unique keyed. Advantage is
faster appends, permitting undo update operation, or permitting multiple
key,value pairs with the same key, allowing one to many relations for example,
or using J's key function on data structure. The key/value lists are also
order preserved if that is relevant to context used.
There are operations to uniquify and sort the dictionary (by key). The usual J
dataflow is to bulk append/manipulate data, then set it in access mode only.
kv's design is to separate these steps.
Some of the example KVs model attributes and DATA as special key containing
value.
Pyxs are probably better boxed than attributed, but might have some convenience
with some extra attributes. Perhaps using them for hints as to when they might
be complete, perhaps with code running inside a thread that updates % complete.
OTOH, using pyx attributes would generally involve a system that can track
attributes in its own data structures. Sorry if this is not useful.
On Tuesday, January 10, 2023 at 09:48:17 p.m. EST, Elijah Stone
wrote:
I originally wanted just one adverb to indicate associativity. But then other
things just started piling up. As yet, we have:
- associativity
- commutativity
- identity
- fixedpoint
Commutativity enables a bit more flexibility wrt parallelism, and might have
other uses (forget); identity plugs a long-standing hole, which is that +/''
is 0, but user-defined u/'' is an error, and it also slightly simplifies some
parallel pipelines; fixedpoint enables early-out in u/; all of these are
useful and desirable. There could be more yet.
I don't love naming them with strings, but I don't think names like ASSOC. are
better. I would like to have one-character abbreviations for all or most,
which is hopefully more palatable.
For unset, I imagine saying u A: 'associative' is sugar for u A:
('associative';1); hence, you could say u A:('associative';1)
A:('associative';0). That doesn't work for identity/fixedpoint; I guess you
could add a layer of boxing, but that seems annoying. I don't think it's very
important, but could surely be worked out. (I almost hesitate to say
it--perhaps use _. to unset a noun attribute?)
I don't think there's a strong need to allow users to set flags on nouns.
It's rather a dangerous thing to do, and you could instead just run the nouns
through /:~ or ~. (in the case of sorted/unique); the thing about functions is
that rice's theorem is always waiting around the corner to screw you over the
moment you try to do anything useful.
On Wed, 11 Jan 2023, Hauke Rehr wrote:
> Very interesting indeed, all of this thread.
>
> I think annotation both of nouns and verbs would be useful.
> Do we also need a way of de-annotation?
> Probably not but I haven’t thought it through.
>
> I don’t like the literal approach. I’d rather have J know about
> constants ASSOC. and SORTED. and the like to be used for that
> purpose (better response to misspellings and imo cleaner approach).
>
> What grammar should the query and set (and maybe unset) primitives have?
> Hard to tell which approach would work out better.
>
> But I would favor such primitives – building corresponding
> conjunctions should be fairly easy and might even be done
> for all currently known decorations in a script distributed
> but not loaded by default.
> But maybe I missed a point why that new train actually
> improves the situation here.
>
> Hauke
>
>
> Am 10.01.23 um 19:10 schrieb 'Pascal Jasmin' via Programming:
>> There is after all a Conjunction approach that permits ambivalent u verb,
>> and so for attributes that current native J code could leverage, it would
>> be possible to have full functionality of (A n) suggestion.
>> Dn =: 2 : 'v u ]' NB. dyadic with x as n or monadic with [: as v
>> +/"1 0 (Dn 2 3) i.5 NB. or natural xy order: 2
