Any Surveyors?

[buffalo]

(John said)
That's funny, I get pretty much the opposite result. On a physical 50g:
<< CYLIN ->V2 RECT V-> >> about 49ms
#30EA6h SYSEVAL 26ms
<< ->V2 CYLIN V-> RECT >> 33ms
#30E79h SYSEVAL 10ms
making the SYSEVALs about twice as fast as well as not having to mess with system flags. Still seems silly to me to not include P->R and R->P as user functions.
John

My Post ***PLEASE NOTE BACKUP MEMORY PRIOR TO USING SYSEVALS***
---------
number format.....Std
Cas Modes _Approx (unticked)

stack (pre P->R, p->r)
4:
3:
2: 555.555
1: 55.9319444444

stack (pre R->P, r->p)
4:
3:
2: 311.20926336
1: 460.206641004

P->R << DEG #30EA6h SYSEVAL >> note now with DEG that RMollov found for me
R->P << DEG #30E79h SYSEVAL >> note DEG

i have just made up IMO a better program Timer

<< TICKS DEPTH ROLLD *stick program in here* TICKS DEPTH ROLL - B->R 8192 / >> 'Timer' STO

p->r << ->V2 CYLIN V-> RECT >>
r->P << CYLIN ->V2 RECT V-> >>
Results
-------
P->R 0.03942 secs (9 buttons pushed) different because of DEG
p->r 0.06091 " (4 buttons pushed) ??? different to John
R->P 0.02417 " (9 buttons pushed) different because of DEG
r->p 0.0487 " (4 buttons pushed) same as John

[RMollov]

(03-29-2016 08:21 AM)buffalo Wrote:  Results
-------
P->R 0.03942 secs (9 buttons pushed) different because of DEG
p->r 0.06091 " (4 " ) ???
R->P 0.02417 " (9 " ) different because of DEG
r->p 0.0487 " (4 " ) same as John

It's not only that. RPL has vectors and complex numbers. To use the result of P->R or R->P further in a program you'll end up with longer and less readable code.

[RMollov]

(03-29-2016 08:21 AM)buffalo Wrote:  (John said)
That's funny, I get pretty much the opposite result. On a physical 50g:
<< CYLIN ->V2 RECT V-> >> about 49ms
#30EA6h SYSEVAL 26ms
<< ->V2 CYLIN V-> RECT >> 33ms
#30E79h SYSEVAL 10ms
making the SYSEVALs about twice as fast as well as not having to mess with system flags. Still seems silly to me to not include P->R and R->P as user functions.
John

My Post ***PLEASE NOTE BACKUP MEMORY PRIOR TO USING SYSEVALS***
---------
number format.....Std
Cas Modes _Approx (unticked)

stack (pre P->R, p->r)
4:
3:
2: 555.555
1: 55.9319444444

stack (pre R->P, r->p)
4:
3:
2: 311.20926336
1: 460.206641004

P->R << DEG #30EA6h SYSEVAL >> note now with DEG that RMollov found for me
R->P << DEG #30E79h SYSEVAL >> note DEG

i have just made up IMO a better program Timer

<< TICKS DEPTH ROLLD *stick program in here* TICKS DEPTH ROLL - B->R 8192 / >> 'Timer' STO

p->r << ->V2 CYLIN V-> RECT >>
r->P << CYLIN ->V2 RECT V-> >>
Results
-------
P->R 0.03942 secs (9 buttons pushed) different because of DEG
p->r 0.06091 " (4 " ) ???
R->P 0.02417 " (9 " ) different because of DEG
r->p 0.0487 " (4 " ) same as John

About timing programs search for James M. Prange's contribution.

OT: I miss Mr Prange's postings. Can anyone shed some light about his status?

[buffalo]

RMollov said

Quote:If you add argument checking as you should when using SYSEVAL timing may get different. Also timing is negligible in this case. Pressing a single button probably takes longer than 49ms Wink
What's more, P->R and R->P are essential for the older RPN style programming (excluding HP42s). Unless one wants to replicate 1:1 HP41 program to HP48, RPL has lots of options dealing better with this. I've written quite a big suite of surveying programs for both HP41 & HP48/28 doing the same thing and noticed that I never actually needed P->R and R->P on the HP48 (or 28).

