From: Chris Marshall Sent: Saturday, October 03, 2015 12:24 AM To: Sisyphus Cc: kmx ; perldl Subject: Re: [Pdl-general] CHM/PDL-2.013_01.tar.gz uploaded to CPAN
> On Fri, Oct 2, 2015 at 9:06 AM, <[email protected]> wrote: > > ...snip... > > That *looks* like a "long double" precision result, and you don't know > otherwise until you compare it to the correct result: > > C:\>perl -le "print sqrt(2.0);" > 1.41421356237309505 > > I'm in the process of making a topic branch where the conversion to double > from long double is made with a warning if the conversion cannot be exact. > That seems a reasonable approach in the short term (for PDL-2.014). The warning should also cater for conversion to double from __float128 (if __float128 is the nvtype). And won't that get a bit noisy ? (The warning would want to be silenceable.) Also note that, in the example I gave, "2.0" is the only value that involves conversion from long double to double - which is exact, and therefore would *not* warn. It's all a bit messy and I don't have any ideas that I regard as an improvement on your suggestion - though I'd probably be satisfied with a warning at the start of the build, another one explaining the failures of t/limit_trans_err.t (which is the only script that currently fails because of this), and just leave it at that. (If they miss the warnings they'll soon discover it for themselves, anyway :-) On second thoughts, it mightn't hurt to warn at the beginning of *every* test script. Something like: warn("\nYour NV is $Config{nvtype}, but PDL provides precision no greater than 'double'.\nPDL computations will therefore be accurate to (at most) double precision\n") if $Config{nvsize} > 8; > My current plan is to stabilize the PDL-2.x type support with working > 64bit indexing. > The current types support is a bit of bailing wire and twine. I think the > effort of further improvements would be better made on the new "PDL3" core > work. We have a number of missing features that are really needed for PDL > to be viable as a computational tool: > > * extended types support (at least all the standard elemental types in > C/C++ > * extendable type support > * support for pointers, objects, arrays of structs,... > * others I'm missing go here... > > All of this should be much easier to implement with a clean start at the > innermost levels. The hope is that we can implement in a way so that > existing PDL-2.x modules could switch to the new core and make use of the > capability transparently. Sounds very sane to me. Cheers, Chris ------------------------------------------------------------------------------ _______________________________________________ pdl-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-general
