51 views

Skip to first unread message

Oct 7, 2004, 5:58:09 AM10/7/04

to

PDQ2.TXT: documentation for the PDQ2 Directory & Program

The PDQ Algorithm, Version 2, for the HP49G and hp49g+.

Unlimited Precision Version of the PDQ Fraction Finder Algorithm.

Dedicated to Rodger Rosenbaum, who said that it couldn't be done.

Code and documentation: Copyright (C) 2004 by Joseph K. Horn.

Not to be used in ANY commercial product without written permission.

"Somebody said that it couldn't be done,

But he with a chuckle replied

That MAYBE it couldn't, but he would be one

Who wouldn't say so till he tried.

So he buckled right in with a trace of a grin

On his face. If he worried, he hid it.

He started to sing as he tackled the thing

That couldn't be done, and he did it."

-- Edgar Guest

INTRODUCTION: Three Problems of Increasing Difficulty

(a) What is the simplest fraction (smallest possible numerator and

denominator) between 0.4 and 0.6? The answer is obviously 1/2. No

software is needed for such a simple problem. Even though there are an

infinite number of fractions between 0.4 and 0.6, it's obvious that

they all have numerators and denominators greater than 1/2 does, so 1/2

is clearly the "winner" of the "simplest fraction award" in that

interval.

(b) What is the simplest fraction between 0.671 and 0.672? The answer

is not quite as obvious this time! Answer: 43/64 (=0.671875). PDQ2

finds the answer, as do PDQ1, DEC2FRAC, the HP-32SII, the hp33s, the

Sparcom Math-Pro cards for the HP48, and many other tools.

(c) What is the simplest fraction equal to pi +/- 261 parts per

septillion (US) or per quadrillion (UK)? The answer is not only

non-obvious, it's impossible to calculate in one's head. In fact, it is

not attainable by *anything* other than PDQ2! [Challenge: A prize of

pi^3 dollars +/- 1 part per hundred will be awarded to the first person

who demonstrates to me any software or hardware that gets the right

answer to this and all similar problems. -jkh-] Answer:

899125804609/286200632530.

*ALL* questions like these, regardless of complexity, can be answered

by PDQ2 swiftly and exactly. The inputs and outputs can be of any

desired length, and are always exact (no round-off errors ever occur).

Decimals can be entered either as a string (e.g. "3.14159265358979") or

as a ratio of integers (e.g. '314159265358979/10^14'), thus allowing

for inputs of any desired length. The outputs are always ratios of

integers.

CONTENTS of the PDQ2 directory:

(1) PDQ2 - finds simplest fraction within any interval.

(2) CF~I2 - toggles between Continued Fraction & two integers.

(3) ISQR - infinite-precision square root of integer.

(4) PI64 - Pi to 64 decimal places.

(5) TOF - decimal-to-fraction by definition of decimals.

(6) $TOF - same as TOF but uses strings for unlimited precision.

(7) FRAC? - tests if object is a ratio of two integers.

INSTRUCTIONS

___________________________________________________________

(1) PDQ2, "Simplest Ratio of Integers = Target +/- Tolerance"

Input:

Level 2: Exact TARGET (real, string, or ratio of two integers)

Level 1: Exact TOLERANCE (real, or ratio of two integers)

If the input tolerance is a ratio of two integers, or a decimal between

0 and 1, it is used as-is.

If the input tolerance T is >1, it is taken to mean that many TRUNCATED

decimal places of accuracy are desired, and is automatically replaced

by 1/10^T. For exact results, use only integers.

If the input tolerance T is <0, it is taken to mean that many ROUNDED

decimal places of accuracy are desired, and is automatically replaced

by 5/10^(|T|+1).

Output:

Level 2: Simplest Fraction (ratio of two integers)

Level 1: N/X:(sign)Exact Error (ratio of two integers)

The "N" or "X" tag on the output indicates whether the output is a

"normal" or "extra" result. "Normal" results are convergents of the

continued fraction expansion of the input target. "Extra" results are

"intermediate convergents" that cannot be found by most other software.

The sign of the error indicates whether the output is greater than

(positive) or less than (negative) the target. For example, an error

of -1/10 would mean that the output is exactly 0.1 less than the

target.

Pressing [-] [EVAL] converts the output back into the original target.

Pressing ABS LOG ABS on the level-1 output changes it from the actual

error into the number of decimal places of accuracy.

If the specified tolerance exceeds the precision of the target, then

its invisible trailing zeros will be assumed to be significant digits.

For example, 3. 1/x 12 PDQ2 --> 1/3 as expected, but 3. 1/x 13 PDQ2 -->

256410256410/769230769231, because that's the simplest fraction that

rounds to .3333333333330 (notice the trailing zero in the 13th decimal

place!). The PDQ2 Algorithm follows the HP Calculator Philosophy of

assuming that the user knows what he's doing and that his inputs are

exactly what he intended to input. Whenever PDQ2 gets an answer that

you don't expect, raise your expectations accordingly.

Examples (the three from the Introduction above, plus one more):

(a) What is the simplest fraction (smallest possible numerator and

denominator) between 0.4 and 0.6, inclusive? In other words, what's

the simplest fraction equal to .5 +/- a tolerance of .1?

.5 .1 PDQ2 --> '1/2' N:0

This means that the answer is 1/2, with no error, and it's a "normal"

result.

(b) What is the simplest fraction between 0.671 and 0.672, inclusive?

In other words, what's the simplest fraction that's equal to 0.6715 +/-

0.0005?

.6715 .0005 PDQ2 --> '43/64' X:3/8000

This means that the answer is 43/64, which is 3/8000 above the target,

and is an answer that cannot be discovered by the simple continued

fraction algorithm that everybody else uses.

(c) What is the simplest fraction equal to pi with a tolerance of +/-

261 parts per septillion (US) or per quadrillion (UK)?

[PI64] 261 24 10^x / PDQ2 --> 899125804609/286200632530 X:big/bigger

That fraction (in level 2) is greater than the target by exactly the

amount in level 1... a fraction so long that you'll probably need to

press ->NUM to get an idea of its magnitude.

(d) What's the simplest fraction for sqrt(13) on an 80-bit calculator

(e.g. the hp30s)?

If the calculator truncates its results, use this:

13 30 ISQR 2 -80 y^x PDQ2 --> 6536561700241/1812916028881, slightly

less than sqrt(13).

If the calculator rounds its results, use this instead:

13 30 ISQR 2 -81 y^x PDQ2 --> 7955840589842/2206553168161, slightly

less than sqrt(13).

___________________________________________________________

(2) CF~I2, "Toggle Between Continued Fraction and Two-Integer Ratio"

Input --> Output options:

(a) { a0 a1 a2 a3 ... } --> P Q

(b) 'P/Q' --> { a0 a1 a2 a3 ... }

(c) P Q --> { a0 a1 a2 a3 ... }

(d) Decimal number --> { a0 a1 a2 a3 ... }

Converts numbers to and from "continued fraction" form, represented as

a list containing the integer part of the input (a0) followed by the

"partial quotients" (a1, a2, a3, etc). P and Q are the numerator and

denominator, respectively, of the equivalent regular fracton. All

outputs are exactly equal to the input; no roundoff errors occur.

Examples:

.123 CF~I2 --> { 0 8 7 1 2 5 }

This means that .123 = 0+1/(8+1/(7+1/(1+1/(2+1/5))))

{ 0 8 7 1 2 5 } CF~I2 --> 123 1000

This means that 0+1/(8+1/(7+1/(1+1/(2+1/5)))) = 123/1000

'15/37' CF~I2 --> { 0 2 2 7 }

This is the same as:

15 37 CF~I2 --> { 0 2 2 7 }

Some irrational numbers have continued fractions containing discernable

patterns. For example, the constant 'e' (approx. 2.71828182846) is

exactly equal to the continued fraction { 2 1 2 1 1 4 1 1 6 1 1 8 1 1

10 1 1 12 1 1 14 ... }. This fact allows CF~I2 to be used to generate

fractions that are better than the 12-digit limit of the hp49g+.

Example:

{ 2 1 2 1 1 4 1 1 6 1 1 8 1 1 10 1 1 12 1 1 14 2 } CF~I2

--> 848456353 312129649

This ratio (848456353/312129649) is the same as 'e' to 18 decimal

places. Use more partial quotients to get as close to 'e' as you want.

___________________________________________________________

(3) ISQR, "Infinite-Precision Square Root of Integer"

Input:

Level 2: The integer to be square-rooted.

Level 1: The number of desired ROUNDED decimal places.

Output: 'p/q', exactly equal to the decimal expansion of the square

root rounded to the specified number of digits.

Example:

What is the exact sqrt(50) rounded to 25 decimal places?

50 25 ISQR --> '17677669529663688110021109/2500000000000000000000000'

This fraction can then be used as an input for PDQ2, keeping in mind

that the tolerance should not exceed 24 decimal places. If more places

are desired, use a larger input for ISQR.

The ISQR program is included in the PDQ2 directory only to help you

generate super-accurate square roots for the PDQ2 program to chew on.

___________________________________________________________

(4) PI64, "Pi to 64 decimal places"

To experiment with pi as an input to PDQ2, you can use PI64 to put pi

on the stack in string form, accurate to 64 decimal places. Therefore,

when using PI64 with PDQ2, do not specify a tolerance greater than 64,

or trailing zeros will be assumed as significant digits, diverging away

from pi. If more than 64 digits of pi are needed (for what?!?), you'll

have to type them in.

Example:

PI64 49 PDQ2--> 17579871157983393066594923/5595846787423398162594219

This is the simplest fraction in the interval [pi-1/10^49, pi+1/10^49].

Furthermore, only PDQ2 can find this answer, and it finds it very

quickly.

___________________________________________________________

(5) TOF, "To Fraction" using the simple definition of decimals.

Input: any real number or integer or ratio of integers.

Output: P Q (where P/Q is exactly equal to the input).

TOF is only included in the PDQ2 directory because it is called by the

PDQ2 program. It is rather useless by itself, since its results are

rather brainless. It merely puts the input over 1 and then multiplies

by 10/10 until the numerator is an integer. If a fraction is input, it

merely performs a FXND.

Examples:

'2/3' TOF --> 2 3

2. 3. / TOF --> 666666666667 1000000000000

