Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

HP-35s & Surveyors

151 views
Skip to first unread message

reth

unread,
Jul 27, 2007, 9:26:21 PM7/27/07
to
Hi
Surveyors should be disappointed with otherwise excellent new HP-35s
lacking massively used P->R and R->P, strange decision IMO. There is a
workaround and that I did first:

My program label S is dedicated for subroutines and here are the first
ones:

S001 LBL S
S002 GTO S004
S003 GTO S015
S004 X<>Y
S005 SIN
S006 X<>Y
S007 LASTx
S008 COS
S009 X<>Y
S010 *
S011 X<>Y
S012 LASTx
S013 *
S014 RTN
S015 i
S016 *
S017 +
S018 ABS
S019 LASTx
S020 ARG
S021 360 ; optional, to get angles between 0 and 360
degrees
S022 RMDR ; optional, to get angles between 0 and 360
degrees
S023 X<>Y
S024 RTN

If not obvious, XEQ S002 is equivalent of theta,r -> x,y on the HP-33s
and XEQ S003 - of x,y -> theta,r

The other thing I find weird is the presence of ->cm conversion;
should be ->m but... nothing is perfect. BTW I'm nicely surprised of
the keyboard quality of the HP-35s, IMO 9 out of 10, 10 out of 10
being the one of the HP-41.

Cheers,

Reth

Dieter

unread,
Jul 28, 2007, 1:32:34 PM7/28/07
to
reth wrote:

> My program label S is dedicated for subroutines and here are the first
> ones:

> ...

> S019 LASTx
> S020 ARG
> S021 360 ; optional, to get angles between 0 and 360 degrees
> S022 RMDR ; optional, to get angles between 0 and 360 degrees

IMHO it's not a good idea to hard code such a constant like 360 degrees.
What if a different angle mode happens to be set? Radians requires 2 pi
instead, and in grad mode it's 400 g. This is especially important for
routines like yours that are designed to be universally used by other
programs.

However, there's a simple workaround: have that value calculated by a
simple inverse trig function, like acos(0) = 90 deg (or equivalent).
On a 41 I would simply code -1 ACOS ST+ X to get a 360-deg-equivalent.
Since the 35s uses 37 (in words: thirty-seven ) bytes for any number in
a program, a more memory-saving way to get 360 deg might be

ENTER
CLX
ACOS ; 90 deg = pi/2 rad = 100 grads
ENTER
+ ; 180 deg = pi rad = 200 grads
ENTER
+ ; 360 deg = 2 pi rad = 400 grads

Okay, it saves memory, not running time. <8)

After all, in this particular case there is a more elegant solution:
If negative values are okay, use a simple SIN ASIN combination. 8-)

> The other thing I find weird is the presence of ->cm conversion;
> should be ->m

Should better be -> mm.
Meters are converted to feet and vice versa.

Dieter

reth

unread,
Jul 28, 2007, 5:05:19 PM7/28/07
to
On Jul 29, 3:32 am, Dieter <didis.mehl...@web.de> wrote:
> reth wrote:
> > My program label S is dedicated for subroutines and here are the first
> > ones:
> > ...
> > S019 LASTx
> > S020 ARG
> > S021 360 ; optional, to get angles between 0 and 360 degrees
> > S022 RMDR ; optional, to get angles between 0 and 360 degrees
>
> IMHO it's not a good idea to hard code such a constant like 360 degrees.
> What if a different angle mode happens to be set? Radians requires 2 pi
> instead, and in grad mode it's 400 g. This is especially important for
> routines like yours that are designed to be universally used by other
> programs.

that's why it says *optional*, take them 2 lines off and there you
go ;)

> However, there's a simple workaround: have that value calculated by a
> simple inverse trig function, like acos(0) = 90 deg (or equivalent).
> On a 41 I would simply code -1 ACOS ST+ X to get a 360-deg-equivalent.
> Since the 35s uses 37 (in words: thirty-seven ) bytes for any number in
> a program, a more memory-saving way to get 360 deg might be
>
> ENTER
> CLX
> ACOS ; 90 deg = pi/2 rad = 100 grads
> ENTER
> + ; 180 deg = pi rad = 200 grads
> ENTER
> + ; 360 deg = 2 pi rad = 400 grads
>
> Okay, it saves memory, not running time. <8)
>
> After all, in this particular case there is a more elegant solution:
> If negative values are okay, use a simple SIN ASIN combination. 8-)

