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:
u;._1!.n ↔ u;._1 @: (n&,)
u;._2!.n ↔ u;._2 @: (,&n)
u;. 1!.n ↔ u;. 1 @: (n&,)
u;. 2!.n ↔ u;. 2 @: (,&n)
and when u =: < then the respective inverses are:
[: }.@:; n&,&.>
[: }:@:; ,&n&.>
}.@:;
}:@:;
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.
-- Dan Bron <2007-10-30T00:19:42Z>
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:
** No worrying about losing the shard.
** 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.
!.^:_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).!.reduces the consistency of J; they should be used sparingly, if at all.-- Dan Bron <2007-10-30T00:19:42Z>