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.
(http://www.atelierweb.com/a/mpfr.png)
The examples were assembled with the static LIBs. More details in the attachment.
Updated 3rdAugust:
Fixed bug and refactored (see message #5).
Really curious. What would have been the timing to compute (and display) each of the three examples you posted????
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.
The exe. displayed the first two values quite rapidly but crashed before printing the pi^1000 value. :icon_eek: :icon_confused:
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.
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.
(http://www.atelierweb.com/a/mpfr.png)
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.
What would happen if you made the results 2 or more values longer then truncated it to the preferred length ?
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:
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:
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:
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:
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).
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.
:biggrin:
> it is always straightforward to compile for some crap OS nobody uses. :P
Attached is the 64-bit counterpart :t
I have updated the LIBs to MPFR 3.1.5 (it took a few hours :(, believe it or not).
And updated the ASM examples for both static and dynamic linking (dynamic has not been done before) and for x86 and x64.
Unfortunately, I can not include the LIBS and DLLs in the attachment because there is a limit of 512KB, so you will have to download them from the URL supplied in the source inside the attachment.
That is nice work, well presented :t
Thank you for demonstrating the ability of UASM 8)
you could have used instead of:
mov ebx, 1
.while ebx<=100
INVOKE mpfr_mul_ui, addr t, addr t, ebx, MPFR_RNDU
INVOKE mpfr_set_d, addr u, REAL8ONE, MPFR_RNDD
INVOKE mpfr_div, addr u, addr u, addr t, MPFR_RNDD
INVOKE mpfr_add, addr s, addr s, addr u, MPFR_RNDD
inc ebx
.endw
this:
.for (ebx=1:ebx<=100:ebx++)
INVOKE mpfr_mul_ui, addr t, addr t, ebx, MPFR_RNDU
INVOKE mpfr_set_d, addr u, REAL8ONE, MPFR_RNDD
INVOKE mpfr_div, addr u, addr u, addr t, MPFR_RNDD
INVOKE mpfr_add, addr s, addr s, addr u, MPFR_RNDD
.endfor
I am here not trying to be smart ass but showing ability of UASM :icon_cool:
There is nothing wrong with your choice :biggrin:
Quote
.for (ebx=1:ebx<=100:ebx++)
Nice suggestion habran. :t
Quote
Topic moved: Arbitrary Precision with MPFR
I agree, all source code that does not assemble directly with the amazing Microsoft Macro Assemblers must be dispatched to specialized subforums. :eusa_clap:
Its done for a sensible reason, the code you posted will not build with any version of MASM so I moved it to where it is properly supported with an assembler that will build it.
Quote from: hutch-- on August 09, 2017, 01:23:56 AM
Its done for a sensible reason, the code you posted will not build with any version of MASM so I moved it to where it is properly supported with an assembler that will build it.
Reasonable decision. Fortunately, MasmBasic builds with Masm :P
Jokes apart,
for builds fine but:
for_s:
.for (ebx=1:ebx<=100:ebx++)
nop
.endfor
for_endp:
while_s:
mov ebx, 1
.While ebx<=100
nop
inc ebx
.Endw
while_endp:
whileOpt_s:
xor ebx, ebx
.While ebx<=100
inc ebx
nop
.Endw
whileOpt_endp:
repeat_s:
xor ebx, ebx
.Repeat
nop
inc ebx
.Until ebx>100
repeat_endp:14 bytes for for
14 bytes for while
11 bytes for whileOpt
9 bytes for repeat
Quote from: jj2007 on August 09, 2017, 01:31:23 AM
Reasonable decision. Fortunately, MasmBasic builds with Masm :P
MASM, or any assembler for the case, can deal with undocumented libraries written in any language. This does not mean that the whole has anything to do with Assembly Language.
I don't know how many people you have convinced it has, after all these years. :badgrin: