The idea I had in mind was to make a PDL_SV that could hold a reference to any type, not just array-like types. It would basically enable fast looping over your SVs. This would turn PDL into a general N-dimensional data container. Limiting the PDL_SV type only to references to arrays is not as general as I would like.
As for allowing blessed arrays to masquerade as PDL objects, I think that's tangential to the discussion. Cool idea, and probably a very difficult one, but not necessary from the standpoint of PDL types. David On Tue, Jun 11, 2013 at 12:53 PM, Craig DeForest <[email protected]>wrote: > I imagine being able to bless an array ref to being a PDL, and have it > autodetected, just like hashes are autodetected now...? > > On Jun 11, 2013, at 11:52 AM, Chris Marshall <[email protected]> > wrote: > > > Would it need to be specifically a PDL? > > I could imagine arrays of objects of any style > > that could fit that framework. Of course, a > > specialization for the PDL case would be a > > common optimization. > > > > This would actually be very nice as a way > > to apply PDL threading and looping to perl > > level constructs---maybe both directions. > > > > --Chris > > > > On Tue, Jun 11, 2013 at 1:44 PM, Craig DeForest > > <[email protected]> wrote: > >> I think this is a nifty idea, if it can be made to interoperate with the > >> rest of the threading engine without slowing everything down. Maybe > the SV > >> * type should operate only on array refs...? > >> > >> The only way I can see it working is if we make it "superior" to PDL_D > in > >> the type hierarchy, so everything is promoted if possible (or demoted if > >> necessary) when a PDL_SV is encountered. Selection operations would > require > >> some thought - basically a new case for each of slicing, dicing, and > >> indexing. > >> > >> > >> > >> On Jun 11, 2013, at 11:31 AM, David Mertens <[email protected]> > >> wrote: > >> > >> I would really like to have an SV* PDL type, as well as a PDL method > >> 'invoke' that would call a supplied function reference or method name on > >> each SV*. Said method would croak on all but SV* types, of course. > >> > >> Obviously, any operations on this would be really slow compared to bare > C > >> types, but they could also be far more diverse. I could easily write a > >> PDL::Drawing::Prima method that could take x, y, and (possibly utf-8) > >> strings and thread over coordinates and strings correctly. With > PDL::Char, I > >> only get ASCII, and all the strings are allocated to the longest needed > >> string, which is not quite what I would like. > >> > >> It would also be possible to have each SV* be a reference to another PDL > >> with arbitrary shape, allowing Edward to achieve what he wants. > >> > >> David > >> > >> > >> On Tue, May 28, 2013 at 2:57 AM, Edward Baudrez < > [email protected]> > >> wrote: > >>> > >>> On Mon, May 27, 2013 at 4:28 PM, Chris Marshall < > [email protected]> > >>> wrote: > >>>> For example, from the PDL::IO::HDF5 README: > >>>> > >>>> This package provides an object-oriented interface for the > >>>> PDL package to the HDF5 data-format. Information on the > >>>> HDF5 Format can be found at the NCSA's web site at > >>>> http://hdf.ncsa.uiuc.edu/ . > >>>> > >>>> LIMITATIONS > >>>> > >>>> Currently this interface only provides a subset of the total > >>>> HDF5 library's capability. > >>>> > >>>> o Only HDF5 Simple datatypes are supported. No HDF5 Compound > >>>> datatypes are supported since PDL doesn't support them. > >>>> > >>>> o Only HDF5 Simple dataspaces are supported. > >>>> > >>>> So clearly, PDL has a need for <something new>. :-) > >>>> Your responses will help to prioritize and select the > >>>> implementation of this feature for PDL3. > >>>> > >>>> Thanks in advance for your replies. > >>>> Chris Marshall > >>>> PDL-3.000 release manager > >>> > >>> Hi > >>> > >>> > >>> I am sorry I haven't spoken up earlier, but I do have an idea for a > 'new' > >>> data type that you may want to consider. As you may know, I wrote a > >>> multidimensional binning/histogramming library for PDL > >>> (https://metacpan.org/module/PDL::NDBin). The idea is very simple: > data > >>> points are classified into (fixed-width) bins, much like histogram(). > My > >>> library also allows arbitrary callbacks on the data, so that, after > >>> classification into the bins, you can perform any kind of computation > on the > >>> data values inside the bins (not just counting them, like > histogram()). I > >>> use it, for example, to classify satellite data collected all over the > globe > >>> in latitude/longitude boxes, and calculate mean and standard deviation > >>> inside every latitude/longitude box. > >>> > >>> The actions I've implemented so far (count, sum, average, standard > >>> deviation, minimum and maximum) are all reductions, so I end up with > one > >>> value per bin. The final value for all the bins are grouped into a > piddle of > >>> one of the standard types. I need this functionality to handle > >>> multidimensional binning with an algorithm that is essentially > >>> one-dimensional (i.e., I use reshape() to convert the internal, > >>> one-dimensional piddle holding all the return values from the bins > into an > >>> N-dimensional piddle). > >>> > >>> But now I am thinking of creating an action that would collect the data > >>> values in the bins (this would be useful for plotting or regression). > >>> Obviously the number of data values per bin would be different for all > the > >>> bins. So if there was a data type in PDL that would essentially hold > other > >>> piddles, instead of raw C data values, that would be very convenient. > (A > >>> piddle containing piddles). > >>> > >>> I admit that I haven't thought through this very thoroughly. It may > even > >>> be infeasible. But you asked for suggestions ;-) > >>> > >>> I imagine the above may not be very clear. Let me know if you want more > >>> information. > >>> > >>> > >>> > >>> Best regards > >>> & All my sympathy for the continuing development of PDL - Much > >>> appreciated! > >>> > >>> Edward > >>> > >>> _______________________________________________ > >>> PDL-porters mailing list > >>> [email protected] > >>> http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters > >>> > >> > >> > >> > >> -- > >> "Debugging is twice as hard as writing the code in the first place. > >> Therefore, if you write the code as cleverly as possible, you are, > >> by definition, not smart enough to debug it." -- Brian Kernighan > >> _______________________________________________ > >> PDL-porters mailing list > >> [email protected] > >> http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters > >> > >> > > > > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
