Strange nested subroutine behaviour in hp50G

[Eduardo]

See this simple program for the lower cumulative normal:

\<< \-> m v x \<< 1 m v x UTPN - \>> \>> LTPN STO

e.g..

1.

.5

.8

LTPN

and you get .388648705395 on the stack



And now, with this one, we have the inverse function:

\<< \-> m v y \<< \<< y m v $xx LTPN - \>> '$xx' 2 v y * * v - m +
ROOT '$xx' PURGE \>> \>> ILCN STO

or this simplified version, if anyone wants to follow the code without
unnecessary details:

\<< \-> m v y \<< \<< y m v $xx LTPN - \>> '$xx' 2. ROOT \>> \>> ILCN
STO

e.g..

1.

.5

.388648705395

ILCN

and you get .80000000001



And now, the problem. I define now a gamma cumulative distribution:

\<< \-> a b x \<< x a 1 - ^ x NEG b / EXP * b a ^ a GAMMA * / \>>
\>> GDIS STO

\<< \-> a b x \<< 0 x a b t GDIS t \.S \>> \>> LTPG STO

e.g..

2.

3.

4.

LTPG

.384940011064



And now I want the inverse cumulative gamma, i.e..

\<< \-> a b y \<< \<< y a b $xx LTPG - \>> '$xx' 4. ROOT \>> \>> ILCG
STO

and then,

2.

3.

.384940011064

ILCG

Error: Undefined Name

and garbage, probably from the nested subroutine GDIS, in the stack.



I remark how similar the two inverse function implementations are:

\<< \-> m v y \<< \<< y m v $xx LTPN - \>> '$xx' 2. ROOT \>> \>> ILCN
STO

\<< \-> a b y \<< \<< y a b $xx LTPG - \>> '$xx' 4. ROOT \>> \>> ILCG
STO



I am used to top-down programming in Fortran 95. Once a subroutine is
tested, I can forget about the 'lower-layer' subroutines called. Here,
the problem seems to be in the nested subroutine GDIS, who gives a
numerical result and works perfectly when tested alone, and even when
called from the upper-level LTPG, that also works perfectly. I don't
understand what is happening, and moreover, I have no idea how to
solve the problem.

It seems as if the calculator were trying to somehow symbolically
'unroll' the nested subrutine tree before doing numerical evaluation.
I have tried to override this behaviour by including EVAL and/or \-
>NUM in the subroutines, but with no success.

[Georg Bisseling]

I think I got it. Please don't mind if I'm wrong.

> \<< \-> m v y \<< \<< y m v $xx LTPN - \>> '$xx' 2 v y * * v - m +
> ROOT '$xx' PURGE \>> \>> ILCN STO

^^^^^^^^^^^

This destroys the global variable $xx.

> \<< \-> a b y \<< \<< y a b $xx LTPG - \>> '$xx' 4. ROOT \>> \>> ILCG
> STO

And this tries to use it afterwards.

Did you know that there is a single step debug mode?
At least on the HP48GX there is..

ciao
Georg

[Joe Horn]

> Did you know that there is a single step debug mode?
> At least on the HP48GX there is..

If you have flag -117 set, the debug menu on the 50G is accessed by
pressing left-shift EVAL (PRG), NXT, NXT, RUN.

If flag -117 is clear, press left-shift EVAL (PRG), up-arrow, ENTER.

Unlike the HP48, the DBUG command on the HP49/50 is programmable.

-Joe-

[ba...@barend.plus.com]

There are some inverse statistical formulas that
the 50g has problems with in RPN mode. See my rant here:
http://h30499.www3.hp.com/t5/Calculators/HP-50g-bug-some-inverse-statistical-formulas-in-RPN-mode/m-p/2372937

I have had the problem with inverse CHI^2 function.
I got it working as follows: Store the inverse
equation as (inv CHI as example) `p=1-UTPC(v,x)`
(note the ` ` and not ' ' - the equation can be
entered with these ticks in RPN mode, or entered
normally in algebraic mode and saved).

I saved it as ICHI.

As it is a pre-stored equation, only global variables
work and trying to make it work with local variables
gives errors again.

So my program that uses it looks like this:
<< 'v' STO 'p' STO 'ICHI' RCL 'x' 4 ROOT >>

note the need to RCL 'ICHI', otherwise it gives an error again.

(global variables will be created, you have to purge them at the end of the program to reduce clutter in your VAR area).

Hope this helps
B

[pin224466]

On Tuesday, May 15, 2012 9:39:55 PM UTC-5, Eduardo wrote:
>
> And now, the problem. I define now a gamma cumulative distribution:
>
> \<< \-> a b x \<< x a 1 - ^ x NEG b / EXP * b a ^ a GAMMA * / \>>
> \>> GDIS STO
>
> \<< \-> a b x \<< 0 x a b t GDIS t \.S \>> \>> LTPG STO
>
> e.g..
>
> 2.
>
> 3.
>
> 4.
>
> LTPG
>
> .384940011064
>
>
>
> And now I want the inverse cumulative gamma, i.e..
>
> \<< \-> a b y \<< \<< y a b $xx LTPG - \>> '$xx' 4. ROOT \>> \>> ILCG
> STO
>
> and then,
>
> 2.
>
> 3.
>
> .384940011064
>
> ILCG
>
> Error: Undefined Name
>
> and garbage, probably from the nested subroutine GDIS, in the stack.
>

> \<< \-> a b y \<< \<< y a b $xx LTPG - \>> '$xx' 4. ROOT \>> \>> ILCG
> STO
>
>

can anyone explain the reason that the original ILCG program produces an error in the GDIS subroutine (the error is related to the use of the variable 't' passed to GDIS from the LTPG program)

