On Fri, Oct 2, 2015 at 9:06 AM, <[email protected]> wrote: > > -----Original Message----- > From: kmx > Sent: Friday, October 02, 2015 6:33 PM > To: [email protected] > Subject: Re: [Pdl-general] CHM/PDL-2.013_01.tar.gz uploaded to CPAN > ...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). > > > 2/ implement PDL_LD support (perhaps not in 2.014) > > We should also start thinking about PDL_FLT128 support as it's now (ie as > of > perl-5.22.0) possible to build a perl whose nvtype is __float128 - so long > as libquadmath is available. > In fact, doing so on linux (and presumably many other nix-type systems) is > quite trivial. It's just a matter of passing -Dusequadmath to Configure. > (On > Ubuntu my builds of perl are now always "-Dusequadmath".) > MinGW ports of gcc provide libquadmath, so it should be equally trivial to > build such perls on Windows once someone finds the tuits to insert that > capability into the perl source. > 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. > I must confess that I often wonder about the importance of "long double" > builds - if 53 bits of precision aren't enough for you, then it's likely > that 64 bits will also be insufficient. > But 113 bits .... well .... now you might be getting somewhere !! > I guess I forgot arbitrary precision numbers, rational numbers, L x $n doubles... Cheers, Chris
------------------------------------------------------------------------------
_______________________________________________ pdl-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-general