i agree RMollov if only running a program in single instances speed isn't much of an issue
(whats .0324 m/sec between friends)
however if running a more extensive routine which might invoke (evaluate whatever the correct word is :-)) our little P->R hundreds of times then the extra speed could help. i am setting up a routine(not survey related) that will need the fastest SORT (thingy) i can find. i have looked at some machine language (can get huge speed increases but 10 minutes of reading this stuff causes my brain to bleed (& i estimate i would need 10^9 years to learn it) .

[RMollov]

(03-29-2016 09:22 AM)buffalo Wrote:  RMollov said

Quote:If you add argument checking as you should when using SYSEVAL timing may get different. Also timing is negligible in this case. Pressing a single button probably takes longer than 49ms Wink
What's more, P->R and R->P are essential for the older RPN style programming (excluding HP42s). Unless one wants to replicate 1:1 HP41 program to HP48, RPL has lots of options dealing better with this. I've written quite a big suite of surveying programs for both HP41 & HP48/28 doing the same thing and noticed that I never actually needed P->R and R->P on the HP48 (or 28).

i agree RMollov if only running a program in single instances speed isn't much of an issue
(whats .0324 m/sec between friends)
however if running a more extensive routine which might invoke (evaluate whatever the correct word is :-)) our little P->R hundreds of times then the extra speed could help. i am setting up a routine(not survey related) that will need the fastest SORT (thingy) i can find. i have looked at some machine language (can get huge speed increases but 10 minutes of reading this stuff causes my brain to bleed (& i estimate i would need 10^9 years to learn it) .

Sorry mate, I thought you were after some surveying stuff.
Still, read above. Dealing with single numbers on the stack rather than vectors or matrices is a thing of the past. So, I congratulate HP48 development team for not making polar-to-rectangular routines part of the userRPL system.
This concludes my input here.
Cheers,

[buffalo]

Your Post
---------
Sorry mate, I thought you were after some surveying stuff.
Still, read above. Dealing with single numbers on the stack rather than vectors or matrices is a thing of the past. So, I congratulate HP48 development team for not making polar-to-rectangular routines part of the userRPL system.

My Post
-------
Not much call for programs where i work, everything is calculated using CAD software & uploaded into Leica Total Stations (jiggers) via memory cards, however we just got a loan of the latest Leica model TS16 & it takes SD cards (haven't tried a HP50 SD card yet)
The age of programming may be returning.


BTW **IMPORTANT** news to hand

number format.....Std
Cas Modes _Approx (unticked) <----- correction please tick box

*******WHY?*********

with Cas Mode _Approx (unticked)

STACK
4:
3:
2: any whole number
1: any whole number

R->P

STACK
4:
3:
2: complete rubbish **********
1: complete rubbish **********

A GOOD REASON TO STAY AWAY FROM SYSEVALS (unless you really need to)

[buffalo]

(03-22-2016 02:25 AM)BrendanJ Wrote:  hey i am currently in the process of writing a basic program for the hp50g to calculate the co-ordinates from one mark to the next knowing the northing and easting a (point A) and having a distance and bearing.
so for this is what i have got so any help will be appreciated i am a bit stuck
<<RECT
"ENTER N1 AND E1"
PROMPT ->V2 -> NE
<< CYLIN
"ENTER DIST AND BRG"
PROMPT HMS-> ->V2 RECT >>
>>
(I symbolising the arrow as cant do on keyboard ->)
so once it has converted the distance and bearing to rect i need it to add to the northing and easting of the station entered first and give me answer
i am capable of doing this all manually but i just want to write my own program as i am doing this on a daily basis in the field to check things cheers Help greatly needed.

My Post
---------
Hey Brendan (here is yet another way)

ENTER Northing then Easting

STACK
4:
3:
2: 100.000 (remember that northing is here)
1: 100.000 (remember that easting is here )

ENTER Distance then Bearing

STACK
4: 100.000 (nth)
3: 100.000 (est)
2: 555.555 (dist is here)
1: 55.5555 (brg is here)

<< HMS-> P->R >> 'start' STO (note start is lower case)

start (press VAR then the key u just made)

STACK
4: 100
3: 100
2: 311.209 (change in nth)
1: 460.207 (change in est)

<< SWAP DEPTH ROLL + DEPTH ROLLD + >> 'finish' STO (again lower case)

finish (press VAR then the key u just made)

STACK (and the answer)
4:
3:
2: 411.209 (nth)
1: 560.207 (est)

(make this var beforehand, it is used above)
<< ->V2 CYLIN V-> RECT >> 'P->R' STO

(u could have made the 'start' & 'finish' vars beforehand also)

[John Keith]

(03-29-2016 11:36 AM)buffalo Wrote:  Your Post
---------
Sorry mate, I thought you were after some surveying stuff.
Still, read above. Dealing with single numbers on the stack rather than vectors or matrices is a thing of the past. So, I congratulate HP48 development team for not making polar-to-rectangular routines part of the userRPL system.

My Post
-------
Not much call for programs where i work, everything is calculated using CAD software & uploaded into Leica Total Stations (jiggers) via memory cards, however we just got a loan of the latest Leica model TS16 & it takes SD cards (haven't tried a HP50 SD card yet)
The age of programming may be returning.


BTW **IMPORTANT** news to hand

number format.....Std
Cas Modes _Approx (unticked) <----- correction please tick box

*******WHY?*********

with Cas Mode _Approx (unticked)

STACK
4:
3:
2: any whole number
1: any whole number

R->P

STACK
4:
3:
2: complete rubbish **********
1: complete rubbish **********

A GOOD REASON TO STAY AWAY FROM SYSEVALS (unless you really need to)

You are correct, the SYSEVALs do not return the correct answer if the inputs are exact integers. Type checking is indeed necessary for general use but the SYSEVALs are significantly faster inside a loop.

Also, while I agree that P->R and R->P are not strictly necessary in RPL, the lack of these functions may be disconcerting to users unfamiliar with RPL, and it may not be obvious how to replace them.

John

[buffalo]

[John said]
You are correct, the SYSEVALs do not return the correct answer if the inputs are exact integers. Type checking is indeed necessary for general use but the SYSEVALs are significantly faster inside a loop.
Also, while I agree that P->R and R->P are not strictly necessary in RPL, the lack of these functions may be disconcerting to users unfamiliar with RPL, and it may not be obvious how to replace them.
John

[my post]
thanks John using Sysevals in loops seems like the place for them, i will have to delve into the scary world of sysrpl to learn a bit about argument & type checking (or else end up with a result as shown above with weird interger result) i have the link to sysrpl user guide at Erics site.
i will attempt to post an example using what else but the P->R function, (we must all be getting a little sick of this one)

to do list(so far)
------------------
*check for real number (integer no good)
*check for minimum of 2 numbers
*check that 1 of the numbers doesn't exceed 360 (max range for bearing)

[BrendanJ]

Hey guys thanks for the replys on the programming now I have another ? I have written another program to calculate the bearing and distance between 2 known nothing and eastings I have it working so it will calculate it correctly if I enter the higher north and east in first but I want it to work either way so I need to put a parameter or condition on it so if the bearing is negative then it calculates to add 360 to get correct bearing can someone help me with this please I will post pictures of what I have written so far that works one way

[BrendanJ]

Hey guys thanks for the replys on the programming now I have another ? I have written another program to calculate the bearing and distance between 2 known nothing and eastings I have it working so it will calculate it correctly if I enter the higher north and east in first but I want it to work either way so I need to put a parameter or condition on it so if the bearing is negative then it calculates to add 360 to get correct bearing can someone help me with this please I will post pictures of what I have written so far that works one way

[Brad Barton]

(04-17-2016 07:35 PM)BrendanJ Wrote:  ...a parameter or condition on it so if the bearing is negative then it calculates to add 360 to get correct bearing can someone help me with this please I will post pictures of what I have written so far that works one way

When working with vectors, I always run this simple subroutine before any angle output, because as you know the calculator will return angles in the -180 to +180 degree range. You can call it anything you like. I call it TEST360. I keep it in the Home directory so I can call it from any program I write.

Code:

IF 0. < THEN
   360. +
END

[DavidM]

(04-18-2016 01:54 AM)Brad Barton Wrote:  When working with vectors, I always run this simple subroutine before any angle output, because as you know the calculator will return angles in the -180 to +180 degree range. You can call it anything you like. I call it TEST360. I keep it in the Home directory so I can call it from any program I write.

Code:

IF 0. < THEN
   360. +
END

Brad, did you mean to put a DUP in there somewhere? Seems like one might be needed (either before or after the "IF" most likely).

I'm also wondering if this would work just as well:

Code:

360. MOD

Are there situations where it won't provide the correct results?

[BrendanJ]

thanks so much this has all helped me i have finished my program and it works a treat now applied two conditions within it

[Brad Barton]

(04-18-2016 02:25 AM)DavidM Wrote:  

(04-18-2016 01:54 AM)Brad Barton Wrote:  When working with vectors, I always run this simple subroutine before any angle output, because as you know the calculator will return angles in the -180 to +180 degree range. You can call it anything you like. I call it TEST360. I keep it in the Home directory so I can call it from any program I write.

Code:

IF 0. < THEN
   360. +
END

Brad, did you mean to put a DUP in there somewhere? Seems like one might be needed (either before or after the "IF" most likely).

Yes, you'd need a DUP in there for it to work correctly. Thanks for pointing that out.

Quote:I'm also wondering if this would work just as well:

Code:

360. MOD

Are there situations where it won't provide the correct results?

I like this very much, and I don't see any cases where it wouldn't return the correct answer. Thanks for the tip.