> With ammend, no transformation of the indices is needed;
> m&{^:_1 could be equivalent to m&}.
I think you do not mean m&}. but instead meant m&} because } is amend
and }. is drop.
But m&} is a syntax error.
So maybe you really meant m} instead?
But m} is not an inverse for m&{ for any significant examples I can think of.
But perhaps I am missing something? This would hardly be the first
occasion where I've overlooked something obvious. (Could you provide a
working example of what you were suggesting?)
Thanks,
---
Raul
On Wed, Mar 2, 2016 at 9:02 PM, Louis de Forcrand <[email protected]> wrote:
> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
