I forgot to mention one thing I would love to see added .. bit storage format... (bit-fields)
pdl bit, 1000,1000 -------| http://ifni.co On Fri, Dec 6, 2013 at 9:44 AM, Chris Marshall <[email protected]> wrote: > Thanks for the reply and constructive feedback, Ingo. > > On Fri, Dec 6, 2013 at 8:05 AM, Ingo Schmid <[email protected]> wrote: >> >> I wanted to post that a while ago, better late than never, I >> guess. >> >>> Dear PDL Users- >>> >>> In an effort to gauge the progess of PDL development in >>> functionality and usability, I would invite you to reply to me >>> or to list with a quick message about your PDL use: >>> >>> - How long have you used PDL? >> >> several years, 2.4.3 was released then. > > I guess you started with PDL about the time I first put on the > release manager hat. :-) > >>> - What PDL version do you use? >> >> at the moment, 2.007 >> >>> - Best thing(s) about PDL >> >> Most important, it's perl, which I happen to use since the 90s. >> A piddle is a perl referebce ! (Almost) everything you can do >> with perl, you can do with a piddle. So integration into other >> applications is easy. >> >> threading! >> Niceslice! >> active and very helpful mailing list! >> >>> - Worst thing(s) about PDL >> >> PDL::Complex - or rather a lack of native complex data types, >> and standardised interface to complex numbers. > > Improved type support to include complex numbers is planned > for PDL3. > >> Far less important but still, the barf on multielement piddles! >> It breaks the expected if ($var) { ...} perl behaviour. This is >> an issue whenever you use existing perl code with piddles. I >> thought about it and maybe a per-piddle $piddle->cond_behave() >> call added? The default value and undef would mean the >> current behaviour, the other values would be, for example >> 'any','all','defined'. Then these calls are used in the >> conditional expression. Discussion should go to a separate >> thread, I guess. > > There has been some discussion about this already and > I think the "proper" solution would be to make PDL be > consistent with other perl objects. The existing error > could be moved to planned PDL warnings support. That > has been on the wish list for quite some time. > >>> - I would use PDL more (or at all) if only ... >> >> ... I could find the time to look into PP. >> >> honestly, hard to say, I already do most stuff in PDL. >> >>> - Any suggestions for PDL development? >> >> many ;) >> >> A lot of work has gone into making PDL easy to install. Keep >> that going! > > Bug reports, testing and user feedback are critical to > keeping this going. > >> The graphics side took huge steps forward with bindings to >> Prima and Gnuplot. BTW., what do you get if you install PDL but >> have no graphics package installed? I'd like to see a big fat >> warning whenever that is the case, because nothing would turn >> people away faster than not being able to say "plot $x;" and >> get something on the screen, I guess. > > Good idea. > >> Better documentation, especially some kind of index to look for >> keywords related to modules/functions is always an issue. > > Better documentation, cross-references, and a more uniform > method/function naming scheme and argument format are all > much desired features. > >> There has been a lot of improvements, especially the book is a >> real bonus. As a side note, when I click on the PDL Book link >> (side panel on pdl.perl.org), I come to the page first steps >> with PDL. Only at the very bottom of the page, there is a link >> to the sf book! Please provide a link right at the top! > > Done. > >> Support more data types, especially complex. > > Generic type support is planned in the PDL3 development. > Right now, the goal for PDL-2.008 is to address the > remaining limitation of the 64bit index support within > the current PDL-2.x development sequence. > > The PDL3 work will start from a core-cleanup from the > PDL-2.008 release which is hoped to be completed by > the end of Dec 2013. > >> Make PDL as perlish as possible from the view of other non-PDL >> modules. Ideally, PDL behaves just like another class, and >> a piddle is just yet another reference to an object. Recent >> discussions on use base PDL; and Storable should give you an >> idea what I mean. > > Clean up of the default PDL import semantics is also > a goal for PDL3 work. Various clean up along the > way is occurring. > >> Support for meaningful dimensions (names, units, spacing). >> Rather than having to remember and keeping track of what your >> piddle looks like, ie. the mes one can end after using several >> mv(), reshape(), etc., calling sumover('x','t') would be cool. > > Support for attributes to tag dimensions with various > metadata are planned for PDL3 as well. We have a general > approach already (roughly based on HDF5) but want to > clean up the PDL base before adding anything new. The > idea is that PDL3 will be more minimalist (closer to the > current PDL core distribution but allowing for backwards > compatibility to the 2.x sequence while enabling aggressive > new capabilities. > >> I have been working on that and some stuff is already there. >> I plan to release a module some time in the future, but have >> currently too much other stuff to do. Discussion should go to a >> separate thread, I guess. > > Yes, and please keep pdl-porters in the loop. It could > help to avoid redundant effort or inconsistent implementations. > >> To summarise, I like PDL a lot and use it a lot. > > Great to hear... > > Happy PDL-ing! > Chris > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
