I'm not sure what do to for inverses of other u, as u^:_1 is probably not what's wanted. (For example, the inverse of < is > but what we want here is ; instead.)
However, that is not a large obstacle, because I think that:
u&.>&.(<;.m!.n)
will mostly cover the ground. Given that, I believe the idiom should be given special consideration and be supported by special code.
The optimization would ideally apply for all u, but it should at least apply to all u which (cut503) already supports in ;@:(<@:u;.1) (viz my previous request). Special code which supports the idioms <@:u;.m and u&.>@:(<;.m) might also be considered for extension.
Motivations and disincentives for implementing this proposal are as detailed in the original Forum message:
Advantages:
Concise.
Solves a common problem.
** No worrying about losing the shard.
Backwards compatible.
Centralized, easily optimized. In particular, in <;._2 y,n the catenation (and attendant copying of y) need not be performed.
Could easily provide for other optimizations which would support a large body of extant and likely future code. In particular, f&.>&.(<;._2!.n) could be optimized for well-behaved f (the initial definition of "well behaved" might be "doesn't change the type or shape of its argument"). For example:
dtb&.>&.(<;._2!.LF) NB. dtb from lines
though this is "poorly behaved" because it changes the shape of its argument.
In the spirit of !.
In the spirit of ^:_1
Drawbacks (in addition to those associated with every backwards-compatible change to the language):
<;._2 sans fit couldn't have an inverse, or, if it did, it would be inconsistent with the definition of the inverse of fitted cut (cf. previous request).
Every !. reduces the consistency of J; they should be used sparingly, if at all.
Similar to an old request of mine, I propose an extension to
;..The request is for a new application of
!.. Fit should apply to monads derived from the cut conjunction such that:and when
u =: <then the respective inverses are:I'm not sure what do to for inverses of other
u, asu^:_1is probably not what's wanted. (For example, the inverse of<is>but what we want here is;instead.)However, that is not a large obstacle, because I think that:
u&.>&.(<;.m!.n)will mostly cover the ground. Given that, I believe the idiom should be given special consideration and be supported by special code.
The optimization would ideally apply for all
u, but it should at least apply to all u which (cut503) already supports in;@:(<@:u;.1)(viz my previous request). Special code which supports the idioms<@:u;.mandu&.>@:(<;.m)might also be considered for extension.Motivations and disincentives for implementing this proposal are as detailed in the original Forum message:
Advantages:
Backwards compatible. Centralized, easily optimized. In particular, in
<;._2 y,nthe catenation (and attendant copying ofy) need not be performed. Could easily provide for other optimizations which would support a large body of extant and likely future code. In particular,f&.>&.(<;._2!.n)could be optimized for well-behaved f (the initial definition of "well behaved" might be "doesn't change the type or shape of its argument"). For example:dtb&.>&.(<;._2!.LF) NB. dtb from linesthough this is "poorly behaved" because it changes the shape of its argument.
In the spirit of
!.In the spirit of
^:_1Drawbacks (in addition to those associated with every backwards-compatible change to the language):
<;._2sans fit couldn't have an inverse, or, if it did, it would be inconsistent with the definition of the inverse of fitted cut (cf. previous request).Every
!.reduces the consistency of J; they should be used sparingly, if at all.-- Dan Bron <2007-10-30T00:19:42Z>