Yet, a revised ILGC program, that looks identical to the original ILCG program but uses an algebraic formula enclosed in back tics (not single quotes) apparently works??


ORIGINAL ILCG PROGRAM that causes error in subroutine GDIS:

\<< \-> a b y
\<<
\<< y a b $xx LTPG - \>>
'$xx' 4. ROOT
\>>
\>>

2.
3.
.384940011064
ILCG

Error: Undefined Name

REVISED ILCG PROGRAM that functions:

\<< \-> a b y
\<<
\<< `y-LTPG(a,b,$xx)` \>> @back tics used not quotes
'$xx' 4. ROOT
\>>
\>>

2.
3.
.384940011064
ILCG
3.99999999997

[ba...@barend.plus.com]

On Sunday, May 20, 2012 8:51:27 PM UTC+1, pin224466 wrote:
>
> can anyone explain the reason that the original ILCG
> program produces an error in the GDIS subroutine (the
> error is related to the use of the variable 't' passed
> to GDIS from the LTPG program)
>
> Yet, a revised ILGC program, that looks identical
> to the original ILCG program but uses an algebraic
> formula enclosed in back tics (not single quotes)
> apparently works??
>

Bad implementation by HP!!
I have the same problem with some inverse statistical functions,
see my initial post on the problem here:
http://h30499.www3.hp.com/t5/Calculators/HP-50g-bug-some-inverse-statistical-formulas-in-RPN-mode/m-p/2372937
It seems to be evident now that it's a problem in more than just
those functions.

It made me very frustrated. Something that should have
been straightforward to implement, took me some time
and ugly work-arounds to make it work.

By the way, your work-around is nicer than mine, and I will see
if it can work in my program, it will make it a bit neater.

Regards,
B

[John H Meyers]

On 5/15/2012 9:39 PM, Eduardo wrote:

\<< \-> a b x \<< x a 1 - ^ x NEG b / EXP * b a ^ a GAMMA * / \>> \>> 'GDIS' STO

Which seems to be equivalent to:

'GDIS(a,b,x)=x^(a-1.)*EXP(-x/b)/(b^a*GAMMA(a))' DEFINE

Eduardo continues:

\<< \-> a b x \<< 0 x a b t GDIS t \.S \>> \>> 'LTPG' STO

Which seems to be equivalent to:

'LTPG(a,b,x)=\.S(0,x,GDIS(a,b,t),t)' DEFINE

Eduardo continues:

> And now I want the inverse cumulative gamma, i.e..

\<< \-> a b y \<< \<< y a b $xx LTPG - \>> '$xx' 4. ROOT \>> \>> 'ILCG' STO

> and then: 2. 3. .384940011064 ILCG

This seems to work fine with my versions of your programs,
yielding the answer 4.00000000001

So, what's the problem with your versions of your programs?

Note that I did not need to use any `Backquoted_ALG_mode_expression`

> Error: Undefined Name

You did look on the stack, yes?

So you should see that the "undefined name"
is the global variable 't'
which you even neglected to 'quote' in your LTPG program
(the same way as you didn't originally quote names into which you stored programs,
which would not work very well if any of those named variables already existed) --
what if 't' exists and has a number stored in it, for example,
causing the number to be recalled each time an unquoted t is encountered
in your LTPG program, thus passing that number,
rather than a 'variable of integration' to the integral function?

Try this, for example: 5 't' STO 2 3 4 LTPG

Note that this does not bother _my_ version of LTPG, however -- why not?

Replacing each t by 't' in your version of LTPG
still does not solve your problem, however -- why not?

Bart later writes:

> Bad implementation by HP!!

Hardly -- it's lack of attention to or knowledge of
subtle details of programming,
some of the details being how variables and functions are evaluated,
the need to sometimes quote arguments and/or evaluate results,
another detail being in the difference between
numeric vs. symbolic inputs and results (and the role of flag -3),
particularly in regard to integration,
the difference between integration with stack arguments
vs. integration expressed as an algebraic function,
and, I suppose, given the other `Backquoted_ALG_mode_expression`
variations that were suggested, how those are actually evaluated.

Care must also be taken that input to functions which create local variables
does not already involve any local variables of the same names,
nor require run-time compiling of the same name for any global variable,
in which case the current "inner" local variable value
replaces any "outer" value of the same-named variable from the calling program,
while the "inner" function is being evaluated.

Within calculator ROM, some internal local names are prefixed with an invalid
name character (usually an apostrophe) to ensure non-conflict with
any user-provided names; other SysRPL functions use NULLLAMs indexed by numbers,
rather than named local variables.

[r->] [OFF]

[pin224466]

On Wednesday, May 23, 2012 2:02:17 AM UTC-5, John H Meyers wrote:
> On 5/15/2012 9:39 PM, Eduardo wrote:
>
> \<< \-> a b x \<< x a 1 - ^ x NEG b / EXP * b a ^ a GAMMA * / \>> \>> 'GDIS' STO
>
> Which seems to be equivalent to:
>
> 'GDIS(a,b,x)=x^(a-1.)*EXP(-x/b)/(b^a*GAMMA(a))' DEFINE
>
> Eduardo continues:
>
> \<< \-> a b x \<< 0 x a b t GDIS t \.S \>> \>> 'LTPG' STO
>
> Which seems to be equivalent to:
>
> 'LTPG(a,b,x)=\.S(0,x,GDIS(a,b,t),t)' DEFINE
>
> Eduardo continues:
>
> > And now I want the inverse cumulative gamma, i.e..
>
> \<< \-> a b y \<< \<< y a b $xx LTPG - \>> '$xx' 4. ROOT \>> \>> 'ILCG' STO
>
> > and then: 2. 3. .384940011064 ILCG
>
> This seems to work fine with my versions of your programs,
> yielding the answer 4.00000000001
>
> So, what's the problem with your versions of your programs?
>
> Note that I did not need to use any `Backquoted_ALG_mode_expression`
>
> > Error: Undefined Name
>
> You did look on the stack, yes?
>
> So you should see that the "undefined name"
> is the global variable 't'

