Using the HMS functions in a user RPL program.
sunburned...@gmail.com
the HP49G+ in several programs I am writing in UserRPL.
How would I reference those functions in my UserRPL program? What
syntax would I use?
It would be great if I could see one or two lines of code in an example
of how to do this.
Thanks,
The Sunburned Surveyor
John
Cheers from one Surveyor to another!!
<< 2.3015 2.3015 HMS+ >> Would return 5.0030
The HMS+ and HMS- commands require two values to be on the stack when
the command is executed. The ->HMS and HMS-> command act upon the value
in level one of the stack.
By the way... are you a regular poster on POB board? I seem to
recognize your name.
John Evers
John
I was thining of. Please look me up, and give me a call. I tried
calling the number I found for you, and only heard a very fast busy
signal.
sunburned...@gmail.com
Can you send me your phone number at sunburned...@gmail.com?
I'll get a hold of you that way.
The Sunburned Surveyor
R. G. Newbury
>
> sunburned...@gmail.com wrote:
> > I would like to use the HMS functions available under the time menu in
> > the HP49G+ in several programs I am writing in UserRPL.
> >
> > How would I reference those functions in my UserRPL program? What
> > syntax would I use?
> >
> > It would be great if I could see one or two lines of code in an example
> > of how to do this.
> >
> > Thanks,
> >
> > The Sunburned Surveyor
>
> Cheers from one Surveyor to another!!
>
> << 2.3015 2.3015 HMS+ >> Would return 5.0030
>
> The HMS+ and HMS- commands require two values to be on the stack when
> the command is executed. The ->HMS and HMS-> command act upon the value
> in level one of the stack.
> John Evers
You do have to be careful that what you deal with is in the correct
units. I found that
CYLIN \->V2 RECT V\-> will ensure that your distance/course vectors
are properly 'signed' especially after arithmetic operations on the
course unit of the vector (Think, adding variation)
And you often need to do \->HMS and HMS\-> so that you can do things
like COS(x) on the correct unit type ( 45.3000 is not the same thing
as 45.5000 unless you actually do the 'HMS\->' )
Having HMS+ and HMS- is a convenience for adding time, but rarely
useful for navigation/survey type uses, such as finding the present
position by course and distance vectors from a known start or finding
course and distance to go.
What sort of program are you writing?
Geoff
sunburned...@gmail.com
I just want to have a custom menu that allows me to quickly convert
between DMS and Decimal Degrees. I also want to be able to add,
subtract, divide, and mulitply DMS values.
I know you can reference functions above the directory in wich a
UserRPL program is stored, but I didn't know if this applied to the
functions in the Time>Tools Menu on my HP49G+.
The Sunburned Surveyor
Brother-Peter
news:1133828053....@g49g2000cwa.googlegroups.com...
> R.G.
>
> I just want to have a custom menu that allows me to quickly convert
> between DMS and Decimal Degrees. I also want to be able to add,
> subtract, divide, and mulitply DMS values.
HMS/ as a command
<< SWAP HMS-> SWAP / ->HMS >> 'HMSD' STO
HMS* as a function
<< -> t a
<< t a SWAP HMS-> * ->HMS >> 'HMSM' STO
{ HMS+ HMS- {"HMS*" HMSM } {"HMS/" HMSD } } MENU
CUSTOM
menu is always available above [ H ]
or you can program it by
1 MENU
Heiko Arnemann
"Brother-Peter" <DROP...@dlc.fi>
> HMS/ as a command
> << SWAP HMS-> SWAP / ->HMS >> 'HMSD' STO
>
> HMS* as a function
> << -> t a
> << t a SWAP HMS-> * ->HMS >> 'HMSM' STO
>
> { HMS+ HMS- {"HMS*" HMSM } {"HMS/" HMSD } } MENU
>
> CUSTOM
> menu is always available above [ H ]
> or you can program it by
> 1 MENU
My half cent:
Due to a very old bug, 8 minutes (0.08 in HMS format) are not converted
correctly.
You should use/add
<< 0 HMS+ >>
to convert bad hms-formats to good ones.
Regards
Heiko
Brother-Peter
news:43974684$0$4535$ba62...@news.skynet.be...
Could you please correct the above examples, I'm confused...
John H Meyers
> I know you can reference functions above the directory in which
> a UserRPL program is stored, but I didn't know if this applied
> to the functions in the Time>Tools Menu on my HP49G+.
An upward search is performed during execution on user variable names,
in case you have stored things of your own in higher directories,
but built in functions reside in ROM libraries,
and are always available.
There is also an upward search during compilation
for function names in externally attached libraries,
but almost all libraries attach themselves to HOME,
so that their function names are also always available,
as long as the library remains installed.
[r->] [OFF]
timwe...@gmail.com
> Due to a very old bug, 8 minutes (0.08 in HMS format) are not converted
> correctly.
My 1/4 cent:
Decimal precision rears its ugly head again! HMS> gives
.133333333333333333.....and so on. >HMS will return
.07599999999....and so on. Not all numbers can be represented
accurately with decimals as I'm sure you know. Doesn't seem like a
bug.
> You should use/add
> << 0 HMS+ >>
> to convert bad hms-formats to good ones.
This doesn't seem to do anything for me. What is it supposed to do?
TW
reth
It certainly does not do anything; I had to program my own routine to
display properly angles (to get rid of the annoying ....xx'60" :)
reth
John H Meyers
> Due to a very old bug, 8 minutes (0.08 in HMS format)
> are not converted correctly.
Could you explain that a bit more?
.08 HMS\-> produces .133333333333 [hours];
this is as precise as is possible in 12 digits.
Conversion back yields .0759999999999
(equally correct for the given input at the previous stage),
so what is needed seems to be some rounding,
tho of course .0760 is not quite what is desired either :)
> You should use/add \<< 0 HMS+ \>>
> to convert bad hms-formats to good ones.
This will not fix the above, although
1.0 HMS+ 1.0 HMS- will fix it.
In general, you could try
\<< DUP 100 * SWAP OVER HMS- HMS+ \>>
as a means of "rounding" ugly-looking results :)
The HP42S/48/49 do better than the HP17Bii in these conversions
(I guess financial programmers finally figured out how to do it properly,
although it can also be done perfectly with just UserRPL, see below);
I don't think there is any way to improve those functions further,
because we are up against the granularity of having to round results
to a fixed number of significant digits,
and rounding errors inevitably creep in.
More about Hours (Degrees), Minutes, Seconds conversions
(even UserRPL programs that are as accurate as is possible)
http://groups.google.com/group/comp.sys.hp48/msg/e51ab09539f0ea7c
[r->] [OFF]
Brother-Peter
news:op.s1gd4...@news.cis.dfn.de...
I liked the best this:
"Time's fun when you're having flies." - Kermit the Frog
VPN
PS: does anybody have a solution to the root finder problem?
Perhaps using units?
Unfortunately I can't find
_hms (24) or _dms (360)
I would like to have _dhms
[bad example: 365.24606099]
and naturally also ->DHMS & DHMS->
Heiko Arnemann
> My 1/4 cent:
>
> Decimal precision rears its ugly head again! HMS> gives
> .133333333333333333.....and so on. >HMS will return
> .07599999999....and so on. Not all numbers can be represented
> accurately with decimals as I'm sure you know. Doesn't seem like a
> bug.
>
> > You should use/add
> > << 0 HMS+ >>
> > to convert bad hms-formats to good ones.
>
> This doesn't seem to do anything for me. What is it supposed to do?
Hello together,
Ok, I was wrong, or at least not complete. Sorry!
Tim is right:
the behaviour of the calculator is not a bug, but the user
need to take care, e.g. when working with the FIX-format, in
combination with HMS- or DMS-formats.
"1/8 cent"
1. A rounding function for HMS-formats is not provided by the
build in functions, but it is required to handle HMS-formats properly.
2. After rounding an HMS-format to full seconds (or minutes) my
"1/2 cent solution" works fine:
Assuming STD-format.
Example:
After 0.08 HMS-> ->HMS and rounding to full seconds
you will get 0.0760 or 7 minutes and 60 seconds.
0.0760 0 HMS+ converts back to 8 minutes (0.08).
Regards
Heiko
Heiko Arnemann
> > Due to a very old bug, 8 minutes (0.08 in HMS format)
> > are not converted correctly.
>
> Could you explain that a bit more?
Please, have a look to my answer to Tim in this thread.
> This will not fix the above, although
> 1.0 HMS+ 1.0 HMS- will fix it.
Yes, I thought about and tried it.
by adding one hour you are loosing precession,
which helps in case of 8 minutes HMS-> ->HMS
> In general, you could try
> \<< DUP 100 * SWAP OVER HMS- HMS+ \>>
> as a means of "rounding" ugly-looking results :)
Yeah, I have tried, the same trick as above. It makes "loosing
precission".
My finding with 0 HMS+:
it just "repairs" e.g. 0.0760 (HMS-format)
back to 8 minutes.
> The HP42S/48/49 do better than the HP17Bii in these conversions
> (I guess financial programmers finally figured out how to do it
properly,
> although it can also be done perfectly with just UserRPL, see below);
> I don't think there is any way to improve those functions further,
> because we are up against the granularity of having to round results
> to a fixed number of significant digits,
> and rounding errors inevitably creep in.
You are right, nothing really to improve. Only a rounding function
for HMS-formats is missing
> More about Hours (Degrees), Minutes, Seconds conversions
> (even UserRPL programs that are as accurate as is possible)
> http://groups.google.com/group/comp.sys.hp48/msg/e51ab09539f0ea7c
Thanks for the link.
Regards
Heiko
John H Meyers
> by adding and subtracting one hour
> [or 100 times the current value, as also suggested]
> you are losing precision,
> which helps in case of 8 minutes HMS-> ->HMS
> Only a rounding function for HMS-formats is missing.
That's what was just supplied -- a rounding function for HMS;
the very nature of "rounding"
means "choosing the closest answer of lesser precision,"
and it can be accomplished by adding and then subtracting again
a larger value (in this case using the HMS+ and HMS- functions
themselves for the "adding" and "subtracting");
how much larger a value determines to how many remaining digits
you are "rounding."
[r->] [OFF]
Brother-Peter
news:op.s1hjq...@news.cis.dfn.de...
What where? HMSRND ?
Please again and with similar syntax than RND
Thank you
(I somehow seem to inherited a sort of timing bug)
(I lost track of your routines and also did not quite get it - this time)
;-)
John H Meyers
[didn't see the whole thread, wants an HMSRND function]
So look back; I didn't parameterize it with an argument
for how many decimal digits to keep, say,
but you can proceed to do that for yourself,
as I am taking a short break from writing calc programs :)
Actually, the following "cheap shot" has some chance of working,
but I leave testing (and any fixing) to you:
Args: HMS_value(real) #places(real_or_zint)
\<< SWAP 0. HMS+ SWAP RND 0. HMS+ \>> 'HMSRND' STO
It works even with "improper" input like .995999999999 11
or .999999999999 11 (that's what the first HMS+ is for),
but no warranty is expressed or implied :)
Values of 1 or 3 for number of places are not very reasonable,
but try anyway and see what happens :)
[r->] [OFF]
Heiko Arnemann
"John H Meyers" <jhme...@miu.edu> schrieb
> Args: HMS_value(real) #places(real_or_zint)
>
> \<< SWAP 0. HMS+ SWAP RND 0. HMS+ \>> 'HMSRND' STO
>
> It works even with "improper" input like .995999999999 11
> or .999999999999 11 (that's what the first HMS+ is for),
> but no warranty is expressed or implied :)
0. HMS+ seem to be very powerfull. More than I have expected :-)
> Values of 1 or 3 for number of places are not very reasonable,
> but try anyway and see what happens :)
The value 0 for number of places is not reasonable, as well.
The required program need additionaly takes care, if
the user means hours, degrees or grad.
A case strukture with the faktors 24, 360 and 400 would take
care for "0", and 3600 and 60 can be applied for the digit rounding for
1 to 3.
I suggest to challenge the user, instead of implementing
another rounding function.
There is may be a need to improve/AddSomethingTo the AUR.
Regards
Heiko
Brother-Peter
>
> "John H Meyers" <jhme...@miu.edu> schrieb
>
>> Args: HMS_value(real) #places(real_or_zint)
>>
>> \<< SWAP 0. HMS+ SWAP RND 0. HMS+ \>> 'HMSRND' STO
>>
>> It works even with "improper" input like .995999999999 11
>> or .999999999999 11 (that's what the first HMS+ is for),
>> but no warranty is expressed or implied :)
>
> 0. HMS+ seem to be very powerfull. More than I have expected :-)
>
>> Values of 1 or 3 for number of places are not very reasonable,
>> but try anyway and see what happens :)
>
> The value 0 for number of places is not reasonable, as well.
> The required program need additionaly takes care, if
> the user means hours, degrees or grad.
>
> A case strukture with the faktors 24, 360 and 400 would take
> care for "0", and 3600 and 60 can be applied for the digit rounding for
> 1 to 3.
_dms would be for 360
_gms would be for 400
_hms would be for 24
_dhms would be for ddd.hhmmsscc
The last one is easily convertible to/from _dms
> I suggest to challenge the user, instead of implementing
> another rounding function.
RND could look for the UNIT
> There is may be a need to improve/AddSomethingTo the AUR.
Currently it would be nice to have a separate chapter on
UNITS
- solving with units
- plotting with units
- numerical integration with units
- angle units & angular motion
- temperature units & calculations
- user units & custom menus
- unit tips & tricks
John H Meyers
> The value 0 for number of places [to round HMS] is also not reasonable.
What's wrong with rounding to the nearest hour (or degree)?
Lawyers, in fact, seem to always round that way, although actually,
I think they tend to use the CEIL function in place of RND :)
> The required program need additionaly take care,
> if the user means hours, degrees or grad.
The HMS conversions and HMS arithmetic functions
are valid only for hours.mins_seconds or degrees.mins_seconds
(not angles in grads or radians), but there is no way
for the calculator to read the mind of the user,
nor even to imagine whether HMS is being used
to deal with angles or to deal with time,
(not that it matters, since the numeric operations are identical),
so inasmuch as there is no specially marked object type or unit
to distinguish the inputs or outputs of these functions,
it has to remain the user's responsibility
to decide when it's proper to use these functions,
and the calculator's responsibility
to simply carry them out whenever demanded.
Program authors, of course, can design whatever user interface
they want, but here we are only considering an HMSRND function
with which to provide them, and then leave it to them
to decide when to use it.
Once upon a time this was even the case for conversions
between Polar and Rectangular coordinates; when the
calculator objects were only real numbers,
all responsibilty fell on the programmer and user to remember
which format each pair of real numbers was supposed to mean,
but the HP48 introduced a new paradigm, which is that
a coordinate pair is contained within a single special object,
and that the pair is *always* stored in rectangular form.
However, an input parser recognizes a special syntax
to distinguish polar input from rectangular input,
and the display can present these objects in the user's choice
of polar or rectangular formats, using the same syntax,
obviating any need for the old R->P and P->R functions,
but leading many a new user to complain "hey, how come
this stupid calculator left out those standard functions?" :)
That new paradigm took care of one old ambiguity, but when
it comes to the different ways of expressing hours or degrees,
either as "straight decimal" or "with minutes and seconds,"
we are still where we used to be with Rectangular vs. Polar,
and it remains up to the user to keep mental track of what (s)he means.
I would therefore say that an HMSRND program
has exactly the same validity as any other built-in HMS function,
and must likewise just do what the user asks,
hoping that (s)he knows what (s)he is doing :)
> A case strukture with the faktors 24, 360 and 400
> would take care for "0", and 3600 and 60 can be applied
> for the digit rounding for 1 to 3.
The format "xxxx.mmssssssssss" (as used by HMS functions)
has a hard-coded definition (that there are 60 seconds
to each minute, and 60 minutes to each degree or hour);
this definition is not adjustable in these products,
and the very fact that you elect to use an HMS function
implies your acceptance and consent to that user agreement :)
The format itself, however, inherently introduces
the possibility of specfying "mm" as 60-99
and "ss.ssssss" also in the range of 60 to 99.999999 etc.
The calculator designer could choose either to regard such
inputs as invalid and throw an exception, or to proceed
more generally to accept them and simply add together
the meanings of the three separate parts of the format,
with the given factor of 60 between each adjacent part.
Inasmuch as some of the HP ROM developers
(in financial models particularly)
were not too thoughtful in how they implemented the conversions,
allowing values of exactly 60 to appear in results,
it's sort of a good thing that they decided
not to throw an exception on input which could have been
the previous output of the very same functions :)
My microwave oven does exactly the same, by the way,
as do most of my digital countdown timers; you can specify
99 minutes, or 99 hours, or 99 seconds, and they never complain;
they just count down to zero before affecting the next
group of digits to the left (if any),
and thus they do exactly the right thing for me, the user,
who is, after all, always right :)
> I suggest to challenge the user,
> instead of implementing another rounding function.
If someone needs rounded results for the HMS format, to clean up
inevitable perturbations which could produce longer-looking answers,
I can see no more reason to discourage it than to discourage
the basic decimal RND function already provided.
> There may be a need to improve/AddSomething To the AUR.
Yes, why not educate users of the HMS format by pointing out
that they need to take responsibility for using it properly,
that it needs a program to be properly rounded,
as well as other things such as that the HMS format
can not be properly used with the numeric solver,
as has already been illustrated in an earlier referenced post.
Well, enough of my chatting here;
I must get back to the rest of my scheduled 99 hour day :)
With best wishes from http://www.mum.edu
and http://www.maharishischooliowa.org
John H Meyers
we need to avoid using the built-in RND at all,
as I (sanely) first did, and rely only on HMS+ and HMS-
Feel free to post a correct program;
I'll work out mine later, thanks.
[r->] [OFF]
Heiko Arnemann
"John H Meyers" <jhme...@miu.edu> answered to
> On Sat, 10 Dec 2005 03:42:38 -0600, Heiko Arnemann wrote:
> > The required program need additionaly take care,
> > if the user means hours, degrees or grad.
>
> The HMS conversions and HMS arithmetic functions
> are valid only for hours.mins_seconds or degrees.mins_seconds
> (not angles in grads or radians), but there is no way
...
Yes, I did not finish my thoughts. Of course, grads and radians
are decimals and need to be handled simply as real numbers (RND).
...
> > A case strukture with the faktors 24, 360 and 400
Here I was wrong. 24 h, 360 ° and 400 grad has nothing
to do with rounding, they only become important for
periodic analysis, e.g. with the MOD-function.
> > would take care for "0", and 3600 and 60 can be applied
> > for the digit rounding for 1 to 3.
> The format "xxxx.mmssssssssss" (as used by HMS functions)
> has a hard-coded definition (that there are 60 seconds
> to each minute, and 60 minutes to each degree or hour);
...
> My microwave oven does exactly the same, by the way,
> as do most of my digital countdown timers; you can specify
> 99 minutes, or 99 hours, or 99 seconds, and they never complain;
> they just count down to zero before affecting the next
> group of digits to the left (if any),
> and thus they do exactly the right thing for me, the user,
> who is, after all, always right :)
I like this way.
Thanks for your explanations/thougts.
Best regards
Heiko
Heiko Arnemann
> Okay, to correctly round so that 30 minutes or seconds rounds up,
> we need to avoid using the built-in RND at all,
> as I (sanely) first did, and rely only on HMS+ and HMS-
Yes, that is the point. I suggest to use HMS-> before applying RND.
> Feel free to post a correct program;
> I'll work out mine later, thanks.
I have just started, to blow up one of my older clock-rounding
programs.
The program should round to even hours (degrees),
even 10 minutes or 1 minute, even 10 seconds, even second
or fraction of a second.
input:
real, with format xxx.mmssssss (with xxx: degrees or hours)
real, digit rounding number.
output is depending on the digit rounding number:
0 rounds to even hour
1 to even 10 minutes
2 to even minutes
3 to even 10 seconds
4 to even seconds
5 to a tenth of a second...
RNDXMS (perhaps for chrismas ;-)
\<< SWAP HMS\->
\<< SWAP OVER * 0 RND SWAP /
\>> \-> prg @ this program is used three times below
\<<
CASE OVER 0 ==
THEN OVER RND
END OVER 1 ==
THEN 6 prg EVAL
END OVER 2 ==
THEN 60 prg EVAL
END OVER 3 ==
THEN 360 prg EVAL
END
END \->HMS SWAP DUP
IF 4 <
THEN DROP 4
END RND 0 HMS+
\>>
\>>
Rounding-errors give me some headache.
Example:
1 hour 0 minutes 30 seconds need to be rounded to even minutes.
1.003 RNDXMS will give only
1. (h), while expecting 1.01 (1 h 1 m)
but
0.003 RNDXMS
gives the correct
0.01 (the equivalet to one minute).
Regards
Heiko
reth
->HMS 4 RND 0 HMS+
does the job perfectly (as per the initial post)
thanks, Heiko :)
Reth
Heiko Arnemann
> ->HMS 4 RND 0 HMS+
> does the job perfectly (as per the initial post)
> thanks, Heiko :)
Hello reth,
I am nosy to see, *which problem has been solved
perfectly? I assume..., but could you explain?
I assume, you can "clear up" all reals in
the "hour-format" (hh.xxxxx, e.g.:
by the way this nice expamle12.83333)
converted to a "clean" HMS-format,
within the acuracy of a full second "only"?
I have improved my program to
round hms-format input.
input:
real, with format xxx.mmssssss (with xxx: degrees or hours)
real, digit rounding number.
output is depending on the digit rounding number:
0 rounds to even hour
1 to even 10 minutes
2 to even minutes
3 to even 10 seconds
4 to even seconds
5 to a tenth of a second...
so, it is supposed to be "Die eierlegende Woll-Milch-Sau"
(to do all you want :-)
RNDXMS
%%HP: T(3)A(R)F(.);
\<< SWAP DUP IP DUP 4 ROLLD - HMS\->
@ first substruct the hours (degrees) to get better accuracy
@ in case of having somthing short like 1.003 in HMS-format
\<< SWAP OVER * 0. RND SWAP /
\>> \-> prg
\<<
CASE OVER 0. ==
THEN OVER RND @ round to hours (degrees)
END OVER 1. ==
THEN 6. prg EVAL
END OVER 2. ==
THEN 60. prg EVAL @ round to minutes
END OVER 3. ==
THEN 360. prg EVAL
END
END \->HMS SWAP DUP @ round to seconds or better
IF 4. < THEN DROP 4. @ in case of rounding worse than a second
END RND 0. HMS+ + @ finaly add the degrees (hours) (s.a.)
\>>
\>>
Can easylily be changed to round to
even 5 minutes or even 5 seconds :-)
by changing 6. to 12. or 360. to 720?
Or it can be simplified to round
only to minutes or seconds.
Today I have tried with an HP 11 (does it exist?)
it easily handles 0.08 H-> ->HMS.
Good old times, John ;-)
It seem to be beneficial, to have a proven
program which solves the hms-rounding problem.
I would like to give a chanllenge for the shortest
usrRPL and sysRPL program.
Any comments to define the chanllenge
are appreciated.
Best regards
Heiko
PS: Up to now I am using a program
which is not able to handle exactly 1.003
(1 h and 30 s rounding to even minutes).
John H Meyers
> ->HMS 4 RND 0 HMS+ does the job perfectly
Even 0 HMS+ n RND 0 HMS+
gives correct answers only for n >= 4
The first HMS+ is needed for unusual (but still possible)
input such as .999999999999
n >= 4 comes about because 30 seconds should round up
to the next minute, and 30 minutes should round up
to the next hour.
Be careful about declaring things "perfect" (or bug free)
based on a handful of garden-variety examples,
based on Murphy's law that "the user will always
try input that you didn't think of" :)
[r->] [OFF]
John H Meyers
Args: HMS_value n
[only for non-negative n]
\<< ABS 0. RND \-> n \<<
DUP SIGN SWAP ABS 0. HMS+
n 0. == { .2 HMS+ } IFT
n 2. == { .002 HMS+ } IFT
n RND 0. HMS+ * \>> \>> 'HMSRND' STO
See you 'round :)
[r-> [OFF]
reth
should have been more careful about that.
It's very annoying to get that XXX.XX60 and it has been happening alot.
Surveyor using angle units DMS would know what I'm talking about. The
way I see it, ->HMS should check the current value for FIX and if it's
4, display 0.0760 as 0.0800. In respect to the above, Heiko's solution
does the job.
"Even 0 HMS+ n RND 0 HMS+
about, even make that n=4 :)
regards,
reth
reth
"I would like to give a chanllenge for the shortest usrRPL and sysRPL
program. "
For the vast majority of surveyors using DMS (including me) rounding
properly to the nearest second is all they need. In Europe GRADs are
used so NO DMS -> NO PROBLEM ;)
regards,
reth
John H Meyers
Args: HMS_value n [n>=0, no "scientific" rounding]
\<< ABS 0. RND OVER ABS
OVER 0. == .2 * 3. PICK 2. == .002 * + HMS+
SWAP RND 0. HMS+ SWAP SIGN * \>> 'HMSRND' STO
Examples:
1.34299999999 4 ==> 1.3430
1.343 2 ==> 1.35
1.593 2 ==> 2.00
-2.2455 3 ==> -2.2500
.99999999 4 ==> 1.4040
[r->] [OFF]
Brother-Peter
0. ==
isn't that
NOT
Brother-Peter
news:FcGnf.1529$Kj2....@reader1.news.jippii.net...
isn't that
PICK3
Brother-Peter
\<< ABS 0. RND OVER ABS OVER
NOT 5 / PICK3 2. == 500 /
John H Meyers
> 0. == [is equivalent to] NOT
Sounds good; you win a 2.5 byte refund :)
[r->] [OFF]
John H Meyers
> 3. PICK
> isn't that PICK3
Only if you have a 49G;
the 48 series doesn't have a PICK3 command,
so I used 3. PICK to be completely general.
[r->] [OFF]
Brother-Peter
> On Tue, 13 Dec 2005 14:30:18 -0600, VPN wrote:
>
>> 0. == [is equivalent to] NOT
>
> Sounds good; you win a 2.5 byte refund :)
:)
I thinkk I'll spend it on Qonos...
John H Meyers
> NOT 5 / PICK3 2. == 500 /
If you enter program in Approximate mode (or on 48 series),
then size will be same and speed microscopically slower;
in exact mode (49 series), size will be less
but speed also slightly less (for ZINT -> REAL conversion).
Life is filled with endless tough choices, isn't it? ;-)
[r->] [OFF]
Brother-Peter
> On Tue, 13 Dec 2005 14:36:41 -0600, VPN wrote:
>
>> NOT 5 / PICK3 2. == 500 /
>
> If you enter program in Approximate mode (or on 48 series),
can't ENTER that PICK3 on the 48 series...
> then size will be same and speed microscopically slower;
> in exact mode (49 series), size will be less
> but speed also slightly less (for ZINT -> REAL conversion).
>
> Life is filled with endless tough choices, isn't it? ;-)
when the going gets tough - the tough gets going :-D
Heiko Arnemann
> Args: HMS_value n [n>=0, no "scientific" rounding]
>
> \<< ABS 0. RND OVER ABS
> OVER 0. == .2 * 3. PICK 2. == .002 * + HMS+
> SWAP RND 0. HMS+ SWAP SIGN * \>> 'HMSRND' STO
>
> Examples:
>
> 1.34299999999 4 ==> 1.3430
> 1.343 2 ==> 1.35
> 1.593 2 ==> 2.00
> -2.2455 3 ==> -2.2500
> .99999999 4 ==> 1.4040
Hello John,
I am very much impressed :-)
It seem to work properly for n = 1 and n = 3
as well, rounding to even 10 minutes and
even 10 seconds.
The first "0. RND" seem to be dispensable.
I understand, you need the rounding, in
case somebody would use 0.4 or 2.4 for n
but this should be part of the documentation?
n should be a positive integer.
The first "ABS" seem to be also dispensable,
because your require n>=0?
It looks, you are very carefull :-)
I like it, because of it愀 understanding and
learning.
Brother Peters proposals:
- NOT instead of "0. ==" seem to be an improvement
- PICK3 seem to be a little "picky", because of incompatability with
HP 48G-series
- "5 /" instead of "0.2 *" would give some less space for sysRPL
- "500 /" seem to be more consistant for the above
It should be noted, that SIGN is flag-sensitive.
In Exact mode (-105 CF)
0 SIGN gives "?".
This might be important for the user, who
would like to avoid a possible interuption for his
program, using HMSRND.
John,
your algortithm seem to look a bit unbeatable
in terms of speed and space? :-)
Regards
Heiko
PS: I am wondering about the format you
post your programs. I have not yet figured
out, how to extract and easily transfer to
my emulator. I am missing the header
for ascii-transfer. Any hint appreaciated.
John H Meyers
>> \<< ABS 0. RND OVER ABS
>> OVER 0. == .2 * 3. PICK 2. == .002 * + HMS+
>> SWAP RND 0. HMS+ SWAP SIGN * \>> 'HMSRND' STO
> It seems to work properly for n=1 and n=3 as well
Thought it might :)
> The first "0. RND" seems to be dispensable.
Required by Murphy's law: "the user will supply unanticipated args"
We don't want to fail the subsequent tests for special n
(e.g. arg of 0.1 would round to zero places
but not make the needed correction of adding 0.2 to HMS,
similarly for an arg of 2.1 failing to add .002 to HMS)
0. RND also treats n exactly the same way as the RND command
itself, which actually *rounds* its own arg n to an integer
(so to be as consistent as possible,
we don't substitute IP, for example).
> I understand, you need the rounding, in
> case somebody would use 0.4 or 2.4 for n
> but this should be part of the documentation?
> n should be a positive integer.
Maybe we can speed up UserRPL by not carefully checking
args at all; after all, everyone *should* read the AUR,
and *should* supply the right sort of args all the time :)
Telling the user "well, you didn't read and follow the
directions" is too late, after something goes wrong
and the user is dissatisfied, even though we might
try to point the finger of blame back toward the user
(if we ever get the opportunity to communicate at all).
Is it not better to make something foolproof,
so that no one could ever get to that point
of having anything fail, at least not without
helpful information being provided on the spot
to enable the user to correct and try again?
> The first "ABS" seems to be also dispensable,
> because your require n>=0?
We *request* n>=0, but who can stop the user from disobeying?
(and then perhaps complaining of incorrect results).
If n<0 is supplied, that would cause "scientific" rounding;
no doubt we could make a much larger program to even handle it,
but I wasn't interested in going so far,
as it makes even less sense than rounding to 1 or 3 places :)
The formal way to treat unwanted args is to rigorously test
and perform 515 DOERR ("Bad Argument Value"), but often for
trivial UserRPL programs I choose to just make the arg conform;
in this case treat neg args the same as positive :)
> It looks, you are very careful :-)
I learned from Professor Murphy herself :)
> I like it, because of its understanding and learning.
Glad it offers more than just its function :)
> Brother Peter's proposals:
> - NOT instead of "0. ==" seem to be an improvement
Slightly shorter and probably faster.
Slightly less intelligible too,
but for an example of really obscure functionality,
the following program (by Joe Horn, from GD#10)
takes any real integer and returns the number of bits
required to express it in binary (your mission,
should you choose to accept it,
is to figure out how it works :)
\<< 0 1 ROT FOR
DEPTH 1 +
DEPTH STEP
\>>
> PICK3 seem to be a little "picky",
> because of incompatibility with HP48S[X]/G[X]
I have often posted "all in one" versions for all models,
even having different syseval addresses in the same program,
with a test for which model we're on -- unfortunately,
the newer 48Gii may defeat this if its VERSION command
identifies it as an HP48, just as pre-49 programs
knowing only HP48 addresses might crash a 49
(someone might suggest using VERSTRING to remedy this,
but then how are we going to know how to call VERSTRING
before we even know which model we're on?)
It might be a "very good thing" to have a sure way
of distinguishing all current models, including
to distinguish any 49G from any 49G+;
how to do that in such a way that
it runs correctly even on a 48S?
But it certainly wouldn't be worth the great effort
to figure out which model,
just to decide between 3. PICK and PICK3 :)
> It should be noted, that SIGN is flag-sensitive.
> In Exact mode (-105 CF)
> 0 SIGN gives "?"
Ouch, please don't tell Prof. Murphy that I've flunked again ;-)
Yes, you should insert 0. + before SIGN to force to real
(in an HP48 compatible way, of course :)
Thank you for finding this bug!
> PS: I am wondering about the format you
> post your programs. I have not yet figured
> out, how to extract and easily transfer to
> my emulator. I am missing the header
> for ascii-transfer. Any hint appreciated.
I have always used translation mode 3 and decimal points (not commas),
which I have always thought to be evident, so after my first year
I stopped cluttering up my posts with %%HP: T(3)F(.);
[which then itself had to be explained each time,
telling people not to actually type that into the editor :]
Note that A(x) matters only for inputs in polar coordinates,
or for angle calculations immediately executed,
which probably I've never posted.
Has Emu48 ever included its own ascii translator?
Assuming not,
I have always used trivially simple programs of my own,
called IN and OUT, stored in my emulated HOME directory,
to translate and execute ascii text input
(copied and pasted into Emu48 using "Edit > Paste String"
or by simply dragging any whole text file to an Emu48 window).
Emulated calc results can also be turned into strings
and then copied out of Emu48 using "Edit > Copy String"
(after which you can paste into anything else)
That's in fact exactly how I test everything posted here
(who needs a real calculator, anyway? :)
Here are the simple versions for each calc ROM type;
first, to invoke the internal ascii translator functions,
which are already in calculator ROM:
@ ROM type *49* -- including 48Gii, apparently
\<< \->STR :KINVISLF:#2F34Dh SYSEVAL + \>> 'KINV' STO
\<< \->STR :KVISLF:#2F34Fh SYSEVAL \>> 'KVISL' STO
\<< \->STR :KVIS:#2F34Eh SYSEVAL \>> 'KVIS' STO
@ ROM type *48* -- only HP48S[X] or 48G[X or +]
\<< \->STR :KINVISLF:#3016Bh SYSEVAL + \>> 'KINV' STO
\<< \->STR :KVISLF:#2FEC9h SYSEVAL \>> 'KVISL' STO
\<< \->STR :KVIS:#2FEDDh SYSEVAL \>> 'KVIS' STO
The "tags" (e.g. :KVIS: ) are just for documentation
of the internal function names, and may be omitted.
NOTE: We highly recommend making memory backups before use,
because any wrong addresses or arguments of system functions
can crash a calc and/or wipe out its memory.
The above are almost ready to do the entire job,
but here are the simplest and most convenient
IN and OUT programs for any calc model,
to set the translation mode, evaluate the object on input,
and assure that we don't lose any details on output:
\<< 3 TRANSIO KINV STR\-> \>> 'IN' STO
\<< 3 TRANSIO STD 64 STWS KVISL \>> 'OUT' STO
@ You may prefer KVIS (no CRLF line endings) for Linux etc.
These simplest IN and OUT neither parse nor create
the HP ascii file headers, but just translate
"cut and pasted" text, assuming translation mode 3,
which is generally the safest and best assumption,
almost always adequate for input, and always good for output.
This 'IN' also assumes that we want to immediately parse
what we pasted, as if typed into the onboard editor,
which exactly suits what I post,
but of course you may omit STR\-> to avoid immediate evaluation
(the 49 series editor would then allow you to select text
and directly evaluate all or any part that you have selected;
on the 48 series you can edit and then remove the string quoting).
If you want to add complete ascii header processing,
you can insert KHOUT before KVISL in the 'OUT' program;
here is 'KHOUT' for any calc model,
to insert an ascii header, based on current modes:
\<< \->STR "%%" "HP: " +
{ "T(0)" "T(1)" "T(2)" "T(3)" }
OPENIO CLOSEIO { HOME IOPAR } RCL 6 GET 1 + GET +
-17 FS? "A(R)"
{ -18 FS? "A(G)" "A(D)" IFTE } IFTE +
-51 FS? "F(,)" "F(.)" IFTE +
";" + 10 CHR + SWAP + \>> 'KHOUT' STO
To parse any incoming ascii header and set its modes
(also removing the ascii header from the string),
you can insert KHIN before KINV in the 'IN' program;
here is 'KHIN' for any calc model:
\<< \->STR DUP 1 64 SUB "%%" "HP:" +
POS { DUP 1 OVER ";" POS SUB
DUP "T(0)" POS { 0 TRANSIO } IFT
DUP "T(1)" POS { 1 TRANSIO } IFT
DUP "T(2)" POS { 2 TRANSIO } IFT
DUP "T(3)" POS { 3 TRANSIO } IFT
DUP "A(D)" POS { DEG } IFT
DUP "A(R)" POS { RAD } IFT
DUP "A(G)" POS { GRAD } IFT
DUP "F(.)" POS { -51 CF } IFT
DUP "F(,)" POS { -51 SF } IFT
SIZE 1 + OVER SIZE SUB } IFT \>> 'KHIN' STO
Finally, below is a much stricter 'IN' for ROM type 49,
which makes sure that we parse the input but never execute
functions or commands; Kermit handles ascii file transfers
in an identical fashion, to make sure that we simply
store the object, without letting it take control of our calc
and execute arbitrary code, like a virus breaking into Windows :)
For example:
Incoming string Result
--------------- ------
"X" or "'X'" 'X' (unevaluated)
"VARS" The command VARS (not executed!)
"1 2 3" One single "program" (without delimiters),
containing the multiple objects.
"" (empty) An empty program (rather than "no object")
Development Library 256 should be attached before compiling:
\<< 3 TRANSIO KHIN KINV "\<<" SWAP + STR\-> \->LST
2 OVER SIZE 1 - SUB DUP SIZE OVER 1 DUP SUB +
"\<<'x'\<<" STR\-> \->LST
3 OVER 2 GET 2 \->LIST 2 ROT 5 GET 2 \->LIST
2 \->LIST SWAP POS { 2 GET }
{ DUP SIZE 1 == { 1 GET } { \->PRG } IFTE } IFTE
\>> 'IN' STO
This may also be used to import ascii files from your SD card
(after recalling them to the stack);
if it turns out that you *want* to evaluate the results,
you can of course then just press EVAL.
The same program may be used in ROM type 48,
provided that we supply additional small SysRPL programs
for \->LST and \->PRG
Is that all you wanted? ;-)
[r->] [OFF]
Christoph Giesselink
From: "John H Meyers" <jhme...@miu.edu>
Newsgroups: comp.sys.hp48
Sent: Thursday, December 15, 2005 6:14 AM
Subject: Re: Using the HMS functions in a user RPL program.
> [..]
> Emulated calc results can also be turned into strings
> and then copied out of Emu48 using "Edit > Copy String"
> (after which you can paste into anything else)
> [..]
Without doubt this is working, but newer versions of Emu48 use "Edit >
Copy/Paste Stack" having the ability to copy/paste real numbers (since
v1.39) and HP49G precision integers (since v1.40) directly.
Cheers
Christoph
Heiko Arnemann
> >> \<< ABS 0. RND OVER ABS
> >> OVER 0. == .2 * 3. PICK 2. == .002 * + HMS+
> >> SWAP RND 0. HMS+ SWAP SIGN * \>> 'HMSRND' STO
>
> Required by Murphy's law: "the user will supply unanticipated args"
Yes, but in my opinion there are maybe three "good" reactions
of the program.
1. The program gives an error
2. The program gives a wrong result
3. The program crashes
In my oppinion, the documentation should be clear for
the allowable input. In case a user tries non documenented
input, it his on its own responsibility, or it should
give an error.
...
> 0. RND also treats n exactly the same way as the RND command
> itself, which actually *rounds* its own arg n to an integer
> (so to be as consistent as possible,
> we don't substitute IP, for example).
Ok, this is a feature, but would not be a need if you would
have defined (positive) "integer" between 0. and 12.
> > I understand, you need the rounding, in
> > case somebody would use 0.4 or 2.4 for n
> > but this should be part of the documentation?
> > n should be a positive integer.
>
> Maybe we can speed up UserRPL by not carefully checking
> args at all; after all, everyone *should* read the AUR,
> and *should* supply the right sort of args all the time :)
...
> Is it not better to make something foolproof,
> so that no one could ever get to that point
> of having anything fail, at least not without
> helpful information being provided on the spot
> to enable the user to correct and try again?
I would say e.g.:
0.55 -2.4 HMSRND makes no sence.
The best result should be an Error.
> > The first "ABS" seems to be also dispensable,
> > because your require n>=0?
>
> We *request* n>=0, but who can stop the user from disobeying?
> (and then perhaps complaining of incorrect results).
Your are right, but the "only possible" result should
be an error as well, or maybe a "RTNM"
where N stands for nice :-)
> If n<0 is supplied, that would cause "scientific" rounding;
> no doubt we could make a much larger program to even handle it,
> but I wasn't interested in going so far,
> as it makes even less sense than rounding to 1 or 3 places :)
"Scientific" rounding is a very good argument for giving
an error, because the user might have assumed to much,
and he will not get the answer he has expected.
> The formal way to treat unwanted args is to rigorously test
> and perform 515 DOERR ("Bad Argument Value"), but often for
> trivial UserRPL programs I choose to just make the arg conform;
> in this case treat neg args the same as positive :)
I would prefer this way for "our" example,
and I hope you would change your mind, too :-)
> > It looks, you are very careful :-)
>
> I learned from Professor Murphy herself :)
I never met "her" and I was`nt aware he is
a she, but this would be consitant with her/his law ;-)
> > - NOT instead of "0. ==" seem to be an improvement
>
> Slightly shorter and probably faster.
>
> Slightly less intelligible too,
I aggree, there is another property of good
programs, which is typically faced out, when
stating a challenge in the NG :-)
____
Joes prog.
> takes any real integer and returns the number of bits
> required to express it in binary (your mission,
> should you choose to accept it,
> is to figure out how it works :)
>
> \<< 0 1 ROT FOR
> DEPTH 1 +
> DEPTH STEP
> \>>
It seems to be that DEPTH has a bug, because
it is not doing the documented job.
It seem to count a kind of "invisible" stack levels.
Very nice example, but I would
not accept/use it. Nevertheless, congratulations
to Joe :-)
> > PICK3 seem to be a little "picky",
> > because of incompatibility with HP48S[X]/G[X]
...
> It might be a "very good thing" to have a sure way
> of distinguishing all current models, including
> to distinguish any 49G from any 49G+;
> how to do that in such a way that
> it runs correctly even on a 48S?
I am not aware of the 48S. The VERSION
command was helpfull for me, when
making a program compatible for HP
49G-series and 49G 49gII/+.
> But it certainly wouldn't be worth the great effort
> to figure out which model,
> just to decide between 3. PICK and PICK3 :)
I aggree, and would state, it is an *extra *benefit
to state that a program is compatible with
lets say HP 48GS/X, but who takes care,
nowadays?
> > It should be noted, that SIGN is flag-sensitive.
> > In Exact mode (-105 CF)
> > 0 SIGN gives "?"
>
> Ouch, please don't tell Prof. Murphy that I've flunked again ;-)
Ok, but I have talled Prof. Parisse some years ago.
It is a matter of taste, but 0 SIGN should give
0 and not "?" :-) It can simply be defined to be
zero. You might know, how a mathematician could
catch a lion?
He places himself in a cage, and defines
outside to be inside.
> Yes, you should insert 0. + before SIGN to force to real
> (in an HP48 compatible way, of course :)
Thanks for the "compatibility hint".
It is becoming a demanding job, developing
perfect programs :-)
> > PS: I am wondering about the format you
> > post your programs. I have not yet figured
> > out, how to extract and easily transfer to
> > my emulator. I am missing the header
> > for ascii-transfer. Any hint appreciated.
>
> I have always used translation mode 3 and decimal points (not commas),
> which I have always thought to be evident, so after my first year
> I stopped cluttering up my posts with %%HP: T(3)F(.);
> [which then itself had to be explained each time,
> telling people not to actually type that into the editor :]
You might have missed my word combination
"easily transfer" :-) I am heavily laughing,
while trying to understand your "well saved" answer.
I suggest to define this as "off topic". Please give
me the chance to follow up. I will give a
new topic for this issue, in case my "to do list"
does not explode.
Best regards
Heiko
John H Meyers
> in my opinion there are maybe three "good" reactions
> of the program.
> 1. The program gives an error
It is often more trouble in small UserRPL programs
to analyze inputs and find things to fault in them
than to do something which is simple and sensible
with any input at all.
If the built-in RND command accepts any numeric input
and does something sensible with it,
why should we be any fussier?
I did the same -- made my suggested function
act just like the built-in, and never complain
unless fed a non-number (the nice thing about UserRPL
is that we can just pass args to built-in commands,
and let them do their own checking,
no need to spend our own extra effort on it :)
> 2. The program gives a wrong result
> 3. The program crashes
> In my opinion, the documentation should be clear
> for the allowable input. In case a user tries
> non-documented input, it is his own responsibility,
> or it should give an error.
I take it that you would not want an ABS braking system
in your auto; better that if you don't know exactly how
to pump the brakes just right, go ahead and skid off the road;
it's you own fault, after all, for not practicing until
you have mastered every detail about controlling the car :)
I recommend that you do all SysRPL programming,
and skip even the up-front error checking to save time;
if you make a mistake (which of course you never will),
then get wrong results or crash, it serves you right :)
>> 0. RND also treats n exactly the same way as the RND command
> Ok, this is a feature
> but would not be a need if you would have
> defined (positive) "integer" between 0. and 12."
Is it not considered an art of our time
to create environments which by themselves
guide a user into spontaneously doing the right thing,
and which deliver what (s)he would want
without even having to study details?
If it were up to you, would we ever have had
DHCP, or Plug-and-Play device installation,
or any of those other things which we take for granted,
where someone has anticipated our needs
and taken care of them, even without our asking?
If it takes only one or two words in a program
to provide such a thing, why should we not just do it?
> I would say e.g.:
> 0.55 -2.4 HMSRND makes no sence.
> The best result should be an Error.
It takes me, the programmer, much more work
to analyze for and reject all possible problem inputs
then to simply condition any input to act sensibly.
Sometimes the user can then take advantage of this,
just as I take advantage of all the built-in error checking
(and other useful behaviors)
to spare me the trouble of having to do it all at my level :)
> Joe's program:
>> \<< 0 1 ROT FOR
>> DEPTH 1 +
>> DEPTH STEP
>> \>>
>
> It seems to be that DEPTH has a bug, because
> it is not doing the documented job.
The program does exactly what it should;
if you'd read the programming manual (or AUR) very thoroughly
and applied that knowledge carefully,
then you would see how it works,
despite the "red herring" false clue.
Hint: you can change the word DEPTH
to any other word (e.g. try LINSOLVE or GBASIS or \pi),
and it will still work.
> Very nice example, but I would not accept/use it.
Do you use MS Windows, and/or other programs which are
all the time giving false or misleading messages?
Same thing, then :)
> Nevertheless, congratulations to Joe :-)
Yes, both he and God accomplish some things
without anyone's ever understanding how :)
> I am not aware of the 48S.
> The VERSION command was helpful for me,
> when making a program compatible for HP
> 49G-series and 49G 49gII/+.
There is no VERSION command in the original HP48
(which was called HP48S); the command was introduced
with the HP48G.
I imagine that VERSION in the 48Gii might say
"HP48" rather than "HP49" -- but the 48Gii
is really an HP49 inside, right?
So how do we use VERSION properly to determine
the type of underlying product (for binary addresses)?
Can we say that if (and only if)
VERSION DROP "." POS is true [1],
then it's a "ROM type 49"?
What about distinguishing 49G+ from 49G?
(often we don't care, but sometimes we need
to know the screen size, for example).
> You might have missed my word combination
> "easily transfer" :-) [posted programs to Emu48?]
Well, how hard is storing this one line program into Emu48
(for ROM type *49* only), and then typing "IN"
after pasting the copied program text to the stack?
@ For ROM type *49* only:
\<< 3 TRANSIO \->STR #2F34Dh SYSEVAL + STR\-> \>> 'IN' STO
And if you want also to *export* any stack object from Emu48
(as text, ready for copying to clipboard):
@ For ROM type *49* only:
\<< 3 TRANSIO STD 64 STWS \->STR #2F34Fh SYSEVAL \>> 'OUT' STO
All the rest of the posted stuff was for die-hards
who want to be able to parse and generate those
pesky ascii headers, which I never use anyway :)
For those who prefer to transfer to a real calc via cable,
no calc helper programs are needed -- just set up the transfer
software to use ascii and to *assume* translation mode 3;
store the posted program text into a new file using Notepad,
and drag it to the Conn4x window. If a warning message comes up
about there being no header, just click the "text" button.
Now Heiko, please *save* and *study* these complicated directions,
until you have mastered what to do and don't need more help :)
[r->] [OFF]
John H Meyers
> newer versions of Emu48 use "Edit > Copy/Paste Stack"
> having the ability to copy/paste real numbers (since v1.39)
> and HP49G precision integers (since v1.40) directly.
So now that I've installed the "service pack 1.40",
how do I just paste the *string* "123" on the stack?
I do *not* want it changed into the real number 123.
I want to paste the *string* "123" !
[but this now seems impossible]
Does this mean that a new *feature*
has wiped out the original simple ability
to just paste any string?
That's sort of Microsoft-like :)
Thanks for the many updates and improvements
(BTW, in these latest versions, the first thing
it always does with my 49G is to turn off,
no matter what key is pressed, or drop any object
on stack, etc. -- it just turns off, no matter what).
All best wishes.