News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Arbitrary Precision with MPFR

Started by aw27, August 02, 2017, 01:47:38 AM

Previous topic - Next topic

aw27

The MPFR library is a C library for multiple-precision floating-point computations with correct rounding. MPFR.
It is  very easy    :dazzled:  to convert the headers for use with ASM. I did the conversion for the examples I assembled.



The examples were assembled with the static LIBs. More details in the attachment.

Updated 3rdAugust:
Fixed bug and refactored (see message #5).

raymond

Really curious. What would have been the timing to compute (and display) each of the three examples you posted????
Whenever you assume something, you risk being wrong half the time.
https://masm32.com/masmcode/rayfil/index.html

aw27

Quote from: raymond on August 03, 2017, 04:18:05 AM
Really curious. What would have been the timing to compute (and display) each of the three examples you posted????

Hello Raymond,
A few milliseconds. You can also run the .exe and confirm.

raymond

The exe. displayed the first two values quite rapidly but crashed before printing the pi^1000 value.  :icon_eek: :icon_confused:
Whenever you assume something, you risk being wrong half the time.
https://masm32.com/masmcode/rayfil/index.html

aw27

Quote from: raymond on August 03, 2017, 05:03:55 AM
The exe. displayed the first two values quite rapidly but crashed before printing the pi^1000 value.  :icon_eek: :icon_confused:

it happens occasionally, i will have a look tomorrow.

aw27

Quote from: aw27 on August 02, 2017, 01:47:38 AM
The MPFR library is a C library for multiple-precision floating-point computations with correct rounding. MPFR.
It is  very easy    :dazzled:  to convert the headers for use with ASM. I did the conversion for the examples I assembled.



The examples were assembled with the static LIBs. More details in the attachment.


Updated 3rdAugust:
Fixed bug and refactored.

Tested also the computation of PI with 100,000 decimals, which took less than 2 seconds. The value obtained agrees with published value on the internet, except the last 2 digits. But I believe MPFR is correct because when calculating with more decimals MPFR keeps the same digits.

hutch--

What would happen if you made the results 2 or more values longer then truncated it to the preferred length ?

aw27

Quote from: hutch-- on August 03, 2017, 03:19:47 PM
What would happen if you made the results 2 or more values longer then truncated it to the preferred length ?

Hi Hutch!

I am far from an expert in MPFR, my understanding is that:
MPFR provides Precision guarantee but can not provide Accuracy guarantee.
Accuracy depends on a good algorithm and a good algorithm always converges to the exact solution.
In the case of PI and other internal constants it can calculate on demand, MPFR uses carefully selected  algorithms.
So, the result presented is very likely Accurate for the requested Precision.  :idea:


aw27

Adding this to the demo to print Sinus (3 radians) with over 1000 correct decimals:


sin3 proc
LOCAl temp:mpfr_t
LOCAL sin : mpfr_t

INVOKE mpfr_init2, addr temp, 3321 ; precision is the number of bits required for the mantissa
INVOKE  mpfr_init2, addr sin, 3321
INVOKE mpfr_set_d, addr temp, 3.0, MPFR_RNDD
INVOKE mpfr_sin, addr sin, addr temp, MPFR_RNDD
INVOKE mpfr_out_str, stdout, 10, 0, addr sin, MPFR_RNDD
INVOKE mpfr_clear, addr temp
INVOKE mpfr_clear, addr sin
ret
sin3 endp


Result is much more accurate than Wolfram and thousands of times faster:

1.41120008059867222100744802808110279846933264252265584151882641232422009967014471911282172853449863750413672948267327416844457031668857573754033
6578549112178117854768348207821667641372155666588646898440315383301251527835907652235044419509448898339255456222416038362418293954425917441036645
7405665411545993098230085116590155481231031583793547592135167007015594919392616345818890677219844117206290487343422419576073412055998255165452357
1181141157051291632363677805391569780117869106825084336169124441480909264583362905393835462108457470290217543588672312529211634350700961692923958
6145331225375554941402040165404357932054456319714946223945359863000276624402822710733322778095501745939557122297837990906606806047234413166348807
2380848409952351317791104969019896090661636052901473458475801562578834422352600035898237549697414268135133547407596174355974403786377257820881701
241668793413754081821157597324836794512404522587303964830620759438578135627057794071783223003917052243003339995311417988653251409001e-1

:badgrin:


felipe

Quote from: aw27 on August 03, 2017, 10:01:42 PM
1.41120008059867222100744802808110279846933264252265584151882641232422009967014471911282172853449863750413672948267327416844457031668857573754033
6578549112178117854768348207821667641372155666588646898440315383301251527835907652235044419509448898339255456222416038362418293954425917441036645
7405665411545993098230085116590155481231031583793547592135167007015594919392616345818890677219844117206290487343422419576073412055998255165452357
1181141157051291632363677805391569780117869106825084336169124441480909264583362905393835462108457470290217543588672312529211634350700961692923958
6145331225375554941402040165404357932054456319714946223945359863000276624402822710733322778095501745939557122297837990906606806047234413166348807
2380848409952351317791104969019896090661636052901473458475801562578834422352600035898237549697414268135133547407596174355974403786377257820881701
241668793413754081821157597324836794512404522587303964830620759438578135627057794071783223003917052243003339995311417988653251409001e-1


Wow! But who really can use such big numbers?   :dazzled: I guess doing computations between this kind of numbers would make some differences in the final result, that they (people who use this numbers), would finally truncate to less decimal digits. Maybe in astronomy?  :shock:

aw27

Quote from: felipe on August 03, 2017, 11:06:36 PM
[Wow! But who really can use such big numbers?   :dazzled: I guess doing computations between this kind of numbers would make some differences in the final result, that they (people who use this numbers), would finally truncate to less decimal digits. Maybe in astronomy?  :shock:

In their website they give you an idea who uses this library for what. A large number of free software  titles and a large number of mathematicians doing their PHDs are likely to be the main targets.

All people that develop GNUs, FSF and the likes softwares tend to suck a bit (in my opinion, of course), so I am not endorsing MPFR in any way.  :badgrin:

LiaoMi

Hi,

library for windows is only suitable for 32 bit? 64 bit version should be faster ..

QuoteChanges from version 3.1.4 to version 3.1.5

C++11 compatibility.
Bug fixes (detailed list on the MPFR 3.1.4 page and ChangeLog file).
More tests.
Platforms Known to Support MPFR

MPFR 3.1.5 has been successfully compiled and checked on the following platforms:

armv5tejl-unknown-linux-gnueabi (ARM926EJ-S rev 5, gcc 4.4.5, under qemu),
i386-pc-solaris2.10 (Sun C 5.9 SunOS_i386 Patch 124868-10 2009/04/30),
i586-mingw32msvc (Wine, gcc 6.1.1),
mips64el-unknown-linux-gnu (n32 ABI, gcc 4.9.2),
powerpc64-unknown-linux-gnu (POWER7, gcc 4.8.3),
sparc64-unknown-linux-gnu (gcc 6.4.0),
x86_64-pc-linux-gnu (gcc 4.7.4, 4.8.5, 4.9.4, 5.4.1, 6.2.0 and 7.0.0 snapshot, g++ 4.9.4 and 6.2.0, clang 3.4.2, 3.5.2, 3.6.2, 3.7.1 and 3.8.1, icc 15.0.0, and tcc 0.9.26),
x86_64-unknown-netbsd5.1 (NetBSD 5.1, gcc 4.1.3).

aw27

Hi LiaoMi,

The libraries and dlls for Windows x64 are provided as well. x64 is indeed much faster. Last version I compiled is 3.1.2.

When my Zen allows it, I will try to compile for 3.1.5 but I don't see important differences since 3.1.2.
As usual in the GNU world , it is not straightforward to compile for Windows, it is always straightforward to compile for some crap OS nobody uses.


hutch--

 :biggrin:

> it is always straightforward to compile for some crap OS nobody uses.  :P

aw27

Attached is the 64-bit counterpart  :t