yes, the undefined variable 't' has been known. It should have been noted in the previous post but wasn't

see initial postings here:
http://h30499.www3.hp.com/t5/Calculators/I-have-RTFM-but-this-is-really-odd/td-p/5659005

> which you even neglected to 'quote' in your LTPG program
> (the same way as you didn't originally quote names into which you stored programs,
> which would not work very well if any of those named variables already existed) --

have become too used to keyboard shortcuts on 50g... alpha alpha L T P G ENTER STO......... the calculator takes automatically adds the single quotes around LTPG.

> what if 't' exists and has a number stored in it, for example,
> causing the number to be recalled each time an unquoted t is encountered
> in your LTPG program, thus passing that number,
> rather than a 'variable of integration' to the integral function?
>
> Try this, for example: 5 't' STO 2 3 4 LTPG
>
> Note that this does not bother _my_ version of LTPG, however -- why not?
>
> Replacing each t by 't' in your version of LTPG
> still does not solve your problem, however -- why not?

again, this was noted in early posts

http://h30499.www3.hp.com/t5/Calculators/I-have-RTFM-but-this-is-really-odd/td-p/5659005

and you are correct that it is not smart programming practice for the 50G; however..

even when the 't' was quoted as you are suggesting that did not solve the issue that was found as you pointed out.

But also note, that many of us are still learning the nuances/subtleties of 50G programming. Learned syntax from fortran, pascal, etc has to be sometimes
un-learned.

>
> Bart later writes:
>
> > Bad implementation by HP!!
>
> Hardly -- it's lack of attention to or knowledge of
> subtle details of programming,
> some of the details being how variables and functions are evaluated,
> the need to sometimes quote arguments and/or evaluate results,
> another detail being in the difference between
> numeric vs. symbolic inputs and results (and the role of flag -3),
> particularly in regard to integration,
> the difference between integration with stack arguments
> vs. integration expressed as an algebraic function,
> and, I suppose, given the other `Backquoted_ALG_mode_expression`
> variations that were suggested, how those are actually evaluated.
>
> Care must also be taken that input to functions which create local variables
> does not already involve any local variables of the same names,
> nor require run-time compiling of the same name for any global variable,
> in which case the current "inner" local variable value
> replaces any "outer" value of the same-named variable from the calling program,
> while the "inner" function is being evaluated.
>
> Within calculator ROM, some internal local names are prefixed with an invalid
> name character (usually an apostrophe) to ensure non-conflict with
> any user-provided names; other SysRPL functions use NULLLAMs indexed by numbers,
> rather than named local variables.
>
> [r->] [OFF]

Your point is well taken. Except, to the OP's point, some have RTFM.

Where is all this knowledge of the subtle details of programming the 50G found... not so much in the manuals, but most likely from the experience of people who have used/programmed this series of HP calculators.

Especially those subtle programming details about when to use an algebraic formula instead of a stack based formula....on a stack based machine.

so I guess I'm missing or misunderstanding one of your points....

Your solutions was to use an algebraic in place of the stack based formula.

your algebraic formulas do not use single quotes around the variables passed or used in subsequent routines....

I'm missing the reason the original stack based forumula does not work?

unless you are going to say that it has to do with your point...."Care must also be taken that input to functions which create local variables

does not already involve any local variables of the same names,

nor require run-time compiling of the same name for any global variable....."


In which case...

@ GDIS function rolled up into LTPG function
@ LTPG function requires a variable input on the stack
\<< \-> a b x t
\<< 0 x t a 1 - 10 SF
^ 11 SF t NEG b / EXP
* b a ^ a GAMMA * / t
\.S
\>>
\>> 'LTPG' STO

2
3
4
'aa'
LTPG
.384940011064

@ ILCG function requires a variable input on the stack
\<< \-> a b y z
\<< 10 CF 11 CF
\<< a b $xx z LTPG -

\>> '$xx' 4. ROOT
\>>
\>> 'ILCG' STO

2
3
.384940011064
'aa'
ILCG

Error: undefined name

[Eduardo]

After learning so much from your posts, I hardly dare to reply, but
here it is: your solution is an algebraic traslation and works much
slower. I had come to this one, nearly equal (see
http://h30499.www3.hp.com/t5/Calculators/I-have-RTFM-but-this-is-really-odd/td-p/5659005)

ILCG3
\<< \-> a b y
\<< `ROOT('\.S(0,$xx,
t^(a-1)*EXP(-t/b)/(b^
a*GAMMA(a)),t)=y','
$xx',3)`
\>>
\>>

That is very close to yours (at least, the whole GDIS is in algebraic
form). But it takes 163 seconds to give the correct answer, whereas
this 'nearly fully RPL' takes 67 s:

ILCG2
\<< \-> a b y
\<< `y-LTPG(a,b,$xx
)` '$xx' 3 ROOT
\>>
\>>

(where LTPG is defined as \<< \-> \Ga \Gb x \<< 0. x \Ga \Gb t PDFG
t \.S \>> \>>, and PDFG is \<< \-> \Ga \Gb x \<< x \Ga 1 - ^ x NEG
\Gb / EXP * \Gb \Ga ^ \Ga GAMMA * / \>> \>> )

I may not have fully grasped the programming subtleties you mean with
that 't' between or not between quotes (I will RTFM harder) but what I
would like to know is how to code a RPL version of the program that
works. The fortran-style version between quotes solves the problem,
but, as we all know, algebraic versions are more likely to be slower,
as is the case here.

Moreover, consider the following, much more uncanny behaviour: compile
ILCG2 (toghether with LTPG and PDFG, of course) in a library, and try
to run it. It doesn't work.

I have posted a full description of this question, with a ready-to-use
hpdir with the three versions of the program (namely: one that never
works, a second that runs but not after compilation, and the third
one, fully algebraic, that always works but more than twice slower) in
that other forum. Below is a copy of the post, and the enclosed dir.

In summary, two are the main questions I am asking myself (and perhaps
other users) now:
a) What is the RPN version of the program that works, or if there is
none.
b) Now, why the enclosed ILCG2 program stops working if compiled in a
library, whereas ILCG3 does? That is the most strange...

