On Tue, Dec 31, 2013 at 5:19 PM, David Mertens <[email protected]> wrote: > Yes, broadcasting is the numpy equivalent to PDL's "threading": > http://docs.scipy.org/doc/numpy/user/basics.broadcasting.html > > One of the important differences, though, is that PDL performs its > auto-looping by *always* matching the dimensions from the start of the > dimension list, whereas certain numpy methods let you indicate the "axis" > over which to perform an operation. While this seems like a limitation in > PDL, we actually let you *manipulate* the order of your dimension list, so > you can arrange data of various shapes so that they operate the way you > want. To my (limited) knowledge, numpy does not seem to support this.
PDL3 is planned to include attributes for pdls and/or axes. This will support more general threading such as via specific dimension (like dims [2,5]) or even threading specified semantically (an image routine could automatically work on the dims [x, y] and thread over the rest. Imagine not having to be confused about whether pixel color was its own axis (RGBA) or collapsed (grayscale image as 2D intensities). > Knowledge to the contrary would be much appreciated, but a skim over this > document left me unconvinced. Of course, it can be confusing as all hell to > line up your dimensions, which might arguably be considered a bug. Semantic matching would help. I would like to see some sort of wizard or gui/tool that makes it possible to quickly form and debug correct auto-threading code. The improved error outputs that Craig has added will help a lot. Maybe we could syntax highlight matching thread dimensions as the user types in their code into the PDL shell.... > Another important distinction is that in PDL slices never break data flow; > you have to manually sever data flow if you don't want it. The discussion on > Advanced Indexing leaves me to believe that non-affine slices always perform > data copies. This feature of PDL was the major technical reason I preferred > it over Matlab (in addition to the slightly-less-important features of sane > hashes, awesome string manipulation, and simple sysadmin functionality). It does seem that NumPy has that limitation. I like the ability to put a longer but more meaningful newdim in a slice specification. Interestingly, this matches up quite well with the new slice() implementation cleaned up by Craig recently... Cheers, Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
