Of course. I've even used that before... Silly me. However I still can't
understand the inverse of 3&{, for example.
The inverse to m&{ is equivalent to
(/:~ m)&{ (if (i.@# -: /:~) m).
With ammend, no transformation of the indices is needed;
m&{^:_1 could be equivalent to m&}.
This would also render m&{ compatible with boxed m (in order to index into
arrays), and more practical with non-permutation m.
Louis
> On 03 Mar 2016, at 01:58, Raul Miller <[email protected]> wrote:
>
> The inverse for m&{ mostly only makes sense when m&{ permutes the argument.
>
> 1 2 3 0&{ 'ABCD'
> BCDA
> 1 2 3 0&{inv 'ABCD'
> DABC
>
> Then, the inverse reverses the permutation.
>
> Does that help?
>
> Thanks,
>
> --
> Raul
>
>
>> On Wed, Mar 2, 2016 at 7:39 PM, Louis de Forcrand <[email protected]> wrote:
>> The way J handles inverses to functions is quite unique and, while not
>> always very useful, can lead to compact but very descriptive code:
>>
>> +/&.:*: NB. distance
>> +&.^. NB. multiplication
>> u&.(a.&i.) NB. u applied to y’s indices in a., then indexed out of a.
>> etc.
>>
>> However, some less easily invertible functions, such as , (ravel), {: and
>> related,
>> A., m&{ , and others, don’t have a monadic inverse because they are “lossy”
>> functions,
>> in that there is no function u such that
>> y -: u@v y NB. where v is a lossy function
>> for an arbitrary y.
>>
>> However, while there are other lossy functions which I have not cited, the
>> ones I
>> did are particular in that they are invertible with trains of related dyadic
>> functions:
>>
>> u&., y <—> ($ $ u@,) y
>> u&.(m&{.) y <—> (m&}. , u@(m&{.)) y NB. extends to others like
>> }. etc.
>> NB.
>> although {. already has an inverse
>> u&.A. y <—> (A.~ u@A.) y
>>
>> These are all simply “cosmetic”, in that you can obviously write them out
>> by hand, but then again, &. is basically cosmetic too. Nevertheless, it leads
>> to more elegant and concise code (and sometimes leads to new ways of
>> thinking about a problem). However, one inverse that could possibly
>> lead to (possibly big?) gains in speed with special code would be:
>>
>> u&.(m&{) y <—> (m&}~ u@(m&{)) y
>>
>> This might already be implemented for the fork case.
>> I’ve checked, and m&{ already has an inverse, although I don’t see what it’s
>> useful for.
>>
>> On a side note, I’ve noticed that <;.1 has an inverse according to b._1, but
>> using it yields a nonce error (which means it hasn’t been implemented yet,
>> right?). <;._1@(m&,) could be recognised as a whole as well, so that
>> u&.(<;._1@(m&,)) y <—> ({. ;@, m ,&.> }.)@u@(<;._1@(m&,))
>> Or it could be added as an obverse to the cut standard library verb.
>>
>> Again, this can all be done by hand, of course.
>>
>> Louis
>> ----------------------------------------------------------------------
>> 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