The post:
I enclose an hpdir and the ascii translated code, directly from the SD
card. There you will find:
1) Self-explanatory variable MYFLAGS,
2) Small program V that puts on your stack this three numbers as
argument for the functions, so we can work on exactly the same numbers
and get coherent results:
2.
3.
.384940011064

3) Small program ILCG1 whose code is nearly identical to an
implementation with UTPN that works. But ILGG1 doesn't work.

4) Small RPL program ILCG2 that works perfectly, but NOT after
compiling it with CRLIB. Press V and you get the arguments in the
stack:
2.
3.
.384940011064
ILCG2

and, after 67 seconds, you should see the answer:
4.

Note that ILCG2 happily drops a global variable '$xx' left as an
excrement... And this will cause an error the next time you run the
program. So, after every calculation with ILCG2, you have to purge
that variable (in my version this is done automatically at the end of
ILCG2, but I want to keep the code as short and centered on the
problem as possible).

You will see I have enclosed the necessary CRLIB variables ($VISIBLE,
$ROMID etc). If anyone else reads this: run 256 ATTACH and then CRLIB,
followed by 1 STO. Warmstart with ON+F3 and the commands ILCG2 and
ILCG3 will be in the CAT list.

Well, after compilation and warmstart, try to use ILGC2 from any place
out of the enclosed dir (for example, at HOME) and you will see that
is DOESN'T work. Moreover, you will see a lot of garbage in the stack,
as if the code had invalid characters... That is the main question
here, why a program that works OK, stops working after successfully
compiling it with CRLIB?

Finally, you can use the fully algebraic version, ILCG3, both in raw
and compiled form. It works. However, it is much slower: 163 seconds
to find the same answer as the RPL version that only works if not
compiled...

+++++++++++++++++++++++++++++++++++++++++++++++

%%HP: T(3)A(R)F(.);
DIR
MYFLAGS {
# 20000204190FF2h
# 0h
# 8010012202000000h
# 0h }
V
\<< 2. 3.
.384940011064
\>>
ILCG3
\<< \-> a b y
\<< `ROOT('\.S(0,$xx,
t^(a-1)*EXP(-t/b)/(b^
a*GAMMA(a)),t)=y','
$xx',3)`
\>>
\>>
ILCG2
\<< \-> a b y
\<< `y-LTPG(a,b,$xx
)` '$xx' 3 ROOT
\>>
\>>
ILCG1

\<< \-> a b y
\<<
\<< y a b $xx
LTPG -

\>> '$xx' 3 ROOT
\>>
\>>
PDFG
\<< \-> \Ga \Gb x
\<< x \Ga 1 - ^ x NEG
\Gb / EXP * \Gb \Ga ^ \Ga
GAMMA * /
\>>
\>>
LTPG
\<< \-> \Ga \Gb x
\<< 0. x \Ga \Gb t PDFG
t \.S
\>>
\>>
$CONFIG 0
$ROMID 917
$TITLE "PSTA"
$HIDDEN { PDFG LTPG
}
$VISIBLE { ILCG2
ILCG3 }
END

[ba...@barend.plus.com]

@ John H Meyers

>
> Bart later writes:
>
> > Bad implementation by HP!!
>
> Hardly -- it's lack of attention to or knowledge of
> subtle details of programming,
> some of the details being how variables and functions are evaluated,
> the need to sometimes quote arguments and/or evaluate results,
> another detail being in the difference between
> numeric vs. symbolic inputs and results (and the role of flag -3),
> particularly in regard to integration,
> the difference between integration with stack arguments
> vs. integration expressed as an algebraic function,
> and, I suppose, given the other `Backquoted_ALG_mode_expression`
> variations that were suggested, how those are actually evaluated.
>
> Care must also be taken that input to functions which create local variables
> does not already involve any local variables of the same names,
> nor require run-time compiling of the same name for any global variable,
> in which case the current "inner" local variable value
> replaces any "outer" value of the same-named variable from the calling program,
> while the "inner" function is being evaluated.
>
> Within calculator ROM, some internal local names are prefixed with an invalid
> name character (usually an apostrophe) to ensure non-conflict with
> any user-provided names; other SysRPL functions use NULLLAMs indexed by numbers,
> rather than named local variables.
>

Then please show me how to enter the following formulas in RPN mode:
(found on p17-15 of the User Guide)
p = 1 – UTPN(u,s2,x)
p = 1 – UTPT(v,t)
p = 1 – UTPC(v,x)
p = 1 – UTPF(vN,vD,F)

Let's start off simply, and NOT with a program, just to store each one
as an equation in the VAR menu.


@ pin224466

Thank you for your multiple program quote solution, although it cost an
extra 76 bytes in the program, it saved 100 bytes of storing the formula
separately, so a 36 byte saving overall - but best of all I do not have
to remember to copy the equation separately from the program, it's all
in one now.

-B

[Eduardo]

On 23 mayo, 08:02, John H Meyers <jhmey...@nomail.invalid> wrote:

Moreover, I have just tested your implementation, and it takes 196
seconds (!) departing from the same guess value (3.). Clearly, it
would be desirable to solve the problem without translations to
algebraic. Not for the specific program itself (I have never had the
need for an inverse cumulative gamma in my life) but in the interest
of learning the subtleties of RPL programming.

To learn all that subtleties from the documentation is nearly
impossible, no matter how hard you RTFM's. Users that complain about
the documentation not fully covering the calculator functionality,
have (with all my respect) not really grasped the scope of the
calculator capabilities. Fortran 95, to mention an example, is a
relatively small set of rules with less than 80 intrinsic functions,
many of them redundant for historical backwards compatibility. It has
no graphical capabilities and no symbolic manipulations. The goal of
Fortran is very specific, namely solid numerical implementations
departing from a small, well standarized set of pieces. Despite the
fact that Fortran is so small in its definition, its standard ANSI
definition is a document of about 350 pages, and it is barely a
defining document with no explanations... So, how big should be a
'complete' documentation for this calculator, with more than 2000
functions, radically different working areas (symbolic calculus,
graphic representation, numerical computations...) and "archeological"
superposition of commands from much older models and programming
styles that must interact with each other? Decompiling and working in
the ROM must be a real hell !

So it is always very nice to learn directly on the arena, sharing
information and problems with other users. In that sense, your post
are in most cases very useful, so thanks very much (I take this
opportunity to say it).

[Eduardo]

A rule of thumb for writing such expressions in RPN is "quotes inside
back quotes", i.e.
`'p = 1 – UTPN(u,s2,x)'`
and now you can store it in a variable.

Much the same, if you want to plot one of that things. In the plot
setup dialog, the EQ shall be:
{`'1-UTPN(U,S2,X)'`}

[pin224466]

>
>
> @ pin224466
>
> Thank you for your multiple program quote solution, although it cost an
> extra 76 bytes in the program, it saved 100 bytes of storing the formula
> separately, so a 36 byte saving overall - but best of all I do not have
> to remember to copy the equation separately from the program, it's all
> in one now.
>
> -B

The use of back tics to solve the original inverse gamma function is the OP's, (Eduardo's) solution.

