Hi Ingo and all,
On Mon, Mar 08, 2021 at 09:07:11PM +0100, Ingo Schmid wrote:
> ...
> The native way treats complex numbers as scalars of native complex
> types. This solves the dimensions issue, obviously.
I think it is a good idea not having access explicitly to an
additional index at the beginning of complex pdl's to select its real
or imaginary part. With PDL::Complex, operations like sumover had
to sum over the second, not the first index, something that has produced
some confusion (the first dimension had to be moved
temporarily out of the way before applying some vector operators that
are not complex aware, but not others). So being able to treat a
complex number as a scalar is a very good step forward.
> E.g,. creal and
> cimag can be either seen as slice() where data flow would be welcome or
> as aggregate, where it would not. I think either case can be argued for.
I'm not sure I understand the 'aggregate' alternative.
pdl> my $x=ci
pdl> help $x
This variable is CDouble D [] P 0.02KB
pdl> $r=$x->creal
pdl> help $r
This variable is CDouble D [] P 0.02KB
pdl> use PDL::Complex
pdl> $x1=i
pdl> help $x1
This variable is Double D [2] P 0.02KB
pdl> $r1=$x1->re
pdl> help $r1
This variable is Double D [] -C 0.00KB
In this example $r1 is connected to $x1, but $r is not connected to
$x. What would be the downside of allowing the sharing of data between
$x and $r?
> I guess treating these casts as slicing
I'm not sure if creal and cimag should be called 'casts', or just real
valued functions of complex argument.
> with data flow intact has the
> advantage that there are always sever() and copy() if this is not
> desired.
I think so.
> Can we maintain data flow when changing to abs/arg representation?
I wouldn't try that. As the native format is an array of real, imag
parts, some processing of the data would be necessary for the abs/arg
representation, so it might be more complicated and maybe slow. But
data flow to the real and imaginary parts and/or conversion from a
complex to and from the corresponding real [2] array would be useful
and maybe relatively simple. Something analogous to the real and
cplx functions of PDL::Complex.
>
> On the other hand, any other type cast, I think, breaks data flow. This
> would mean unexpected behaviour to at least some degree, no?
>
> The third issue is automatic conversion with data loss. I think this
> should throw an exception, if you ask me, maybe as a build option for
> those relying on old code?
I agree.
Best 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
