Re: Decimal Floating Point (DFP) and does Perl needs DFP?

It always brings a smile

It makes me smile, too - and I smile again at the responses that suggest "this is the way it has to be and you just have to live with it".
It's crazy - for years we've been putting up with using base2 approximations of the actual (decimal) values that we're interested in.

Jarrko Hietaniemi has added an option (current blead) that allows perl to be built with an nvtype of __float128.
And this capability will be available in perl-5.22 for any system/compilers that support the (quad) __float128 type - which includes most Linux and windows systems. (It utilises libquadmath.)

Update: Ooops ... libquadmath is available for windows (and the potential exists), but setting nvtype to __float128 is currently done via the configure script, which therefore excludes Windows (as Windows don't run no configure script).

Further, Jarrko did consider enabling perl to be built with NV type of _Decimal64 or _Decimal128. He didn't think about it for very long before deciding it was a crazy idea ... but he did at least ask himself the question.
I don't know his reasons for deeming it crazy, but my reason for deeming it crazy is that gcc's implementation of decimal math is quite lacking in terms of providing the usual math library functions.
AFAIK, all that's provided by gcc are the basic arithmetic functions (add, subtract, multiply, divide). Therefore if this type were to be the NV, then perl would have to provide sqrt, pow, log, exp, and trig functions for it.
Furthermore, gcc provides no strtod64 or strtod128 function, and nor does it provide (s)printf formatting of those types ... more work to be done by perl in assigning/printing.

I think the IBM compiler provides all of those things that are missing in gcc - and if gcc ever catches up, then I'd be pushing for perl to have the capability of setting its NV to one of these decimal data types.

Hopefully, gcc's coverage will eventually improve but, wrt fp arithmetic, most of us are currently stuck with using base2 approximations (for anything other than the basic arithmetic operations).

Has anyone done any work in this area specific to Perl?

I have written Math::Decimal64 and Math::Decimal128 which wrap the _Decimal64 and _Decimal128 math operations.
Have a play with them if you're interested.
They match gcc's coverage - ie no sqrt, pow, log, exp, trig functions and, given the absence of strtod64(), strtod128() and sprint formatters, the input/output functions are a bit kludgy.
(And now I've *exceeded* this month's quota of self-promotion.)

Cheers,
Rob

Update: Math::Decimal should probably be mentioned here - though it performs its decimal operations via strings, not via decimal floating point data types.

Comment on Re: Decimal Floating Point (DFP) and does Perl needs DFP?

Replies are listed 'Best First'.
Re^2: Decimal Floating Point (DFP) and does Perl needs DFP? by flexvault (Monsignor) on Jan 17, 2015 at 02:31 UTC
Hello syphilis, Now, your answer is what I was looking for! This isn't about finding fault with the current Perl implementation, but about the possibility of improving the future of Perl5. Were you able to view the referenced article? If not, I'll try to get a pdf of the article for you. IBM added 54 DFP instructions and the XLC compiler uses them. I haven't looked at 'C' code in more than 20 years, but the idea of getting 34 digits of decimal accuracy when using Perl is down right 'sexy'. What was interesting in the wiki article was that the hardware was 76 times faster than the software for the demo. The wiki is from power6, and power7 was twice the speed of power6, and power8 is more than 3 times the performance of power7. But what is also interesting is that the software implementation is supported by Linux. So if some OpenPower hardware company developed a DFP plug-in, then Perl could have hardware Decimal Floating Point in the future on less expensive hardware. Developers could use the software versions for design/development/testing, and then production could use the hardware. You gave me a lot to look into, so thanks for your work on this subject. Regards...Ed "Well done is better than well said." - Benjamin Franklin	[reply]
Re^3: Decimal Floating Point (DFP) and does Perl needs DFP? by syphilis (Archbishop) on Jan 17, 2015 at 03:38 UTC
Were you able to view the referenced article? Yes, but the only IBM (I think) processor that I have is a ppc64 on an old mac box - now running Debian Wheezy with gcc-4.6.3. I think that pre-dates the hardware improvements that you're talking about. Certainly, the _Decimal64/128 operations on that box are generally slower than on my (newer) Intel (Windows) and AMD (Ubuntu) boxes. My ppc64 processor does, however, utilise IBM's favoured "Densely Packed Decimal" format instead of Intel's/AMD's preferred "Binary Integer Decimal" format. DPD format is really nice - I can encode/decode that fairly quickly using a hash lookup, whereas BID format necessitates that the value be calculated. I assume that each of my processors has some special capacity to handle DFP operations, and that gcc is making use of that capability - but there's no guarantee that either of those assumptions is correct. the idea of getting 34 digits of decimal accuracy when using Perl is down right 'sexy' I agree, and Math::Decimal128 will give you that - but only for the basic arithmetic operations at the moment. Perl will improve markedly when someone gets around to (optionally) providing DFP processing built into perl. (But I think the time for that is not yet quite right.) You've actually now got me wishing I had a power8 box to play with. Which OS should it run to best test/experience these IBM capabilities ? ... AIX ? Is power8 bigendian ? Cheers, Rob	[reply]
Re^4: Decimal Floating Point (DFP) and does Perl needs DFP? by flexvault (Monsignor) on Jan 17, 2015 at 13:49 UTC
Hello syphilis, ...slower than on my (newer) Intel (Windows) and AMD (Ubuntu) boxes... While searching the IBM site, I found a Redbook that describes the use of the DFP hardware and software. It stated that 3 Linux distributions ( Redhat, SUSE, and Ubuntu ) support the hardware and software DFP. It had a link to download the software, which if the hardware is present, will use the hardware, otherwise is does the calculation(s) in software. So it may be available for your Ubuntu system??? The Redbook stated that the software was designed to co-exist with binary floating point. Which OS should it run to best test/experience these IBM capabilities ? ... AIX ? Is power8 bigendian ? I honestly don't know enough now to give a good answer about which OS, but I'll be looking into the subject and hope to know more soon. The announcement letter for power8 says hardware supports both bigendian and littleendian. How, I don't know yet! The newest RS\6000 (p-series) that I have is power5 (bigendian), so I can't use any of the new features. Just so you know, Google, Hitachi and several other companies are coming out with non-IBM power8 computers during 2015. While IBM's entry level systems are around $10K, the non-IBM versions are projected to be less than $3K. Hopefully Google will want to dominate the market and build an entry level around the price point of Intel/AMD PCs. But that's just a wish! I don't have much time until March, but I am interested in furthering this capability for Perl, so lets keep in touch. Best Regards...Ed "Well done is better than well said." - Benjamin Franklin	[reply]
Re^4: Decimal Floating Point (DFP) and does Perl needs DFP? by flexvault (Monsignor) on Jan 17, 2015 at 19:48 UTC
Hello syphilis, Just a quick update. I went to this site and downloaded the code and successfully compiled using 'make -f Makefile.Linux' on a AMD server running Debian with gcc 4.4.5. It seems to contain the missing functions that you mentioned. I ran the sample, and it seems to work????? `~/dfpal# ./dfpsample 1.000001 60000 Version of DFPAL: 2.20 DFPAL is operating in software value of n4 = 9.000000000000000E+384 9E+384 * 9E+384 = Infinity 9E+384 * 9E+384 => Overflow DFPAL_TRP_INVALID is enabled! DFPAL_TRP_OVERFLOW is not enabled! DFPAL_TRP_INVALID is enabled! sign of n1 0 Zero value = 0 n1 is less than n2 n1 - n2 = -59998.999999 N1 - N2 = -59998.999999 original decimal64 n1=1.000001 minus n1 = -1.000001 It is still Overflow Now, it is not Overflow ~/dfpal#` [download] Don't know what the sample is supposed to do, so your knowledge of the subject would be greatly appreciated to show some light. At least it's a start! Regards...Ed "Well done is better than well said." - Benjamin Franklin	[reply] [d/l]
Re^5: Decimal Floating Point (DFP) and does Perl needs DFP? by syphilis (Archbishop) on Jan 18, 2015 at 01:56 UTC


Your skill will accomplish what the force of many cannot
	PerlMonks