Hi,

My astronomy program HPlanetarium provides to the user some routines to
get, for example, the elongation of a planet, so that one can draw the
elongation graph over a year, using the plotter provided with the
HP48/49/50. So, the problem here is about plotting user programs, those
programs being quite slow: a few seconds for computing a point.

- When using the TRACE function to link the cursor to the curve, moving
the cursor is very slow. Each time I press the left or right arrow, the
calculator is computing the Y-value of the pixel, which takes a few
seconds for my application. This is quite annoying and makes TRACE
unpractical. This could have been fixed by storing in an array the
value of every computed pixels. Does anyone know a plotter that does a
quick TRACE?

- When plotting a user program, one can use the ROOT function in the
PICTURE menu to find the point where the graph does zero.
Unfortunately, it's impossible to get the value of an extremum: I get
the 'Invalid EQ' error message. I think that the extremum algorithm
does calculate symbolically (?) the derivative of the plotted
expression, which is impossible for a user program. Does anyone know a
plotter that could find an extremum for a user program?

And finally, it would be interesting to know which plotter everyone
here is using, and why...

Can you post some function to see how slow is?

Keep in mind that a computer is about 100 times more powerful or more,
just try tracing the same on EMU48 unchecking "real calculator speed"
from options :D

Try to speed up your calc to 124mhz temporally when tracing with
http://www.hpcalc.org/hp49/utils/misc/cat.zip

"Avatar_e" <erwinried@gmail.com> wrote:
> Can you post some function to see how slow is?

You have to install my program HPlanetarium first to use my function.
Each point needs about 2.5s on my HP49G. I don't have neither a 49G+ nor
a 50g, but it may be twice faster with these calcs.

Just try to plot something like � 2.5 WAIT X SIN � to see how usable it
is.

> Keep in mind that a computer is about 100 times more powerful or more,
> just try tracing the same on EMU48 unchecking "real calculator speed"
> from options :D

I know. But I wrote a program designed to run on a calculator because
I need it to work on a handheld calculator, not a computer.

Khanh-Dang wrote:

> Does anyone know a plotter that does a quick TRACE?

I know of one (that caches usually about 1k points), it's unfortunately
not ready for release yet.

This plotter doesn't currently support plotting of user programs (as it
is implemented in C) - is this a big issue? If it is, I might look into
parsing UserRPL programs to C (almost 60% of the numeric math functions
are ported to C anyway by now).

> And finally, it would be interesting to know which plotter everyone
> here is using, and why...

I use Plot50, and I use it because it's 5-50 times faster than the
built-in one ;-) Albeit in a messy state right now (aka not-releasable
:-/) But eventually...

Cheers,
Steen

"Steen Schmidt" <sschmidt@nospam.dk> wrote:
> This plotter doesn't currently support plotting of user programs (as
> it is implemented in C) - is this a big issue? If it is, I might look
> into parsing UserRPL programs to C (almost 60% of the numeric math
> functions are ported to C anyway by now).

I need plotting user programs, because I don't use any standard
mathematical functions. Just imagine a function which is described by an
algorithm and not an algebraic expression.

hello,

in this case, the slowness will not come from the plotter, but from your 
program, so why not use the build in ploter.
you just need to enter your program in the palce of the Equation (the 
programs takes no arguements, uses the X global variable (or any other if 
you changed the indep variable) and returns 1 real on the stack.

cyrille


"Khanh-Dang" <khanh-dang@w.fr.invalid> wrote in message 
news:44d1f869$0$872$ba4acef3@news.orange.fr...
> "Steen Schmidt" <sschmidt@nospam.dk> wrote:
>> This plotter doesn't currently support plotting of user programs (as
>> it is implemented in C) - is this a big issue? If it is, I might look
>> into parsing UserRPL programs to C (almost 60% of the numeric math
>> functions are ported to C anyway by now).
>
> I need plotting user programs, because I don't use any standard
> mathematical functions. Just imagine a function which is described by an
> algorithm and not an algebraic expression. 

"cyrille de Brebisson" <cyrille@hp.com> wrote:
> in this case, the slowness will not come from the plotter, but from
> your program, so why not use the build in ploter.

Yes. I was actually blaming the slowness of the TRACE function (when
the cursor sticks to the curve), which could be avoided.

Anyway, I think I will write my own ploter, because I need more
(cosmetic) functionnalities, such as displaying the X-coord as a date
or in "hh:mm:ss" format.

Khanh-Dang wrote:
> - When using the TRACE function to link the cursor to the curve, moving
> the cursor is very slow. Each time I press the left or right arrow, the
> calculator is computing the Y-value of the pixel, which takes a few
> seconds for my application. This is quite annoying and makes TRACE
> unpractical. This could have been fixed by storing in an array the
> value of every computed pixels. Does anyone know a plotter that does a
> quick TRACE?

Would a Scatter plot work for you?

On Thu, 03 Aug 2006 04:06:01 -0500, Khanh-Dang wrote:

> My astronomy program HPlanetarium provides to the user some routines t=
o
> get, for example, the elongation of a planet, so that one can draw the=

> elongation graph over a year, using the plotter provided with the
> HP48/49/50. So, the problem here is about plotting user programs, thos=
e
> programs being quite slow: a few seconds for computing a point.

> When using the TRACE function to link the cursor to the curve, moving
> the cursor is very slow. Each time I press the left or right arrow, th=
e
> calculator is computing the Y-value of the pixel, which takes a few
> seconds for my application. This is quite annoying and makes TRACE
> unpractical. This could have been fixed by storing in an array the
> value of every computed pixels. Does anyone know a plotter
> that does a quick TRACE?

You could create your own value table (per pixel) in advance using SEQ
(this would of course be exactly as slow as your current initial plot),
and then replace the plotted function by a table lookup program;
alternatively, you could generate a table as the built-in plotter
calls your function during normal plotting (avoiding duplicates),
and simply repeat a table lookup whenever the same input value
is presented again.

You do not actually need to compute precise values of each pixel
to do this -- all you need is fine enough resolution (spacing
between values) so that simple interpolation (such as the built-in
plotter itself performs to connect points) would produce
sufficiently accurate values -- this can often save plotting time,
the same as does reducing the "resolution" of the built-in plotter,
which reduces the number of needed function evaluations.

Suppose, for example, that you have either used SEQ or
collected values during initial plotting to generate a list
{ x01 y01 x02 y02 x03 y03 ... } then
LIST\-> 2. / 2. DUP \->LIST \->ARRY \->COL DROP AXL SWAP AXL
produces: { y01 y02 y03 ... } { x01 x02 x03 ... }

Given this table, you can look up any x-value and compute
a corresponding y-value; looking up random x-values might
be aided by using part of Joe Horn's clever INSORT program
 from Goodies Disk #10; there is also an HP48 series
interpolation library INTRP15 on Goodies Disk #11
(see http://www.hpcalc.org/hp48/compilations/horn)
and many more such programs and libraries here:
http://www.hpcalc.org/search.php?query=3Dinterpolat

Of course, if you create a table based on already-encountered
input values, and if the identical input values are subsequently
repeated, then no interpolation is needed -- just an exact lookup
(such as performed via the POS command).

> Unfortunately, it's impossible to get the value of an extremum

You could make a difference table from the first table,
and then look for its zeros; you could even plot both functions
at the same time, using NXEQ to swap which function is active
at any given moment.

Surely it's straightforward to use any of these methods
to replace repeated function evaluations with table lookups;
no need to go to extremes :)

[r->] [OFF]

"John H Meyers" <jhmeyers@nomail.invalid> wrote:
> [snip some good ideas]

Thank you for all your suggestion. They are very helpful to me.

> > Unfortunately, it's impossible to get the value of an extremum
> 
> You could make a difference table from the first table,
> and then look for its zeros; you could even plot both functions
> at the same time, using NXEQ to swap which function is active
> at any given moment.

Yes. I wonder why doing this isn't implemented in the built-in ploter.
It seems that the built-in extremum finder use symbolic derivation.
If I remember well, the 48S series didn't have symbolic calculus. Then,
how did the extremum finder (if there was any) work?

On Fri, 04 Aug 2006 01:18:40 -0500:

> If I remember well, the 48S series didn't have symbolic calculus.
> Then, how did the extremum finder (if there was any) work?

48S and 48G both had symbolic "derivative" function; in fact,
even their predecessors 28C and 28S seem to have had it:

http://www.hpmuseum.org/hp28c.htm
http://www.hpmuseum.org/img/28cs.jpg
http://www.hpmuseum.org/img/28ss.jpg