If negative values are OK, do absolutely nothing

> > The other thing I find weird is the presence of ->cm conversion;
> > should be ->m
>
> Should better be -> mm.
> Meters are converted to feet and vice versa.

Unit for length in SI is *meter*; surveyors worldwide use either
metres or feet thus ->m and ->ft would be handy

> Dieter

regards,

reth

Dieter

unread,
Jul 28, 2007, 5:32:00 PM7/28/07
to
reth wrote:

> that's why it says *optional*, take them 2 lines off and there you
> go ;)

Well, the idea was to provide a *better* option. 8-)

> If negative values are OK, do absolutely nothing

That's also a nice solution. <8)

> > > The other thing I find weird is the presence of ->cm conversion;
> > > should be ->m
> >
> > Should better be -> mm.
> > Meters are converted to feet and vice versa.
>
> Unit for length in SI is *meter*; surveyors worldwide use either
> metres or feet thus ->m and ->ft would be handy

We're talking about two different things. You mentioned the "-> cm"
function which converts from inches to centimeters. My point is that
inches to *millimeters* would have been a better idea.

An additional conversion between m and ft would be nice as well -
agreed.

Dieter

reth

unread,
Jul 28, 2007, 6:04:11 PM7/28/07
to

Sure Dieter,
I just can't miss the fact that the HP-35s is a bit surveyor-
unfriendly :(
I'm really curious who and what for will use inch->cm conversion?
House wifes? :)

Cheers,

Reth

reth

unread,
Jul 29, 2007, 1:30:24 AM7/29/07
to
On Jul 29, 3:32 am, Dieter <didis.mehl...@web.de> wrote:
> reth wrote:
> > My program label S is dedicated for subroutines and here are the first
> > ones:
> > ...
> > S019 LASTx
> > S020 ARG
> > S021 360 ; optional, to get angles between 0 and 360 degrees
> > S022 RMDR ; optional, to get angles between 0 and 360 degrees
>
> IMHO it's not a good idea to hard code such a constant like 360 degrees.
> What if a different angle mode happens to be set? Radians requires 2 pi
> instead, and in grad mode it's 400 g. This is especially important for
> routines like yours that are designed to be universally used by other
> programs.

That's why it says "optional", take them 2 lines off and there you go.
I prefer doing it that way and I don't care about waisting a few
bytes, there is plenty.

> Okay, it saves memory, not running time. <8)
>
> After all, in this particular case there is a more elegant solution:
> If negative values are okay, use a simple SIN ASIN combination. 8-)

If negative values are OK then you need no solution at all, see above.

> > The other thing I find weird is the presence of ->cm conversion;
> > should be ->m

> Should better be -> mm.
> Meters are converted to feet and vice versa.

I'm talking surveying here, surveyors worldwide use either metres or
feet. Than in SI system meter is the unit for length;


> Dieter


regsards,
reth

John H Meyers

unread,
Jul 29, 2007, 5:44:00 AM7/29/07
to
On Sat, 28 Jul 2007 17:04:11 -0500:

> who and what for will use inch->cm conversion?

http://www.hpmuseum.org/45.jpg [HP, in<->cm]

http://www.hpmuseum.org/55.jpg [HP, in<->mm, ft<->m]

http://keysan.com/big/pic34753.html [Sharp EL344R, ft<->m]

http://www.casionz.co.nz/default.asp?ObjectID=269&StockCode=MC100
(in<->cm, ft<->m, yd<->m, mi<->km>)

http://www.datamath.org/Sci/Slimline/Converter.htm [TI]
(mi,km,yd,m,ft,in,cm,mm: any<->any)

Note that retail outlets (including HP)
seem to prefer small, blurry photos :)

.

0 new messages