pi ->NUM TOF --> 314159265359 100000000000

___________________________________________________________

(6) $TOF, "To Fraction" for long inputs in string form.

Input: any decimal number as a string.

Output: 'P/Q' (where P/Q is exactly equal to the input).

See TOF for details.

Examples:

".123456789012345" $TOF --> '24691357802469/200000000000000'

which is *exactly* equal to .123456789012345, even though HP

calculators cannot directly verify that fact, since they are limited to

12-digit precision. The $TOF program (and the PDQ2 program) do not

have that limitation.

___________________________________________________________

(7) FRAC?, "Is this a fraction?"

Input: any object

Output: same object; 0. or 1. (1. if ratio of two integers, 0.

otherwise)

Examples:

3.1416 FRAC? --> 3.1416 0. (because the object 3.1416 is not a ratio of

two integers)

'3927/1250' FRAC? --> '3927/1250' 1. (because that object IS a ratio of

two integers)

'1.2/3.4' FRAC? --> '1.2/3.4' 0. (it's NOT a ratio of two integers)

"Foo" FRAC? --> "Foo" 0.

153 FRAC? --> 153 0.

Included here only because it gets called by the TOF program.

___________________________________________________________

SOURCE CODE

The programs in this 'PDQ2' directory are written entirely in

un-optimized User RPL for the sake of those who wish to study how the

programs work. Optimizing the code, or rewriting it in System RPL, or

in Saturn Assembly Language, or in ARM Assembly Language, is left as an

exercise for the student.

Google apparently removes the indenting that HP so carefully puts into

program listings. Sorry 'bout that.

%%HP: T(3)F(.);

@ PDQ2 directory by Joe Horn (C) Copyright 2004

@ See PDQ2.TXT for details.

DIR

PDQ2

@ PDQ Algorithm demo, version 2

@ Input: Exact target (%|$|'n/d'), Exact tolerance (%|'a/b')

@ Output: Exact rational approximation ('p/q'), Exact error ('x/y')

@ Example: "3.14159265358979", 14

@ --> '53047102/16885417', '-15109243/1688541700000000000000'

\<<

IF OVER TYPE 2. SAME

THEN SWAP $TOF SWAP

END

IF OVER FXND MOD

THEN

IF DUP 0 <

THEN NEG 2. LOG +

END

IF DUP 1 \>=

THEN NEG ALOG

END TOF ROT TOF DUP2 1 1 0 0 0 1 0 1 1 0 0

\-> a b n d n0 d0 cn x pn cd y pd lo hi mid q r

\<<

DO n d IDIV2 'r' STO 'q' STO

q cn * pn + 'x' STO

q cd * pd + 'y' STO

cn 'pn' STO

x 'cn' STO

cd 'pd' STO

y 'cd' STO

d 'n' STO

r 'd' STO

UNTIL b n0 y * d0 x * - ABS * a d0 * y * \<=

END

IF q 1 >

THEN q 'hi' STO

DO

lo hi + 2 IQUOT 'mid' STO

cn pn mid * - 'x' STO

cd pd mid * - 'y' STO

IF b n0 y * d0 x * - ABS * a d0 * y * \<=

THEN mid 'lo' STO

ELSE mid 'hi' STO

END

UNTIL hi lo - 1 \<=

END

cn pn lo * - 'x' STO

cd pd lo * - 'y' STO

END x y / DUP n0 d0 / - EVAL

IF lo

THEN "X"

ELSE "N"

END \->TAG

\>>

ELSE DROP :N: 0

END

\>>

CF~I2

@ Toggles between Continued Fraction (list) and two integers (p/q).

@ {} --> p q; e.g. { 3 7 16 } --> 355 113

@ p q --> {}; e.g. 355 113 --> { 3 7 16 }

@ %.% --> {}; e.g. 1.2345 --> { 1 4 3 1 3 1 1 2 5 }

@ 'p/q' --> {}; e.g. '355/113' --> { 3 7 16 }

\<<

IF DUP TYPE 5. SAME

THEN LIST\-> R\->B 1 0 # 1h 4. ROLL

START OVER 4. ROLL * + SWAP

NEXT

ELSE

IF DUP FXND MOD

THEN FXND

END DUP2

IF 12 ALOG < SWAP 12 ALOG < AND

THEN I\->R SWAP I\->R SWAP

END DEPTH DUP 1. + ROLLD SWAP

WHILE OVER DUP2 MOD ROT OVER - ROT / SWAP DUP

REPEAT ROT

END ROT DROP2 DEPTH ROLL DEPTH SWAP - 1. + \->LIST R\->I

END

\>>

ISQR

@ "Infinite-Precision Square Root"

@ Input: x (integer), p (integer)

@ Output: 'p/q' exactly equal to sqrt(x) rounded to p decimal places.

@ Example: 3 14 --> '21650635094611/12500000000000'

\<< SWAP OVER 1 + 2 * ALOG * DUPDUP \->STR

1. OVER SIZE 2. / SUB OBJ\->

WHILE DUP2 IQUOT + 2 IQUOT ROT OVER - SIZE

REPEAT SWAP OVER

END NIP DUP 10 IREMAINDER + 10 IQUOT SWAP ALOG /

\>>

PI64

@ Pi to 64 decimal places, just for playing with.

"3.1415926535897932384626433832795028841971693993751058209749445923"

TOF

@ "To Fraction" using the definition of decimal numbers.

@ e.g. 1.2 --> 12/10 & .333333333333 --> 333333333333/1000000000000

@ Note: the output is always exactly equal to the input.

\<<

IF FRAC?

THEN FXND

ELSE

IF DUP FXND MOD

THEN 11. OVER XPON - ALOG SWAP OVER * R\->I SWAP R\->I SIMP2

ELSE 1

END

END

\>>

$TOF

@ Same as 'TOF' but inputs strings (of unlimited length).

@ e.g. "1.2345678901234567" --> 1234568901234567/10000000000000000'

@ Note: the output is always exactly equal to the input.

\<< DUP "." POS DUP2 1. - 1. SWAP SUB PICK3 PICK3 1 +

OVER SIZE SUB + STR\-> ROT SIZE ROT - R\->I ALOG /

\>>

FRAC?

@ Input: obj

@ Output: obj, 0/1 (1 if obj is 'integer/integer', else 0)

\<<

IF DUP TYPE 9. -

THEN 0.

ELSE DUP \->LST DUP 1.

\<< TYPE

\>> DOSUBS R\->I { 28 28 18 } SAME SWAP DUP SIZE GET

{ / } 1. GET SAME AND

END

\>>

END

Oct 7, 2004, 11:38:43 AM10/7/04

to

//* Challenge: A prize of

pi^3 dollars +/- 1 part per hundred will be awarded to the first person

who demonstrates to me any software or hardware that gets the right

answer to this and all similar problems. -jkh- *//

pi^3 dollars +/- 1 part per hundred will be awarded to the first person

who demonstrates to me any software or hardware that gets the right

WRI Mathematica 5.0 :

Rationalize[Pi,261/10^(4*6)]

returns exactly what's needed.

I want my 31bucks. :-]

Oct 7, 2004, 2:44:13 PM10/7/04

to

"Joe Horn" <joe...@holyjoe.net> wrote:

> (c) What is the simplest fraction equal to pi +/- 261 parts per

> septillion (US) or per quadrillion (UK)? The answer is not only

> non-obvious, it's impossible to calculate in one's head. In fact, it is

> not attainable by *anything* other than PDQ2! [Challenge: A prize of

> pi^3 dollars +/- 1 part per hundred will be awarded to the first person

> who demonstrates to me any software or hardware that gets the right

> answer to this and all similar problems. -jkh-] Answer:

> 899125804609/286200632530.

> (c) What is the simplest fraction equal to pi +/- 261 parts per

> septillion (US) or per quadrillion (UK)? The answer is not only

> non-obvious, it's impossible to calculate in one's head. In fact, it is

> not attainable by *anything* other than PDQ2! [Challenge: A prize of

> pi^3 dollars +/- 1 part per hundred will be awarded to the first person

> who demonstrates to me any software or hardware that gets the right

> answer to this and all similar problems. -jkh-] Answer:

> 899125804609/286200632530.

This one is easy :-) This has been a part of Mathematica since at least version 3.0.

$Version = 5.0.1 for Microsoft Windows (November 18, 2003)

$TopDirectory = C:\Program Files\Wolfram Research\Mathematica\5.0.1

In[1]:= Rationalize[Pi, 261/10^24]

899125804609

Out[1]= ------------

286200632530

Cheers,

Bhuvanesh.

Oct 7, 2004, 6:44:24 PM10/7/04

to

On 7 Oct 2004 02:58:09 -0700, "Joe Horn" <joe...@holyjoe.net> wrote:

>PDQ2.TXT: documentation for the PDQ2 Directory & Program

>

>The PDQ Algorithm, Version 2, for the HP49G and hp49g+.

>Unlimited Precision Version of the PDQ Fraction Finder Algorithm.

>Dedicated to Rodger Rosenbaum, who said that it couldn't be done.

*Exactly* what was it I said that you believe you have provided a counterexample for

in PDQ2?

I say *exactly* because I want to avoid a long back and forth like we had in the

original PDQ thread. :-)

Oct 7, 2004, 10:53:05 PM10/7/04

to

-=[ Fri, 8.10.04 3:12 p.m. +1300 (NZDT) ]=-

Hi Rodger Rosenbaum ! <nos...@aol.com>

03h28m ago, on Thu, 7.10.04 at 3:44 p.m. -0700, you wrote

in message ID <uhhbm050o0dddbdi3...@4ax.com> :

> On 7 Oct 2004 02:58:09 -0700, "Joe Horn" <joe...@holyjoe.net> wrote:

>

> >PDQ2.TXT: documentation for the PDQ2 Directory & Program

> >

> >The PDQ Algorithm, Version 2, for the HP49G and hp49g+.

> >Unlimited Precision Version of the PDQ Fraction Finder

> >Algorithm. Dedicated to Rodger Rosenbaum, who said that

> >it couldn't be done.

>

> *Exactly* what was it I said that you believe you have

> provided a counterexample for>

> I say *exactly* because I want to avoid a long back and

> forth like we had in the original PDQ thread. :-)

I remember this sentence well:-

