I have some awareness of PDL::Dims, which I did think was neat but couldn't fully see how to get more out of it. Thinking of it now, I think that the idea of naming dimensions more "properly" should be a core PDL capability. I believe the starting point would be to build on the FITS support that's already there, and that PDL::Transform and the plotting of FITS-enabled ndarrays utilise. I have pondered not long ago that e.g. slice should update any FITS header so the output ndarray is still correct if e.g. a dim gets "squished", which doesn't currently happen, similarly with mv and xchg. What do others think?
And on the subject of capabilities I think should be stolen into core PDL, I believe "apply an operation over dims other than 0" is another. I haven't yet figured out how a user would express that, but when I do, it will allow skipping one mv (etc) operation, which would make programs run a bit faster. If anyone has an idea of code snippets they think "should work", please share them for inspirational purposes! By the way, PDL::Dims doesn't show up on MetaCPAN search box, because the POD formatting isn't right. Also there's no repository metadata in there (see https://github.com/PDLPorters/PDL-Graphics-TriD/blob/master/Makefile.PL for specifics on how to add it, especially the 3 lines of string stuff above WriteMakefile, and the META_MERGE param to that) and also there's an open bug with it (regarding an author test that shouldn't be under t/) on https://rt.cpan.org/Ticket/Display.html?id=141596 which should be easy to fix, and should actually be fixed. The POD needs to be "=head1 NAME\n\nPDL::Dims - give PDL ndarrays named dimensions\n\n", then the SYNOPSIS would be just a short bit of code, moving the human text currently in that into the DESCRIPTION. This is not to shame anyone, just so that everyone is aware of the conventions that MetaCPAN depends on people sticking to. And finally, in the ncop function, for overloaded stuff in modern PDL you don't need to supply the 0 parameter (it defaults to that with a new mechanism), and I'd suggest the doc should say to consult the PDL::Ops module doc to find that name. The next version of PDL is going to have what I think is much better docs especially for PDL::Ops, as now PDL::PP knows what Perl operators an operation overloads, and generates quite nice unified "usage" documentation automatically. Coming to a CPAN near you, very soon! (Just got a couple more bugs to squash) Best regards, Ed ________________________________ From: Luis Mochan <[email protected]> Sent: 13 January 2025 18:50 To: Ingo Schmid <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [Pdl-general] [Pdl-devel] Pdlpp modules On Mon, Jan 13, 2025 at 03:08:51PM +0100, Ingo Schmid via pdl-general wrote: > Hi Luis, > > I like this, thank you! > > For completeness sake, I have written PDL::Dims a long time ago, which > allows accessing dims via names (and, to some extent units), which sort of > does that. Thanks! PDL::Dims looks nice and useful. Regards, Luis > > Ingo > > On 12.01.25 2:10 AM, Luis Mochan wrote: > > Hi again, > > > > By the way, I made a small package which may be useful (unless its > > functionality is already part of PDL and I missed it): PDL::ApplyDim. > > The idea is to factor out a common shuffling and unshuffling of > > ... -- 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 | [email protected] /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB _______________________________________________ pdl-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-general
_______________________________________________ pdl-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-general
