Dear all, I've been working on native complex number support and got it to the stage of passing all tests on my linux box. Each element of a piddle is a complex number, no more hassle whether the first dimension needs to be two or not. Essentially it adds binding to C's complex.h.
Check out the nat_c2 branch here, all others are irrelevant and should be deleted: https://github.com/fantasma13/pdl Use cdouble, cfloat, ci() (imaginary unit), cimag, creal, abs, carg to convert. Most basic functions should work as expected from complex math, please report any odd behaviour. The FFT module should play along. I'd love to see the same for FFTW3. There are two general issues I've come across: Implicit type conversion to the next datatype that allows a specific operation. I've seen two examples while working on this: 1.) Comparison operators like < or > silently use the real part of complex numbers and return doubles instead of throwing some error. 2.) asin(2) now returns a complex number when 2 is a scalar, NaN when asin(pdl(2)). In both cases I've no simple solution ready. Also, I think type handling could be improved. Using type classes, e.g. real, integer, complex, unsigned and assigning GenericType classes instead of individual types seems rather straight forward. Also, there's an explicit listing of conversion functions in Core.pm, that could be extracted from Types.pm, I guess. There is no perl complex SV type, so I chose string. That means sclr or at return strings that are not numeric. Any suggestion on this are welcome. It really is only an issue when using these values for math and comparison, string eq should work well enough or convert to real/imag beforehand. The other, more difficult issue is with the Types(..) %{ ... %} construct in PP. It seems to be resistant to my attempts to supply it a variable rather than a literal. Much more testing is required, especially on other platforms, putting it to cpan testers would be easiest, I guess. I hope this is useful to someone. Any feedback is welcome, in particular suggestions for tests, I guess. Best, Ingo PS: Ed, I think it's a good time to pull it over to PDLA, if you like. I was rather afraid to do so with unfinished work. Again, only the nat_c2 branch should be merged. On 21/04/2019 21:17, Ed . wrote:
Fair enough on all points! You may find it more convenient to work on this against pdla-core rather than pdl, just because it will build far faster without all the “kitchen-sink” stuff. It’s possible to get your commits over to pdla-core using git but it’s a bit involved. If you’d like me to do it for you, then please: * fork PDLPorters/pdla-core * add me (mohawk2) as a collaborator * let me know! Best regards, Ed Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 ------------------------------------------------------------------------ *From:* ingo...@gmx.at <ingo...@gmx.at> *Sent:* Sunday, April 21, 2019 6:57:00 PM *To:* pdl-devel; Ed . *Subject:* RE: [Pdl-devel] pdl complex support yes, i agree with most of what you say. Let me just say that I didn't understand the internals when I started and still don't really in many places. so a lot of the changes were and are trial and error. tests are missing and will come, so will reverting the unnecessary changes. the livstc++ is one of them. it isn't propagated anyway. For keeping copies of files, i sometimes find it very tedious to work with git when quickly comparing changes. the version update was primarily for myself to be sure to be in the right branch. i mostly lack time to work on this. best Ingo Sent from MailDroid <https://goo.gl/ODgwBb> -----Original Message----- From: "Ed ." <ej...@hotmail.com> To: "ingo...@gmx.at" <ingo...@gmx.at>, pdl-devel <pdl-devel@lists.sourceforge.net> Sent: Sun, 21 Apr 2019 19:33 Subject: RE: [Pdl-devel] pdl complex support I don’t have much help to offer for the complex stuff currently, only a couple of thoughts. Looking at the diffs between your branch and master, I see you’re doing lots of interesting things, together with a couple I don’t understand: * There’s no reason for you to change version numbers, let the releasing person worry about that :-) * Changing indentation creates diffs for no reason and means reviewing takes longer * I see you have made copies of Core.pm.PL with -master and -multielement on the name; since you have git, why not just put those changes either on a different branch, or just in comments in your copy of Core.pm? Or at the very least, don’t add them to git :-) * You say you’re trying to use PMCode to make things work; at https://github.com/PDLPorters/pdl/compare/master...fantasma13:nat_complex#diff-621e73c99459a6921891a9de81d5818aR379 I see you have what may be a typo and it says “PMCod”, that may be connected? (PP really should complain about unknown options, that’s a bug I think) * I don’t think adding “-lstdc++” is going to be very portable, there’s probably a better way? * Your perldl.conf has turned off WITH_BADVAL? It’s a pity that PDL types aren’t implemented as plugins that get assembled into the full PDL implementation. I see it’s necessary to have pdlcore.c know about this one, which means it wouldn’t be possible to add “complex native” at runtime, but it would at least make managing PDL easier. It’s also a pity that you’ve had to add the “GenericTypes=>BSULNFD” to so many .pd files, it seems like there should be a better way. I think docs are often an interesting way to start on writing code, in order to help understand the code one will write. However, I think if you understand this change well, there’s no problem leaving that till last! However, I /do/ think that writing tests is incredibly critical, and makes your own life a lot easier (as I mentioned in a previous email). As a drive-by observation, I believe that a lot of PDL modules operate in a way that looks a lot like “roles”, in that they add functionality to central PDL. I don’t have any specific thoughts that lead from this yet. Best regards, Ed Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 ------------------------------------------------------------------------ *From:* ingo...@gmx.at <ingo...@gmx.at> *Sent:* Sunday, April 21, 2019 9:00:36 AM *To:* pdl-devel; Ed . *Subject:* Re: [Pdl-devel] pdl complex support Ed, great, that split helps development, I'm sure. basic complex number support seems to work. Currently, I face two issues: print does not do what i want. it seems to ignore my format. the other is abs. i need to set output type based on input type, i want to cast complex double to double, while the rest keep there input type. i tried pmcode to make the cast, but that is ignored, apparently. I'm doing something wrong, apparently. nothing is documented yet in changes. but feel free to check out. ci returns a complex piddle 0+1i. creal, cimag, carg do what you expect, most basic math should as well. to display, use print on creal/cimag. tests are missing Best wishes Ingo Sent from MailDroid <https://goo.gl/ODgwBb> -----Original Message----- From: "Ed ." <ej...@hotmail.com> To: Ingo Schmid <ingo...@gmx.at>, pdl-devel <pdl-devel@lists.sourceforge.net> Sent: Sun, 21 Apr 2019 8:24 Subject: Re: [Pdl-devel] pdl complex support Hi PDL Porters, As I’m just going to announce on pdl-general, I would say PDLA is ready to develop (and run experiments) against. It’s up to date with legacy PDL master, on v2.019101 for both PDLA::Core and PDLA::Rest. There is an experimental single module that has been carved off from the mass – PDLA::IO::HDF. It’s also been brought up to date. Feel free to fork and have a play with either or both of https://github.com/PDLPorters/pdla-core <https://github.com/PDLPorters/pdla-core> and https://github.com/PDLPorters/pdla-rest <https://github.com/PDLPorters/pdla-rest> ! Next steps: * stop -rest using %PDLA::Config to decide on building stuff or not * make the -rest CI test everything, at least on Linux (I may need help for Windows) * make all the .pd files instead be Inline::Pdlapp .pm files, installable using Inline::Module, for PDLA::IO::HDF first, then ::Core (I already have a branch that this works on) * put the demos together with what they’re demo-ing, installed as PDLA::Demos::* * make the command shells search for PDLA::Demos::* when asked for what demos are available Somewhere in there, I’ll be making a “repro” tool, which will help in publishing easily-reproducible scientific experiments; it will capture OS + version, scripting language + version, modules + versions, actions (possibly from URLs), and expected outputs. Ingo, I’d like to see what you come up with for this complex numbers processing idea! Best regards, Ed *From:* Ed . <mailto:ej...@hotmail.com> *Sent:* Tuesday, April 16, 2019 5:37 PM *To:* Ingo Schmid <mailto:ingo...@gmx.at> ; pdl-devel <mailto:pdl-devel@lists.sourceforge.net> *Subject:* Re: [Pdl-devel] pdl complex support Hi Ingo, > I and my group use it daily for scientific use in medical imaging Great to know. Yes, you won’t be able to update the main pdl repo yourself. A fork is the “normal” way to go about this. This looks like the branch you’re working on? https://github.com/PDLPorters/pdl/compare/master...fantasma13:nat_complex You’re quite right that PDLA isn’t quite ready to work off, but watch this space because that’s imminent. To use your local, non-installed copy there are two ways forward. One is just to use it in blib: make perl -Mblib myscript.pl # or perl –Mblib pdl2 An alternative model is just test-driven development; make a t/complexnatives.t file, put in there stuff you expect to work, then run it like this: make && prove -bt/complexnatives.t I use the second one myself, since you then have something that will permanently constrain the code to work the way you specify in the tests. Best regards, Ed *From:* Ingo Schmid <mailto:ingo...@gmx.at> *Sent:* Tuesday, April 16, 2019 4:56 PM *To:* pdl-devel <mailto:pdl-devel@lists.sourceforge.net> *Subject:* [Pdl-devel] pdl complex support Hi, I'm glad to hear PDL isn't dead, it's been very quiet on the lists. I and my group use it daily for scientific use in medical imaging. I have started work on native c-level complex numbers support. I tried to push to github, but I got this error: fatal: unable to access 'https://github.com/PDLPorters/pdl/': The requested URL returned error: 403 So I had to create this fork: https://github.com/fantasma13/pdl.git I guess this is to be expected. It's still very much work in progress. I just managed to pass all tests. Bad value support is not implemented yet, that horribly failed. I have no idea if you can actually create a piddle yet. ;) Essentially I created a new entry in Types.pm.PL with c type complex double and included complex.h. The rest was weeding through errors and extensive use of GenericTypes in pp_def I am really missing proper complex number support. Let's see where we can get that. It's based on 2.019 PDL, I looked to base on PDLA but since it was behind the main PDL tree I chose against. Now I would really like to use and test the freshly made PDL from the build directory without having to make install it. in particular the pdl2 shell. Does anyone know how to do that? So far I failed. Best wishes Ingo ------------------------------------------------------------------------ ------------------------------------------------------------------------ _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel ------------------------------------------------------------------------ ------------------------------------------------------------------------ _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
_______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