[ba...@barend.plus.com]

Thanks, I was aware of the back-ticks, but it was the extra programming
brackets that helped.

-B

[ba...@barend.plus.com]

> >
> > Then please show me how to enter the following formulas in RPN mode:
> > (found on p17-15 of the User Guide)
> > p = 1 – UTPN(u,s2,x)
> > p = 1 – UTPT(v,t)
> > p = 1 – UTPC(v,x)
> > p = 1 – UTPF(vN,vD,F)
> >
> > Let's start off simply, and NOT with a program, just to store each one
> > as an equation in the VAR menu.
> >
> > @ pin224466
> >
> > Thank you for your multiple program quote solution, although it cost an
> > extra 76 bytes in the program, it saved 100 bytes of storing the formula
> > separately, so a 36 byte saving overall - but best of all I do not have
> > to remember to copy the equation separately from the program, it's all
> > in one now.
> >
> > -B
>
> A rule of thumb for writing such expressions in RPN is "quotes inside
> back quotes", i.e.
> `'p = 1 – UTPN(u,s2,x)'`
> and now you can store it in a variable.
>
> Much the same, if you want to plot one of that things. In the plot
> setup dialog, the EQ shall be:
> {`'1-UTPN(U,S2,X)'`}

OK, I wanted Mr. Meyers to answer, but thank you Eduardo for your good
investigations and answers to the problem.

My point is:
I know you can enter it that way, but you still cannot select the
UTPN, UTPT, UTPC or UTPF functions from the "MATH -> PROBABILITY" menu,
you have to type U T P N etc manually.

Also, once you have one of the expressions on the stack, now you try to edit
it to change it to one of the other 3, it doesn't work!

Now do it in Algebraic mode: you can enter it with straight quotes only, as
per the expected norm, and select the functions from the "MATH -> PROBABILITY"
menu.

If this was to be blamed on our inability to understand the "subtleties" of
the 50g, then shouldn'd we see similar behaviour in both modes?

Also, Mr. Meyers' DEFINE option may work, but this is first and foremost an
RPN calculator, why can't we build the equation the RPN way? And that was
the question that Mr. Meyers seemed to totally miss from Pin224466's post.

Why the fiddlyness to get these kind of equations to work? I maintain that
if it's got to do with the subtleties of the 50g, then it's the subtleties
of HP's bad implementation!

It seems Mr. Meyers made the mistake of jumping to answer before first fully
investigating the matter. Did he even bother to read the post that I linked
to on the HP Communities forum? And try the equations for himself in both modes?

He browsed Pin's and my replies, seeing without seeing, reading without comprehending, like my partner's students in school.

Or does he just not want to hear anything bad about the 50g, it has to be
the user's fault for not understanding the bad implementation.

"The eye sees only what the mind is prepared to comprehend."
ROBERTSON DAVIES, quoted in The Wordsworth Dictionary of Quotes

"The common eye sees only the outside of things, and judges by that, but the seeing eye pierces through and reads the heart and the soul, finding there capacities which the outside didn't indicate or promise, and which the other kind couldn't detect."
MARK TWAIN, Joan of Arc

[pin224466]

