The (A n) proposal is based on these performance considerations.

u P. 'attribute' returns u but sets as side effect "context of y" (and u if 
attribute is decorating the function) making the context available to u to 
determine action.

((P. 'attribute') n) ie. (A n) turns a y argument (noun n) into an Adverb that 
will add side effects "to context" from P.  but does nothing until u will be 
bound.

(C n) doesn't require any parser changes.  (A C n) is a useful new train, that 
allows for generic C

improvement over my previous post.

APPLY =: 2 : ' u n'  NB. works for monad
D =: 1 : '&u' NB. double adverb "that will look like" x u y call.  Avoids 
parentheses related mistakes of x&u"ranks instead of x&(u"ranks)

so with (A C n) train,

((P. 'attribute') APPLY n)  NB. will work as I want.  monad u required.

an alternative to doubleadverb D to turn dyad to monad is

(1 2 +"0 1 D  -: +"0 1(1 2&)) i.5
1

in terms of syntax, if attributes cannot have spaces, then multiple space 
separated attributes can be assigned at once.  perhaps a '-' prefix removes 
that attribute if it exists.  So, simplified code for P. using cut instead of 
the full features.

CONTEXT =: i.0
P =: 2 : ('CONTEXT =: ~. CONTEXT , cut n';'u')


ATTRIB =: 2 : '(P m) APPLY n'

'sorted' ATTRIB (i.5)

(P('sorted')) APPLY (0 1 2 3 4)


code dump I call attributes.ijs . Everything is 1 line with leading assignment 
if line wrap confusion.

CONTEXT =: i.0 NB. reset context. reload this file if you turn off any 
automatic reset operations.

D =: 1 : '&u' NB. double adverb "that will look like" x u y call. Avoids 
parentheses related mistakes of x&u"ranks instead of x&(u"ranks)

cutunboxed =: cut^:(0 = L.@]) NB. if y already boxed, leave alone.

G0 =: 0 {:: ]

G1 =: 1 {:: ]

Pdsl =: ([ ((}.each@G1) ~.@:-.~ (, G0)) (] ((#~ -.) ,&< #~) ('-' = 
{.)&>)@cutunboxed@])

P =: 2 : (' Pdsl wCONTEXT n';'u')

assignwithD =: 1 : '(x) =: x~ u y'

wCONTEXT =: assignwithD('CONTEXT'&) NB. u is dyad x is CONTEXT result assigned 
to CONTEXT


NB. side effect by code insert double adverb. double box for monad/dyad 
difference. list of single boxes for multiple line inserts. apply y =. [x] u y, 
do side effect/code insert, return new y

SE =: {{ 1 : ( ('y=. u y' (,&boxopen) (, ]`(0 {::])@.(2 = L.) m) 
(,&boxopen)'y'(,&boxopen)':'(,&boxopen)'y =. x u y'(,&boxopen)(, ]`(1 {::])@.(2 
= L.) m)(,&boxopen)'y'))}}

NB. 2 -('y =. +: y' ; 'y =. x,y') SE 4 NB. double result then prepend x. error 
if monad

NB. - ('y =. 0 , y' ,&<&< 'y =. x,y') SE 4 NB. double box monad/dyad cases. 
avoid error accessing x in monad.

NB. 3 : 'try. x=.x catch. x=. '''' end. y' 3 NB. alternative method to access x 
from monad without error. (so single boxed code insert)

preSE =: {{] [ 3 : m}}@] NB. returns y. m is explicit code that can access y. 
ambivalent verb result

APPLY =: 2 : ' u n' NB. works for monad

ATTRIB =: 2 : '(P m) APPLY n'

nATTRIB1 =: 1 : '(P (3 : ''CONTEXT'' a:) ) ATTRIB m' NB. MAKE "Decorated 
Adverb" from noun result assumes (change by filtering by DATAATTRIBUTES) 
CONTEXT only contains dataattributes

nATTRIB =: 'nATTRIB1' oa NB. if calculation result is to preserve adverb 
decorated noun

isNoun_z_ =: (0 = 4!:0 ( :: 0:))@:<

eval_z_ =: 1 : 'if. 2 ~: 3!:0 m do. m else. a: 1 : m end.' NB.1 : ' a: 1 : m'

aar =: 1 : 'if. isNoun ''u'' do. q =. m eval else. q =. u end. 5!:1 < ''q'' '

Cloak=: aar(0:`)(,^:)

oa =: 1 :'u Cloak @:' NB. apply quoted adverb after result. Can produce modifier


NB. fixed data attributes: 'sorted sortedD unique sortedbyitem sortedbyitemD 
uniquebyitem'

DATAATTRIBUTES =: 'sorted sortedD unique sortedbyitem sortedbyitemD 
uniquebyitem'

NB. monotonicI: sorted becomes sortedD (descending/inverted monotonic)

monotonicI =: (] [ ([ Pdsl (< '-monotonicI') , ('`' cut each cut 
'sortedD`-sorted sorted`-sortedD unique sortedbyitemD`-sortedbyitem 
sortedbyitem`-sortedbyitemD uniquebyitem') ;@#~ (cut 'sorted sortedD unique 
sortedbyitem sortedbyitemD uniquebyitem') e. [) wCONTEXT)

minus =: 3 : '(0 - ]) P ''monotonicI'' y': (4 : 'x - D P ''monotonicI'' y') 
(monotonicI@:)

iotaA =: 3 : 'i. P ''sorted sortedbyitem unique uniquebyitem'' y ' : (4 : 'x (+ 
i.) (P ''sorted sortedbyitem unique uniquebyitem'') y')

CONTEXT =: i.0 NB. P definitions pollute global CONTEXT

appologies for unused code.  SE not used or discussed until asked.  Highlights 
include Pdsl implements the cut and -prefix to delete syntax.  oa allows an 
adverb that takes noun input to chain from a verb phrase "result".  The code to 
clean up a monotonic (inverse) functions is pretty short compared to 8 case 
switch statement.

 2 iotaA 5  NB. sets CONTEXT to <;._1 ' sorted sortedbyitem unique uniquebyitem'

2 3 4 5 6

or can make an "adverb decorated" noun

 2 iotaA nATTRIB 5

(P(<;._1 ' sorted sortedbyitem unique uniquebyitem')) ATTRIB (2 3 4 5 6)

 2 minus 2 iotaA 5 NB. explicit minus version permits natural 
ambivalence.CONTEXT: <;._1 ' unique uniquebyitem sortedD sortedbyitemD'

0 _1 _2 _3 _4


choosing an adverb result

 2 minus nATTRIB 2 iotaA 5  NB. minus inverts sorted and sortedbyitem

(P(<;._1 ' unique uniquebyitem sortedD sortedbyitemD')) ATTRIB (0 _1 _2 _3 _4)

2 minus@:minus nATTRIB 2 iotaA 5  NB. minus@minus reverts to sorted

(P(<;._1 ' unique uniquebyitem sorted sortedbyitem')) ATTRIB (0 1 2 3 4)

(minus 2 minus 2 iotaA 5)nATTRIB1 NB. use core adverb (nATTRIB1 ) to transform 
linear code result to "adverb decoration of noun".

(P(<;._1 ' unique uniquebyitem sorted sortedbyitem')) ATTRIB (0 1 2 3 4)

Things I learned from doing this:

It is possible to step into a manageable world where cats eat dogs, and nouns 
can be turned into adverbs.

(A APPLY n) replaces the need for (A n) except that perhaps magic behind (A n) 
could make dyadic u more convenient.

A guard adverb to a noun can present promises on the noun.  u@/:~ or  u@~.  are 
ways to ensure the same, but if data is already in a sorted/unique state, those 
functions "get free guards" when operation is free.  Performance impact when 
not needed/useful is minimal. 


On Wednesday, January 11, 2023 at 05:28:46 p.m. EST, Raul Miller 
<rauldmil...@gmail.com> wrote: 





On Wed, Jan 11, 2023 at 1:15 PM 'Pascal Jasmin' via Programming
<programm...@jsoftware.com> 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 
> <elro...@elronnd.net> 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 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to