Hi Karl, The old design makes sense when put that way, though I don’t feel you need to justify it :-) There were a couple of tests that needed updating with the change, and a few downstream things also needed updating. Largely, as you say, the reliance on the old behaviour wasn’t huge.
Speaking of older scripts, it will help the current PDL maintainers if you turned your scripts into something module-ish, and put that with tests on CPAN (or even on GitHub). That way it could be added to Zaki’s amazing downstream testing, which runs every known downstream against each new commit in PDL to identify any regressions. That’s led to some very interesting problems identified, sometimes in the downstream modules, sometimes revealing assumptions that wanted revisiting. Best regards, Ed From: Karl Glazebrook<mailto:[email protected]> Sent: 15 January 2024 07:16 To: Ed .<mailto:[email protected]> Cc: perldl<mailto:[email protected]> Subject: Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - scalars vs piddles Hi Ed I believe the original logic here (likely mine) was that if the 0D PDLs turned automatically in to scalars they could be fed directly, without casting, in to perl-to-C calls and PDL did a lot of that. e.g. I used to do a lot of direct calling of the PGPLOT module commands. I guess if that sort of thing has now been extirpated from the PDL source (which seems likely given all tests pass) itself all is good. Probably not many end user scripts need fixing. I think you are right it is better these days if objects do not magically change type. Happy for the name change :) It was not my joke... Karl On 14 Jan 2024, at 12:46 am, Ed . <[email protected]<mailto:[email protected]>> wrote: Hi Karl, Good to hear from you! And I hope that apart from the issues you’ve raised, that your experience with the new PDL is good. Have a look at the updated demo system, including the updated 3D demos, and see if you can tell the pthreading is done automatically on large-enough data by detecting the number of cores available by default. The change in the aggregate functions was introduced in 2.056. I would now say I didn’t take sufficient account of backwards compatibility on that one. Sorry for the inconvenience. My reasoning was in how shocked I was that those functions were returning Perl scalars. By the way, you (of all people!) are welcome to call these data objects what you like, but another change made (this time in 2.040) was to rename “piddles” (which always struck me as faintly juvenile, and I felt would undermine PDL’s credibility for no good reason) to “ndarrays”, which is a widely-used term. The “piddle” function was retained for back-compatibility. Best regards, Ed From: Karl Glazebrook via pdl-general<mailto:[email protected]> Sent: 07 January 2024 00:29 To: perldl<mailto:[email protected]> Subject: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - scalars vs piddles Hi all, This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is lame) I noticed a few things when running one of my complicated codes, I will start seperate email threads Next I think this one is a design choice change I missed. - Functions like median() max() etc now return a 0D piddle and no longer a scalar. This broke some gnarly code I had. I expect this change was sensible, I am just curious as the reasons and when it happened? best Karl _______________________________________________ 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