http://www.hpmuseum.org/hp48s.htm
http://www.hpmuseum.org/img/48s/48ssxs.jpg

Integrals too, for that matter -- the CAS can integrate some things
better (unless there's a real number anywhere in the expression :)
but symbolic derivatives are simple and straightforward,
and were there long before this CAS, before Erable,...
probably before Stonehenge :)

http://witcombe.sbc.edu/earthmysteries/EMStonehenge.html
http://britannia.com/history/h7.html
http://en.wikipedia.org/wiki/Stonehenge

[r->] [OFF]

"John H Meyers" <jhmeyers@nomail.invalid> wrote:
> 48S and 48G both had symbolic "derivative" function; in fact,
> even their predecessors 28C and 28S seem to have had it:

Well, I didn't know.

> Integrals too, for that matter -- the CAS can integrate some things
> better (unless there's a real number anywhere in the expression :)

I've just written a little program to convert all real number to
infinite precision :
\<<
 \->LST
 1 OVER SIZE
 FOR k
  DUP k GET IF DUP TYPE THEN DROP ELSE ->Q k SWAP PUT END
 NEXT
 \->ALG
\>>

This is very useful for some large polynomial expressions, when you want
to avoid round off errors.

Could it be written shorter? (mini-challenge here :))

> http://en.wikipedia.org/wiki/Stonehenge

Ah, Stonehenge :) There are some beautiful photos on APOD:
http://apod.nasa.gov/apod/ap060621.html
http://apod.nasa.gov/apod/ap040525.html
http://apod.nasa.gov/apod/ap020509.html

Khanh-Dang wrote:

#AA0h, 82 bytes:

> \<<
>  \->LST
>  1 OVER SIZE
>  FOR k
>   DUP k GET IF DUP TYPE THEN DROP ELSE ->Q k SWAP PUT END
>  NEXT
>  \->ALG
> \>>
[...]
 > Could it be written shorter? (mini-challenge here :))

#D754h, 66 bytes:

<< ->LST LIST-> 1. OVER START SWAP IF DUP TYPE NOT THEN ->Q END OVER 1.
+ ROLLD NEXT ->LIST ->ALG >>

or another approach:

#CC46h, 59 bytes:

<< ->LST 1. << IF DUP TYPE NOT THEN ->Q END >> DOLIST ->ALG >>

But this screams for SysRPL.

Regards
Steen

"Steen Schmidt" <sschmidt@nospam.dk> wrote:
> #CC46h, 59 bytes:
> 
> << ->LST 1. << IF DUP TYPE NOT THEN ->Q END >> DOLIST ->ALG >>

Then, what about this one:

#9F57h, 55.5 bytes:

<< "->LST 1<<DUP TYPE NOT::->Q IFT" STR-> DOLIST ->ALG >>


> But this screams for SysRPL.

SysRPL is not funny for this kind of challenges :)

Khanh-Dang wrote:

> Then, what about this one:
> 
> #9F57h, 55.5 bytes:
> 
> << "->LST 1<<DUP TYPE NOT::->Q IFT" STR-> DOLIST ->ALG >>

Or, what simply about this one?:

#0h, 2.5 bytes:

->Q

Cheers,
Steen

"Steen Schmidt" <sschmidt@nospam.dk> wrote:
> > Then, what about this one:
> > 
> > #9F57h, 55.5 bytes:
> > 
> > << "->LST 1<<DUP TYPE NOT::->Q IFT" STR-> DOLIST ->ALG >>
> 
> Or, what simply about this one?:
> 
> #0h, 2.5 bytes:
> 
> ->Q

I think nobody could write a shorter version :)
It's really great that ->Q is also working on algebraic expressions.

On Sat, 05 Aug 2006 06:48:45 -0500, Khanh-Dang wrote:

> a program to convert all real number [in algebraic formulae]
> to infinite precision (mini-challenge here :)

The XQ command does everything, e.g. (even in Approx. mode):

'X^2.+5.5*X-1.2' XQ =3D=3D> 'X^2+11/2*X-6/5'

[r->] [OFF]

On Sat, 05 Aug 2006 10:30:58 -0500:

[about posted program suggestions, whether UserRPL or SysRPL]

To work in general on all elements of any algebraic formula,
a program would actually need to recurse
into any embedded composite objects.

