Hi Ed and all, I think we are touching on two non-trivial issues here when looking at complex numbers which, I think, merits discussing.
In PDL::Complex, complex numbers where vectors with size 2 of whatever real data type used. This made for awkward code if functions worked on either complex or real input. On the other hand, accessing real or imaginary parts are essentially slicing operations. The native way treats complex numbers as scalars of native complex types. This solves the dimensions issue, obviously. 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 guess treating these casts as slicing with data flow intact has the advantage that there are always sever() and copy() if this is not desired. Can we maintain data flow when changing to abs/arg representation? 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? Do you think this is already handled correctly? Ingo
_______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
