HP Forum Archive 13

[ Return to Index | Top of Index ]

performance of 48g vs 49g Message #1 Posted by Eric Lundgren on 10 Oct 2003, 6:07 p.m. Hi, In waiting for the 49g+, I ran some tests between my 49g and my new 48g. I ran them side by side calculating the volume of y=1/x revolved about the x-axis from 1 to 10,000. I'd have like to do it to infinity and get an answer of PI, but so far I don't see why the 48g won't like that. I keyed it in as an algebraic object: 'PI*Int(1,10000,(INV(SQ(x)),x)' and was amazed that the 48g finished 63 seconds faster than the 49g..?? I must have something 'flagged' on my 49g that causes the slow down.... Also, I have Chotkeh mechanical engineering software loaded, leftover from my pops PE exam...could its presence be contributing? I don't think it should, but.. Eric

Re: performance of 48g vs 49g Message #2 Posted by James M. Prange on 10 Oct 2003, 7:04 p.m., in response to message #1 by Eric Lundgren On the 49G, maybe try it in appoximate mode, or use a trailing decimal on the numbers. Regards, James

Re: performance of 48g vs 49g Message #3 Posted by Eric Lundgren on 10 Oct 2003, 8:08 p.m., in response to message #2 by James M. Prange Thanks, I just tried it again with Approximate on the 49g, but it still took 191 seconds (I may have miscounted a few on first run). I'd try the trailing decimal if I knew what you meant by that, you don't refer to 'float' as the same thing, do you? I think I remember trying something like this on the ti89 for fun, and that went quicker. Hahaa, looking at my 49g kbd, the enter key says 'ente ', as the 'r' is gone as well as the alpha c, d, e, and f :) Eric

Re: performance of 48g vs 49g (long) Message #4 Posted by James M. Prange on 11 Oct 2003, 6:55 a.m., in response to message #3 by Eric Lundgren Aha, apparently you meant: %%HP: T(3)A(R)F(.); '\pi*\.S(1,1000,INV(SQ(x)),x)' (I'm using the "backslash" character translations here, so "\pi" represents the lower-case Greek letter pi, "\.S" represents the integral symbol, "\->" represents the right-arrow, and "\.d" represents the derivative symbol.) instead of: 'PI*Int(1,10000,(INV(SQ(x)),x)' For a while there, I was thinking that by "Int" you meant "INT". Flag settings (besides exact/approximate) that I think *may* be relevant are: -2 clear (Constant \-> symb) -3 clear (Function \-> symb) and in the 49G: -99 clear (CAS:quiet) -100 clear (Step by step off) -120 set (Silent mode on) -123 clear (Allow Switch Mode) All of the times are for a single trial each, and should be considered to be approximate. I thought that it would be best to get the algebraic evaluated all the way to a numeric value in one step, so I used \->NUM instead of EVAL. It turned out that that wasn't such a good idea. A 48SX returned 3.13845106094 in 433_s. A 48GX returned 3.13845106094 in 293_s. A 49G in approximate mode returned 3.13845106094 in 369_s. A 49G in exact mode returned 3.13845106094 in 369_s. By "trailing decimal", I meant: %%HP: T(3)A(R)F(.); '\pi*\.S(1.,1000.,INV(SQ(x)),x)' Which causes the 49G to treat the numbers as type 0 floating point numbers ("real" numbers, in RPL jargon) instead of type 28 exact integers. A 49G in approximate mode with reals returned 3.13845106094 in 369_s. A 49G in exact mode with reals returned 3.13845106094 in 369_s. BUT... Using EVAL, the 48SX returned: '\pi*(-INV(x)/\.dx(x)|(x=1000)-(-INV(x)'/\.dx(x)|(x=1)))' in 1.49_s. EVAL on that returned: '\pi*.999' in 1.12_s. \->NUM on that returned 3.13845106094 in .0132_s. Using EVAL, the 48GX returned: '\pi*(-INV(x)/\.dx(x)|(x=1000)-(-INV(x)'/\.dx(x)|(x=1)))' in 1.05_s. EVAL on that returned: '\pi*.999' in .793_s. \->NUM on that returned 3.13845106094 in .0092_s. Using EVAL, the 49G in approximate mode with exact integers returned 3.13845106094 in 365_s. Using EVAL, the 49G in exact mode with exact integers returned: '(999*\pi)/1000' in 3.54_s. \->NUM on that returned 3.13845106094 in .157_s. Using EVAL, the 49G in approximate mode with reals returned 3.13845106094 in 365_s. Using EVAL, the 49G in exact mode with reals returned: '.999*\pi' in 3.04_s and left the 49G in approximate mode. EVAL on that returned 3.13845106094 in .0779_s Go figure.... It looks to me as if the best strategy is to use EVAL (and in the 49G, exact mode) to solve symbolically as far as possible, and only then force a numeric result. And for "real work", I think I'll keep using the 48 series. Regards, James

Re: performance of 48g vs 49g Message #5 Posted by Thomas Radtke on 11 Oct 2003, 2:30 p.m., in response to message #3 by Eric Lundgren I can't resist: 'Ente' means 'duck' in german and that is a synonym for 'slow'. Try to recover the 'r' and see if it gets faster then:). Thomas

[ Return to Index | Top of Index ]

Go back to the main exhibit hall