> Subject: Re: 48/49: Best Fraction Challenge

> Date: Sat, 18 Oct 2003 06:16:23 -0700

> Message-ID: <m2d2pvor8kupc24oe...@4ax.com>

[...]

> Even you aren't able to find a small fraction whose value is

> "equal" to the input argument except in a relatively small

> number of cases.

You meant "equal" in the strictest mathematical sense. Joe's

PDQ1 was limited to calculator precision. His PDQ2 handles

unlimited precision, which approaches your "equal"

assymptotically at least. I don't know whether he has

expanded on your "relatively small number of cases" though.

Perhaps Joe took your statement above as a challenge.

--

Tony Hutchins

New Zealand

Oct 7, 2004, 11:23:37 PM10/7/04

to

On 7 Oct 2004 02:58:09 -0700, "Joe Horn" <joe...@holyjoe.net> wrote:

Not if one is an Idiot Savant; in fact an Idiot Savant friend of mine wants to know

what is the "simplest fraction" equal to Pi +/- 13131 parts in 10^440 and he wants to know

how long it takes PDQ2 to find it. It took him less than a second! Way less!

In fact, it is

>not attainable by *anything* other than PDQ2! [Challenge: A prize of

>pi^3 dollars +/- 1 part per hundred will be awarded to the first person

>who demonstrates to me any software or hardware that gets the right

>answer to this and all similar problems. -jkh-] Answer:

>899125804609/286200632530.

>

>*ALL* questions like these, regardless of complexity, can be answered

>by PDQ2 swiftly and exactly. The inputs and outputs can be of any

>desired length,

I don't think you really meant to say that. Can they be 10^20 digits long? Looks like

imprecise speaking to me.

and are always exact (no round-off errors ever occur).

>Decimals can be entered either as a string (e.g. "3.14159265358979") or

>as a ratio of integers (e.g. '314159265358979/10^14'), thus allowing

>for inputs of any desired length. The outputs are always ratios of

>integers.

>

>

Snip...

>(4) PI64, "Pi to 64 decimal places"

>

>To experiment with pi as an input to PDQ2, you can use PI64 to put pi

>on the stack in string form, accurate to 64 decimal places. Therefore,

>when using PI64 with PDQ2, do not specify a tolerance greater than 64,

>or trailing zeros will be assumed as significant digits, diverging away

>from pi.

You don't really mean to say that adding trailing zeroes to a 64 decimal approximation

to Pi will cause its value to diverge (further than it already is) from Pi? Won't the

value of an N-digit approximation to Pi have exactly the same value if any number of

trailing zeroes are added, rather than "diverging away from Pi" as zeroes are added?

If more than 64 digits of pi are needed (for what?!?), you'll

>have to type them in.

>

Snip...

>

>(6) $TOF, "To Fraction" for long inputs in string form.

>

>Input: any decimal number as a string.

>Output: 'P/Q' (where P/Q is exactly equal to the input).

>

>See TOF for details.

>

>Examples:

>".123456789012345" $TOF --> '24691357802469/200000000000000'

>which is *exactly* equal to .123456789012345, even though HP

>calculators cannot directly verify that fact, since they are limited to

>12-digit precision.

I think you mean to say something else here, rather than an unqualified "...HP

calculators cannot directly verify that fact...". It seems to me that the HP49 can, and

it's an HP calculator, isn't it?

Oct 8, 2004, 12:15:38 AM10/8/04

to

I think it's limited by the amount of memory which the HP49 has, which means that his

algorithm, like everything else on the HP49, is limited to "calculator precision". It's

just that "calculator precision" is much bigger than it was on the HP48. It's the same

result you would get if you had a machine with arithmetic registers of 10,000 digits, or

50,000 digits, or 1,000,000 digits. That's what all arithmetic systems of so-called

"infinite precision" (metaphorically speaking, that is) do. The only way you can get true

infinite precision arithmetic is if all your numbers can be represented as rationals.

Speaking of which, I'm going to post a mini-challenge for the HP49.

which approaches your "equal"

>assymptotically at least. I don't know whether he has

>expanded on your "relatively small number of cases" though.

My original argument still applies. Whatever the largest fractions you can represent

in the HP49's memory, only a relatively small number of them have denominators with only 2

and 5 as prime factors.

Oct 8, 2004, 2:41:28 AM10/8/04

to

-=[ Fri, 8.10.04 7:26 p.m. +1300 (NZDT) ]=-

Hi The Phantom ! <pha...@aol.com>

03h03m ago, on Thu, 7.10.04 at 8:23 p.m. -0700, you wrote

in message ID <p02hm0915vjoepg8l...@4ax.com> :

> >(c) What is the simplest fraction equal to pi +/- 261 parts per

> >septillion (US) or per quadrillion (UK)? The answer is not only

> >non-obvious, it's impossible to calculate in one's head.

>

> Not if one is an Idiot Savant;

;-)

> >*ALL* questions like these, regardless of complexity, can

> >be answered by PDQ2 swiftly and exactly. The inputs and

> >outputs can be of any desired length,

>

> I don't think you really meant to say that. Can they be

> 10^20 digits long? Looks like imprecise speaking to me.

OK desired length is limited by memory.

> >To experiment with pi as an input to PDQ2, you can use

> >PI64 to put pi on the stack in string form, accurate to

> >64 decimal places. Therefore, when using PI64 with PDQ2,

> >do not specify a tolerance greater than 64, or trailing

> >zeros will be assumed as significant digits, diverging

> >away from pi.

>

> You don't really mean to say that adding trailing zeroes to

> a 64 decimal approximation to Pi will cause its value to

> diverge (further than it already is) from Pi? Won't the

> value of an N-digit approximation to Pi have exactly the

> same value if any number of trailing zeroes are added,

> rather than "diverging away from Pi" as zeroes are added?

It diverges in the sense that it becomes more and more laden

with spurious significant digits. It therefore diverges in

spuriousness, not in value.

> >Examples:

> >".123456789012345" $TOF --> '24691357802469/200000000000000'

> >which is *exactly* equal to .123456789012345, even though HP

> >calculators cannot directly verify that fact, since they are limited to

> >12-digit precision.

>

> I think you mean to say something else here, rather than

> an unqualified "...HP calculators cannot directly verify

> that fact...". It seems to me that the HP49 can, and it's

> an HP calculator, isn't it?

Yes but

24691357802469 ENTER 200000000000000 / ->

.123456789012 not .123456789012345

And, the "directly" qualifies the statement just fine.

--

Tony Hutchins

Oct 8, 2004, 3:14:35 AM10/8/04

to

-=[ Fri, 8.10.04 7:56 p.m. +1300 (NZDT) ]=-

Hi Rodger Rosenbaum ! <nos...@aol.com>

02h40m ago, on Thu, 7.10.04 at 9:15 p.m. -0700, you wrote

in message ID <n44cm0tm86mq7ptqj...@4ax.com> :

[...]

> >You meant "equal" in the strictest mathematical sense. Joe's

> >PDQ1 was limited to calculator precision. His PDQ2 handles

> >unlimited precision,

>

> I think it's limited by the amount of memory which the

> HP49 has

Oops, yes, I forgot about memory.

--

Tony Hutchins

Oct 8, 2004, 5:00:22 AM10/8/04

to

I'm trying to get people to use proper mathematical terminology, since mathematics is

what we're talking about here. "Diverges" has a standard meaning, and if it isn't

qualified then it doesn't mean "diverges in spuriousness"; I've never heard of such a

thing. How would anybody have known that he didn't mean "diverges in value"? That's what

it means if you don't say otherwise. If he wants to convey to the reader that the extra

zeroes COULD be treated as (spurious) significant digits, he should say just that.

Furthermore, extra zeroes are not necessarily spurious. Remember that recent MC, "How

many got polled?" The first percentage was 47.61% and then he asked about 47.610%; the

zero in the second number was not spurious. Joe says above, "...trailing zeros will be

assumed as significant digits..."; if that's what the user wants, then those zeroes are

not spurious. Joe was not clear.

>

>> >Examples:

>> >".123456789012345" $TOF --> '24691357802469/200000000000000'

>> >which is *exactly* equal to .123456789012345, even though HP

>> >calculators cannot directly verify that fact, since they are limited to

>> >12-digit precision.

>>

>> I think you mean to say something else here, rather than

>> an unqualified "...HP calculators cannot directly verify

>> that fact...". It seems to me that the HP49 can, and it's

>> an HP calculator, isn't it?

>

>Yes but

>24691357802469 ENTER 200000000000000 / ->

>.123456789012 not .123456789012345

This is in approximate mode, right?

>

>And, the "directly" qualifies the statement just fine.

I disagree that it qualifies the statement "just fine". What did HE mean by the word

"directly"? Too bad he didn't tell us. If the presence or absence of the word "directly"

is that important in this sentence, then he should tell us what it means. Apparently,

with regard to the HP49, you are suggesting that it means "in approximate mode"; this is

the first time I've heard that.

And it isn't true for this example to say that "HP calculators cannot directly verify that

fact" if that's what is meant by "directly". Any Saturn based HP calculator can use my

DIGI24 package from Goodies Disk 9 (or its algorithms) to verify this example and any

others up to 24 digits, and is therefore not limited to 12-digit precision as Joe asserts

above. And in fact, Dekker's method can be extended to any multiple of the calculator's

basic floating point precision. So if "directly" means "in approximate mode", then that's

what the pre-HP49 Saturn based calcs do, and the DIGI24 package can "directly" verify the

example above. If "directly" means something else, how would I know if Joe doesn't tell

me?

Maybe he meant that if you type 24691357802469 200000000000000 and press the divide key

(or execute some other single built-in function) on the HP49 in approximate mode (or a

pre-49 Saturn based machine), then you won't get the 15 digit result. Of course, you

can't even put the 14-digit numerator on the stack of an HP49 in approximate mode (or a

pre-49 Saturn based machine). With this I would have to agree, and he should say that

this is what he means if he does. (You could use extended precision system RPL functions

I suppose, and verify with a single extended precision divide.)

But I would point out that if (in exact mode) you type the numerator on an HP49 with 15

more zeroes after it, hit enter and then type the denominator followed by IDIV2, you get

123456789012345--that's pretty "direct" verification, so it could be said that the HP49

