complex NaN

[rurban]

$ perl6
> say NaN*1i
NaNNaNi

All complex ops with NaN should return NaN.

Check the complex ops with NaN, add tests.

[rurban]

reported by leto in irc:  http://irclog.perlgeek.de/parrot/2009-02-18#i_920220

[rurban]

Current situation:

  $P1=new ["Complex"]
  $P2=new ["Complex"]
  $P1="NaN" 
  $P2="i"
  $P2 = mul $P1, $P2
  say $P2

The result is "NaNi", because both parts are treated individually and the plus is dropped from i in the printout.

NaN in the real part will not harm the calculation if the imaginary part in non-NaN: NaN+i * 1-2i = NaN-2i

The string representation of a complex is sprintf("%vg%+vgi", re, im) So NaN-2i is "NaN-2i" and NaN+i is printed as "NaNi"

So NaN * 1i = NaNi

The proposed is the represent a complex with either the real or imaginary part of NaN as "NaN", and do not seperate them.

[rurban]

unfinished

[dukeleto]

The code snippet

    $P1=new ["Complex"]
    $P1="NaN"

now gives the error

Complex: malformed string
current instr.: 'test_complex_nan' pc 21447 (t/pmc/complex.t:1170)

[dukeleto]

    $P1 = new ["Complex"]
    $N0 = 'NaN'
    set $P1, "1 + i"
    $P1 += $N0
    say $P1

prints

NaN+1i

[coke]

On Thu, Aug 20, 2009 at 10:26 PM, Parrot<parrot-tickets@lists.parrot.org> wrote:
> #358: complex NaN
> --------------------+-------------------------------------------------------
>  Reporter:  rurban  |       Owner:  dukeleto
>     Type:  bug     |      Status:  assigned
>  Priority:  normal  |   Milestone:
> Component:  core    |     Version:
>  Severity:  medium  |    Keywords:
>     Lang:          |       Patch:
>  Platform:          |
> --------------------+-------------------------------------------------------
>
> Comment(by dukeleto):
>
>  {{{
>     $P1 = new ["Complex"]
>     $N0 = 'NaN'
>     set $P1, "1 + i"
>     $P1 += $N0
>     say $P1
>  }}}
>  prints
>  {{{
>  NaN+1i
>  }}}
>

Should it print Nan+1i or just NaN? (How infectious /is/ Nan?)


-- 
Will "Coke" Coleda

[dukeleto]

I am going on the assumption that there "can be only one" NaN. The entity 'NaN' is for encoding the idea that we should represent an invalid arithmetic operation as something special. There is no "real" NaN and "complex" NaN. *All* arithmetic operations, no matter they be real or complex, that contain a NaN should simplify to NaN. The partial patch that was added to this ticket adds some support for parsing complex numbers of the form "NaN+2*i" and such, but there are still all kinds of other ways that you can make either the real or imaginary part of the resulting number NaN that does not require parsing a string, and these are the cases where we still have bugs.

Also, the patch attached is quite old and the tests no longer compile, but it is a good start.

[jkeenan]

plobsing,

As with TT #954, based on your work around infnan, can you evaluate the issues discussed in this ticket?

Thank you very much.

kid51

[dukeleto]

We need a branch that has tests for this bug. It is still present.