On Thursday, May 24, 2012 10:49:15 AM UTC-5, ba...@barend.plus.com wrote:
> Why the fiddlyness to get these kind of equations to work? I maintain that
> if it's got to do with the subtleties of the 50g, then it's the subtleties
> of HP's bad implementation!
>
> It seems Mr. Meyers made the mistake of jumping to answer before first fully
> investigating the matter. Did he even bother to read the post that I linked
> to on the HP Communities forum? And try the equations for himself in both modes?
>
> He browsed Pin's and my replies, seeing without seeing, reading without comprehending, like my partner's students in school.
>
> Or does he just not want to hear anything bad about the 50g, it has to be
> the user's fault for not understanding the bad implementation.
>
> "The eye sees only what the mind is prepared to comprehend."
> ROBERTSON DAVIES, quoted in The Wordsworth Dictionary of Quotes
>
> "The common eye sees only the outside of things, and judges by that, but the seeing eye pierces through and reads the heart and the soul, finding there capacities which the outside didn't indicate or promise, and which the other kind couldn't detect."
> MARK TWAIN, Joan of Arc

for best results, it's usually best to cast the net wide and then draw it back rather than just drop it over the side.....

give a man a fish... feed him for a day..... teach a man to fish.... feed him for a lifetime....

[John H Meyers]

On 5/23/2012 12:57 PM, pin224466 wrote:

> have become too used to keyboard shortcuts on 50g... alpha alpha L T P G ENTER STO.........
> the calculator takes automatically adds the single quotes around LTPG

It may sometimes look as if so, but it actually does not.

Try storing a program \<< 123 \>> into variable XYZ,
in the manner you describe above.

Now try storing \<< 456 \>> into that same variable,
in exactly the same manner again.

The second attempt will fail unless you explicitly quote the name yourself.

This is because of the rules of evaluation of global names:

A global name is always evaluated if not explicitly quoted.
During evaluation of the name, if no such variable is defined,
the result of the evaluation is the name itself;
otherwise the content of any found variable is evaluated,
which in the case of repeating the name in the exercise above
will recall and run the first program as soon as you type its name,
instead of leaving the name on the stack
for you to store the second program into -- this is exactly
what you expect when you want to run programs that you have
previously stored, but the rules which make that happen
are always in effect, even if you have some other intent in mind,
and may have forgotten that you've already created variable 'XYZ'

The way in which objects are displayed can also fool us,
because the quotes displayed on the stack
when a stack level contains only a global name like 'XYZ'
are visually added so that we can recognize the object type
as a global name, but when we type 'XYZ' (with quotes)
into a program, these quotes actually generate additional objects --
the quote on the left side is an object which causes the name which follows
to be left on the stack without being evaluated,
and the quote on the right side basically does nothing
except to appear as the quote on the right side
when this snippet of UserRPL syntax is displayed!

When we type _only_ 'XYZ' (with explicit quotes)
into the command line and press ENTER, the first thing which happens
is the creation of a program containing three objects,
but that just-created program is then immediately evaluated,
the initial quote causing the unevaluated name to remain on the stack,
regardless of whether or not a variable of that name already exists,
and the final quote doing nothing, leaving only the global name XYZ on the stack,
displayed with surrounding quotes which are not what we typed in,
but are shown simply to inform us of the type of object left on the stack.

All this may seem either confusing or annoying at first,
but everything is the consequence of rules which are always in effect,
all the time, and which are also designed to make UserRPL
turn out to do what we would want it to do,
most of the time without having to think about it,
but occasionally, when the results surprise us,
we can always explain them via reference to the rules of evaluation,
which are always in effect, all the time.

The slightly ironic thing is that everything is completely explicit
and unambiguous in SysRPL, whereas UserRPL is designed to accomplish
what the manual claims it does, often via a conspiracy between the
UserRPL compiler and decompiler (the stack displayer)
to hide the mechanics of how it all really happens.

[r->] [OFF]

[John H Meyers]

On 5/24/2012 10:49 AM, bart... wrote:

> Why the fiddlyness to get these kind of equations to work? I maintain that
> if it's got to do with the subtleties of the 50g, then it's the subtleties
> of HP's bad implementation!

You might as well fault God for the subtleties of creation,
so much of which is still abused and misused by human beings,
most of whom don't have the depth of experience
to truly know what their own consciousness comes from,
nor the slightest sense of how to be proper stewards
of the planet which took billions of years
to develop what contains everything they could ever need,
as if provided exactly as in the 23rd psalm,
but which they threaten to completely destroy in but a few generations
of vast hubris coupled with vast ignorance.

> It seems Mr. Meyers made the mistake of jumping to answer before first fully
> investigating the matter. Did he even bother to read the post that I linked
> to on the HP Communities forum? And try the equations for himself in both modes?
>
> He browsed Pin's and my replies, seeing without seeing, reading without comprehending,
> like my partner's students in school.

"Seems" is the operative word there;
I wrote to show other approaches to defining programs
to evaluate essentially algebraic expressions,
which are often forgotten or never known.

I could have also defined the last program in the same way,
but I sort of cheated by trying it in advance,
and seeing that it wouldn't work,
which no one other than myself seems to realize ;-)

> Or does he just not want to hear anything bad about the 50g, it has to be
> the user's fault for not understanding the bad implementation.

The level of what was posted suggests that the user is a relative
beginner in programming this specific calculator series,
so why not expand the thread to introduce more information
about alternate techniques, and a bit of "Socratic method"
to spur some further thinking?

It is still a matter of our collectively not understanding everything,
rather than a "bad implementation" -- aspects of the ALGebraic mode
(which are invoked by the `back quotes`) and of the built-in (and new)
algebraic evaluation of all expressions in this series
can be pretty hard to fathom, and if anything is "bad" about it,
this difficulty of comprehending everything all at once is what's "bad."