can "directly" verify this example. This is possible because HP49 calculators are NOT

(unqualifiedly) "...limited to 12-digit precision." If they were, his PDQ2 program

wouldn't work the way it does. Had Joe said "...HP calculators...are limited to 12-digit

precision (including the HP49 in approximate mode) in their four basic arithmetic

functions.", that would have been a true, qualified, statement with which I could not

disagree.

Oct 8, 2004, 6:36:03 AM10/8/04

to

-=[ Fri, 8.10.04 10:31 p.m. +1300 (NZDT) ]=-

Hi Rodger Rosenbaum ! <nos...@aol.com>

31m ago, on Fri, 8.10.04 at 02:00 a.m. -0700, you wrote

in message ID <volcm0ltfn6gnvr9c...@4ax.com> :

> >> >To experiment with pi as an input to PDQ2, you can use

> >> >PI64 to put pi on the stack in string form, accurate to

> >> >64 decimal places. Therefore, when using PI64 with PDQ2,

> >> >do not specify a tolerance greater than 64, or trailing

> >> >zeros will be assumed as significant digits, diverging

> >> >away from pi.

Let me interject and ask for the last sentence to be re-read.

It is quite clear what is meant if the last phrase, which

merely qualifies "trailing zeros", is removed.

> >> You don't really mean to say that adding trailing zeroes to

> >> a 64 decimal approximation to Pi will cause its value to

> >> diverge (further than it already is) from Pi? Won't the

> >> value of an N-digit approximation to Pi have exactly the

> >> same value if any number of trailing zeroes are added,

> >> rather than "diverging away from Pi" as zeroes are added?

> >

> >It diverges in the sense that it becomes more and more laden

> >with spurious significant digits. It therefore diverges in

> >spuriousness, not in value.

>

> I'm trying to get people to use proper mathematical

> terminology, since mathematics is what we're talking about

> here. "Diverges" has a standard meaning, and if it isn't

> qualified then it doesn't mean "diverges in spuriousness";

> I've never heard of such a thing.

I made it up. How can those "trailing zeros" diverge in any

other way?

> How would anybody have known that he didn't mean "diverges

> in value"?

By reading the sentence which is quite specific.

> That's what it means if you don't say otherwise. If he

> wants to convey to the reader that the extra zeroes COULD

> be treated as (spurious) significant digits, he should say

> just that.

But that is exactly what the sentence addresses. The last

phrase is almost redundant.

> Furthermore, extra zeroes are not necessarily spurious.

Sure, but Joe was not adressing the whole universe of

possibilities.

> Remember that recent MC, "How many got polled?" The first

> percentage was 47.61% and then he asked about 47.610%;

> the zero in the second number was not spurious. Joe says

> above, "...trailing zeros will be assumed as significant

> digits..."; if that's what the user wants, then those zeroes

> are not spurious. Joe was not clear.

Consider it without the last phrase:

> >> >Therefore, when using PI64 with PDQ2,

> >> >do not specify a tolerance greater than 64, or trailing

> >> >zeros will be assumed as significant digits.

Seems very clear to me. Maybe the "diverging away from pi"

could be left off, unless we can allow ourselves to endow

"diverge" with a merely English meaning. We are not even

talking about a series so "diverge" doesn't have a

mathematical meaning anyway.

> >> >Examples:

> >> >".123456789012345" $TOF --> '24691357802469/200000000000000'

> >> >which is *exactly* equal to .123456789012345, even though HP

> >> >calculators cannot directly verify that fact, since they are limited to

> >> >12-digit precision.

> >>

> >> I think you mean to say something else here, rather than

> >> an unqualified "...HP calculators cannot directly verify

> >> that fact...". It seems to me that the HP49 can, and it's

> >> an HP calculator, isn't it?

> >

> >Yes but

> >24691357802469 ENTER 200000000000000 / ->

> >.123456789012 not .123456789012345

>

> This is in approximate mode, right?

Exact actually - I pressed ->NUM as well.

It seems a direct way - i.e. copy the example given directly??

> >> > '24691357802469/200000000000000' which is *exactly*

> >> > equal to .123456789012345, even though HP calculators

> >> > cannot directly verify that fact

> >

> >And, the "directly" qualifies the statement just fine.

>

> I disagree that it qualifies the statement "just fine".

I consider it meaningful in the context in which it is used.

> What did HE mean by the word

The connotation is surely just "execute the expression as given

by pressing a few keys and get the answer as quickly as

possible" - in particular use the divide key as shown in the

example.

[some snippage - ]

> But I would point out that if (in exact mode) you type

> the numerator on an HP49 with 15 more zeroes after it, hit

> enter and then type the denominator followed by IDIV2, you

> get 123456789012345--that's pretty "direct" verification,

> so it could be said that the HP49 can "directly" verify

> this example.

Pretty direct indeed ;-) Exactly what PDQ2 does.

> This is possible because HP49 calculators

> are NOT (unqualifiedly) "...limited to 12-digit precision."

> If they were, his PDQ2 program wouldn't work the way it does.

> Had Joe said "...HP calculators...are limited to 12-digit

> precision (including the HP49 in approximate mode) in their

> four basic arithmetic functions.", that would have been a

> true, qualified, statement with which I could not disagree.

Thanks Roger! Nor would I. Some HP calculators also have less

precision.

--

Tony Hutchins

Oct 8, 2004, 1:05:30 PM10/8/04

to

>>or trailing zeros will be assumed as significant digits, diverging away

>>from pi.

>>from pi.

the only possible 'divergence', would be caused by the last digit due to

rounding, truncation etc. Though this could cause more errors in later

operations..

>We are not even talking about a series so "diverge" doesn't have a

mathematical meaning anyway.

An integral isn't a series, well maybe only the indefinite in the limit.

Neither is a function necessarily.

