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
