The problem with that is in “treated as” – remember that native complex numbers
are an area of memory very closely resembling two floating-point numbers of
whatever precision. There is no way to persuade the computer to “treat” an area
of memory which is only one floating-point number as that. A
> >> 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
>
Hi Ingo,
[adding a “real” type qualifier]
> How do you do that? I tried to implement this and failed because I didn't
> know where to start. ;)
Looking in PP.pod gives a good start. In this case, it’s related to Pars, which
are encapsulated in PdlParObj. After that, it was easy! (Apart from fix
Luis, use cdouble or cfloat for that.
If you want to preserve the floating point precision, this is harder. I
think a function should be introduced to do exactly this. complex() in
PDL::Complex ?
Ingo
On 26.03.21 06:29, Luis Mochan wrote:
I started playing with the new complex numbers. I find
Hi Ed,
very nice! See comments inline.
On 26.03.21 06:40, Ed . wrote:
I’m currently working on making creal and cimag return real data
rather than complex, which I’m doing by implementing a “real” type
qualifier (in PP terminology), so:
Pars => “a(); real [o] b()”
How do you d
