Actually, seconding my second, a good working (failing) example can be the starting point for new failing tests, which are *always* useful in development.
On Tue, Apr 17, 2012 at 9:26 AM, David Mertens <[email protected]>wrote: > On Tue, Apr 17, 2012 at 6:41 AM, Chris Marshall <[email protected]>wrote: > >> Hi Ingo, >> >> Do you have a simple test case to >> show the problem? What version >> of perl+PL... do you have? >> >> See BUGS in the PDL distribution for >> the information needed for problem >> reports. >> >> --Chris >> > > Ingo, I will second what Chris said. It's always helpful to give a > complete working (i.e. failing) example so that we devs can just > copy-and-paste it into an editor and start hacking. Also, the full error > message might have been helpful here as well, as it likely would have given > us this line number where the dimension mismatch occurred. To make a long > story short, this is a bug with PDL::Func. Your best bet is to file a bug > report on sourceforge.net here: > http://sourceforge.net/tracker/?func=browse&group_id=612&atid=100612&status=1. > I suggest using a title such as "PDL::Func does thread properly" since the > code works fine if you want the interpolation at a single x-value. Be sure > to read the instructions when adding a bug (i.e. include the output of > perldl -V, etc). > > Even though you did not provide a working example, a difference in > dimension handling is usually pretty easy to pick out from the module's > code itself, so I decided to simply look over PDL::Func's code. For devs > and other interested parties, see PDL::Func (Lib/Func.pm in the repo) > starting around line 723. Hermite interpolation uses the chfe routine > provided by PDL::Slatec while linear interpolation uses the interpolate > routine provided by PDL::Primitive. These two routines expect different > kinds of inputs, as evidenced by their signatures (which are far from > obvious and which I explain next): > > chfe (x(n);f(n);d(n);int check();xe(ne);[o]fe(ne);int [o]ierr()) > interpolate (xi(); x(n); y(n); [o] yi(); int [o] err()) > > For the Slatec function chfe(), x(n) and f(n) are the known x and y values > to be used in the interpolation. d(n) is... something (the derivatives at > these points, perhaps?); the docs do not make it clear. The important point > is that the value of x at which we want interpolation are given by xe(ne). > For interpolate(), x(n) and y(n) are the known x and y values and the x at > which we want interpolation is xi(). NOTICE THE DIFFERENCE IN THE DIMENSION > between xi() and xe(ne). This difference was not properly accounted for by > Doug and means that the hermite interpolation and linear interpolation > interfaces are not interchangeable as written. That sucks, as the whole > point of this module was to unify the interface between two distinct > packages. Properly reconciling differences in dimension handling is doable > but tricky, and writing cogent documentation to explain the dimension > handling is even trickier. :-P > > David > > >> On 4/17/12, Ingo Schmid <[email protected]> wrote: >> > Hi, >> > >> > I just noticed that when using interpolate, there is an inconsistency >> > when changing from 'Hermite' to 'Linear' and threading. This is my code. >> > When I try 'Linear' it barfs with thread dim 0 mismatch. >> > >> > my $seq=sequence(eval $p{kx})-$p{kx}/2; >> > say $r->info,cat($r,$i)->info,$resample->info,$seq->info; >> > >PDL: Double D [256,128,1,1,2,32]PDL: Double D [256,128,1,1,2,32,2]PDL: >> > Double D [256]PDL: Double D [256] >> > my $obj=PDL::Func->init(Interpolate => "Hermite", x >> > =>$resample, y=>cat($r,$i)); >> > my $kres=($obj->interpolate($seq))->mv(0,-1); >> > >> > >> > Btw., are there other schemes/modules to try? >> > Best >> > Ingo >> > >> > >> > >> >> _______________________________________________ >> Perldl mailing list >> [email protected] >> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >> > > > > -- > "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
