->NUM not the opposite of ->Q ?

[aca...@aztechnetworking.com]

Hello All,

Hopefully this isn't too dumb of a question...

Why can I do this:

2.3*X ->Q
result = 23/10*X

but not this:

23/10*x ->NUM
result = "Undefined Name"

I expected that to return:
result = 2.3*x


It seems that ->Num can't handle expressions with variables but ->Q can? Is there a different command I should use?

Thanks,

Aaron Carlow

[aca...@aztechnetworking.com]

Forgot to mention this is on a 50G.

[Virgil]

In article <a7a894e0-4d99-4c63...@googlegroups.com>,

Try this little program:
\<< -105 SF EVAL \>>
Which first puts things in approximate mode, after which EVAL will
convert all numerical expressions to decimals, among other things.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Aaron Carlow
--

[julieta...@gmail.com]

On Friday, April 19, 2013 7:31:43 PM UTC-7, Virgil wrote:
>
> Try this little program:
>
> \<< -105 SF EVAL \>>
>

But in order to maintain exact mode, I'd need to clear that flag, right?

\<< -105 SF EVAL -105 CF \>>

I've stored that in a VAR as program ANUM (Approximate Number), but I just can't shake the feeling that this should be included or that ->NUM should be the logical opposite of ->Q (or ->QPI).

Having never used a CAS system before of any kind, and learning to use the 50G i get the idea that the workflow is to use ->Q when starting a problem (if necessary) so that the ALG48/Erable functions work without needing to switch to approx mode, and then using ->NUM to convert the final answer to a decimal (if needed).

Am I way off base with my assumptions here?

Thanks for the assistance in understanding all this.

[Virgil]

In article <c008f734-bc75-4f8d...@googlegroups.com>,

julieta...@gmail.com wrote:

> On Friday, April 19, 2013 7:31:43 PM UTC-7, Virgil wrote:
> >
> > Try this little program:
> >
> > \<< -105 SF EVAL \>>
> >
>
> But in order to maintain exact mode, I'd need to clear that flag, right?

Yes!

>
> \<< -105 SF EVAL -105 CF \>>
>
> I've stored that in a VAR as program ANUM (Approximate Number), but I just
> can't shake the feeling that this should be included or that ->NUM should be
> the logical opposite of ->Q (or ->QPI).
>
> Having never used a CAS system before of any kind, and learning to use the
> 50G i get the idea that the workflow is to use ->Q when starting a problem
> (if necessary) so that the ALG48/Erable functions work without needing to
> switch to approx mode, and then using ->NUM to convert the final answer to a
> decimal (if needed).
>
> Am I way off base with my assumptions here?
>
> Thanks for the assistance in understanding all this.

In the HP48, all numbers were in approximate mode and there was no exact
mode at all.

The HP49 and HP50 were built on top of that HP48 base so naturally were
designed to include conversions from the old forms to the new exact
forms, but apparently overlooked the reverse conversions.
--

[John H Meyers]

On 4/19/2013 6:02 PM, Aaron Carlow wrote:

> Why can I do this:
>
> '2.3*X' ->Q
> result = 23/10*X
>
> but not this:
>
> '23/10*x' ->NUM
> result = "Undefined Name"
>
> I expected that to return:
> result = 2.3*x