>>>'''''''''parts per septillion (US) or per quadrillion (UK)?

Talking about mathmatical language.

Daveh

"Tony Hutchins" <jus...@csi.com> wrote in message

news:1154688...@news.individual.net...

Oct 8, 2004, 1:55:34 PM10/8/04

to

"Rodger Rosenbaum" <nos...@aol.com> wrote in message

news:volcm0ltfn6gnvr9c...@4ax.com...

X

> And it isn't true for this example to say that "HP calculators cannot

> directly verify that

> fact" if that's what is meant by "directly". Any Saturn based HP

> calculator can use my

> DIGI24 package from Goodies Disk 9 (or its algorithms) to verify this

> example and any

> others up to 24 digits, and is therefore not limited to 12-digit precision

> as Joe asserts

> above. And in fact, Dekker's method can be extended to any multiple of

> the calculator's

> basic floating point precision. So if "directly" means "in approximate

> mode", then that's

> what the pre-HP49 Saturn based calcs do, and the DIGI24 package can

> "directly" verify the

> example above. If "directly" means something else, how would I know if

> Joe doesn't tell

> me?

X

I have use vectors with 6 significant numbers on one element

(at the most) for extended precision multiplication and addition

The routines were an adaption from the routines from

Jean-Michel Frerrard's book "Mastering Your HP-48 Volume 2:

Programming and Applications (Large Integers, pages 205)

[VPN]

news:volcm0ltfn6gnvr9c...@4ax.com...

X

> And it isn't true for this example to say that "HP calculators cannot

> directly verify that

> fact" if that's what is meant by "directly". Any Saturn based HP

> calculator can use my

> DIGI24 package from Goodies Disk 9 (or its algorithms) to verify this

> example and any

> others up to 24 digits, and is therefore not limited to 12-digit precision

> as Joe asserts

> above. And in fact, Dekker's method can be extended to any multiple of

> the calculator's

> basic floating point precision. So if "directly" means "in approximate

> mode", then that's

> what the pre-HP49 Saturn based calcs do, and the DIGI24 package can

> "directly" verify the

> example above. If "directly" means something else, how would I know if

> Joe doesn't tell

> me?

I have use vectors with 6 significant numbers on one element

(at the most) for extended precision multiplication and addition

The routines were an adaption from the routines from

Jean-Michel Frerrard's book "Mastering Your HP-48 Volume 2:

Programming and Applications (Large Integers, pages 205)

[VPN]

Oct 8, 2004, 2:21:08 PM10/8/04

to

-=[ Sat, 9.10.04 06:45 a.m. +1300 (NZDT) ]=-

Hi Daveh ! <da...@worldonline.dk>

40m ago, on Fri, 8.10.04 at 7:05 p.m. +0200, you wrote

in message ID <GMz9d.56596$Vf.26...@news000.worldonline.dk> :

> >>or trailing zeros will be assumed as significant digits, diverging away

> >>from pi.

>

> the only possible 'divergence', would be caused by the last digit due to

> rounding, truncation etc. Though this could cause more errors in later

> operations..

>

> >We are not even talking about a series so "diverge" doesn't have a

> mathematical meaning anyway.

>

> An integral isn't a series, well maybe only the indefinite in the limit.

> Neither is a function necessarily.

Point taken. I have almost turned into a troll<G>. The series

is the number of 'trailing zeros assumed as significant

digits' in: [PI64]0, [PI64]00, [PI64]000 etc., i.e. 1,2,3

etc. But, I diverge again...

- Tony

Oct 9, 2004, 3:11:11 AM10/9/04

to

Veky wrote:

> I want my 31bucks. :-]

You certainly earned it, since (a) you answered the challenge

precisely, and (b) in doing so you taught me something that I was dying

to know! THANK YOU!

Just email me your snail-mail address and the $31.01 is yours.

Do you (or any other readers here) know how Mathematica's "Rationalize"

function zeros in on intermediate convergents? It astounds me that it

does it at all, let alone so quickly.

Rodger: To avoid the confusion caused by my documentation's manifest

vagaries, I'm seriously thinking of replacing the ENTIRE documentation

for PDQ2 with this single line from Mathematica's help screen:

"Rationalize[x, dx] yields the rational number with the smallest

denominator that lies within dx of x." That's exactly what PDQ2 does.

Any further "explanation" might be counterproductive.

-Joe-

"A picture is worth a thousand words, and has a higher baud rate."

Oct 9, 2004, 9:13:34 AM10/9/04

to

Joe Horn wrote:

> (a) What is the simplest fraction

> (smallest possible numerator and denominator)

Do you mean just "smallest possible denominator"?

Did you get your patent yet?

http://groups.google.com/groups?selm=87233f9e.0310260306.6280c493%40posting.google.com

Interesting historical debate:

NEW2Q.TXT vs. DEC2FRAC on HP48 Goodies Disk #3

http://www.hpcalc.org/search.php?query=new2q

http://www.hpcalc.org/details.php?id=234

http://www.hpcalc.org/hp48/compilations/horn/horn3.zip

Want to see some remarkable "Mathematical Snapshots"?

Go here and keep clicking "next page":

http://www.amazon.com/gp/reader/0486409147/ref=sib_rdr_fm/002-0219654-3656047#reader-page

About the author (quoted from source below):

[Hugo] Steinhaus is best known for his book Mathematical Snapshots written in 1937.

Kac, writing in [7] says:-

... to understand and appreciate Steinhaus's mathematical style,

one must read (or rather look at) snapshots. ... designed to appeal

to "the scientist in the child and the child in the scientist" ...

it expresses, not always explicitly and at times even unconsciously,

what Steinhaus thought mathematics is and should be. To Steinhaus

mathematics was a mirror of reality and life much in the same way

as poetry is a mirror, and he liked to "play" with numbers, sets,

and curves, the way a poet plays with words, phrases, and sounds.

http://www-gap.dcs.st-and.ac.uk/~history/Mathematicians/Steinhaus.html

"A mathematician, like a painter or a poet, is a maker of patterns.

If his patterns are more permanent than theirs,

it is because they are made with ideas.

The mathematician's patterns, like the painter's or the poet's,

must be beautiful; the ideas, like the colours or the words,

must fit together in a harmonious way. Beauty is the first test."

- G. H. Hardy, A Mathematician's Apology

With best wishes from http://www.mum.edu

Oct 10, 2004, 12:33:50 AM10/10/04

to

-=[ Sun, 10.10.04 5:20 p.m. +1300 (NZDT) ]=-

Hi Joe Horn ! <joe...@holyjoe.net>

21h09m ago, on Sat, 9.10.04 at 00:11 a.m. -0700, you wrote

in message ID <1097305871.2...@z14g2000cwz.googlegroups.com> :

> Do you (or any other readers here) know how Mathematica's

> "Rationalize" function zeros in on intermediate

> convergents? It astounds me that it does it at all, let

> alone so quickly.

This code by David Eppstein from Aug 1993:

http://www.ics.uci.edu/~eppstein/numth/frap.c

was posted on sci.math by him in March 1995 and he states

there that "similar routines are built into Mathmatica ..."

He's moving in a similar direction to you, and looks at some

intermediate convergents.

Enjoy :)

--

Tony Hutchins

Oct 10, 2004, 5:35:12 AM10/10/04

to

> in fact an Idiot Savant friend of mine wants to know

> what is the "simplest fraction" equal to Pi +/- 13131

> parts in 10^440 and he wants to know how long it takes

> PDQ2 to find it. It took him less than a second! Way less!

> what is the "simplest fraction" equal to Pi +/- 13131

> parts in 10^440 and he wants to know how long it takes

> PDQ2 to find it. It took him less than a second! Way less!

Hey, that's an excellent example of an intermediate convergent (using

10389, close to half of the partial quotient 20776). Is your friend's

name "Mathematica"? If so, you're right; he finds the answer to be the

following (broken into groups to keep Google from choking to death):

1975891706368 5406240845438 0413327813798 8557337219023 6919811855516

7226743047306 6290670359362 0215835931889 2308274160360 1397933071609

0096564056017 1119521293561 5317285063233 0284830147063 7551101789451

7380003505989 8203820427519

/

62894586416 56661036380 99443296751 77193853240 54623832389 70103364398

48926113959 96646403296 10522734293 18178568324 25836690143 45452239256

64431830927 38965162183 77776034085 40500659700 57153850182 98465893270

92348744070 13579584688

as fast as I could press the Enter key.

PDQ2, written in UBASIC, also gets the same result in no measurable

time. And it says that the diff/tolerance is

0.999987905955071639255847132....

I do not know how long the 49g+ would take, running the posted User RPL

program. Probably several minutes!

>> The inputs and outputs can be of any desired length...

>

> I don't think you really meant to say that.

> Can they be 10^20 digits long? Looks like imprecise speaking to me.

"I do not, my dear Sir, conceive you to be of that sophistical,

captious spirit, or of that uncandid dullness, as to require, for every

general observation or sentiment, an explicit detail of the correctives

and exceptions which reason will presume to be included in all the

general propositions which come from reasonable men." -- Edmund Burke,

1790.

Please also note that Mathematica's documentation even uses the same

"imprecise speaking" as I did. It says, "Mathematica can handle

approximate real numbers with any number of digits" and

"Arbitrary-precision numbers can contain any number of digits". See

both of these general propositions here:

http://documents.wolfram.com/v5/TheMathematicaBook/AdvancedMathematicsInMathematica/Numbers/3.1.4.html

-Joe-

Oct 10, 2004, 5:49:28 AM10/10/04

to

Tony Hutchins wrote:

> http://www.ics.uci.edu/~eppstein/numth/frap.c

>

> was posted on sci.math by him in March 1995 and he states

> there that "similar routines are built into Mathmatica ..."

>

> He's moving in a similar direction to you...

Thanks, but please note that his program requires a *maximum

denominator* (not a tolerance), and uses exactly the same logic as

does my 'DEC2FRAC' program on Goodies Disk #3 (21 March 1991). That's

a simpler task than working towards a given tolerance, which is what

both PDQ2 and Mathematica's "Rationalize" do.

-Joe-

Oct 10, 2004, 6:07:31 AM10/10/04

to

John H Meyers wrote:

> Joe Horn wrote:

>

> > (a) What is the simplest fraction

> > (smallest possible numerator and denominator)

>

> Do you mean just "smallest possible denominator"?

Yes. Gosper uses the term "simplest" in that sense, so I've adopted

it too. "Smallest possible numerator and denominator" is how I think

of it, but "smallest possible denominator" (or numerator) is

equivalent.

> Did you get your patent yet?

I suspect that my name will be somewhere on the patent (if one is

obtained), but I'm no longer in control of that aspect of PDQ, nor am

I at liberty to discuss the details. If Mathematica's "Rationalize"

function essentially uses the PDQ algorithm, then Wolfram has

"pre-existing art" that reduces all my work to a mere reinvention of

the patently obvious. :-(

-Joe-

Oct 10, 2004, 6:32:58 AM10/10/04

to

-=[ Sun, 10.10.04 11:18 p.m. +1300 (NZDT) ]=-

Hi Joe Horn ! <joe...@holyjoe.net>

3 days 19m ago, on Thu, 7.10.04 at 02:58 a.m. -0700, you wrote

in message ID <1097143089....@z14g2000cwz.googlegroups.com> :

> FRAC?

> @ Input: obj

> @ Output: obj, 0/1 (1 if obj is 'integer/integer', else 0)

> \<<

> IF DUP TYPE 9. -

> THEN 0.

> ELSE DUP \->LST DUP 1.

I assume that \->LST should be \->LIST

Otherwise an algebraic input results in '->LST' on the stack

and DOSUBS has a problem.

But here a \->LIST doesn't work either because the stack

doesn't have a dimension in level 1.

I'm trying it on a 49g after direct transfer from your

message.

> \<< TYPE

> \>> DOSUBS R\->I { 28 28 18 } SAME SWAP DUP SIZE GET

> { / } 1. GET SAME AND

> END

> \>>

> END

>

--

Tony Hutchins

Wellington

New Zealand

#16 Beginnings and endings are truly artificial constructs.

Oct 10, 2004, 10:48:40 AM10/10/04

to

I doubt he was criticizing mathematical exposition.

>

>Please also note that Mathematica's documentation even uses the same

>"imprecise speaking" as I did.

"An offense may be common yet remain an offense"; Cromwell to Thomas More in "A Man For

All Seasons"

You should strive to do better than Wolfram, and not try to justify your own

shortcomings by pointing to the shortcomings of others.

Let's see how HP did it in the not too distant past. On page 82 of the HP71 Math Pac

owners manual, bottom of the page: "...solve any number of different systems, limited

only by memory...". Or page 134, bottom of the page: "The number of data points you can

use is limited only by the amount of available memory...". Maybe you've been infected by

the increasing use of hyperbole that seems common in the 21st century.

It says, "Mathematica can handle

>approximate real numbers with any number of digits" and

>"Arbitrary-precision numbers can contain any number of digits".

As you acknowledge above, this is "imprecise speaking". At least one person at

Wolfram knows the truth of it. In section 1.4.9 of the Book, you will find: "You should

have no trouble working out Expand[(1+x)^100] on any computer that can run Mathematica.

But as you increase the exponent of (1+x), the results you get will eventually become to

big for your computer's memory to hold."

Oct 10, 2004, 3:22:08 PM10/10/04

to

-=[ Mon, 11.10.04 08:03 a.m. +1300 (NZDT) ]=-

Hi Tony Hutchins ! <jus...@csi.com>

08h30m ago, on Sun, 10.10.04 at 11:32 p.m. +1300 (NZDT), you wrote

in message ID <1154352...@news.individual.net> :

> > ELSE DUP \->LST DUP 1.

>

> I assume that \->LST should be \->LIST

This seems to work instead of the \->LST:

OBJ\-> SWAP 1 + \->LIST

--

Tony Hutchins

Oct 10, 2004, 7:23:08 PM10/10/04

to

-=[ Mon, 11.10.04 11:17 a.m. +1300 (NZDT) ]=-

Hi Joe Horn ! <joe...@holyjoe.net>

12h42m ago, on Sun, 10.10.04 at 02:35 a.m. -0700, you wrote

in message ID <1097400912....@z14g2000cwz.googlegroups.com> :

> PDQ2, written in UBASIC, also gets the same result in no

> measurable time. And it says that the diff/tolerance is

> 0.999987905955071639255847132....

Ahha we see a memory limitation at last ;-) No no no, I see

you mean the error(diff) is 0.9999879.. times the precision

(tolernace) of 13131 E-440.

> I do not know how long the 49g+ would take, running the posted User RPL

> program. Probably several minutes!

Yup about 10 or so. It gives the same result you quoted for

the rational approximation, but unfortunately the numerator

and denominator in the error both exceed E500 so direct

floating point division gives 1. But, just using the first few

significant digits, and roughly measuring the lengths as 796

(numerator) and 1232 (denominator) - based on PC file-lengths

of the integers as strings - the difference is 436, I can see

the error is just under 13131 E-440 ;-) Probably something

like 1.313084 E-436. Ahha, yes it agrees with your UBASIC

result.

Pretty impressive! It took about 30-40 mins on the 49g. Then I

finally got the new connx working again and tried on the g+.

On win2K I had all sorts of problems installing the 30 March

2004 connx from HP's site - it kept asking for the CD to get

the driver - refused to use the new drivers - I read

all the readme's. In the end I just fed it the CD and used the

old driver, which it thought was "more recent".

I used [PI1000] instead of [PI64] ;-)

--

Tony Hutchins

Oct 11, 2004, 12:14:07 AM10/11/04

to

-=[ Mon, 11.10.04 5:03 p.m. +1300 (NZDT) ]=-

Hi Tony Hutchins ! <jus...@csi.com>

04h40m ago, on Mon, 11.10.04 at 12:23 p.m. +1300 (NZDT), you wrote

in message ID <1081179...@news.individual.net> :

> I can see the error is just under 13131 E-440 ;-) Probably

> something like 1.313084 E-436. Ahha, yes it agrees with

> your UBASIC result.

Ahha, I see the 49g can do this. BIGDIV below gives: -436 and

1.31308411931. But I'm sure it can be done better than

this<G>.

%%HP: T(3)F(.);

@ BIGDIV: Handy for evaluating error from PDQ2

@ where N or D exceeds E500.

@ Input: 'N/D'

@ Output: E,M (Exponent-like,Mantissa-like)

@ Where Evaluated error=M*10^E

\<<

OBJ\-> DROP2 DUP2

SWAP SIZE SWAP SIZE -

UNROT

SWAP \->STR 1 499 SUB STR\-> I\->R

SWAP \->STR 1 499 SUB STR\-> I\->R

/

\>>

--

Tony Hutchins

Wellington

New Zealand

#347 "Facts are a special form of fantasy." - Michael Lukas Moeller

Oct 11, 2004, 12:33:43 PM10/11/04

to

Tony Hutchins wrote:

> > FRAC?

> > ...

> > ELSE DUP \->LST DUP 1.

>

> I assume that \->LST should be \->LIST

->LST is a command in library 256. It can convert an algebraic object

directly into list form. If you don't have 256 ATTACH in your

'STARTUP' program, you'll have to manually type 256 ATTACH before

keying in that program. Sorry; I am so used to having library 256

available that I forgot to mention the need for it here.

-Joe-

Oct 11, 2004, 4:08:51 PM10/11/04

to

-=[ Tue, 12.10.04 08:35 a.m. +1300 (NZDT) ]=-

Hi Joseph K. Horn ! <joe...@holyjoe.net>

03h01m ago, on Mon, 11.10.04 at 09:33 a.m. -0700, you wrote

in message ID <87233f9e.04101...@posting.google.com> :

> Tony Hutchins wrote:

[...]

> > I assume that \->LST should be \->LIST

>

> ->LST is a command in library 256.

Thanks Joe! BTW your CF~I2 gets the 432 items in the CF for

that PI rational approximation with tolerance 13131 E-440 in

20 seconds. I wish I had Mathematica here - I'd try to find

an example where it produces a different result to PDQ2.

--

Tony Hutchins

Oct 11, 2004, 6:22:27 PM10/11/04

to

Why would you expect to find such an example? As long as the 49 doesn't run out of

memory, I would expect PDQ2 to work properly. Joe is a good programmer, even if his

documentation is some what enthusiastic.

FYI, these interesting tests of PDQ2 occur where the partial quotients of the CF of PI

are big. After the one at 432 terms (the PQ is 20776 there), the next four in the

expansion of Pi are:

Partial Quotient Location

78629 28422

179136 156382

528210 267314

12996958 453294

It's beginning to take even Mathematica a while (minutes) to find these.

Oct 11, 2004, 8:45:28 PM10/11/04

to

-=[ Tue, 12.10.04 1:06 p.m. +1300 (NZDT) ]=-

Hi Rodger Rosenbaum ! <nos...@aol.com>

01h44m ago, on Mon, 11.10.04 at 3:22 p.m. -0700, you wrote

in message ID <l81mm0tsbjatc6smd...@4ax.com> :

> >> ->LST is a command in library 256.

> >

> >Thanks Joe! BTW your CF~I2 gets the 432 items in the CF for

> >that PI rational approximation with tolerance 13131 E-440 in

> >20 seconds. I wish I had Mathematica here - I'd try to find

> >an example where it produces a different result to PDQ2.

>

> Why would you expect to find such an example?

Did I say that?<G>. It would indeed be surprising to find one.

> As long as the 49 doesn't run out of memory, I would expect

> PDQ2 to work properly. Joe is a good programmer, even if

> his documentation is some what enthusiastic.

Yes, I'm sure PDQ2 works as I can see the algorithm in source

code. And we have documentation ;-). The Mathematica algorithm

for Rationalize[x,dx] does not seem to be published on the net.

AFAIK the only reason we have for thinking it is the same as

Joe's is its surprising speed.

> FYI, these interesting tests of PDQ2 occur where the partial quotients of the CF of PI

> are big. After the one at 432 terms (the PQ is 20776 there), the next four in the

> expansion of Pi are:

>

> Partial Quotient Location

>

> 78629 28422

> 179136 156382

> 528210 267314

> 12996958 453294

>

> It's beginning to take even Mathematica a while (minutes)

> to find these.

Thanks Roger - very interesting. That last one is 1000*

further out than the 432nd and may take 6 hours or so on the

49g+. Hmm I might see how far CF~I2 can get before we hit

the space-time limitations ;-) Oops I mean memory-battery_life

limitations.

Joe - all your documentation needs at the beginning is a

little poem about memory and battery-life limitations ;-)

Roger - I just twigged that you MUST be "The Phantom"!! It

could only be you ;-) LOL! Excellent example BTW - thanks.

Nice to see your "idiot savant" friend finally taking

measurable minutes to compute though - was he computing

Rationalize[x,dx] out near these peaks, or just doing the

prolonged CF?

--

Tony Hutchins

Oct 11, 2004, 10:04:06 PM10/11/04

to

On Tue, 12 Oct 2004 13:45:28 +1300 (NZDT), Tony Hutchins <jus...@csi.com> wrote:

> -=[ Tue, 12.10.04 1:06 p.m. +1300 (NZDT) ]=-

>

>Hi Rodger Rosenbaum ! <nos...@aol.com>

>

>01h44m ago, on Mon, 11.10.04 at 3:22 p.m. -0700, you wrote

>in message ID <l81mm0tsbjatc6smd...@4ax.com> :

>

>> >> ->LST is a command in library 256.

>> >

>> >Thanks Joe! BTW your CF~I2 gets the 432 items in the CF for

>> >that PI rational approximation with tolerance 13131 E-440 in

>> >20 seconds. I wish I had Mathematica here - I'd try to find

>> >an example where it produces a different result to PDQ2.

>>

>> Why would you expect to find such an example?

>

>Did I say that?

A few lines above you said: "I wish I had Mathematica here - I'd try to find

an example where it produces a different result to PDQ2."

Why would you bother if you didn't expect (at least a little bit) to find such an

example?

Maybe you're a little like me. When I got my first HP calculator (an HP 45) I used to go

through log tables and trig tables and pick a value at random to see if the HP got the

right result. I didn't really expect it to fail, but it just amazed me (at that time; I'm

spoiled now) to see all those digits match the numbers in the table. And this was in a

book of 7 place (!!!) tables; the HP got 10 digits!!! WOW!!

So I understand how much fun it is to see your HP do all this stuff almost as well as the

big boys. Joe would probably tell us that the Hurwitz accuracy of the HP calcs is

superior since you are getting so much more "bang" for the buck. The HP runs on penlight

batteries and can still do this kind of thing in a reasonable time.

I was looking at a paper in the IEEE Transactions on Circuit Theory from the 1950's where

the author (at Bell Labs) discussed the need to find the roots of a 12th degree polynomial

and separate the roots with positive real parts from those with negative real parts. She

said that one way would be to just find the roots and manually separate them, but she went

on to describe this really convoluted algorithm that she said gave better performance. I

typed in the coefficients on my HP48G and found the roots in 21 seconds, saved them to a

variable, OBJ-> on the stack, deleted the ones with positive real parts, saved them, did

it again to get the ones with negative real parts. This took about 30 seconds each. She

said her fancy algorithm took 80 (!) minutes on an IBM 650, and her results weren't as

accurate as mine! It's fun and good practice on your calc to see how fast and easy it is

to redo things like that from old journals; and I usually get better results.

Have you looked at my nearby "big numbers" MC? Another example where the HP exhibits

its astounding performance. But, as I said, I'm spoiled now and wouldn't expect anything

less.

Just a prolonged CF. I've been trying to find some irrational number that has a really

huge PQ after only a few terms, but I think it will be necessary to use come clever

artifice to get one.

The "best" one I found so far is 7^(1/5); it has a PQ of 55318 at position 125 in the

expansion.

Oct 11, 2004, 10:09:31 PM10/11/04

to

On Tue, 12 Oct 2004 13:45:28 +1300 (NZDT), Tony Hutchins <jus...@csi.com> wrote:

Snip...

>> >Thanks Joe! BTW your CF~I2 gets the 432 items in the CF for

>> >that PI rational approximation with tolerance 13131 E-440 in

>> >20 seconds. I wish I had Mathematica here - I'd try to find

>> >an example where it produces a different result to PDQ2.

I know why you want to do that!! You want to find a bug so you can fix it!! :=)

Oct 12, 2004, 5:21:43 AM10/12/04

to

-=[ Tue, 12.10.04 9:43 p.m. +1300 (NZDT) ]=-

Hi Rodger Rosenbaum ! <nos...@aol.com>

06h39m ago, on Mon, 11.10.04 at 7:04 p.m. -0700, you wrote

in message ID <mtcmm0p30iejlo6i1...@4ax.com> :

> A few lines above you said: "I wish I had Mathematica here

> - I'd try to find an example where it produces a different

> result to PDQ2."

>

> Why would you bother if you didn't expect (at least a little

> bit) to find such an example?

I think I was hoping that a difference in algorithms would

somehow show - maybe a case that took Mathematica 2 seconds

where it should take 1 :-)

> Maybe you're a little like me. When I got my first HP

> calculator (an HP 45) I used to go through log tables and

> trig tables and pick a value at random to see if the HP

> got the right result. I didn't really expect it to fail,

> but it just amazed me (at that time; I'm spoiled now)

> to see all those digits match the numbers in the table.

> And this was in a book of 7 place (!!!) tables; the HP got

> 10 digits!!! WOW!!

Indeed. My first HP was an HP 80. The financial tables were

then useful only to test the HP-80 ;-)

> So I understand how much fun it is to see your HP do all

> this stuff almost as well as the big boys.

And we didn't know till recently that Mathematica did the

Rationalize[x,dx].

> Joe would probably tell us that the Hurwitz accuracy of the

> HP calcs is superior since you are getting so much more

> "bang" for the buck. The HP runs on penlight batteries

> and can still do this kind of thing in a reasonable time.

That means the hp49g+ probably has the highest "HP" Hurwitz

Factor. It's quite interesting to find its limitations. I

tried a PI to 5000 digits this afternoon and naturally got a

"Insufficient Memory" message - when it had about 9000 CF

partial quotients in the stack. Also, using the 'PI5000'

really slows down that 13131 E-440 example - it took over an

hour to get the result that took just a few minutes using

'PI1000'.

[...]

> Have you looked at my nearby "big numbers" MC? Another

> example where the HP exhibits its astounding performance.

> But, as I said, I'm spoiled now and wouldn't expect

> anything less.

I will have a closer look.

> >measurable minutes to compute though - was he computing

> >Rationalize[x,dx] out near these peaks, or just doing the

> >prolonged CF?

>

> Just a prolonged CF. I've been trying to find some

> irrational number that has a really huge PQ after only a

> few terms, but I think it will be necessary to use come

> clever artifice to get one.

Very interesting challenge.

> The "best" one I found so far is 7^(1/5); it has a PQ of

> 55318 at position 125 in the expansion.

On the native 49g+ I only get to position 28 in the CF

expansion of that one.

--

Tony Hutchins

Oct 12, 2004, 6:42:06 AM10/12/04

to

Joe only had a PI64 function in PDQ2. What have you done to get a

PI1000 and PI5000? Did you compute it on the 49 itself, or get the

digits from another, bigger, computer and import into the 49?

>

>> Have you looked at my nearby "big numbers" MC? Another

>> example where the HP exhibits its astounding performance.

>> But, as I said, I'm spoiled now and wouldn't expect

>> anything less.

>

>I will have a closer look.

>

>> >measurable minutes to compute though - was he computing

>> >Rationalize[x,dx] out near these peaks, or just doing the

>> >prolonged CF?

>>

>> Just a prolonged CF. I've been trying to find some

>> irrational number that has a really huge PQ after only a

>> few terms, but I think it will be necessary to use come

>> clever artifice to get one.

>

>Very interesting challenge.

>

>> The "best" one I found so far is 7^(1/5); it has a PQ of

>> 55318 at position 125 in the expansion.

>

>On the native 49g+ I only get to position 28 in the CF

>expansion of that one.

What was the limiting factor? Why could you only get to position

28?

>

Oct 12, 2004, 12:44:50 PM10/12/04

to

-=[ Wed, 13.10.04 04:23 a.m. +1300 (NZDT) ]=-

Hi Rodger Rosenbaum ! <nos...@aol.com>

04h41m ago, on Tue, 12.10.04 at 05:42 a.m. -0500, you wrote

in message ID <15dnm0purih79nvf3...@4ax.com> :

[...]

> >Also, using the 'PI5000' really slows down that 13131

> >E-440 example - it took over an hour to get the result

> >that took just a few minutes using 'PI1000'. [...]

>

> Joe only had a PI64 function in PDQ2. What have you done

> to get a PI1000 and PI5000? Did you compute it on the 49

> itself, or get the digits from another, bigger, computer

> and import into the 49?

The latter. Thanks to Google ;-)

[...]

> >> The "best" one I found so far is 7^(1/5); it has a PQ of

> >> 55318 at position 125 in the expansion.

> >

> >On the native 49g+ I only get to position 28 in the CF

> >expansion of that one.

>

> What was the limiting factor? Why could you only get to

> position 28?

I started with the 12 digit 1.47577316159. Adding another 4

digits from the 200LX palmtop didn't help. I'd probably need at

least 100 digits to find the 55318.

--

Tony Hutchins

Oct 12, 2004, 1:27:10 PM10/12/04

to

Hi,

Rodger Rosenbaum <nos...@aol.com> wrote in message news:<15dnm0purih79nvf3...@4ax.com>...

> On Tue, 12 Oct 2004 22:21:43 +1300 (NZDT), Tony Hutchins

> <jus...@csi.com> wrote:

>

> > -=[ Tue, 12.10.04 9:43 p.m. +1300 (NZDT) ]=-

> >

> >Hi Rodger Rosenbaum ! <nos...@aol.com>

> >

> >06h39m ago, on Mon, 11.10.04 at 7:04 p.m. -0700, you wrote

> >in message ID <mtcmm0p30iejlo6i1...@4ax.com> :

> >

> >> A few lines above you said: "I wish I had Mathematica here

> >> - I'd try to find an example where it produces a different

> >> result to PDQ2."

> >>

Rodger Rosenbaum <nos...@aol.com> wrote in message news:<15dnm0purih79nvf3...@4ax.com>...

> On Tue, 12 Oct 2004 22:21:43 +1300 (NZDT), Tony Hutchins

> <jus...@csi.com> wrote:

>

> > -=[ Tue, 12.10.04 9:43 p.m. +1300 (NZDT) ]=-

> >

> >Hi Rodger Rosenbaum ! <nos...@aol.com>

> >

> >06h39m ago, on Mon, 11.10.04 at 7:04 p.m. -0700, you wrote

> >in message ID <mtcmm0p30iejlo6i1...@4ax.com> :

> >

> >> A few lines above you said: "I wish I had Mathematica here

> >> - I'd try to find an example where it produces a different

> >> result to PDQ2."

> >>

> Joe only had a PI64 function in PDQ2. What have you done to get a

> PI1000 and PI5000? Did you compute it on the 49 itself, or get the

> digits from another, bigger, computer and import into the 49?

> PI1000 and PI5000? Did you compute it on the 49 itself, or get the

> digits from another, bigger, computer and import into the 49?

Sorry to pop in, hope this is relevant:

Just for information: my longfloat library at hpcalc.org has functions

for PI to arbitrary length and conversion between floating / simple

fraction / continuous fraction representation. Could be handy when

doing this kind of calculations.

Best regards

Gjermund Skailand

PS Try continuous fraction expansion of this fraction ( 1.3 sec on

hp49g+ with longfloat lib):

1829151464613551845229766684240085457977114066958132611028137640130366249249264703822076231310349502716995004329909838833967799149726538729584636544830491123626011712281251039707242014594449383181594119455905756335372184341285442894833577777675820454061486809900044466151484538203903862528738851534878481429062476876438743657726379178432129015903949079323534884585879968894630898002489789447203843435

000

/

1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Continuous fraction expansion:

{ 1829 6 1 1 1 1 17 1 1 3 2 2 3 7 1 7 1 428 1 1 3 52 1 5 1 4 1 2 1 1 2

4 3 3 8 1 1 2 1 2 7 5 1 17 2 5 2 3 4 8 2 5 1 13 35 5 1 2 2 1 102 1 1 3

2 1 6 1174432375356999418156906759746231648661456610679530520916425437057426881793642718189281666359914553831730104240207954136420939696280455479951978198341209475388354716281725861581739201751862049650448139929231944021896869379111614535260523870011376825005238855165204139267124381959584353592123424607279088687963807804342933494

1 1 2 1 1 3 41 1 5 1 1 3 1 1 1 13 1 1 1 1 1 1 2 10 2 2 1 2 2 1 2 1 9 4

1 1 1 8 1 6 2 1 13 315 2 2 2 2 2 4 323 28 2 12 5 1 1 1 3 2 2 2 2 2 3

15 1 5 207 2 }

Oct 12, 2004, 6:43:30 PM10/12/04

to

-=[ Wed, 13.10.04 11:11 a.m. +1300 (NZDT) ]=-

Hi Gjermund Skailand ! <gjermund...@yahoo.no>

04h43m ago, on Tue, 12.10.04 at 10:27 a.m. -0700, you wrote

in message ID <dcb26c93.04101...@posting.google.com> :

> > Joe only had a PI64 function in PDQ2. What have you done to get a

> > PI1000 and PI5000? Did you compute it on the 49 itself, or get the

> > digits from another, bigger, computer and import into the 49?

>

> Sorry to pop in, hope this is relevant:

It is, it is! :)

I downloaded your library a few minutes ago.

> Just for information: my longfloat library at hpcalc.org

> has functions for PI to arbitrary length and conversion

> between floating / simple fraction / continuous fraction

> representation. Could be handy when doing this kind of

> calculations.

Thanks Gjermund! I just tried Roger's 7^(1/5) with DIGITS=200

(took under a minute) in your library and then [Fl->SF]

[SF->CF] and can see Roger's 55318 at position 125. What fun!

Mirabile dictu!

Next I will experiment with the [FPI] to a few thousand digits

to test the limits of what is possible on the 49g+. I will

work back from DIGITS=5000, where I got "positive underflow"

after a few minutes :) No chance to find Roger's PQ of 78629

at position 28422.

> Best regards

> Gjermund Skailand

> PS Try continuous fraction expansion of this fraction ( 1.3 sec on

> hp49g+ with longfloat lib):

Amazing. I see a big partial quotient early in the list. What

is the origin of the number input? Is it irrational?

BTW minor thing - CF= "continued", rather than

"continuous", fraction. It's in the longfloatv31b.doc a couple

of times near the end. I tried to go to www.praxelius.de as

mentioned on page 1 of the .doc but alas it was not

contactable.

Cheers - I look forward to your matrix enhancement in

longfloat.

--

Tony Hutchins

Oct 13, 2004, 6:49:30 AM10/13/04

to

"Tony Hutchins" <jus...@csi.com> wrote in message

news:1076850...@news.individual.net...X

> Cheers - I look forward to your matrix enhancement in

> longfloat.

When a matrix is ill-conditioned in such a way

that the elements have exponents range exeeding

even the internal 15 digit accuracy, it's nice to have

1000 digits of floating point range to (possibly) overcome

this lost accuracy during matrix inversions, etc...

Are you going to use

A) the "old" symbolic matrices (internally as a list)

B) a new type of SymMat with slighly different prolog

C) just use lists and let people set the proper flag (-91)

in order to use the Matrix Writer for input

[VPN]

hpgcc 4 ever

Oct 13, 2004, 9:32:42 PM10/13/04

to

I got one more after an all night run:

878783625 11504931

Oct 13, 2004, 9:53:27 PM10/13/04

to

Rodger Rosenbaum writes:

> I've been trying to find some irrational number

> that has a really huge PQ after only a few terms,

> but I think it will be necessary to use come clever

> artifice to get one.

A decidedly UNclever technique is a web search, but it reveals some

goodies, such as these (all on the first page of an AltaVista search

on "partial quotients" and "pi"):

(A) (1-euler)^2 has 372792 as term 8 (if the leading term, the integer

part, is called "term zero"). "euler" is Euler's constant, approx.

0.5772156649.

(B) pi^4 which has 16539 as term 5 (if the leading term is considered

"term zero").

(C) "The number known to recreational mathematicians as Champernowne

Constant has a decimal expansion consisting of the successive digits

of all the integers: 0.123456789101112131415161718192021... It has a

weird continued fraction expansion, which is fairly delicate to

obtain:

[0; 8, 9, 1, 149083, 1, 1, 1, 4, 1, 1, 1, 3, 4, 1, 1, 1, 15, A18, 6,

1, 1, 21, 1 ...]

A18 is a 166 digit integer!"

(D) "The real root of x3 -3600 x2 +120 x -2 :

x = [3599; 1, 28, 1, 7198, 1, 29, 388787400, 23, 1, 8998, 1, 13,

1, 10284, 1, 2, 25400776804, 1, 1, 3, 4, 93, 3, 1, 2, 11, 1, 9, 1, 99,

1, 3, 1, 3, 9, 1, 603118914 ...]"

(E) "the real zero of y3 - 8y - 10 (y = 3.31862821775...) :

y = [3; 3, 7, 4, 2, 30, 1, 8, 3, 1, 1, 1, 9, 2, 2, 1, 3, 22986, 2,

1, 32, 8, 2, 1, 8, 55, 1, 5, 2, 28, 1, 5, 1, 1501790, 1, 2, 1, 7, 6,

1, 1, 5, 2, 1, 6, 2, 2, 1, 2, 1, 1, 3, 1, 3, 1, 2, 4, 3, 1, 35657, 1,

17, 2, 15, 1, 1, 2, 1, 1, 5, 3, 2, 1, 1, 7, 2, 1, 7, 1, 3, 25, 49405,

1, 1, 3, 1, 1, 4, 1, 2, ...]"

-Joe-

Oct 13, 2004, 5:34:31 PM10/13/04

to

"Veli-Pekka Nousiainen" <DROP...@THIS.welho.com> wrote in message news:<ckj17q$3ck$1...@nyytiset.pp.htv.fi>...

the old arry type, so there are some restrictions. You have to see the

manual for that. This is simpler and a bit faster, but not really

supported by the OS. Thus it will always be a beta-version.

> Are you going to use

> A) the "old" symbolic matrices (internally as a list)

> B) a new type of SymMat with slighly different prolog

I have uploaded a version 3.5b to hpcalc.org today. The library uses> A) the "old" symbolic matrices (internally as a list)

> B) a new type of SymMat with slighly different prolog

the old arry type, so there are some restrictions. You have to see the

manual for that. This is simpler and a bit faster, but not really

supported by the OS. Thus it will always be a beta-version.

Tony: A nice manual is partly included in the new package. If you want

to calculate eg. 7^(1/5) use FXROOT it is much faster that FY^X which

uses logarithms, for 200 Digits the timing of FXROOT is about 3 sec.

Some constants like LN2, PI are kept in library data, to avoid

unnecesary recalculation. (Try FXROOT a second time).

Regarding "continued fractions", the prevously mentioned fraction is a

solution to a recent post, using both exact and longreal matrix

calculation, calculated with 400 Digits. Send me a mail if you're

interested in more details.

Best regards

Gjermund Skailand

PS Using the emu49 I was able to calculate PI at upper limit to 9999

digits with version 3.5.

Oct 13, 2004, 9:10:46 PM10/13/04

to

-=[ Thu, 14.10.04 1:26 p.m. +1300 (NZDT) ]=-

Hi Gjermund Skailand ! <gjermund...@yahoo.no>

02h52m ago, on Wed, 13.10.04 at 2:34 p.m. -0700, you wrote

in message ID <dcb26c93.04101...@posting.google.com> :

> Tony: A nice manual is partly included in the new package.

I'll look out for 3.5b on hpcalc - just checked - it'snot

there yet.

> If you want to calculate eg. 7^(1/5) use FXROOT it is much

> faster that FY^X which uses logarithms, for 200 Digits the

> timing of FXROOT is about 3 sec.

Great. Thanks!

> Some constants like LN2, PI are kept in library data, to

> avoid unnecesary recalculation. (Try FXROOT a second time).

I noticed :). Very nice feature.

> Regarding "continued fractions", the prevously mentioned

> fraction is a solution to a recent post, using both exact and

> longreal matrix calculation, calculated with 400 Digits. Send

> me a mail if you're interested in more details.

Ahha. Thanks

> PS Using the emu49 I was able to calculate PI at upper

> limit to 9999 digits with version 3.5.

Ahha that 9999 I keep coming across as an upper limit for some

operations. I look forward to trying that with v3.5 on my 49g+.

--

Tony Hutchins

Oct 19, 2004, 7:55:24 PM10/19/04

to

Hey, Rodger! I finally sat down and started to learn Mathematica!

(Ok, ok, so maybe I'm a little slow on the uptake. Better late than

never!)

(Ok, ok, so maybe I'm a little slow on the uptake. Better late than

never!)

There are an infinite number of ways of generating increasingly large

partial quotients, of course, but here's one that tickles me: the 3rd

partial quotient of the cosines of the increasingly "better" fractions

for pi. So easy to do in Mathematica! Out[2] below is the list of

numerators (of 3/1, 22/7, etc) and Out[3] is the list of the 3rd

partial quotients of their cosines.

In[1]:=

<< NumberTheory`ContinuedFractions`

In[2]:=

Numerator[Convergents[Pi, 25]]

Out[2]=

{3, 22, 333, 355, 103993, 104348, 208341, 312689, 833719, 1146408,

4272943, \

5419351, 80143857, 165707065, 245850922, 411557987, 1068966896,

2549491779, \

6167950454, 14885392687, 21053343141, 1783366216531, 3587785776203, \

5371151992734, 8958937768937}

In[3]:=

ContinuedFraction[Abs[Cos[%]], 3][[All, 3]]

Out[3]=

{98, 25526, 25701, 2200989908, 5465503977, 16483886140, 30375674292, \

237697464198, 373859991506, 5788958372881, 6621691598463,

1370542374992698, \

9164348719628591, 26700401132899689, 53432041505819839,

310803772468965157, \

1832746004640389165, 9989458647919860071, 89204641469760295779, \

91331082019550175280, 650545454929017880194800,

4117455774884563343654118, \

15476430462882332335591161, 17562023095942885732083182, \

4124798882403720305240845429}

The sines' 2nd PQ likewise increase without bound as the input

approaches a multiple of pi. Fun! Mathematica is so fast!!!

However, Mathematica's "Rationalize" function takes about 2.5 times

LONGER than my UBASIC program to perform PDQ2 on 2000-digit inputs.

Strange. Methinks they missed a fundamental shortcut somewhere.

-Joe-

Oct 20, 2004, 6:58:23 AM10/20/04

to

On 19 Oct 2004 16:55:24 -0700, joe...@holyjoe.net (Joseph K. Horn) wrote:

>Hey, Rodger! I finally sat down and started to learn Mathematica!

>(Ok, ok, so maybe I'm a little slow on the uptake. Better late than

>never!)

>

>There are an infinite number of ways of generating increasingly large

>partial quotients, of course, but here's one that tickles me: the 3rd

>partial quotient of the cosines of the increasingly "better" fractions

>for pi.

I'm puzzled; here you seem to be speaking of the convergents themselves--

So easy to do in Mathematica! Out[2] below is the list of

>numerators (of 3/1, 22/7, etc) and Out[3] is the list of the 3rd

>partial quotients of their cosines.

But here you are using the *numerators* of the convergents. If you do this same thing

with the convergents themselves rather than their numerators, the 3rd PQ gets bigger a lot

faster!

When I run Timing[Rationalize[Pi,10^-2000];]

It takes 3.46 seconds under Mathematica 4.1

but only .88 seconds under Mathematica 5.01

Later versions have significantly faster arbitrary precision arithmetic.

This is on my 600 MHz laptop Pentium III

>

>-Joe-

Oct 20, 2004, 9:19:52 AM10/20/04

to

joe...@holyjoe.net (Joseph K. Horn) wrote:

> However, Mathematica's "Rationalize" function takes about 2.5 times

> LONGER than my UBASIC program to perform PDQ2 on 2000-digit inputs.

> Strange. Methinks they missed a fundamental shortcut somewhere.

> LONGER than my UBASIC program to perform PDQ2 on 2000-digit inputs.

> Strange. Methinks they missed a fundamental shortcut somewhere.

Thanks for pointing this out. I haven't tried this yet, but I'll look

into it. Is the source for your UBASIC program available?

Cheers,

Bhuvanesh.

Oct 21, 2004, 2:47:22 PM10/21/04

to

Bhuvanesh wrote!

> Is the source for your UBASIC program available?

http://holyjoe.net/hp/pdq2.txt

Just rename it from .TXT to .UB and it'll load directly into UBASIC.

If you want to time huge inputs, be sure to comment out all but the final output.

-Joe-

Reply all

Reply to author

Forward

0 new messages