If you pick one possible result, that's pretty arbitrary
and not interesting to me.

If you pick all the possible results, then the inverse
of p.^:_1 is not p. .

Your pInv seems good enough to me.

Henry Rich

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Dan Bron
> Sent: Monday, September 29, 2008 5:18 PM
> To: Programming forum
> Subject: [Jprogramming] p.^:_1
> 
> The primitive  p.  is defined
> 
>          (x p. y) = +/x*y^i.#x
> 
> for all open  x  .  
> 
> 
> Its inverse, according to the interpreter, is undefined:
> 
>          6 5 4 p. 2
>       32
> 
>          6 5 4 p.^:_1: 32
>       |domain error
>       |   6 5 4     p.^:_1:32
> 
> 
> What are the major reasons for this?  That is, given:
> 
>          z =: x p. y
> 
> why can't we have :
> 
>          y = x p.^:_1 z
> 
> ?
> 
> I'm no mathematician, but it seems to me that producing  y  
> from  x  and  z  is just a matter of solving a polynomial, 
> and we already have a polynomial solver.
> 
> In broad strokes, we could do something like this:
> 
> 
>          x =:  6 5 4
>          y =:  2
>       
>          ] z =:  x p. y
>       32
>          
>           p. (({.x)-z),}.x
>       +-+-------+
>       |4|_3.25 2|
>       +-+-------+
>       
>          pInv =: ((-~ {.) p.@, [EMAIL PROTECTED])~
>          x pInv z
>       +-+-------+
>       |4|_3.25 2|
>       +-+-------+
>          
>          y e. > {: x pInv z
>       1
>          
> 
> Now, if  p.'s  inverse has been left undefined because it's 
> multivalued, then we have a few options:
> 
>    (A)  Give all the values, as  pInv   does.  But this loses 
> the value of things like  (-: ]&.(x&p.))  .
> 
>    (B)  Select one input.  This has the drawback of biasing 
> results, but 
>         (i)  That's not so bad.  For example,  %:  is 
> multivalued but only one value is selected.
>         (ii) Users could always substitute the user-written  
> pInv  for  p.^:_1  if they always wanted a result.
> 
> To  (B)  , if we had to select a single output, I'd say pick 
> the "normalest" one.  Prefer real to complex,
> positive to negative, whole to fractional, etc.
> 
> Of course, there are still problems with  pInv  :
> 
>          12 pInv 32
>       |domain error: pInv
>       |   12     pInv 32
>          
> and probably more that I haven't noticed, which may be the 
> reason it wasn't implemented in the first place.
> 
> -Dan
> 
> 
> ----------------------------------------------------------------------
> 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