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
hould do the same. Even conj kind of works that way.
Best regards,
Ed
*From: *Luis Mochan <mailto:moc...@icf.unam.mx>
*Sent: *26 March 2021 05:30
*To: *pdl-devel@lists.sourceforge.net
<mailto:pdl-devel@lists.sourceforge.net>
*Subject: *Re: [Pdl-devel] [Pdl-general] PDL 2.029 release
The $T part is just the introduction; so $TGC(floatversion,doubleversion)...
Similarly $TFD(floatv,doublev). It’s one way of dealing with the different
types in a threadloop, with the other being “types(F) %{ ... %} types(D) %{ ...
%}”.
I agree with your analysis of the new “cfunc” functions, s
mag on real data? It
seems to me that too should throw an exception.
Best regards,
Ed
From: Luis Mochan<mailto:moc...@icf.unam.mx>
Sent: 26 March 2021 05:30
To: pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net>
Subject: Re: [Pdl-devel] [Pdl-general] PDL 2.
I started playing with the new complex numbers. I find it nice
and useful that creal and cimag can be applied to real pdl's, but the
results are promoted to complex:
pdl> $x=pdl(1)
pdl> p $x
1
pdl> p $x->creal
1+0i
pdl> p $x->cimag
0+0i
Equality and inequality comparisons do work but they also re
Hi,
I also noticed that complex comparisons don't throw errors but compare
the real part. I must say, I don't like the behaviour, although I did
not catch it.
At the bottom of this, I think, is the implicit type conversion. When an
operation is not defined for a given type, pdl implicitly conver
So, I figured the code bit ($TCG), but have no elegant solution ready.
There's no macro to match a complex' and real basic type, no? Ingo
Ingo
On 15.03.21 12:01, Ingo Schmid wrote:
Hi Ed,
creal, etc. including carg, do not cast onto their real-valued counter
part. I think they should, no?
pd
Hi Ed,
creal, etc. including carg, do not cast onto their real-valued counter
part. I think they should, no?
pdl> p $x
1+1i
pdl> p abs $x
1.41421354+0i
pdl> p creal $x
1+0i
pdl> p cimag $x
1+0i
pdl> p carg $y
0.78539816339744828+0i
That leaves conj (complex conjugate) which should return a
11 matches
Mail list logo
