flat assembler
Message board for the users of flat assembler.

flat assembler > Projects and Ideas > multiprecision calculator for win64

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
tthsqe



Joined: 20 May 2009
Posts: 716
features:
+ all of the stuff from the previous 32 bit version
+ number of unlimited size via N[-,digits] (GMP)
+ memoziation of functions for machine integers
+ flexible and unified input language
+ able to return multiple values
+ uses asymptotically fastest known algorithms for constants and inverse functions
+ better interface with special characters
+ limited array support
+ SSA-based optimizer


Description: 10-8-2013 update
Download
Filename: Calculator64v1.03.zip
Filesize: 664.88 KB
Downloaded: 405 Time(s)



Last edited by tthsqe on 10 Aug 2013, 15:21; edited 12 times in total
Post 07 Mar 2013, 04:41
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15904
Location: SDSS J140821.67+025733.2
It looks like your precision of PI is too low to support the 48 digit output.
Post 07 Mar 2013, 07:51
View user's profile Send private message Visit poster's website Reply with quote
MHajduk



Joined: 30 Mar 2006
Posts: 5976
Location: Poland
tthsqe, what does exactly mean "1.i" notation here? If i is the symbol of sqrt(-1) then "1.i" looks slightly bizarre here (the mix of real integer and imaginary unit as a matissa ?).

BTW, does your calculator support operations on the complex numbers?

[EDIT]Oh, I see. That's a typo, should be something like '1.0*i'.[/EDIT]
Post 07 Mar 2013, 08:19
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
revolution wrote:
It looks like your precision of PI is too low to support the 48 digit output.
it is indeed a SSE double precision. i think he means the bits for the mantissa... when for a 48 decimal digits output it needs room for more than 20 bytes float. if that is the goal, i would suggest to parametrize and virtualize the machine epsilon now and work on big numbers by design. in other cases, using Chebyshev is ok for at least 11 digits approximation on operations with functions.
last method is lookup tables. choosing the method is not trivial in all cases.

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 07 Mar 2013, 11:55
View user's profile Send private message Visit poster's website Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 716
Quote:
It looks like your precision of PI is too low to support the 48 digit output.

it calculates all of those digits - the window on the right is not intended to display all of them
Quote:
in other cases, using Chebyshev is ok for at least 11 digits approximation on operations with functions

not quite sure what this is referring to - the readme contains descriptions of the algorithms to compute stuff
Post 25 Mar 2013, 06:44
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2653
Location: dank orb
Awesome work.

N[Sqrt[2],69213] crashed in gmp.__gmp_doprnt_mpf2
N[Sqrt[2],69212] doesn't though. Very Happy

General limitation of N[] it seems, due to GMP.dll? Still reading the source.

Is there a way to copy the output window? Because this already does about 90% of what I've been using other calculators for. I'd like to generate some number and partition it into dq/dd/etc.. pieces for inclusion in code.

I'll try to break it some more...

[edit]Every win64 OS comes with the Cambia Math Font - which is quite nice.

My first example:
Code:
S[n]:=If[n==0,4,S[n-1]^2-2];
M[p]:=2^p-1;
v=7;N[S[v-2]/M[v],20]    

_________________
utf8everywhere.org
Post 25 Mar 2013, 12:16
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
good work Very Happy
i think GMP may be avoided in some way, because calculations are already done FPU on big numbers. the degree of a minimax polynomials is bound directly to the required accuracy of a function.
Chebyshev may be used in all cases of bare functions, except sqrt and arcsin. a general reference here
http://www.research.scea.com/gdc2003/fast-math-functions_p2.pdf
and the same as textual, browse down to "A Note On Convergence"
http://www.research.scea.com/research/pdfs/RGREENfastermath_GDC02.pdf

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 25 Mar 2013, 16:12
View user's profile Send private message Visit poster's website Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 716
Ok - I fixed the issue that bitrake found and some others.
What are some good formats for outputting the numbers in hex?
Post 25 Mar 2013, 17:10
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2653
Location: dank orb
FASM is very flexible, so if you output hex as 0xF... then it's also good for C/++. You probably don't want to include a whole string library to support general partitioning and concatenation.

p.s. I miss the delete key. Wink
Post 29 Jun 2013, 06:14
View user's profile Send private message Visit poster's website Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 716
So for hex string of integers, I think it is clear how it should be done:
Code:
HexString[-3^200]
dq 0xA40500E155074F5F, 0x7C1309091B5851DD, 0x028C2681BB89F949, 0x3DE56C85890CBCD0, 0xE02A79C3C14FB961    

The result is in 2-complement and Little endian form.

