Thanks Chris, I missed that announcement as I wasn't on the mailing list at that point in time. I like the idea of improving the IO, it makes PDL more usable for day-to-day actions.
I needed the methods I present in PDL::Util because I needed them, but wanted to contribute them back to the community. They seemed natural to be outside the Core since they use Perl level actions rather than PP (which is still rather terrifying to me). You are more than welcome to implement something like `unroll` in the core, it will not offend me, quite the contrary. If instead, you would like to pass other little functions to me for PDL::Util (my inspiration was the List::MoreUtils module, or more specifically its mission) for non-Core but useful PDL routines, I would be happy to include them, and thereby help keep the Core clean. Joel On Sat, Oct 1, 2011 at 11:54 AM, chm <[email protected]> wrote: > Hi Joel- > > The new (in PDL git) support for 2-D pdls in > wcols appears to match the convention used by > your PDL::Util::export2d routine as well. > > The current rcols support for 2-D arrays was > the result of some performance optimization > work last spring which lead to the new functionality > as well. The announcement thread is here: > >> >> http://mailman.jach.hawaii.edu/pipermail/pdl-porters/2010-March/001884.html > > The idea was to make rcols more useful for > mixed string/perl column data and numeric/pdl > data files. Reworking wcols to work the same > has been on the to-do list for a while... just > no time to get to it. > > It turns out that the rcols implementation > evolved a backwards convention for dimensions > compared with wcols. > > On 10/1/2011 11:40 AM, Joel Berger wrote: >> what do you mean "Added support for 2D pdls"? do you mean when you >> call wcols on a 2D pdl it will write it out automatically without >> having to slice it first? I've always wondered why that simple >> operation took so much work. Its been part of my (renamed) PDL::Utils >> module, but I guess I would rather it be in the core. > > There are *many* enhancements to PDL that have > been proposed, it just takes volunteers to make > things happen. If I had known of your interest > in the problem, I would have suggested the wcols > fix directly. > > I think it would make sense to fold unroll() into > the PDL core at some point. I'm just not sure > the best way to do so. Given that PDL users > actually do "real work" with the module one > requirement of new additions to PDL core is that > they *not* break back compatibility if possible > or reasonable (e.g., maintaining broken/buggy > functionality going forward is not reasonable). > > As a project, I would like to see a clean way > to coordinate and involve external PDL development > activity with the PDL core evolution. No good > ideas so far but for 2.4.10 I would like to add > a list of external PDL modules to the available > docs. Searching for PDL on http://search.cpan.org > doesn't give a vey helpful list. I only > accidentally discovered your PDL::Util and its > predecessor module. > > Cheers, > Chris > > >> On Sat, Oct 1, 2011 at 8:58 AM, chm<[email protected]> wrote: >>> rcols/wcols users: >>> >>> I just added support to wcols for 2-D pdls and >>> discovered that it was not the inverse operation >>> to rcols---which I think it should be. >>> >>> The rcols implementation uses dim(0) for input >>> columns for the 1-D inputs, but dim(1) for the >>> multi-column inputs. >>> >>> The wcols implementation uses dog on the 2-D >>> input pdls and then does the original wcols >>> output so effectively, both cases use dim(0). >>> >>> My thought is to modify the rcols 2-D support >>> so that the columns in the file always to to >>> dim(0) in the pdls. That would be consistent >>> with wcols usage and with the general idea of >>> things happening on dim(0) and threading on >>> higher dims---not that we thread with [rw]cols >>> at this time. >>> >>> This also makes the rcols consistent with the >>> original get_data() routine by Maggie which >>> motivated the development of 2-D support. >>> >>> Cheers, >>> Chris > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
