u/ P. 'Associative' and P:
would let you/us describe/annotate verbs and invoke associative optimizations
on it.
The Associative adverb or attribute applies only to functions (doesn't make
sense for data)
It also applies to only insert operations, and then as an adverb it could all
be built in. Following defintion
Associative =: (P. 'Associative')/ NB. insert is built in. So +Associative -:
+/
It would be up to "/" internals to see if u is either one of the native verbs
it knows to be associative, or a user decorated u (as determined by P:), as the
above adverb provides.
Decorating data/nouns could be possible
0 1 2 3 4 P. 'Sorted Unique'
P. P: would be interfaces to hidden dictionaries, that rely on hash values of
data to identify keys/data. So, once 0 1 2 3 4 was declared sorted/unique,
that exact data string would always be unique.
The Sorted as an adverb and (Sorted n) A n train has a few advantages. First,
both u P. n and m P. n would return u/m. So,
Sorted =: {{u P. 'Sorted'}} NB. or just (P. 'Sorted')
The "brains" for what to do with Sorted data would be in i.e.E. family, and
user functions that query P:
using P. 'Attribute' on the verb would result in faster likely hashing speed
then potentially large data. (A n) never applies A to n (only uA n), even
though it associates A (Sorted) and n (data) together.
Another implementation would be that attributes apply to context (of y) only.
data =: ((P. 'Sorted') (P. 'Unique') 1 2 3 4 NB. ((AA) n)
when u applied to data, context of u from queries to P: will return true for
Sorted and Unique attributes. Because u P. 'attribute' returns u, when u y
eventually runs, the context (queried by P:) is available.
(A n) would allow no memory baggage from "data attributes".
However, implementation u (A n) -> (uA n) : (x uA n) is probably hard.
On Tuesday, January 10, 2023 at 03:45:06 p.m. EST, Jan-Pieter Jacobs
<janpieter.jac...@gmail.com> wrote:
Intuitively, to me it would make sense to have a conjunction, e.g. P., to
set properties, provided as literal characters, to a verb (or, if it would
become desirable for other use cases, for nouns as well), and a
corresponding adverb (in line with b.) to query them. I bet there are other
properties one could usefully pass to the JE other than only associativity.
If we have to come up with a dedicated adv/conj for each of them, I think
it's not very sustainable.
Having a query adverb or conjunction (e.g. P:), the user could also use the
queried value in conditional code if needed (e.g. u P: '' returns all
attributes as literal string, u P:'a' could return a boolean whether u is
associative or not).
I didn't take a good look at how nicely such a proposal would play with
modifier trains though.
Jan-Pieter
Op di 10 jan. 2023 om 16:35 schreef 'Pascal Jasmin' via Programming <
programm...@jsoftware.com>:
> > S.
> I was going to suggest some foreign equivalent to S. But this approach is
> sufficient. A: (for (A)ssociative declaration) would be another
> candidate. if A: (or a foreign adverb) were used for this. u S. could be
> a declaration/hint that the y argument to u is in sorted order.
> plus =: + A: NB. or + S.
> becomes a "decorated verb" without creating an "attribute system" that
> would be completely new to J.
> One way to add attributes to data would be a new train:
> A n : adverb where: u (A n) -> (uA n) : (x uA n)
> Though this can already be done with a conjunction, so the case for a new
> train seems dubious. Except that both a conjunction and this new adverb
> train "eat y" argument to produce a noun, which is somewhat unusual, and
> then that "specialness" can perhaps justify a new train. Another issue
> with conjunction approach is that if u is forced monadic only, then x&u
> loses the ability to apply dyadic rank to u. If u is forced to be dyadic
> only, then a conjunction must be a "triple modifier" (return an adverb),
> where say [: would apply uCn, and a noun would apply m uC n (where m is
> final 3rd parameter).
> (A n) would decorate nouns intuitively such that data =: (A data) when
> used as y argument allows "transparent use" where
> u (A n) -: (uA) y x (uA) y -: x u (A n)
>
> even when (A n) is decorating/attributing a noun, it is saying "apply all
> verbs to this noun as uA" where A would typically be a giant switch/case.
> statement that chooses among implementations of u. Even if Associative
> "decorator" applies to verbs rather than data, Unique, Sorted would
> typically attribute data. But "user" decorations like Dictionary,
> RaggedArray would define the structure of a noun such that built in J
> operators can be overriden to "understand the data structure".
> DataIsChunkable can be an adverb that splits the data into chunks and
> applies u in threads on each chunk, then optionally unpixes them, though
> that is more likely to be a verb annotation than data annotation.
> One complication, or possibly elegance, of (A n) is how to handle:
> (A n) A
> where u (A n) -> (uA n) : (x uA n), is treating n as a y argument to uA
> (A1 n) A2 would be an adverb train that defers computation until u is
> provided instead of treating (A1 n) as the m argument to A2. example:
> newdata =: [x] u ((Sorted data) ApplySortedIfSorted)
> would make newdata either a simple noun or (Sorted newdata) "decorated
> noun". ApplySortedIfSorted becomes an adverb applied after u (Sorted data)
> is applied and produces a noun result. You can even define the noun data
> interchangeably with the adverb:
> ((data Sorted) ApplySortedIfSorted)
> and use it interchangeably with verbs that would treat data as their y
> argument.
>
> On Tuesday, January 10, 2023 at 12:10:17 a.m. EST, Elijah Stone <
> elro...@elronnd.net> wrote:
>
> My preference is to allow the user to specify what transformations they
> would
> like to permit the implementation to perform in what contexts, as
> recommended
> by ieee 754 (sec 10.4). Perhaps an adverb S., such that [x] u S. y
> applies u
> with strict fp semantics. Or perhaps a function attribute, specified in
> similar manner to associativity (howsoever that is specified).
>
> On Mon, 9 Jan 2023, Marshall Lochbaum wrote:
>
> > Well, true, I'm not in favor of rearranging +/ either. The dangers of
> > floating point don't include nondeterminism, unless you make them.
> >
> > However, I also think matrix products have it worse. Numbers with widely
> > varying exponents are a bit of an edge case. But when you're multiplying
> > a few large matrices together they can show up naturally, so I expect
> > it's not so rare to have a product that's numerically stable in one
> > direction and not in the other.
> >
> > Marshall
> >
> > On Mon, Jan 09, 2023 at 05:52:34PM -0600, Omar Antolín Camarena wrote:
> >> But that's just normal floating non-associativity. It happens even for
> addition of "integers":
> >>
> >> 1 + (_1e19 + 1e19)
> >> 1
> >> (1 + _1e19) + 1e19
> >> 0
> >>
> >> People using floating point are probably aware of the dangers or at
> least should be.
> >>
> >> --
> >> Omar
> >> ----------------------------------------------------------------------
> >> 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
