Well, I have been thinking about yet another thing to distract me from what I should be doing...
Are there any infinite precision floating point systems out there to use in C?
by infinite, I don't actually mean infinite, but to where you can set the precision to however precise needed..
My best idea is to use just a string of numbers..like split one byte into two nibbles and store a base 10(decimal) number there. Have the extra combinations to be used as special symbols or whatnot..
like if 11 is stored in a nibble, then that is the decimal point, if 12 then a fraction thing..and so on...16 for negative sign...
I have already worked out the adding and subtracting of it...
Using carry is pretty simple..
and having those, you can implement multiplying and division quite easy...square root I never learned how to do on paper, so I'm not sure on it...
has this already been done, to where you can set the precision you want of the numbers? and also, are they not doomed to be inaccurate by the way hardware floatingpoint is done?
Infinite precision floating-point
Any finite precision floating point number is obviously just a rational. In fact, if you consider a floating point number: m*2^e
then this can trivially be rewritten as a rational: m/(2^-e).
Now, an arbitrary precision integer can be implemented by having a length (say number of bytes, or words) and a bit-string. Say, if we used 16-bit words (you should use register-size ofcourse) then we basicly encode the numbers as base-65536 numbers, with each of the 65536-nary digits itself being a 16-bit binary number. Calculations basicly like they teach you to count in schools, carry propagations and all that stuff. I guess some optimizations are possible, but I'm no expert. The trivial approach works anyway.
It should also be obvious that if you now have arbitrary precision integers, you can build arbitrary precision exact rationals from those: simply store a rational as a pair of integers, one for nominator and denominator each. You can then do arithmetics with them just as you normally do with rationals:
a/b + c/d = (a*d + c*b)/(b*d), then normalize if possible, substraction is the same
a/b * c/d = (a*c)/(b*d), then normalize if possible
(a/b) / (c/d) = a/b * d/c, handle as multiply
Now, you can do the same with floats if you store an arbittary precision mantissa and exponent. In fact floats are simply a limited class of rationals. This can potentially save you storage, but unfortunately it won't allow you to store every arbitrary precision rational exactly (in base-10, 1/3 = 0.33333...).
Having infinite precision floats on the other hand would imply being able to store not only all rationals, but also all irrationals (π, sqrt(2), etc..) exactly as the limit of precision going to infinity, so obviously those can't be done.
then this can trivially be rewritten as a rational: m/(2^-e).
Now, an arbitrary precision integer can be implemented by having a length (say number of bytes, or words) and a bit-string. Say, if we used 16-bit words (you should use register-size ofcourse) then we basicly encode the numbers as base-65536 numbers, with each of the 65536-nary digits itself being a 16-bit binary number. Calculations basicly like they teach you to count in schools, carry propagations and all that stuff. I guess some optimizations are possible, but I'm no expert. The trivial approach works anyway.
It should also be obvious that if you now have arbitrary precision integers, you can build arbitrary precision exact rationals from those: simply store a rational as a pair of integers, one for nominator and denominator each. You can then do arithmetics with them just as you normally do with rationals:
a/b + c/d = (a*d + c*b)/(b*d), then normalize if possible, substraction is the same
a/b * c/d = (a*c)/(b*d), then normalize if possible
(a/b) / (c/d) = a/b * d/c, handle as multiply
Now, you can do the same with floats if you store an arbittary precision mantissa and exponent. In fact floats are simply a limited class of rationals. This can potentially save you storage, but unfortunately it won't allow you to store every arbitrary precision rational exactly (in base-10, 1/3 = 0.33333...).
Having infinite precision floats on the other hand would imply being able to store not only all rationals, but also all irrationals (π, sqrt(2), etc..) exactly as the limit of precision going to infinity, so obviously those can't be done.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Always listen to experts. They'll tell you what can't be done, and why. Then do it.
-- Colin Plumb, comp.sys.amiga
Check out MAPM.
-- Colin Plumb, comp.sys.amiga
Check out MAPM.
Every good solution is obvious once you've found it.
Ehm.. MAPM seems to do more or less what I said was possible, and no more.Solar wrote:Always listen to experts. They'll tell you what can't be done, and why. Then do it.
-- Colin Plumb, comp.sys.amiga
Check out MAPM.
Then again, I'm not an expert.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Re: Infinite precision floating-point
There was a really (as in, REALLY) old IBM computer that could do arbitrary precision integers natively. On the other hand, it couldn't be delivered with more than 32K of memory and then only on special request, for thousands of dollars, so I doubt anybody ever used it for a really long number.hckr83 wrote:Well, I have been thinking about yet another thing to distract me from what I should be doing...
Are there any infinite precision floating point systems out there to use in C?
by infinite, I don't actually mean infinite, but to where you can set the precision to however precise needed..
My best idea is to use just a string of numbers..like split one byte into two nibbles and store a base 10(decimal) number there. Have the extra combinations to be used as special symbols or whatnot..
like if 11 is stored in a nibble, then that is the decimal point, if 12 then a fraction thing..and so on...16 for negative sign...
http://en.wikipedia.org/wiki/IBM_1401
It was created a little under 50 years ago and decommissioned 35 years ago
[edit] As requested. [/edit]
Last edited by Candy on Sat May 05, 2007 1:58 am, edited 1 time in total.
THERE ARE NO INFINITE PRECISION NUMBERS IN ANY COMPUTER WITH FINITE MEMORY!!!
Spell with me a-r-b-i-t-r-a-r-y precision, not infinite.
This is of practical importance, because "arbitrary precision" means "any finite precision" and there are things you can't do with "any finite precision" that you could do if you magically got yourself a machine with "infinite precision", especially if the computer with "infinite precision" could do arithmetics with them in finite time. Correctness in mathematics is just as important as it is in programming.
For finite integers "infinite precision" isn't even meaningful, because any finite integer can be expressed exactly with finite precision. And yes, I know that "infinite precision" is sometimes used to describe arbitrary precision, but it's still wrong!
Spell with me a-r-b-i-t-r-a-r-y precision, not infinite.
This is of practical importance, because "arbitrary precision" means "any finite precision" and there are things you can't do with "any finite precision" that you could do if you magically got yourself a machine with "infinite precision", especially if the computer with "infinite precision" could do arithmetics with them in finite time. Correctness in mathematics is just as important as it is in programming.
For finite integers "infinite precision" isn't even meaningful, because any finite integer can be expressed exactly with finite precision. And yes, I know that "infinite precision" is sometimes used to describe arbitrary precision, but it's still wrong!
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
all I'm hearing is "please throw rocks at me"
maybe I should say theoretically infinite! or definable precision with as much precision as memory you have....
btw, I finally learned how to add and subtract any base of number with pen and paper... pretty simple really, just have to think outside the box a bit..
maybe I should say theoretically infinite! or definable precision with as much precision as memory you have....
btw, I finally learned how to add and subtract any base of number with pen and paper... pretty simple really, just have to think outside the box a bit..
Hi, I was just posting a bit here to say I have begun working on this project..
I am making it in C++..(which I am still learning, so operator overloading isn't done yet..) So far, I have a really weird bug, but the way it is done, I think it will be very fast...heck, the way it works, I bet it could be implemented in something like a CPU(hardwire or microcode) very easily, plus it's portable to most anything including 16bit through 64bit...and it is OS-independent as it is a simple maths library, so...
sadly, I am making this closed source, or at least for now..I don't want my ideas being stolen from me by some big corporation... also, when a complete version is made, it will probably be sold...I've been trying to make a bit of money recently with my skills in programming, so..
Right now my adding method works, is fast, but due to a weird bug, it only will work properly with the bottom nibble...
I am making it in C++..(which I am still learning, so operator overloading isn't done yet..) So far, I have a really weird bug, but the way it is done, I think it will be very fast...heck, the way it works, I bet it could be implemented in something like a CPU(hardwire or microcode) very easily, plus it's portable to most anything including 16bit through 64bit...and it is OS-independent as it is a simple maths library, so...
sadly, I am making this closed source, or at least for now..I don't want my ideas being stolen from me by some big corporation... also, when a complete version is made, it will probably be sold...I've been trying to make a bit of money recently with my skills in programming, so..
Right now my adding method works, is fast, but due to a weird bug, it only will work properly with the bottom nibble...