Worst Fraction?
Joseph K. Horn
Although ->Q works well for most inputs, it gets outrageously large
numerators and denominators sometimes. Try this:
STD 0.917369353594 ->Q
It yields this fraction:
6.3493809101E16
---------------
6.9212917188E16
That's equal to this:
63493809101000000
-----------------
69212917188000000
Yow! Them is Big Numbers! This is the worst input to ->Q that I've
run across.
QUESTIONS:
Is there a worse one?
Is there a way of computing the worst possible input?
-Joe-
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Keith Farmer
"Joseph K. Horn" wrote:
> Although ->Q works well for most inputs, it gets outrageously large
> numerators and denominators sometimes. Try this:
> Is there a worse one?
> Is there a way of computing the worst possible input?
I'd guess and say yes, but don't ask me how to find it directly.
Your question also begs knowing how you'd define "worse": maximize the
entropy of the digits used; measure log(n) and log (d); measure the
sheer magnitude of n and d; ...? The first two are base-dependant, no?
Bob Wheeler
MC, OK, but if you want an approximation with the
smallest denominator, then a Farey sequence is the
thing to use. In this particular case, one as
accurate as the one you cite is 171893/187376, and
one good to about 6 places is 544/593.
Here is a program that you can try:
Input
(2) fraction
(1) accuracy -- e.g. .000001
%%HP: T(3)A(D)F(.);
\<<
DROP
0 0 1 1 0 0 0 1
\-> x tol Ns Nl Ds Dl N D F K
\<<
x FLOOR 'Ns' STO
Ns 1 + 'Nl' STO
Ns .5 + 'F' STO
IF x Ns - ABS tol \>= THEN
WHILE F x - ABS tol > K 100 < AND
REPEAT
K 1 + 'K' STO
Nl Ns + 'N' STO
Dl Ds + 'D' STO
N D / 'F' STO
IF F x > THEN
N 'Nl' STO
D 'Dl' STO
ELSE
N 'Ns' STO
D 'Ds' STO
END
END
END
N \->STR "/" + D \->STR +
\>>
\>>
"Joseph K. Horn" wrote:
>
> BRIEF BACKGROUND:
>
> Although ->Q works well for most inputs, it gets outrageously large
> numerators and denominators sometimes. Try this:
>
> STD 0.917369353594 ->Q
>
> It yields this fraction:
>
> 6.3493809101E16
> ---------------
> 6.9212917188E16
>
> That's equal to this:
>
> 63493809101000000
> -----------------
> 69212917188000000
>
> Yow! Them is Big Numbers! This is the worst input to ->Q that I've
> run across.
>
> QUESTIONS:
>
> Is there a worse one?
> Is there a way of computing the worst possible input?
>
> -Joe-
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
--
Bob Wheeler --- (Reply to: bwhe...@echip.com)
ECHIP, Inc. --- (302) 239-6620, voice and
FAX
724 Yorklyn Rd., Hockessin, DE 19707
Randomness comes in bunches
Joseph K. Horn
> .. if you want an approximation with the smallest
> denominator, then a Farey sequence is the
> thing to use.
I must have been unclear. What I'm looking for is a way
to find (a) any decimal number (between 0 and 1) for which
the HP48's ->Q function yields a denominator greater than
for an input of 0.917369353594; and (b) which decimal
number yields the largest possible denominator.
I'm not speaking in general math terms. I'm speaking of
the HP48's ->Q function, specifically.
Meanwhile, thanks for the decimal-to-fraction program!
How does it compare with HP's 'NEW2Q' on Goodies Disk #3?
Paul Guertin
> I must have been unclear. What I'm looking for is a way
> to find (a) any decimal number (between 0 and 1) for which
> the HP48's ->Q function yields a denominator greater than
> for an input of 0.917369353594; and (b) which decimal
> number yields the largest possible denominator.
Try the golden ratio (sqrt(5)-1)/2 which is about 0.618... .
Its continuous fraction expansion has the worst convergents
of all real numbers. If the calculator's algorithm uses
continuous fractions, it may be the worst case.
Paul Guertin
p...@sff.net
Keith Farmer
> Try the golden ratio (sqrt(5)-1)/2 which is about 0.618... .
> Its continuous fraction expansion has the worst convergents
It'd be interesting to see that expansion...
Joseph K. Horn
> Try the golden ratio (sqrt(5)-1)/2 which is about 0.618... .
> Its continuous fraction expansion has the worst convergents
> of all real numbers. If the calculator's algorithm uses
> continuous fractions, it may be the worst case.
Unfortunately, the HP48 only can handle 12-digit mantissas,
so instead of the "real" golden ratio, it only is converting
0.61803398875 to a fraction, which yields '832040/1346269'.
Still looking for something that beats 0.917369353594 when
given to ->Q.
Paul Guertin
> Paul Guertin wrote:
> > Try the golden ratio (sqrt(5)-1)/2 which is about 0.618... .
> > Its continuous fraction expansion has the worst convergents
>
> It'd be interesting to see that expansion...
1/(1+1/(1+1/(...
On an RPN calculator, just do "1 + 1/x" repeatedly.
Paul
John Gustaf Stebbins
-jgs
Joseph K. Horn <joe...@jps.net> wrote in message
news:7nu84c$p9u$1...@nnrp1.deja.com...
Harold Climer
>BRIEF BACKGROUND:
>
>Although ->Q works well for most inputs, it gets outrageously large
>numerators and denominators sometimes. Try this:
>
>STD 0.917369353594 ->Q
>
>It yields this fraction:
>
>6.3493809101E16
>---------------
>6.9212917188E16
>
>That's equal to this:
>
>63493809101000000
>-----------------
>69212917188000000
>
>Yow! Them is Big Numbers! This is the worst input to ->Q that I've
>run across.
>
>QUESTIONS:
>
>Is there a worse one?
>Is there a way of computing the worst possible input?
>
>-Joe-
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
I wonder how ->Q does with endless repeating decimals? ie 0 .11111.... ,
0.125125125.... etc. I remember converting them to fractions when
I was taking a course in Mathematical Physics for my undergraduate degree. We were
using Mary Boaz's book "Mathematical Methods for the Physical Sciences".
Harold A. Climer
Lab Instructor
Dept.Of Physics & Astronomy
U. Tennessee at Chattanooga
Damay
Echange Hp95Lx contre HP48GX
Caractéristiques HP95LX (4/92):
Documentation en Français
Clavier Azerty
512 Ko RAM
Lotus 123
Logiciel et cable de transfert HP - PC
Alimentation secteur
+ Logiciels divers : Jeux etc...
John Gustaf Stebbins
Miscounted the keystrokes.
-jgs
John Gustaf Stebbins <jgste...@home.com> wrote in message
news:2cEo3.23138$dP4....@news.rdc1.wa.home.com...
> How about .99999999975?
>
> -jgs
>
>
> Joseph K. Horn <joe...@jps.net> wrote in message
> news:7nu84c$p9u$1...@nnrp1.deja.com...
> > Paul Guertin wrote:
> >
> > Still looking for something that beats 0.917369353594 when
> > given to ->Q.
> >
Joseph K. Horn
> I wonder how ->Q does with endless repeating decimals?
> ie 0.11111.... , 0.125125125.... etc.
The HP48 has no built-in way of representing endlessly repeating
decimals; it treats all decimal numbers as terminating. Thus if
you evaluate 125/999, you only get 0.125125125125, not the real
answer of 0.125125125125125125125125125125125125125125125125....
Nevertheless, if you input 0.125125125125 to ->Q, it returns an
answer of 125/999, which is so close to the input that the HP
thinks they're the same, which in your case is a Good Thing, since
that's the answer you wanted.
-- BEGINNER'S CORNER --
BTW, in case you never heard of it, you can turn any repeating
decimal into a fraction without any math or thinking, by just
writing the repeating digits over that many 9's:
0.777777777777... = 7/9
0.131313131313... = 13/99
0.557557557557... = 557/999
and so on.
If the repeating section starts after some non-repeating digits,
e.g. 0.123434343434343434... then just notice that this is equal
to: 0.34343433434... - 0.22, that is, 34/99-22/100. The
simplification of this is left to the student. ;-)
Joseph K. Horn
> .999999999975
WOW! That's AWESOME! ->Q turns that into:
1.11111111111E22
----------------
1.11111111114E22
(a) How did you find this?
(b) Is it the "worst-possible" input?
John Gustaf Stebbins
Well, not really. I tried a couple other things first, just picking random
numbers (not fruitful) and using the plotting function (which I'll discuss
more under (b)). What I finally did was write a small program that started
at 1 and kept subtracting 1e-12 and checking the results of ->Q. I had it
check about a thousand values, but of course it found this pretty early. I
also checked in the vicinity of the number you gave, but did not find
anything worse than your number.
(b) My guess there is nothing significantly worse as this result is roughly
22 orders of magnitude beyond the input, which seems like a likely extreme
on system where the numbers cover 12 orders of magnitude. I was using a
function that reported the log of the denominator after a call to ->Q. When
I was graphing the output of the function, I occasionally got peaks that
were just over 20, but I wasn't able track them down. Evidently there is an
assumption somewhere in the plotting package that the function being plotted
behaves nicely. This function does not, and so tracing the plot was not
working correctly. I got frustrated with it and tried the brute force
approach, which worked so well that I never went back to debug the earlier
work.
-jgs
Joseph K. Horn <joe...@jps.net> wrote in message
news:7o15u5$ksk$1...@nnrp1.deja.com...
Dan Kirkland
>to find (a) any decimal number (between 0 and 1) for which
>the HP48's ->Q function yields a denominator greater than
>for an input of 0.917369353594; and (b) which decimal
>number yields the largest possible denominator.
Okay, my math is kinda rusty, and I was never very good with
the definitions anyway...
My understanding is that the numerator is on top, and the
denominator is on bottom, right? (Because I remember having
to find common denominators...)
Well then...
1.E-499 ->Q '1/1.E499'
Hmmm...
Somehow I don't think that is quite what you mean...
Have I got my definitions mixed up? Or does somebody else?
I am just guessing, but I would think that the biggest
numerator that ->Q could find would be somewhat limited
by the size of the mantissa. In a fraction, you are
dealing with two mantissas, so the max size of the
numerator would be less than 2x the size of the mantissa.
Maybe something like:
10^2*(mantissadigits-1) == 10^2*(12-1) == 10^22
Well, that is my guess anyway.
dan
Keith Farmer
> > > Try the golden ratio (sqrt(5)-1)/2 which is about 0.618... .
It may be nasty on the convergence, but it is very aesthetically pleasing...
Rodney Yeh
+ACI-badness.+ACI- I haven't yet found an input resulting in a fraction with a
numerator or denominator with a log greater than 22.
Here are some of my findings:
Numerator and Denominator having E22:
0.500000000008
0.499999999992
N having E21 and D having E22:
0.749999999999
0.749999999998
0.749999999997
0.749999999995
0.749999999994
N and D having E21:
0.999999999945
0.999999999944
0.999999999943
0.999999999942
0.999999999941
0.999999999939
0.874999999993
0.874999999991
0.500000000088
0.500000000066
0.000000000094
0.000000000044
I also found many more with E20 and lower. If you'll notice, most of my
findings are near +ACI-simpler fractions.+ACI-
Rodney
Joseph K. Horn wrote in message +ADw-7nu84c+ACQ-p9u+ACQ-1+AEA-nnrp1.deja.com+AD4-...
+AD4-Paul Guertin wrote:
+AD4-
+AD4APg- Try the golden ratio (sqrt(5)-1)/2 which is about 0.618... .
+AD4APg- Its continuous fraction expansion has the worst convergents
+AD4APg- of all real numbers. If the calculator's algorithm uses
+AD4APg- continuous fractions, it may be the worst case.
+AD4-
+AD4-Unfortunately, the HP48 only can handle 12-digit mantissas,
+AD4-so instead of the +ACI-real+ACI- golden ratio, it only is converting
+AD4-0.61803398875 to a fraction, which yields '832040/1346269'.
+AD4-
+AD4-Still looking for something that beats 0.917369353594 when
+AD4-given to -+AD4-Q.
+AD4-
+AD4--Joe-
+AD4-
+AD4-
+AD4-Sent via Deja.com http://www.deja.com/
+AD4-Share what you know. Learn what you don't.
Michael Hoppe
JKH>If the repeating section starts after some non-repeating digits, e.g.
JKH>0.123434343434343434... then just notice that this is equal to:
JKH>0.34343433434... - 0.22, that is, 34/99-22/100.
Try this:
1234567 - 1234
0.1234 567 567 567 ... = --------------.
9990000
Michael
--
-= Michael Hoppe <michae...@k2.maus.de>, <mho...@hightek.com> =--
-= Key fingerprint = 74 FD 0A E3 8B 2A 79 82 25 D0 AD 2B 75 6A AE 63
-= PGP public key ID 0xE0A5731D. =----------------------------------
Rodney Yeh
a denominator with an exponent 22 or greater, although I haven't found any
+ACI-greater.+ACI-
Input Exponent of Numer.+ADs- Denom.
----- --------------------------
0.999999999971 through 0.999999999975 22 +ADs- 22
0.999999999966 through 0.999999999969 22 +ADs- 22
0.500000000008 22 +ADs- 22
0.499999999992 22 +ADs- 22
0.749999999997 through 0.749999999999 21 +ADs- 22
0.749999999994 and 0.749999999995 21 +ADs- 22
8.33333333393E-02 21 +ADs- 22
5.88235294088E-02 21 +ADs- 22
Rodger Rosenbaum
>BRIEF BACKGROUND:
>
>Although ->Q works well for most inputs, it gets outrageously large
>numerators and denominators sometimes. Try this:
>
>STD 0.917369353594 ->Q
>
>It yields this fraction:
>
>6.3493809101E16
>---------------
>6.9212917188E16
>
>That's equal to this:
>
>63493809101000000
>-----------------
>69212917188000000
>
>Yow! Them is Big Numbers! This is the worst input to ->Q that I've
>run across.
>
>QUESTIONS:
>
>Is there a worse one?
>Is there a way of computing the worst possible input?
>
>-Joe-
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
This behavior appears to be an artifact of the ->Q algorithm. To see why, we need to know
a few things about continued fractions.
Every real number can be represented in the form:
1
a1 + -------------------------------
a2 1
+ -------------------
a3 1
+ -------
a4. . . .
The a1,a2,a3, etc are integers and are called Partial Quotients.
(Consult a Number Theory Text for more detail)
In order to find the a1, a2, etc., start with a number N (for the HP48 problem we are
considering, N is less than one), and subtract the Integer Part; assign the Integer Part
to a1. In this case, a1 is always zero. Now press the reciprocal key (1/x) on your 48.
Subtract the Integer Part and assign it to a2. Reciprocate again, and subtract the
Integer Part, assigning its value to a3. Continue doing this until you get a result of a
pure integer. After subtracting this last integer the result is zero and the process
stops. (This is a description of the ideal result obtained with exact arithmetic, and
doesn't necessarily happen on the HP48.)
Now that we have the various Partial Quotients, write them as a list: {a1,a2,a3,a4,. .
.} This is the standard way to represent the Continued Fraction whose value is the number
N we started with. It is known that rational numbers have finite continued fraction
representations, while irrational numbers have infinite continued fraction
representations.
If you take the first K elements in the continued fraction and reduce the complex
fraction shown above to simplest terms, namely a numerator and denominator, you get a
simple rational number. Now do this for each K=1 to M, where M is the number of elements
in the continued fraction {a1, a2, a3, a4, . . .}. The successive rational numbers
(simple fractions) obtained are called the Convergents. The convergents form a sequence
of numbers which more closely approximate the original number N as we proceed.
Try out the process on the HP48 starting with the number .999999999975. The first
Integer part is zero, so a1=0. Press the 1/x key and get 1.00000000003; subtract the
Integer part of 1 and assign that value to a2. Press the 1/x key and get 33333333333.3;
subtract the Integer part of 33333333333 and assign it to a3. Press the 1/x key and get
3.33333333333; subtract 3 and assign 3 to a4. Press the 1/x key and get 3.00000000003;
subtract 3 and assign to a5. Press the 1/x key and get 33333333333.3. At this point we
see that things are going to repeat endlessly; so the continued fraction we have is:
{0,1,33333333333,3,3,33333333333,3,3,33333333333. . .}
Right away we see that we have a problem--our original starting value of N was
.999999999975 which is a rational number, namely: 999999999975/1000000000000. Rational
numbers have finite continued fraction representations, but we have arrived at an
obviously repeating sequence of partial quotients. This happened because when we first
pressed the 1/x key we got 1.00000000003 which is the correctly rounded 12 digit result of
the reciprocal function, and is exactly what the HP48 should do. It is the best ANY 12
digit calculator can do, but the exact result is in fact:
1.0000000000025000000000625000000015625000. . .and it is this error which causes our
process to repeat rather than terminate. The correct continued fraction representation of
.999999999975 is {0,1,399999999999} and the convergents are
399999999999
0,1,-------------
400000000000
and, in fact, 399999999999/400000000000 is exactly equal to .999999999975.
If you calculate the first 6 convergents of the continued fraction you get when you do
things with the HP48, {0,1,33333333333,3,3,33333333333}, using exact arithmetic, they are:
33333333333 100000000000 333333333333 11111111111088888888889
0,1, -------------, ------------, ------------ -----------------------
33333333334 100000000003 333333333343 11111111111422222222222
Now we can see what the problem is. Apparently the HP's algorithm calculates successive
convergents and compares them to the number N we are trying to approximate as a fraction.
(assume we're in STD mode) It keeps going until it gets a fraction which equals the
number N in all of the significant digits of N; but it must also have a way to avoid
getting stuck in an infinite loop. Notice that the sixth convergent equals .999999999973,
(calculated with 12 digit arithmetic) which doesn't equal the original N, which was
.999999999975. I'm guessing that the 48 continues until it gets an exact result, or until
the numerator or denominator of the current convergent exceeds 12 digits, at which point
it stops.
Look at that sixth convergent; if you round numerator and denominator to 12 digits,
that is the result the HP48 returns when you start with .999999999975 and press ->Q.
Now we see why the values returned have magnitude 22; look at the continued fraction we
are computing the convergents from: {0,1,33333333333,3,3,33333333333. . .}. The fifth
convergent has a 12 digit numerator and denominator; when we use the next term of the
continued fraction (33333333333), it is so large that the next convergent also has a large
number of digits in the numerator and denominator; more than 12 digits, so the 48 stops
and returns this large convergent, the best it can do.
Notice that all of the 48's computations are done with 12 digit arithmetic; otherwise
we wouldn't get the numbers we do.
The problem arises when the continued fraction {a1, a2, a3, a4, ...} has a very large
integer at some point in the sequence so that we are faced with a convergent that has
almost 12 digits in the numerator and denominator and the next integer in the continued
fraction {a1, a2, a3, a4, ...} to be used in computing the next convergent is large.
I wrote a program which starts with a random number from the RAND function and
repeatedly reciprocates and subtracts the integer part. I save the last 25 integer parts
and stop when I get a large integer part. It is necessary to let the 48 do this because
the rounding errors caused by the fact that the calculator only does 12 digit arithmetic
causes this sequence of integer parts to be different than it would be if exact arithmetic
were used. Then I calculate what the decimal fraction would be to generate this sequence
by calculating all the convergents and converting the last one to a decimal fraction.
Here is the best one I found so far; it illustrates the phenomenon.
{0,1,2,7,1,1,1,2,7,1,24,1,21,1,50,1,49,1,1,2,1,1,1,35511363} Sequence A
This equals .6806249848812427... and if you start with .680624984882 and follow the
steps outlined above of repeatedly subtracting the Integer Part and reciprocating,
starting with this number, you will get the integers in sequence A.
However, if you do exact arithmetic starting with the number .680624984882 and compute
the continued fraction representation you will get:
{0,1,2,7,1,1,1,2,7,1,24,1,22,1,2,5,1,1,1,16,1,1,17,1,6,2} Sequence B
Notice that this is different from sequence A and the difference is caused by the fact
that the HP48 doesn't do exact arithmetic.
The last convergent computed from sequence A is 1147004596970805413
-------------------
1685222585784061187
which is what the HP48 gets when you start with .680624984882 and press ->Q
QED
Rodger Rosenbaum
Rodger Rosenbaum
>John Gustaf Stebbins wrote:
>
>> .999999999975
>
>WOW! That's AWESOME! ->Q turns that into:
>
>1.11111111111E22
>----------------
>1.11111111114E22
>
>(a) How did you find this?
>(b) Is it the "worst-possible" input?
>
>-Joe-
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
How did you find your number, Joe?
Rodger Rosenbaum
Joseph K. Horn
> How did you find your number, Joe?
I used the famous, fabulous "BogoSearch" algorithm: The HP48 just kept
picking random numbers until it stumbled upon it. *blush*
-Joe-
Unbreakable toys can be used for breaking other toys.
John Gustaf Stebbins
mine.
So who are you calling Bogo?
I posted elsewhere how I found it.
-jgs
Joseph K. Horn <joe...@jps.net> wrote in message
news:7o6koc$ao1$1...@nnrp1.deja.com...
Keith Farmer
> 1234567 - 1234
> 0.1234 567 567 567 ... = --------------.
> 9990000
= 1/10000 * (1234.567...) = 1/10000 * (1234 + .567...) = 1/10000 * (1234
+ 567/999)
Rodger Rosenbaum
<jgste...@home.com> wrote:
>To be petty, the number Rodger quoted and appears to be asking about is
>mine.
>
>So who are you calling Bogo?
>
>I posted elsewhere how I found it.
>
>-jgs
>
On Sun, 01 Aug 1999 10:01:43 GMT, Joseph K. Horn <joe...@jps.net>
wrote:
---------------------------------------------
If you look at my posting, and not the one Joe edited, you'll see
it says:
>John Gustaf Stebbins wrote: <========== Full credit here
>
>> .999999999975
>
>WOW! That's AWESOME! ->Q turns that into:
>
>1.11111111111E22
>----------------
>1.11111111114E22
>
>(a) How did you find this?
>(b) Is it the "worst-possible" input?
>
>-Joe-
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
How did you find your number, Joe?
Rodger Rosenbaum
Joseph K. Horn
> To be petty, the number Rodger quoted and appears
> to be asking about is mine.
>
> So who are you calling Bogo?
>
> I posted elsewhere how I found it.
Uh... it seems you missed the context.
It was asked how I found 0.917369353594, not your number.
I replied that I found it using a method similar to what
is known as the BogoSort algorithm (see BOGOSORT on
Goodies Disk #8).
Nobody was stealing your discoveries or calling you names.
Okay? d;^)
Michael Hoppe
wrote:
KF>= 1/10000 * (1234.567...) = 1/10000 * (1234 + .567...) = 1/10000
KF>* (1234 + 567/999)
That's right, but with my suggested solution one con convert the periodic
number into *one* fraction without much calculating, esp. without adding two
fractions.
Keith Farmer
>
> In Msg 37A74698...@pacbell.net, far...@pacbell.net (Keith Farmer)
> wrote:
>
> KF>= 1/10000 * (1234.567...) = 1/10000 * (1234 + .567...) = 1/10000
> KF>* (1234 + 567/999)
>
> That's right, but with my suggested solution one con convert the periodic
True, but this demonstrates a generalized solution that is easier to see.
Jean-Yves Avenard
John Gustaf Stebbins <jgste...@home.com> wrote in message
news:QwHp3.25652$dP4....@news.rdc1.wa.home.com...
> To be petty, the number Rodger quoted and appears to be asking about is
> mine.
NO. It's MY number ! :)
I will register every number between 0 and 1 as trademark.
Jean-Yves
John Gustaf Stebbins
But this does bring up the question, doesn't the trademark office require
you to do a prior use search for each trademark. That could get pretty
expensive, even for the rationals. If you really want all the numbers I
couldn't even count the cost.
-j<g>s
Jean-Yves Avenard <aven...@epita.fr> wrote in message
news:37aa...@isoit370.bbn.hp.com...
R. Saylor
<aven...@epita.fr> wrote:
>
>John Gustaf Stebbins <jgste...@home.com> wrote in message
>news:QwHp3.25652$dP4....@news.rdc1.wa.home.com...
>> To be petty, the number Rodger quoted and appears to be asking about is
>> mine.
>
>NO. It's MY number ! :)
>
>I will register every number between 0 and 1 as trademark.
>
>Jean-Yves
>
>
You can only register the numbers STRICTLY between 0 and 1. "God
created the integers. All else is the work of man." So 0 and 1 already
belong to God. You can't have them. :)
Richard S.
Paul Hoffman
It's going to take a long time to registar 'your' numbers seeing as though
there are an infinite number of numbers between 0 and 1.
Paul