That might be useful in general (outside of PDL) even. FLUX is an MHD model I wrote in C, with direct Perl access to all the data structures -- although the engine is in C, all the control code is implemented in Perl/PDL. To make that happen, I implemented a tied-hash structure object that used a linked table present in both the C header files and the .pm file, to tie structures to hashes (which then autoblessed into various classes when found via the internal C data structure). The upshot is that you can drive around the very complex dynamic data structure of the MHD model by following autogenerated references from the perl side.
That was a PITA to do but could easily be generalized if I or anyone else ever got enough tuits. On Jun 12, 2013, at 9:12 AM, David Mertens <[email protected]> wrote: > Another type that I would really like to have is a Struct type, in which I > can specify the layout of a struct. For example, here's a linked list of > points: > > my $struct_layout = build_struct_layout_for(q{ > double x; > double y; > size_t next; > }); > > my $data = pdl_struct($struct_layout, 1000); > > # This returns a piddle "slice" of the xs: > > $data->x .= 0; > $data->y .= 0; > > # Make a linked list, with -1 being "no more" > $data->next .= $data->sequence + 1; > $data->next->set(-1, -1); > > This way, I could write C functions that process the linked list and later > slice out the data for manipulation of plotting. > > David > > > > On Wed, Jun 12, 2013 at 9:56 AM, David Mertens <[email protected]> > wrote: > 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 > > > > -- > "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
