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 <elro...@elronnd.net>:
> 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
> >> fixed u, but monad needs [: in x position.
> >> Decorating a noun requires a conjunction, but is still possible:
> (where
> >> Sorted is a conjunction)
> >> (Sorted data) NB. adverb instead noun that was data.
> >> where Sorted that does nothing (to modify/choose implementation of u)
> can
> >> be:
> >> Sorted =: APPLY =: 2 : ' u n'
> >>
> >> u Sorted data -: u (Sorted data) NB. for monad u
> >>
> >> + Sorted 3
> >>
> >> 3
> >>
> >> (u Dn) (Sorted Data) NB. dyad u
> >>
> >> 2 (+ Dn) (Sorted 3)
> >>
> >> 5
> >>
> >>
> >> 2 (i.~ Dn) (Sorted (i.5))
> >> 2
> >>
> >> 2 (i.~ Dn) Sorted (i.5)
> >>
> >> 2
> >>
> >>
> >> findfirstsorted =: (i.~ Dn) Sorted ]: NB. ACA
> >>
> >>
> >> 2 findfirstsorted (i.5) NB. presumed sorted without "data attribute"
> >>
> >> 2
> >>
> >> findfirstAttributeSorted =: (i.~ Dn) NB. real function might optimize
> >> implementation of i. but delegation requires lookahead not part of
> >> interpreter.
> >>
> >>
> >> 3 findfirstAttributeSorted (Sorted (i.5))
> >>
> >> 3
> >>
> >> The case for (A n) is that it would designate a special decorated noun
> that
> >> because it is special can be peeked inside of (the adverb) to determine
> the
> >> decoration, and then when a verb is applied, the proper verb
> implementation
> >> suited to the decoration can be chosen. It is also a bit more flexible
> to
> >> implement decorations either as (u A) or (A n) for any A.
> >> on a different note, reusing D. and D: could be
> >> D. =: 2 : 'v u ]' NB. Dn above, but v is any ambivalent verb or [: .
> u~ D.
> >> v is dyadic compose with y as 2nd x: ie. becomes ] u v. Also monadic
> >> hook.D:=: 2 : '[ u v' NB. dyadic compose with repeated x, or monadic
> hook
> >>
> >> On Tuesday, January 10, 2023 at 10:35:16 a.m. EST, 'Pascal Jasmin'
> via
> >> Programming <programm...@jsoftware.com> wrote:
> >> > 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
> >
> > --
> > ----------------------
> > mail written using NEO
> > neo-layout.org
> > ----------------------------------------------------------------------
> > 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
