> >> In a similar vein: is it really useful to call creal/cimag on real data?
> >> It seems to me that too should throw an exception.
> > I think it should just return the input and 0, respectively. Thus it can be
> > used to write generic code that accepts real and complex input. carg should
> > do the same. Even conj kind of works that way.
>
> Agreed.
That's what I thought, allow feeding real numbers to routines
that expect complex numbers (real is a kind of complex), but now I'm
not quite sure though, as I recalled the discussion about asin(2)
yielding a complex number vs. NaN. If real numbers are to be considered
special complex numbers, maybe this should be done consistently. Would
it be too confusing/complicated to add complex numbers with an
implicit imaginary part (=0) that may be cast to/from real types (without
moving any data), besides really real types and the intrinsic complex
types (and keeping also for compatibility the actual PDL::Complex's)?
I imagine something as
asin(pdl(2)) yields NaN,
while
asin(pdl(2)->treatascomplex) yields asin(2+0*ci),
where 'treatascomplex' (or however it is named) doesn't touch the
data, just allows reinterpreting it.
Regards,
Luis
--
o
W. Luis Mochán, | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\
Av. Universidad s/n CP 62210 | (*)/\/ \
Cuernavaca, Morelos, México | moc...@fis.unam.mx /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel
