Hi Ingo, That does sound like the right approach. Do you feel like making a PR with at least a sketch like “talk about complex numbers here” in the various places, for me to expand? Obviously, you’ll be welcome to also document it a bit more fully instead ;-)
Best regards, Ed From: Ingo Schmid<mailto:[email protected]> Sent: 08 March 2021 16:58 To: [email protected]<mailto:[email protected]> Subject: Re: [Pdl-general] [Pdl-devel] PDL 2.027 released Hi Ed, I think that the first point of reference for data types should PDL::Types, no? I see that it currently is not containing any discussion of the actual data types, though. Another option would be to add something to the top-level PDL pod, probably referring to other docs (which?). Specific functions should already appear in their respective modules' documentations, no? So I guess a more thorough introduction in PDL::Types or a new PDL::DataTypes (or something) with cross links to PDL::Complex , Ops, UFunc, etc. As a user, I guess PDL::Complex is the first place where I would look, though, so at least a first-paragraph dereference to the actual location of relevant bits is probably a good idea. On 08.03.21 16:28, Ed . wrote: Hi folks, I added the warning because I found the behaviour surprising when adding tests. Yes! It definitely is. I think with the proper pp macros / signature ... this could be changed, I guess. I remember trying to change this (but not very hard, I think) when I created that. I only did so not to interfere with PDL::Complex. My plan now is that ci() will go away, so my proposal is to use it as “ci()” for now, bearing in mind it’s only temporary. How does that sound? Sorry about the API change. If we had a proper bit in the docs about handling of complex numbers, I’d have added a warning that it should be considered experimental and subject to change. If anyone has ideas about the best location for such docs, please say :-) By the way, there is a PDL 2.028_01 that’s intended to fix a few remaining gremlins in native-complex on older (and buggy/incomplete) libm’s on FreeBSD and CentOS, together with some updates I’ve incorporated out of the PDLA distros. If it tests Ok, I’ll be full-releasing 2.029 quite soon, then looking at the PDL::Complex integration. Best regards, Ed From: Luis Mochan<mailto:[email protected]> Sent: 08 March 2021 15:15 To: [email protected]<mailto:[email protected]> Subject: Re: [Pdl-general] [Pdl-devel] PDL 2.027 released Hi Ingo, On Mon, Mar 08, 2021 at 03:35:36PM +0100, Ingo Schmid wrote: > ... > Now, looking into PDL::Ops you will see this warning: > > Returns the complex number 0 + 1i. > > B<WARNING> because this is not defined as a constant (with empty > prototype), you must use it either as C<10*ci> or C<ci()*10>. If you > use it as C<ci*10> this will actually try to use 10 as a glob and pass > that to C<ci>, which will not do what you want. Yes, I saw the warning. Nevertheless, having $x+ci!=$ci+$x would surprise many. For this reason, I guess it would be a good idea in the meantime, before the merge with PDL::Complex mentioned by Ed, to give an explicit error or warning message whenever ci is called, most probably inadvertently, with an actual non-null argument, or else, to promote the use of a 'true' constant (maybe CI), similar to the 'i' of PDL::Complex, instead of the function ci. Would use constant CI=>ci; # or sub CI () {state $i=ci; return $i;} my $z=$x+$y*CI; # ==$x+CI*$y be more expensive than my $z=$x+$y*ci; # !=$x+ci*$x ? If not, then the current ci could be hidden from the users and CI above exported (maybe with a better choice of names). Best regards, Luis _______________________________________________ pdl-general mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/pdl-general
_______________________________________________ pdl-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-general