The meaning of \->NUM in all HP48/49/50 calculators
is that the final result of evaluation
must be purely numeric (real, complex, integer,
or array or list of purely numeric elements),
and if you supply an algebraic expression
containing an undefined name (no stored variable of that name,
or else what's stored eventually leads to a similar problem),
then there's no numeric value to substitute for that name,
and since your "expected" result is still
an algebraic expression, which can not progress any further
toward the type of result demanded by the command,
an appropriate error occurs.

Have you looked up these commands in the 49/50 series
Advanced Users Manual (AUR), where most commands
are somewhat thoroughly defined?

By the way, also look up the command XQ in the AUR
(it does a bit more than just \->Qpi,
and is often what you might want in place of \->Q,
and is easier to manually type :)

[r->] [OFF]

[aca...@aztechnetworking.com]

On Monday, April 22, 2013 7:03:44 PM UTC-7, John H Meyers wrote:
>
>
> The meaning of \->NUM in all HP48/49/50 calculators
>
> is that the final result of evaluation
>
> must be purely numeric (real, complex, integer,
>
> or array or list of purely numeric elements),
>
> and if you supply an algebraic expression
>
> containing an undefined name (no stored variable of that name,
>
> or else what's stored eventually leads to a similar problem),
>
> then there's no numeric value to substitute for that name,
>
> and since your "expected" result is still
>
> an algebraic expression, which can not progress any further
>
> toward the type of result demanded by the command,
>
> an appropriate error occurs.
>
>
>
> Have you looked up these commands in the 49/50 series
>
> Advanced Users Manual (AUR), where most commands
>
> are somewhat thoroughly defined?

I did look through the AUR, but the ->NUM documentation was not as clear as your explanation. For the record, ->NUM also errors on the 48 the same was as the 50G for algebraics with undefined variables.

I still believe that there should be a logical reverse of ->Q, ->Qpi or XQ that will evaluate numbers, constants, and the variables that it can while leaving the ones that it can't.

EVAL works as long as you're not in "exact" mode. But I like being in "exact" mode, so EVAL alone is not a solution for me. On the 48, it is always in "approx" mode so EVAL works as expected.

This leads me to the program:

<< -105 SF EVAL -105 CF >>

If this was included by default what would it be called?

As a side note, I believe this could be very confusing to students, or those less technically inclined and that is rather unfortunate.

[Virgil]

In article <77a99cf8-f7ba-47b1...@googlegroups.com>,

As a sort of opposite to \->Q or XQ which convert from reals.R, to
rationals, Q, how about either \->R or XR?
Or even Q\->R ?

>
> As a side note, I believe this could be very confusing to students, or those
> less technically inclined and that is rather unfortunate.
>
> >
> >
> >
> > By the way, also look up the command XQ in the AUR
> >
> > (it does a bit more than just \->Qpi,
> >
> > and is often what you might want in place of \->Q,
> >
> > and is easier to manually type :)
> >
> >
> >
> > [r->] [OFF]

--

[John H Meyers]

On 4/22/2013 10:50 PM, Aaron Carlow wrote:

> I did look through the AUR, but the ->NUM documentation
> was not as clear as your explanation.

Not as clear?

\->NUM
Type: Command
Description: Evaluate to Number Command.
Evaluates a symbolic argument object (other than a list)
and returns the numerical result.
\->NUM repeatedly evaluates a symbolic argument
until a numerical result is achieved.
The effect is the same as evaluating a symbolic argument
in Numerical Result Mode (flag –3 set).

Have you tried setting flag -3 and then performing EVAL?
What's the result of that,
when a variable in the symbolic argument is undefined?

Since when should "numerical result" be translated to
"an algebraic or numeric result with no integers in it,"
at the same time ignoring the last sentence of the definition above?

> For the record, ->NUM also errors on the 48 the same was as the 50G
> for algebraics with undefined variables.

So you're surprised to find that \->NUM has had the same action,
consistently, across the entire HP48/49/50 series, as stated?

In the HP48, \->NUM works by literally setting flag -3 while evaluating
and then looping on [COMP]EVAL, exactly following what the AUR says.

> EVAL works as long as you're not in "exact" mode.

Obviously not a completely true statement,
given what happens if flag -3 happens also to be set,
and can you tell me whether any other flags influence the result of EVAL?

This might be a good time to read an old fable
about the different descriptions of an elephant
by three different blind people,
each of whom declares the elephant to be wholly like
the single part which they first touch
(leg vs. trunk vs. tusk),
because their awareness and perspective has yet to encompass
the rest of what they have not yet touched.

> I still believe that there should be a logical reverse of ->Q, ->Qpi or XQ
> that will evaluate numbers, constants, and the variables that it can
> while leaving the ones that it can't.

For what purpose? For this CAS, it is vital that only exact integers
be used in algebraic expressions, rather than approximate reals,
so it is equally vital to have commands which replace all reals
by either integers or ratios of integers, but what's the vital need
to replace exact formulae by approximate formulae,
with a goal solely to _eliminate_ all exact integers?

Not even the HP48 does everything you might want in a single command,
which you have yet to even define with any precision,
but there's an EXCO (expand and collect) program
in some manual which tends to do so.

> As a side note, I believe this could be very confusing to students,

> or those less technically inclined, and that is rather unfortunate.

What seems to "confuse" students the most
is how the world does not conform to their very first impression
of everything they encounter, and thus it's hard to find anyone
who just begins to experience a new subject
who has any real knowledge of what a whole elephant actually is,
yet they seem to believe that they already know everything,
and that's what I consider to be most unfortunate of all.

[r->] [OFF]

[John H Meyers]

On 4/20/2013 1:08 PM, juliet wrote:

> Having never used a CAS system before of any kind,

> and learning to use the 50G, I get the idea

> that the workflow is to use ->Q when starting a problem (if necessary)
> so that the ALG48/Erable functions work
> without needing to switch to approx mode,
> and then using ->NUM to convert the final answer to a decimal (if needed).
>
> Am I way off base with my assumptions here?

Mention of ALG48 & Erable suggest prior HP48 experience?

If the calculus and algebraic capabilities of the CAS
are necessary for your task, then it might be useful to be familiar
with commands CASCFG and XQ, as found in any AUR for HP49/50 series.

If your calculations are all numeric,
then you could do all operations in Approximate mode,
which is toggled on/off by a key combination
that is almost the same as Right-shift \->NUM,
except that you must be still holding down the shift key
when you press the second key -- hmm, that's not likely
to be a mere coincidence, is it?

The current state of that mode is seen on the top screen line
(provided that you display at least one "header" line), as:

= Exact mode
~ Approximate mode

Input of an all-digit number becomes "integer" type in Exact mode,
but is automatically converted to a "real" number (with "decimal point")
in Approximate mode. If you want to force an all-digit value
to be interpreted as a "real" number, even in Exact mode,
you can simply append what the [.] key generates.

It seems to be approximately time for me to leave, so goodbye for now.

[r->] [OFF}

[BartdB]

>
> EVAL works as long as you're not in "exact" mode.
>

Play with the calculator.

Flag -3 clear
Flag -105 clear
(i.e. calculator is now in Symbolic & Exact mode)


Example 1:

8/3 'T' STO

'5*T'

EVAL

result: 40/3

EVAL works fine in Exact

Example 2:

'5*T'

->NUM

result: 13.3333333334

Example 3:

Make sure there is nothing saved as 'X'

'5*T*X'

EVAL

result: 40*X/3

Again, EVAL works fine in Exact

Example 4:

'5*T*X'

->NUM

result: Error

(NUM wants to convert the whole equation to a numerical result, but there no number in X)


Now set Flag -3
Flag -3 set
Flag -105 clear
(i.e. calculator is now in Numeric & Exact mode)

Example 5:

'5*T*X'

EVAL

result: Error

(In NUMERICAL mode, EVAL behaves like ->NUM)

Now clear Flag -3 and set Flag -105
Flag -3 clear
Flag -105 set
(i.e. calculator is now in Symbolic & Approx mode)

Example 5:

'5*T*X'

EVAL

13.3333333334*X

Oooooh, hang on, is this not what you were looking for in the first place?

So, toggle EXACT mode again: hold RightShift & ->NUM

2.3*X

->Q

result: 23*X/10

Toggle APPROX mode again: hold RightShift & ->NUM

EVAL

result: 2.3*X

[aca...@aztechnetworking.com]

On Tuesday, April 23, 2013 2:27:00 AM UTC-7, John H Meyers wrote:
> On 4/22/2013 10:50 PM, Aaron Carlow wrote:
>
>
>
> > I did look through the AUR, but the ->NUM documentation
>
> > was not as clear as your explanation.
>
>
>
> Not as clear?
>
>
>
> \->NUM
>
> Type: Command
>
> Description: Evaluate to Number Command.
>
> Evaluates a symbolic argument object (other than a list)
>
> and returns the numerical result.
>
> \->NUM repeatedly evaluates a symbolic argument
>
> until a numerical result is achieved.
>
> The effect is the same as evaluating a symbolic argument
>
> in Numerical Result Mode (flag –3 set).

I guess for me this is not as clear as your explanation:

"The meaning of \->NUM in all HP48/49/50 calculators
is that the final result of evaluation
must be purely numeric (real, complex, integer,

or array or list of purely numeric elements)..."

>
>
>
> Have you tried setting flag -3 and then performing EVAL?
>
> What's the result of that,
>
> when a variable in the symbolic argument is undefined?

I had not realized how flag -3 interacted with EVAL, perhaps because it's usually in Symbolic mode for me.

>
>
> Since when should "numerical result" be translated to
>
> "an algebraic or numeric result with no integers in it,"
>
> at the same time ignoring the last sentence of the definition above?


>
>
> > For the record, ->NUM also errors on the 48 the same was as the 50G
>
> > for algebraics with undefined variables.
>
>
>
> So you're surprised to find that \->NUM has had the same action,
>
> consistently, across the entire HP48/49/50 series, as stated?
>

No, I'm not surprised at all, just thought I'd mention it since I had made some 48 references.

>
> In the HP48, \->NUM works by literally setting flag -3 while evaluating
>
> and then looping on [COMP]EVAL, exactly following what the AUR says.
>
>
>
> > EVAL works as long as you're not in "exact" mode.
>
>
>
> Obviously not a completely true statement,
>
> given what happens if flag -3 happens also to be set,
>
> and can you tell me whether any other flags influence the result of EVAL?

I hope not since the only one mentioned in the AUR under EVAL is flag -3. Are there others?

>
> > I still believe that there should be a logical reverse of ->Q, ->Qpi or XQ
>
> > that will evaluate numbers, constants, and the variables that it can
>
> > while leaving the ones that it can't.
>
>
>
> For what purpose? For this CAS, it is vital that only exact integers
>
> be used in algebraic expressions, rather than approximate reals,
>
> so it is equally vital to have commands which replace all reals
>
> by either integers or ratios of integers, but what's the vital need
>
> to replace exact formulae by approximate formulae,
>
> with a goal solely to _eliminate_ all exact integers?

I may very likely be misguided - I'm certainly no math wiz, but my thinking is that when given approximate numbers for a calculation, converting them to "exact" representations, and then performing the CAS operations would be the best way to use the calculator. After the calculations are finished, converting back to an approximate decimal representation is often what is desired. So ->Q (or XQ, ->Qpi, etc), followed by CAS calculations, followed by the logical reverse of ->Q. Undefined symbolics are handled by ->Q, so the reverse operation, I figured, would as well. Of course, my assumption as to which operation the logical reverse of ->Q was (->NUM) was not correct.

>
>
> Not even the HP48 does everything you might want in a single command,
>
> which you have yet to even define with any precision,
>
> but there's an EXCO (expand and collect) program
>
> in some manual which tends to do so.

I'm not at all trying to hold up the 48 as doing things better. Please don't misunderstand.

>
>
>
> > As a side note, I believe this could be very confusing to students,
>
> > or those less technically inclined, and that is rather unfortunate.
>
>
>
> What seems to "confuse" students the most
>
> is how the world does not conform to their very first impression
>
> of everything they encounter, and thus it's hard to find anyone
>
> who just begins to experience a new subject
>
> who has any real knowledge of what a whole elephant actually is,
>
> yet they seem to believe that they already know everything,
>
> and that's what I consider to be most unfortunate of all.
>

Apparently I utterly failed in my attempt to prevent the "I know everything I'm talking about" impression.

That said, I'm wondering if you at least get my point that given an operation on a calculator, many would expect an "opposite" operation to also exist. It is the lack of this opposite/inverse/reverse (whatever the correct term is) operation that confused me.

[aca...@aztechnetworking.com]

On Tuesday, April 23, 2013 3:16:33 AM UTC-7, John H Meyers wrote:
> On 4/20/2013 1:08 PM, juliet wrote:
>
>
>
> > Having never used a CAS system before of any kind,
>
> > and learning to use the 50G, I get the idea
>
> > that the workflow is to use ->Q when starting a problem (if necessary)
>
> > so that the ALG48/Erable functions work
>
> > without needing to switch to approx mode,
>
> > and then using ->NUM to convert the final answer to a decimal (if needed).
>
> >
>
> > Am I way off base with my assumptions here?
>
>
>
> Mention of ALG48 & Erable suggest prior HP48 experience?

Mentioned only because back in the day I remember that that the 49 and later were based (at least partially) on the ALG48 and Erable libraries. I never used them. When I was in the USMC infantry I created a program on the 48 to do all our ballistics calculations for our mortar systems (call-for-fire stuff). It was much faster and more accurate than the plotting boards we were using. While I had good handle on programming the calculator, I didn't avail myself of any CAS libraries (actually any libraries - I had wanted to create something without any other dependencies.)

>
>
>
> If the calculus and algebraic capabilities of the CAS
>
> are necessary for your task, then it might be useful to be familiar
>
> with commands CASCFG and XQ, as found in any AUR for HP49/50 series.
>

I actually am reading the stuff as I go along, just not always understanding. Hopefully I haven't exhausted all patience yet.

>
> If your calculations are all numeric,
>
> then you could do all operations in Approximate mode,
>
> which is toggled on/off by a key combination
>
> that is almost the same as Right-shift \->NUM,
>
> except that you must be still holding down the shift key
>
> when you press the second key -- hmm, that's not likely
>
> to be a mere coincidence, is it?

I must admit I didn't expect any HOLD-SHIFT-PRESS type key combinations. I certainly don't remember any from the 48, though I see their utility.

Question - is it better you think to do everything in approx mode? I just assumed that it would be better to convert Approx -> Exact, perform calculations, and them convert Exact -> approx for a final decimal answer (when needed or required).

>
>
>
> The current state of that mode is seen on the top screen line
>
> (provided that you display at least one "header" line), as:
>
>
>
> = Exact mode
>
> ~ Approximate mode

Very useful hint, thanks!

>
>
> Input of an all-digit number becomes "integer" type in Exact mode,
>
> but is automatically converted to a "real" number (with "decimal point")
>
> in Approximate mode. If you want to force an all-digit value
>
> to be interpreted as a "real" number, even in Exact mode,
>
> you can simply append what the [.] key generates.

Ok, this explains why I sometimes see the calc generate numbers like "52.". Very helpful.

[aca...@aztechnetworking.com]

On Tuesday, April 23, 2013 7:15:48 AM UTC-7, BartdB wrote:
> >
>
> > EVAL works as long as you're not in "exact" mode.
>
> >
>
>
>
> Play with the calculator.
>

BartdB - this was a surprisingly useful exercise to help understand the interaction of EVAL, ->NUM, and flags -3 and -105. Much appreciated!!

[John H Meyers]

On 4/23/2013 11:35 AM:

> I still believe that there should be a logical reverse of ->Q, ->Qpi or XQ

First try to define exactly what you mean.

E.g. '2.5*X' XQ produces '5/2*X'

EVAL (with my flags) changes that to '5*X/2'
and the old EXCO program changes that further to 'X*5/2'

Should your command treat all those inputs the same,
and try to _simplify_ the result in any case,
or should the second be regarded as the result of
'5.*X/2.' XQ and "reversed" back to that?

What should your command do if 'X' is defined,
perhaps even with a numeric value,
as well as if it is not defined?

What should your command do if flag -3 is set?

If \pi is in the algebraic argument,
how would you know whether this was produced by \->Qpi,
or was \pi in the original algebraic anyway?

The results of \->Q etc. are influenced
by the current display mode (STD, n FIX, n SCI, n ENG);
so any "reversal" is not "lossless" in any case
(nor are the original commands),
and there actually exists no other true "inverse" than UNDO :)

Finally, why don't you set yourself, as an exercise,
to write a program to do what you're looking for,
and test it under "battlefield conditions"
of a wide range of both inputs and environments;
this is a pretty good way to get further steeped
in practical experience, as well as being the only way
that "ought to be" has much chance of turning into "exists."

By the way, my remarks about students were a generalization,
like a stereotype.

[r->] [OFF]

[John H Meyers]

On 4/23/2013 11:50 AM, Aaron Carlow wrote:

> I must admit I didn't expect any HOLD-SHIFT-PRESS type key combinations.
> I certainly don't remember any from the 48, though I see their utility.

There was no built-in way in HP48
to define "shift(hold)+key" any differently than "shift+key"
but a prolific professor produced an HP48 library "Keyman"
to accomplish something like that.

I seem to recall that some conflicts are possible in HP49/50,
perhaps that any user definition involving a given key
might conflict with any built-in Shift(hold) definition
that otherwise would be active in any mode, but I seem
to have forgotten the actual details of what conflicts with what.

The brilliant Joe Horn produced a program to find and recall
all the built-in Shift(hold) definitions, and yours truly
then came along and modified it, like Microsoft,
to do less because it was originally too good ;-)

