1. bignum progress report
bignum7.e
num1= 555555.55555
num2= 11
significant digit limit= 100
num1 / num2 =
50505.0505045454545454545454545454545454545454545454545454545454
545454545454545454545454545454545454
Time= 113 seconds / 100 iterations
--------------------
Still needs speeding up, and a few more numbers to test. Any requests?
Kat
2. Re: bignum progress report
I recently came across this big number. (Hope translated it correctly)
power((((power((27+power(69,1/3))/2,1/3))/3) +
(power((2/(27+power(69,1/3)))),1/3)) , 30000)
Its almost an integer. After the decimal point, a few hundred zeros appear
before the first non-zero.
----------------
cheers,
Derek Parnell
----- Original Message -----
From: "Kat" <kat at kogeijin.com>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, October 25, 2002 6:24 AM
Subject: bignum progress report
>
> bignum7.e
>
> num1= 555555.55555
> num2= 11
> significant digit limit= 100
>
> num1 / num2 =
> 50505.0505045454545454545454545454545454545454545454545454545454
> 545454545454545454545454545454545454
> Time= 113 seconds / 100 iterations
> --------------------
>
> Still needs speeding up, and a few more numbers to test. Any requests?
>
> Kat
>
>
>
>
3. Re: bignum progress report
On 25 Oct 2002, at 7:44, Derek Parnell wrote:
>
> I recently came across this big number. (Hope translated it correctly)
>
> power((((power((27+power(69,1/3))/2,1/3))/3) +
> (power((2/(27+power(69,1/3)))),1/3)) , 30000)
Ack!!! <swoon> That's one for Luscous, i am doing the 4 basic "flat" math
functions, no exponents. We might combine our two libs. Chances are, no
one will need trig functions to this degree of accuracy, right? (i know, famous
last words)
> Its almost an integer. After the decimal point, a few hundred zeros appear
> before the first non-zero.
It's those few hundred zeros that might crash the built-in Eu functions, like
value(). I think my tests now protect against that, but if i can't get around
it,
there will be (unlikely) cases where i'll haveto generate a failure msg, which
the including program will haveto check for.
I don't have any built-in limits to the count of digits in the numerals, except
for using integers to count the digits. So the number of digits in the numeral
is limited by the Eu integer type to 1,073,741,823 characters. I haven't done
any bounds checking for that yet, but maybe i should... And more rigourous
bounds checking value(), and maybe sprintf("%d",) , etc... minding what
Andy said, of course. I am trying to not overdo bounds tests, but it trades off
in other areas.
Kat
> ----------------
> cheers,
> Derek Parnell
> ----- Original Message -----
> From: "Kat" <kat at kogeijin.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Friday, October 25, 2002 6:24 AM
> Subject: bignum progress report
>
>
> > bignum7.e
> >
> > num1= 555555.55555
> > num2= 11
> > significant digit limit= 100
> >
> > num1 / num2 =
> > 50505.0505045454545454545454545454545454545454545454545454545454
> > 545454545454545454545454545454545454
> > Time= 113 seconds / 100 iterations
> > --------------------
> >
> > Still needs speeding up, and a few more numbers to test. Any requests?
> >
> > Kat
> >
> >
>
>
>
4. Re: bignum progress report
Hi the list!
Kat, could you tell us how the long string of 0's can happen?
To put it frankly, I think that continued fractions are good for any
precision arithmetic, and Euphoria could be a good language to handle
them. Yes, transcendant functions (log, sin,...) are harder to code, but
you are much more secure about the precision of the result than with
ordibary multiplication, if only because you can directly control it.
And it is not that slower, also
I had coded routines in 16-bit assembler for big numbers long ago (I
still think asm is best for really serious number crunching); I'd need
to rewrite everything to take advantage of MMX2 and Pentium
optimizations. Why not use some sort of cube algorithm on continued
fractions?
Regards.
Chris
5. Re: bignum progress report
On 28 Oct 2002, at 16:35, Christian.CUVIER at agriculture.gouv.fr wrote:
>
>
> Hi the list!
>
> Kat, could you tell us how the long string of 0's can happen?
String of zeros where? The digits in the string math are counted with
integers, so you can have 1,073,741,823 digits in your number. Note you will
need 8megabytes to email that size number, or 32megabytes to store it in
memory in Euphoria. There are strip functions built in, to strip leading and
trailing zeros. Also, all results and intermediate calulations must fit into a
numeral 1,073,741,823 digits long. I hope that is accurate enough for most
applications.
> To put it frankly, I think that continued fractions are good for any
> precision arithmetic, and Euphoria could be a good language to handle
> them. Yes, transcendant functions (log, sin,...) are harder to code, but
> you are much more secure about the precision of the result than with
> ordibary multiplication, if only because you can directly control it.
> And it is not that slower, also
> I had coded routines in 16-bit assembler for big numbers long ago (I
> still think asm is best for really serious number crunching); I'd need
> to rewrite everything to take advantage of MMX2 and Pentium
> optimizations.
Assy code would be much faster.
> Why not use some sort of cube algorithm on continued
> fractions?
Hmm?
Kat,
not a mathematician
6. Re: bignum progress report
Well, there are whole textbooks on the topic of continued fractions, so
I won't sum them up here :). Just an intuitive sketch:
A real number x is unambiguously defined by an integer (floor(x) --
call it x_0) and a real number in [0,1[. The latter is the inverse of
some real number above 1, which can be applied the transformation above.
You recursively end up with a sequence of integers that converge towards
x rather fast:
x=x_0+1/(x_1+1/(x_2+1/....)...)
Here, all x_i are positive integers, except for x_0, which can be any
integer. In real life, the x_i fit into one byte, so Eu could be the
right language to handle these objects - exceot for the wish list ;)
These are standard continued fractions. If you somehow relax the
constraints (all numerators are 1 and all x_i integers), you get
extended continued fractions, with much greater flexibility, very handy
to compute transcendant functions, but convergence properties will vary.
You'll find quite a few Fortran libraries that rely on this on the Web.
As for the cube algorithm, it's a 20-year old clever trick by Gosper
and al.; it can handle all elementaty arithmetic on continued fractions,
and more. You can find a good description of how it is implemented, as
well as other useful tips and tricks, at
http://www.pipeline.com/~hbaker1/hakmem/cf.html
Actually, this comes from a very old AI memo. Can't remember the
original text-mode address of this, and looks as I lost the .url.
Regards
CChris
>
> Date: Mon, 28 Oct 2002 13:25:15 -0600
> From: Kat <kat at kogeijin.com>
> Subject: Re: bignum progress report
>
>
> On 28 Oct 2002, at 16:35, Christian.CUVIER at agriculture.gouv.fr wrote:
>
> >
> > Hi the list!
> >
> > Kat, could you tell us how the long string of 0's can happen?
>
> String of zeros where? The digits in the string math are counted with
> integers, so you can have 1,073,741,823 digits in your number. Note you will
> need 8megabytes to email that size number, or 32megabytes to store it in
> memory in Euphoria. There are strip functions built in, to strip leading and
> trailing zeros. Also, all results and intermediate calulations must fit into a
>
> numeral 1,073,741,823 digits long. I hope that is accurate enough for most
> applications.
>
> > To put it frankly, I think that continued fractions are good for any
> > precision arithmetic, and Euphoria could be a good language to handle
> > them. Yes, transcendant functions (log, sin,...) are harder to code, but
> > you are much more secure about the precision of the result than with
> > ordibary multiplication, if only because you can directly control it.
> > And it is not that slower, also
> > I had coded routines in 16-bit assembler for big numbers long ago (I
> > still think asm is best for really serious number crunching); I'd need
> > to rewrite everything to take advantage of MMX2 and Pentium
> > optimizations.
>
> Assy code would be much faster.
>
> > Why not use some sort of cube algorithm on continued
> > fractions?
>
> Hmm?
>
> Kat,
> not a mathematician
>
>
7. Re: bignum progress report
Yes, I know, but I'm not sure how the 16-bit thing will be handled by
Linux/Win32. It was reasonably optimized for my 386/33 (I didn't releae
this at the time), probably not adequate now. Further, it extensively
uses direct stack manipulation; I wouldn't try this in ring 3 app's...
How can I get an address for an Euphoria variable inside an ASM routine
I call()? Ok, I know, I can first poke() whatever data I need and call()
the code following this data. Isn't there a better way?
Have a nice day!
CChris
>
> Date: Tue, 29 Oct 2002 02:09:26 +0000
> From: Bernie Ryan <xotron at bluefrognet.net>
> Subject: RE: bignum progress report
>
>
> Christian.CUVIER at agriculture.gouv.fr wrote:
> >
> > Hi the list!
> > I had coded routines in 16-bit assembler for big numbers long ago (I
> > still think asm is best for really serious number crunching);
>
> Chris:
>
> Why don't you dig it out and use it in Euphoria.
> You know that you can use assembler in Euphoria, don't you.
>
> Bernie
>
>