So it's a good thing that XQ is already provided to do it :)

[r->] [OFF]

"John H Meyers" <jhmeyers@nomail.invalid> wrote:
> The XQ command does everything, e.g. (even in Approx. mode):
> 
> 'X^2.+5.5*X-1.2' XQ ==> 'X^2+11/2*X-6/5'

Actually, XQ sets the Exact mode before starting its job, so does ->Q.
Both also clear the flag -2 (the Constant->num flag), but ->Q asks
before clearing it.

I wonder what the other differences between ->Q and XQ are.

John H Meyers wrote:

> The XQ command does everything, e.g. (even in Approx. mode):
> 
> 'X^2.+5.5*X-1.2' XQ ==> 'X^2+11/2*X-6/5'

But XQ and ->Q aren't numerically equivalent. XQ tries to guess if the
number represents a simple construction with roots, pi and logarithms,
just like ->Qpi, while ->Q calculates the simplest ratio of integers
that represent the real to full precision - try;

1.414213563 DUP XQ ->NUM - which yields 0.00000000063 (round-off error)

and

1.414213563 DUP ->Q ->NUM - which yields 0. (no round-off error)

Fortunately ->Q also works directly on algebraics.

Regards
Steen

John H Meyers wrote:

> The XQ command does everything, e.g. (even in Approx. mode):
> 
> 'X^2.+5.5*X-1.2' XQ ==> 'X^2+11/2*X-6/5'

XQ and ->Q aren't numerically equivalent. ->Q calculates the simplest
ratio of integers that maintain full real precision, while XQ (and
->Qpi) might introduce round-off errors (when they decide the real lies
close enough to one of their special values involving roots, pi or
logs).

Fortunately ->Q also works directly on algebraics.

Regards
Steen

On Sun, 06 Aug 2006 03:02:54 -0500, Khanh-Dang wrote:

> Actually, XQ sets the Exact mode before starting its job, so does ->Q.
> Both also clear the flag -2 (the Constant->num flag), but ->Q asks
> before clearing it

And if its input contains any real, then \->Q demands RAD mode, etc.,
like almost all other CAS-related commands,
while XQ and \->Qpi don't!

> I wonder what the other differences between ->Q and XQ are.

XQ is equivalent to \<< { -2 -105 -102 } CF \->Qpi \>>

More intrigue at:
http://groups.google.com/group/comp.sys.hp48/msg/292c1d12faf1af0a

The 49's \->Qpi is also a completely different program
 from the 48's \->Qpi (which originally shared code with \->Q)


Other "deep" questions:

What is flag -102 ?

Why does XQ do
   CK1&Dispatch ZERO :: etc ; ;
rather than
   CK1 etc ;

Don't ask me -- I don't know either answer :)

[r->] [OFF]

On Sun, 06 Aug 2006 03:47:48 -0500, Steen Schmidt wrote:

> John H Meyers wrote:
>> The XQ command does everything, e.g. (even in Approx. mode):
>> 'X^2.+5.5*X-1.2' XQ =3D=3D> 'X^2+11/2*X-6/5'

Steen> But XQ and ->Q aren't numerically equivalent.

The original place where this branch of the discussion
spun off (or out of control :)
was where I remarked, as an aside,
that the CAS won't do symbolic integration
if the input (formula) contains any reals,
whereupon Khanh-Dang started writing an [unnecessary] program
to convert individual reals within expressions to exact fractions.

Though he happened to choose \->Q for this purpose,
that was an arbitrary choice for conditioning an expression
to be ready for the CAS to integrate -- either \->Qpi or XQ
would have done just as well, but laziness
(the most common factor in every day decisions :)
led to my picking XQ, which for me
is simply the easiest of all to input on my keyboard!


Speaking of wandering off one's original subject:

"Remember Alice?  It's a song about Alice!"
http://www.arlo.net/resources/lyrics/alices.shtml

[r->] [OFF]

"John H Meyers" <jhmeyers@nomail.invalid> wrote:
> Other "deep" questions:
> 
> What is flag -102 ?

I was also wondering. Well, we are so lucky to have a GPL CAS in our HP
calcs, so why don't we even think about looking into the source code?

I downloaded the casrelease.zip file, uncompressed it and took a look
at all the source files. There are a lot of interesting think there...