If you think otherwise, how about identifying yourself exactly what's
"bad" (wrong, buggy) and specifics of how to "fix" it?

In my own experiences with other programming, such as Unix shell
(Bourne/Bash shell) programming, I have had to often experiment
a great deal to produce robust complex scripts that always work,
no less even work at all, but I find that those shells are actually
constructed so extremely well that any desired goal can be achieved,
eventually, after I spend enough time to get all the rules of
quoting/expending arguments, etc., to work together -- the development
of consistent original rules that ultimately enable anything to be
accomplished is the masterpiece of the authors of those shells.

I can attribute the hard work it took me to develop some scripts
only to the limitations of the ability of my own mind
to integrate all of the rules and implications
into a complete understanding of how to use them,
and I take exactly the same view in regard to the experience,
practice, and experimentation that it may take
to master all that's available in the current calculator system.

The CAS is convoluted, one main reason being the severe constraints
of the platform, and it does have some bugs, but it's quite a great
accomplishment for the building materials out of which it had to be made.

> "The eye sees only what the mind is prepared to comprehend."
> ROBERTSON DAVIES, quoted in The Wordsworth Dictionary of Quotes

> "The common eye sees only the outside of things, and judges by that,
> but the seeing eye pierces through and reads the heart and the soul,
> finding there capacities which the outside didn't indicate or promise,
> and which the other kind couldn't detect."
> MARK TWAIN, Joan of Arc

I would have expected someone who selected those quotes
to have found them in complete agreement with all that I have said.

-[ ]-

[Eduardo]

> The level of what was posted suggests that the user is a relative
> beginner in programming this specific calculator series,
> so why not expand the thread to introduce more information
> about alternate techniques, and a bit of "Socratic method"
> to spur some further thinking?

In fact, I am just at the beginning of learning how to program the
calculator. That "bit of socratic method" in your posts is very nice,
because it puts the reader in the correct direction without giving
away much written information, so everyone can choose whether to
invest time by investigating further on the question or to remain at a
surface level. There is a danger, however, in that 'clues' you give
(e.g. "You did look on the stack, yes?" ), namely that, although they
are highly pedagogic, some people can missunderstand them and see them
as arrogant, BOFH-like behaviour, but that is not the case in general.

> I can attribute the hard work it took me to develop some scripts
> only to the limitations of the ability of my own mind
> to integrate all of the rules and implications
> into a complete understanding of how to use them,
> and I take exactly the same view in regard to the experience,
> practice, and experimentation that it may take
> to master all that's available in the current calculator system.

That is another point of view I agree with, after developing hundreds,
perhaps millions, lines of numeric implementations in Fortran. That is
the only possible attitude that leads to learning and making progress.
Many people struck again the first difficulty and react by start
complaining: 'this is a bug' / 'this should have been explained in the
documentation' / 'this should have been implemented' / 'my roommate
has a TI model X and he surely can do that' and so on. It may me a bad
consequence of the way of thinking we have in modern western
countries: expecting someone else to solve your problems because you
have paid xxx hundred $/€ for the machine.


And regarding the programming issue of the post, I have arrived to the
conclusion that the only way to have the program working in all
circumstances is the "fully algebraic" version, specially if you want
to code a user-defined function that could be called from another
program. Take this simple example to define a function that returns
the argument ^2:

\<< \-> X 'X*X' \>> \>> 'ALGX2' STO @ Algebraic version
\<< DUP * \>> \>> 'RPNX2' STO @ RPN version
\<< \-> X \<< X X * \>> \>> 'ALTRPNX2' STO @Alternative rpn version

Now, although all the three versions work perfectly, there seems to be
no way to code a definite integration (from 0 to t) of this function
using a version other than the algebraic ALGX2. I mean something like:
\<< \-> T '\.S(0,T,ALG(X),X)' \>>
but using RPNX2 or ALTRPNX2 instead of ALGX2. ("Error: Non algebraic
in expression"). Or any other way. Simply try to involve RPNX2 or
ALTRPNX2 in a definite integration by any way. For instance try
manually to get from the stack the value of the integral between 0 and
5; ALGX2 works, but not the other versions:

0
5
'ALG(X)' @here even single quotes work well.
'X'
@and now press RS TAN


Which leads me to the following personal conclusion: "pure RPN style"
UserRPL coding is more prone to error, and that UserRPL compiler/
decompiler does a better work on "algebraic-like" UserRPL code,
although it leads to less efficient implementations. In other words
(and this is an important point on which your opinion can make me save
me a lot of hours in the next future), the rule would be "learn SysRPL
(Kalinowsky book) or restrict yourself to algebraic-style UserRPL (49G
manuals or Parisse docs)". Algebraic-like UserRPL is easy to implement
and safe. SysRPL is powerfull and efficient. But RPN-like UserRPL is a
bad choice, because the winning in efficiency is not worth the
additional efforts and problems, and eventually you will be forced to
use pieces of algebraic code (like is the case posted here). Right?

> The slightly ironic thing is that everything is completely explicit
> and unambiguous in SysRPL, whereas UserRPL is designed to accomplish
> what the manual claims it does, often via a conspiracy between the
> UserRPL compiler and decompiler (the stack displayer)
> to hide the mechanics of how it all really happens.

From that paragraph, I understand that SysRPL is more close to be a
solid, well stablished set of rules for a programming language with no
surprises, where nothing is assumed but has to be explicitely declared
and correctly used or the program will not work. It is important to
understand these facts before investing time on learning a programe
language, if the goal is to acquire the ability for complex
implementations.

[Uergil]

In article
<a0865409-5f0c-4258...@x21g2000vbc.googlegroups.com>,

Eduardo <ngc...@gmail.com> wrote:

> \<< \-> X 'X*X' \>> \>> 'ALGX2' STO @ Algebraic version

Shouldn't this be

\<< \-> X \<< 'X*X' \>> \>>

?
--
"Ignorance is preferable to error, and he is less
remote from the- truth who believes nothing than
he who believes what is wrong.
Thomas Jefferson

[Eduardo]

On 28 mayo, 19:06, Uergil <Uer...@uer.net> wrote:
> In article
> <a0865409-5f0c-4258-b676-7ab8044a6...@x21g2000vbc.googlegroups.com>,

>
>  Eduardo <ngc6...@gmail.com> wrote:
> > \<< \-> X 'X*X' \>> \>> 'ALGX2' STO @ Algebraic version
>
> Shouldn't this be
>
>    \<< \-> X \<< 'X*X' \>> \>>
>
> ?
> --
> "Ignorance is preferable to error, and he is less
>  remote from the- truth who believes nothing than
> he who believes what is wrong.
>                      Thomas Jefferson

When you create the user-defined function F(X)=X^2 in the EQW followed
by DEF, it is stored automatically as \<< \-> 'X*X' \>> \>>. I don't
know if coding from the scratch in the same way is 100% orthodox, but
it seems to work...

[Uergil]

In article
<ce63355e-491b-42e8...@3g2000vbx.googlegroups.com>,

On my hp50
'F(X) = X^2' DEF
produces the program named 'F' of form

\<< \-> X 'X*X' \>>,

not

\<< \-> 'X*X' \>>

which my HP50 regards invalid syntax.

[John H Meyers]

I take responsibility for such conclusions as being due to
my poor lessons :)