Joe's original KEYHUNT:
<https://groups.google.com/group/comp.sys.hp48/msg/176359e6c2c30ec8>

My "dumbed down" version (dropping the actual definitions,
only identifying which keys have special definitions):
<https://groups.google.com/group/comp.sys.hp48/msg/b0b56044830e5d1e>

> Is it better you think to do everything in approx mode?

> I just assumed that it would be better to convert Approx -> Exact,
> perform calculations, and them convert Exact -> approx
> for a final decimal answer (when needed or required).

When you are using the calculator for purely numeric computation,
a "floating point" representation of numeric quantities,
where 12 to 15 most significant digits are always retained
along with a multiplier (power of 10) from 1E-400 to 1E+400
seems extremely well suited for the majority of needs
of everyone from physicists measuring sub-atomic particles
to astronomers taking the measure of the universe,
so why would we prefer to have to store all 400 or so digits
of the largest of those magnitudes, or all 400 or so digits
of the inverse of the smallest of those magnitudes,
or have to express non-integer values of quantities
even near 1E0 as ratios of many-digit numerators
to many-digit denominators, which is what limiting
our allowed concept of "number" to just integers
would require us to do?

Just try taking the sum of the reciprocals of
all integers from 1 to 100 and see how much memory
it would require to remain an exact ratio of integers,
not to mention the vastly more time even each math operator
takes to combine its "exact" arguments,
and pretty soon we'll remember why floating-point
representation ("real" number objects) was invented :)

On the other hand, computer algebra deals with expressions
in which the numeric value of some as yet undefined variables
is unknown, and various symbolic operations in algebra and calculus
can not remain as the theoretically exact things that they represent
unless a means of representing "algebraic class" objects
using "unlimited precision" is actually introduced.

Even cryptographers now require special "large integer" functions
to do their work, particularly in the realm of "public key
cryptosystems" that are often based on exact factors of
integers having hundreds or thousands of digits.

Lest we forget, these calculators also process binary integers
of up to 64 bits in length, including logical bitwise operations
which would normally make no sense in any of the other sorts
of calculations earlier mentioned, but seem useful
to the "computer scientist."

Original "calculators" for simple accounting managed to exist
with "fixed point" computations of modest maximum length,
subsequent calculators for engineers and scientists
had to invent "floating point"
to effectively deal with the physical universe,
yet still generally manage to do so with only slightly larger objects,
and now, to extend the range of objects that "calculators"
can process into symbolic math and number theory,
yet another set of objects and tools must be brought in,
this time of a nature that readily eats up memory,
so to answer your question, you need to match up
your vague phrase "how to do everything"
with which kind of tools are a good fit
for the "everything" that you, in particular,
have in mind doing, and I'm sure that you can
readily make that decision for yourself,
as well as all the other minor related things
(object types, FIX/SCI/ENG display modes, system flags,
binary word size, coordinate mode, angle mode, etc.)
which we also "tune" as exactly as we can to fit our purposes,
much as we select other vehicles (cars, trucks, buses,
RVs, snowmobiles, skateboards) to match the terrain
in which we'll drive and use them.

[r->] [OFF]