First, there are a lot of unsupported entries' name in the provided
SupRomEntry. Unfortunately, I haven't found what the given adresses
are. They don't seem to match the legacy SUPROM49.a file.

Then, I took a look at the Header.h file, and I could read:
 DEFINE fnPgcd           BINT102         ( set for no gcd computations )

Well, interesting, isn't it?

> Why does XQ do
>    CK1&Dispatch ZERO :: etc ; ;
> rather than
>    CK1 etc ;
> 
> Don't ask me -- I don't know either answer :)

For this one, I haven't find an answer (yet :)).

John H Meyers wrote:

> Though he happened to choose \->Q for this purpose,
> that was an arbitrary choice for conditioning an expression
> to be ready for the CAS to integrate -- either \->Qpi or XQ
> would have done just as well

I don't think ->Q was an arbitrary choice - it simply is a better one
than XQ. ->Q never introduce round-off errors, while XQ often will. XQ
often alters the numerical properties of your expression, while ->Q
doesn't. XQ and ->Qpi are interchangable numerically, while XQ and ->Q
aren't.

0.3333333333 XQ -> '1/3'

0.3333333333 ->Q -> '3333333333/10000000000'

Regards
Steen

On Tue, 08 Aug 2006 02:20:12 -0500, Steen Schmidt wrote:

> I don't think ->Q was an arbitrary choice -
> it simply is a better one than XQ...

> 0.3333333333 XQ -> '1/3'

A bug, since on HP48
STD 0.3333333333 \->Q\pi is '542474/5112697*\pi'
STD 0.3333333333 \->Q\pi \->NUM returns 0.3333333333 again

On 49/50, this doesn't even begin to occur
until you have ten decimal digits anyway, e.g.
0.333333333 \->Q\pi is still '333333333/1000000000'
[better than the HP48 result in this case!]


On the other hand,

STD 45 D\->R \->Q =3D=3D> '138470445106/176306046487' [49/50]

STD 45 D\->R \->Q =3D=3D> '1.38470445106E12/1.76306046487E12' [?48GX]

STD 45 D\->R \->Q\pi =3D=3D> '1/4*\pi' [48/49/50]

STD 45 D\->R   XQ    =3D=3D> '1/4*\pi' [49/50] (doesn't exist in 48)

And since

45 D\->R =3D=3D> .785398163397
'138470445106/176306046487' \->NUM =3D=3D> .785398163393
'1/4*\pi' \->NUM =3D=3D> .785398163398

We see that these numeric answers from \->Q
are less accurate on any model,
whereas \->Q\pi is more accurate on any model
(and a heck of a lot more sensible for integration :)

So it IS arbitrary!

Q.E.D. :)

John H Meyers wrote:

> So it IS arbitrary!

Wouldn't be, but for the bugs. So, ->Q and ->Qpi are buggy on the
HP49/50...or either ->Q is buggy or the AUR is.

Regards
Steen

On Tue, 08 Aug 2006 08:33:45 -0500, Steen wrote:

> ...or either ->Q is buggy or the AUR is.

I think we should all go back to horse and buggy --
slower, more peaceful life (just as the Subject says :)

"Go placidly amid the noise and the haste,
and remember what peace there may be in silence"
[Max Ehrmann]

John H Meyers wrote:
X
> We see that these numeric answers from \->Q
> are less accurate on any model,
> whereas \->Q\pi is more accurate on any model
> (and a heck of a lot more sensible for integration :)
>
> So it IS arbitrary!
>
> Q.E.D. :)

Old post (I was in a vocation), but interesting...

I think it's nice to have XQ rounding a bit
and then that ->Q and/or ->Qpi doing exact work
AT least if it's documented properly with examples

On Sun, 27 Aug 2006 12:54:59 -0500, VPN came back from vacation...

> I think it's nice to have XQ rounding a bit
> and then that ->Q and/or ->Qpi doing exact work

The examples posted illustrated that
when it comes to XQ and ->Qpi vs. ->Q,
either choice is *sometimes*  more accurate
and *sometimes* less accurate; also,
one will *sometimes* factor in pi when appropriate,
but sometimes it might also when inappropriate.

That's why I called the choice "arbitrary,"
although in general I suggest XQ
because in most cases the results are identical,
while typing XQ is generally the least taxing, typing-wise :)

Yes, XQ also leaves some flags cleared (perhaps usefully?)

[r->] [OFF]