Raul wrote:
>  I am having trouble reasoning about how this could 
>  cause problems for Henry's implementation

I haven't been following the puzzle in this thread, I just saw your question
about negative zeros and responded to that in isolation.  Actually, I
haven't read any of the posts in this thread except that short question from
you.  So I'll leave the interpretation of these values (and any trouble they
may cause, in this context) up to you.  

In keeping with that philosophy, to answer your next question:

>  Is there some way of getting an imaginary negative zero?

In my quick research, I couldn't find any "natural" way to do this similar
to %__ (that is, by using only primitives and staying within the language
proper).  But if you want to experiment with imaginary negative zeros, you
can use foreigns to fiddle with the internal representation of nouns:

           bwm =:  22 b./&.:(a. i. 3!:1"1) NB. bit-wise mask
           fib =:  [: bwm _2 j./\ ,.       NB. flip imaginary bits
           
           fib        0 1   _1  1   1 1    NB. (-0) j. 1
        0j1
           % +. fib   0 1   _1  1   1 1
        __ 1
           
           fib        1 0    1 _1   1 1    NB. 1 j. (-0)
        1
           % +. fib   1 0    1 _1   1 1
        1 __
              
           fib        0 0   _1 _1   1 1    NB. (-0) j. (-0)
        0
           % +. fib   0 0   _1 _1   1 1
        __ __

Not sure this is helpful, but there it is.

-Dan

PS:  The above is cute, but it's not totally intellectually satisfying (viz,
"1 and ,.) . I outlined a similar toy a while ago, in [1], and it suffers
from similar warts.  

The fundamental problem is that f"r^:_1 is always calculated as f^:_1"r,
which is fine when the rank of f's output is the same as its input (r), but
when it's not, one has to jump through hoops to use  &. .  The hoops aren't
particularly difficult, but they can destroy the elegance of an expression.

For example, instead of using 22 b. (bitwise xor), we might prefer to use ~:
(which is easier to understand without referencing the documentation, though
slower).  But in order to do that, we first need to explode the integers
from a.&i. into their constituent bits.  Along these lines:


           br =: (8$2) #: a. i. 3!:1                 NB.  bit representation
           ~:/&.br _2 j./\ 0 0  _1 _1  1 1
  
Except we don't want the bit-representation of the whole array 0 _1j_1 1j1;
we want to treat each number separately (so we can use the bit patterns of
earlier numbers as masks for subsequent numbers).  So, we instinctively
reach for:

           ~:/&.:(br"0) _2 j./\ 0 0  _1 _1  1 1
        |rank error
        |       ~:/&.:(br"0)_2 j./\0 0 _1 _1 1 1

Ouch.  Of course, those hoops are always there, if we want the reward badly
enough to jump through them.  We could, say, force the correct inverse (or
merely a convenient one, as we did in [1]):

           ~:/&.:(br"0 :. (br^:_1)) _2 j./\ 0 0  _1 _1  1 1
        0

But this, of course, defeats the purpose of  &.  .  So, we could try other
methods of isolation, as in:

           ~:/&.:(br&>) _2 j./\ 0 0  _1 _1  1 1
        +-+
        |0|
        +-+
           
But this requires us to introduce the irrelevant concept of boxes on an
algorithm which is dealing purely with numbers.  The distraction and
destruction this causes us is very clear in the latter result, and becomes
even more evident if we try to package these expressions up as us reusable
verbs.  Compare the following:

           [: ~:/&.br _2 j./\ ]            NB.  Desired
           [: > [: ~:/&.(br&>) _2 j./\ ]   NB.  Required

The first could be read as "bitwise xor of the complex values given as pairs
of integers", but the second would be something like "open the box
containing the result of bitwise xor of the values in the boxes of the
complex values given as pairs of integers (which, confusingly, are not
boxed; the user only knows about numbers)".  The first expression is the
kind of phrasing which makes us love J: the language at its best.  The
second is ... not.

And this is not the only place this twist (that the inverse of f"r retains
the rank r) shows up. Consider, for example, Henry Rich's puzzle: "Produce
an expression in which >"0 produces a different result than plain > does."
[2].  Can you think of such a situation?  Do you think there _should be_
such a situation?

Just thought this was interesting enough to point out.

[1]  Generating negative zeros in "Zero", Apr 2007:
     http://www.jsoftware.com/pipermail/general/2007-April/029735.html

[2]  Where > and >"0 can differ, " J Trivia Challenge", Dec 2006:
     http://www.jsoftware.com/pipermail/general/2006-December/028461.html



----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to