For hex strings of real numbers, I am thinking of just extending the 80-bit (http://en.wikipedia.org/wiki/Extended_precision) format by making a longer mantissa. So, the exponent and sign still has the same meaning, and the radix point is between the 62nd and 63rd bit of the most significant limb. The 63rd bit of the most significant limb should be 1. EX:
Code:
HexString[-p\^2]
dq 0x08566a3fe0d0a228, 0x56e26cd9808c1ac7, 0x9de9e64df22ef2d2, 3, -1    

would indicate that
Code:
-Pi^2 = - 2^4 * 0.9de9e64df22ef2d256e26cd9808c1ac708566a3fe0d0a228........    

Again, the exponent on the 2 is 4 because the implied radix point in the representation is on the rhs of the 63rd bit of the most sig limb. This kind of representation is nice when rolling your own multiprecision arithmetic functions on numbers of a fixed size.
Post 10 Jul 2013, 07:09
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2653
Location: dank orb
Had some confusion and a crash:
Code:
n=255;dn=90/n;a={0};
S[x]:=n*Sin[x];
dS[x]:=S[(x+1)*dn]-S[x*dn];
Do[a[[i]]=Floor[dS[i]],{i,0,n}]    
It doesn't crash when "a={}".

Not sure where the syntax error is?

Sin probably takes radians rather than degrees.
Post 15 Jul 2013, 01:21
View user's profile Send private message Visit poster's website Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 716
All that is behavior that I expected.
When you do a={}, that is invalid syntax because the List function has an arg count of zero.
When you do a={0}, you are only guaranteed that 32bytes(one entry) are allocated for a.
No bounds checking are done for statements such aa a[[i]]=x, so if n is high enough, you will get seg fault.
Code:
n=256; dn=90/(n); a = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; 
S[x]:=n*Sin[x];  
dS[x]:=S[(x+1)*dn]-S[x*dn]; 
Do[a[[i]]=Floor[dS[i]],{i,0,n-1}]; 
a

{88,77,57,29,-2,-32,-59,-79,-89,-88,-77,-56,-28,3,33,60,79,88,87,75,53,26,-6,-36,-62,-81,-90,-87,-75,-53,-25,7,37,63,81,89,86,73,50,22,-10,-40,-65,-82,-90,-86,-72,-50,-21,11,40,65,82,89,85,70,47,18,-14,-43,-68,-84,-90,-85,-70,-46,-17,15,44,68,84,89,83,68,43,14,-17,-47,-70,-85,-90,-84,-67,-43,-13,18,47,71,85,89,82,65,40,10,-21,-50,-73,-87,-90,-82,-64,-39,-9,22,51,73,86,89,80,62,36,6,-25,-53,-75,-88,-89,-80,-62,-35,-5,26,54,75,87,88,78,59,32,2,-29,-57,-77,-88,-89,-79,-59,-32,-1,30,57,77,88,88,77,56,29,-2,-33,-60,-79,-89,-88,-76,-56,-28,3,34,60,79,88,87,74,53,25,-6,-37,-63,-81,-90,-87,-74,-52,-24,7,37,63,81,89,86,72,50,21,-10,-40,-65,-83,-90,-86,-72,-49,-20,11,41,66,82,89,85,70,46,17,-14,-44,-68,-84,-90,-85,-69,-46,-16,15,45,68,84,89,83,67,43,13,-18,-47,-71,-86,-90,-83,-67,-42,-12,19,48,71,85,89,82,64,39,9,-22,-51,-73,-87,-90,-82,-64,-38,-8,23,51,73,86,89,80,62,36,5,-26}    

With the source I just posted (slight type in previous), the above does what you want, but there are some obvious problems. There are two possibilities:
1. I could implement a CreateArray function which allocates space for an array of specified size
2. I could implement the missing Table operator
In either case the proposed code would be
1.
Code:
n=255; dn=90/n; a = CreateArray[n];
S[x]:=n*Sin[x]; 
dS[x]:=S[(x+1)*dn]-S[x*dn];
Do[a[[i]]=Floor[dS[i]],{i,0,n-1}];
a    

2.
Code:
n=255; dn=90/n;
S[x]:=n*Sin[x]; 
dS[x]:=S[(x+1)*dn]-S[x*dn];
a = Table[Floor[dS[i]],{i,0,n-1}]    

Which is better? They are both quite doable... maybe both?
And yes, I do not use degrees.
Post 15 Jul 2013, 02:17
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2653
Location: dank orb
That makes sense, no dynamic array. Although the routine you posted also crashes. Think I found the error (Evaluator.inc, line 132):
Code:
        .ARRAY:       movzx  edx,word[rbx+12]
                        xor  ecx,ecx
                        shl  edx,5
                        mov  r8d,MEM_COMMIT
                        mov  r9d,PAGE_READWRITE
                       call  [VirtualAlloc]
                        mov  rdi,rax
                        mov  rsi,qword[rbx+0]
                  my_pinsrq  xmm6,rax,0,xmm0
                        mov  ecx,[rbx+8]
                        shl  ecx,4
                  rep movsq
                        jmp  .ret    
The word at offset [rbx+8]=[rbx+C]=$100. Only 32 bytes are being allocated for each item, whereas 128 bytes are being copied.

*Looks like I might have had an older version of the code.

_________________
utf8everywhere.org
Post 15 Jul 2013, 03:44
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2653
Location: dank orb
Okay, so I tried another method (weird character is Pi):
Code:
n=255; dn=90/(n);
S[x]:=Floor[n*Sin[x * ยง/180]];
dS[x]:=S[(x+1)*dn]-S[x*dn];

a=0;i=0;
While[j=dS[i],
  If[j==2,a=a+Power[2,i]];
  i=i+1
];
b=i;
While[i<256,
  If[dS[i]==1,a=a+Power[2,i]];
  i=i+1
];
HexString[a]    
Which crashes in Convert_B_REAL_to_M_FP, _mp_d is $4'0000'0005 causing the read to be invalid.

The first loop does execute, but not the second.

_________________
utf8everywhere.org
Post 15 Jul 2013, 05:33
View user's profile Send private message Visit poster's website Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 716
Man, i guess you should not be very confident in the bug-freenes of the program Laughing
I'll have a look at that and see what the issue is.
I don't think that
Code:
While[j=dS[i], 
  If[j==2,a=a+Power[2,i]]; 
  i=i+1 
];    

is doing what you want. Nor do I know what you are trying to do. It is just like Mathematica - the first argument of While should return a boole, and yours is calculating dS[i], saving dS[i] to j, then returning the value of dS[i].
It is true that I mapped booles onto machine integers (true -> -1, false->0), but While expects that its first argument, say x, is a machine integer, and says that x is true depending on whether the lowest byte of x is nonzero or not.

PS: dynamic array allocation and the Table function are almost ready, if this is what you are trying to replicate...

So I ran
Code:
n = 255; dn = 90/(n);
S[x_] := Floor[n*Sin[x*Pi/180]];
dS[x_] := S[(x + 1)*dn] - S[x*dn];

a = 0; i = 0;
While[BitAnd[j = dS[i], 255] =!= 0,
  If[j == 2, a = a + Power[2, i]];
  i = i + 1];
b = i;
While[i < 256, If[dS[i] == 1, a = a + Power[2, i]];
  i = i + 1];
IntegerString[a, 16]    

in mathematica and the result was
Code:
40010444494a95aadb6dddf7e00000020208444492494a552aaaaaab556ad5aa    

is this your intended number?
Post 15 Jul 2013, 08:19
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2653
Location: dank orb
DOS386, posted a link for a sine table generator. Since sine is an increasing function on [0-90] degrees, a sub-table of 256 bits are generated which indicate if 0,1, or 2 should be added to get the next table value. I wanted to reproduce that sub-table of bits. We need to know when the first repeat entry (zero delta) happens to have the code switch from adding 1,2 to adding 0,1.

So, the first loop stops when dS[i]==0 and does appear to do that, although the value of (i) is 156, and should be 209, iirc. I've changed the While function to j !=\ 0, and it seems to perform the same. dS[i] only returns 0,1,2.

The second loop doesn't work, and I'm still debugging. My confidence only waned slightly, as I'm still learning what's what.

The table equates to (in hex):
55ab56aad5555554aa5292492222104040000007efbbb6db55a9529222208003
...but there is an extra set bit at the top. Actually, 156 is correct for the first loop as there are 100 bits set - for a total of 256.

_________________
utf8everywhere.org


Last edited by bitRAKE on 15 Jul 2013, 09:09; edited 2 times in total
Post 15 Jul 2013, 08:54
View user's profile Send private message Visit poster's website Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 716
Ok, so if the argument of the first while is (j = dS[i]) != 0, the calculator and mathematica both terminate with
a=683266112844956550622064541659919209898
i=156
so I think 156 is correct.
It's really strange - the second While should not even be doing such a conversion.
Post 15 Jul 2013, 09:04
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2653
Location: dank orb
tthsqe wrote:
in mathematica and the result was
Code:
40010444494a95aadb6dddf7e00000020208444492494a552aaaaaab556ad5aa    
is this your intended number?
Once I reversed the bits, my macro takes them in other order, that is indeed the number. So, the first loop checks out completely, correct values for (a) and (b).

_________________
utf8everywhere.org
Post 15 Jul 2013, 09:13
View user's profile Send private message Visit poster's website Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 716
Ok, since the mistake was trivial I'll just have you correct it in your source, since mine is currently busy.
line 83 or so of printer.inc should read
Code:
Print_B_INT:           test  ecx,ecx
                         jz  .float
                       push  rbp
                        mov  rbp,rsp
                        and  rsp,-16
                     invoke  gmp_sprintf,rdi,'%Zd',rsi
                        add  rdi,rax
                        mov  rsp,rbp
                        pop  rbp
                        ret
       .float:          mov  rax,'Big Int '
                      stosq
                        mov  rcx,rsi
                       call  Convert_B_INT_to_M_FP      ; not B_REAL_to_M_FP
                       fstp  st1
                       call  PrintFloat
                        ret             


Nevermind this: the newer posted version has this corrected
Post 15 Jul 2013, 09:46
View user's profile Send private message Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 716
bitrake, I have seen you with an integer square root algorithm before, Could you post it here? It should work as follows:
input: positive integer x (3 qword limbs)
return: s = Floor[Sqrt[x]] and r = x-s^2
Actually, if r is not zero, I do not need r nor do I need s.
Post 09 Aug 2013, 10:16
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.