Some commands require algebraic arguments or "user-defined functions"
because of basic principles, such as that there's no general way
to take a derivative (or integral) of an arbitrary program,
hence no programs are allowed.

However, yet another paradox is that although algebraic expressions
are entered and _display_ as humans expect them to look,
they are compiled internally into RPN/RPL programs,
which are executed in pure RPN fashion when actually calculating.

E.g. 'X^2' is actually the RPN program X 2 ^
but when the latter has a "prolog word" claiming to be algebraic,
rather than a program, then the decompiler displays it
in an algebraic style, even though, during execution,
all "algebraic" expressions compute using RPL,
which is the only mode that the internal operating system has.

The \->PRG command of internal library 256 will reveal what
simple algebraic expressions actually contain, but for more general
and complex expressions, a program '\->RPN' that was created for HP48 series
calculators produces an RPN equivalent for almost any algebraic expression,
using the special action of OBJ\-> upon algebraic objects to dissect them.

>> The slightly ironic thing is that everything is completely explicit
>> and unambiguous in SysRPL, whereas UserRPL is designed to accomplish
>> what the manual claims it does, often via a conspiracy between the

>> UserRPL compiler [command line] and decompiler (the stack displayer)

>> to hide the mechanics of how it all really happens.

> From that paragraph, I understand that SysRPL is more close to be a

> solid, well established set of rules for a programming language with no
> surprises, where nothing is assumed but has to be explicitly declared

> and correctly used or the program will not work. It is important to
> understand these facts before investing time on learning a program

> language, if the goal is to acquire the ability for complex
> implementations.

This again proves that my random asides make poor educational material :)

SysRPL is more primitive, and its compiler has little work to do;
UserRPL might be said to be a "higher level language,"
and its compiler has a great deal of work to do,
to break down what the user wants into little SysRPL bits
which make it happen, many of which are "invisible"
when UserRPL programs are displayed.

UserRPL also goes to great lengths to be crash-proof, whereas SysRPL
has no safeguards at all, and the slightest mistake can easily
crash, hang, or worse (e.g. cause all user data saved in memory to be lost).

Let's credit you with being fundamentally right all along -- no one
would ever guess why some attempts to accomplish what you wanted
fail while others succeed -- we should probably blame it
on the contortions of the CAS, which include the fact that
algebraic expression evaluation in the 49/50 series
always uses a special CAS function, while in the original 48 series,
algebraic evaluation was identical to all other RPL evaluation;
this may have translated into how using some algebraic definitions
worked better than RPL programming, yet I also mentioned
that making the final program algebraic as well would cause it to fail again.

Just like in some other contorted areas of programming,
sometimes the only way to get something to work
is to keep tinkering until it manages to do what you want,
at least that's what I have to do, when I'm unable to untangle
some of the inner knots.

I'm aware of some cases in even my SysRPL functions
(e.g. Full screen CHOOSE for HP48 series using its small font)
where I got it to work, using other code found in ROM as a hint,
and I gave it exhaustive tests which failed to uncover any bug,
yet I feel more as if the horse just galloped away on its own
rather than that I rode it and told it where to go :)

[r->] [OFF]

[Eduardo]

On 29 mayo, 18:43, Uergil <Uer...@uer.net> wrote:
> In article

> <ce63355e-491b-42e8-95fa-fe7b254c9...@3g2000vbx.googlegroups.com>,

On 29 mayo, 18:43, Uergil <Uer...@uer.net> wrote:
> In article

> <ce63355e-491b-42e8-95fa-fe7b254c9...@3g2000vbx.googlegroups.com>,

Yes, of course, the \-> X can't be omitted; that is a typo in the last
post. I tried to answer to

> > > Shouldn't this be
>
> > > \<< \-> X \<< 'X*X' \>> \>>

and the answer is: "No. It works as I wrote it in the first place:
\<< \-> X 'X*X' \>>

[Eduardo]

Thanks!