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
