Re: [Pdl-devel] Bad value support - all configuration options still necessary?

Before bad value support was built into PDL, we implemented our own bad value handling using NaNs to mark bad (or empty/missing) values as PDL subclasses. Since we are handling bad values outside of the normal PDL codebase, we are depending on the PDL bad-value support to NOT be on. On 3/4/20

Re: [Pdl-devel] Bad value support - all configuration options still necessary?

That’s good news! I’m glad the extra labour is worth it. I’m interested if you could help me understand (in just a few words) why you do that? Ed From: John Cerney Sent: Tuesday, March 03, 2015 10:53 PM To: pdl-devel@lists.sourceforge.net Subject: Re: [Pdl-devel] Bad value support - all config

Re: [Pdl-devel] fitpoly1d()

Craig, Please could you try this workflow: make the (apparently minor) change, on a git branch? Then we can give it a run through Travis, and test and adjust as necessary, before merging it to master. Ed From: Karl Glazebrook Sent: Wednesday, March 04, 2015 9:39 PM To: Craig DeForest Cc: pdl

Re: [Pdl-devel] fitpoly1d()

Would someone mind switching it back for me? The overhead of figuring out the source control system again is too much for a two character change. I’d be happy to write a short test Karl > On 4 Mar 2015, at 11:35 am, Craig DeForest wrote: > > I made that change during the whole g77-to-gfortra

Re: [Pdl-devel] fitpoly1d()

I made that change during the whole g77-to-gfortran switch several years ago, when it was hard to get slatec to compile on many platforms. I have no objection to switching it back. MatrixOps was an attempt to put at least *something* in place that would compile whenever the core of PDL would —

Re: [Pdl-devel] fitpoly1d()

Hi Derek Yes it seems the switch from PDL::Slatec::matinv to PDL::MatrixOps::inv was at fault! Clearly the latter does not thread correctly. Further investigation suggests that for fitpoly1d($x,$y) with 2D $y then it fails when - $x is absent - $x is 2D But it WORKS when $x is 1D, with $y 2D

Re: [Pdl-devel] fitpoly1d()

Hi Karl, Maybe if we had a test for threaded fitpoly1d we would have caught this 4.5 years ago! Looks like the problem is with the change from PDL::Slatec::matinv to PDL::MatrixOps::inv [8adb0b] . Running your ex

[Pdl-devel] fitpoly1d()

fitpoly1d() no longer seems to thread over extra dimensions: pdl> $x = pdl( [101,103,104,102,109] ) pdl> p $x [101 103 104 102 109] pdl> ($xf, $c) = fitpoly1d($x, 2) pdl> p $xf [100.8 102.3 103.8 105.3 106.8] pdl> pdl> $x = pdl( [101,103,104,102,109],[101,103,104,102,109] ) pdl> p $x [ [101