Pi as a SYMBOL - list processing mystery
Peter Karp
I'm pretty sure that somebody has explained that already, but I can't
find it in google :-/
Anyway, try that example:
Pi is the normal Pi on your keyboard :) Open a list and input Pi and
press ENTER then
2: { Pi }
1: 3
and do * (multiplication for example)
That won't work: "Bad Argument Type".
But when I have 'Pi' on the stack and put that 'Pi' into a list
{ 'Pi' } and try to multiplicate the list with 3 I get the desired
result. Note the quotation marks.
{ 'Pi' } dissambles to
{
SYMBOL
xPi
;
}
while { Pi } will return
{
xPi
}
Is this a "bug" that no SYMBOL is put before the Pi (internally), when
I "type" Pi into an open list. I wonder if Pi = Pi ? ;-)
SYMBOL means that one does have an algebraic expression. Isn't Pi in a
mathematical sense always an "expression" and should "deserve" a
SYMBOL in all situations?
Greetings from Cologne
Peter
--
Great HP48/49 links:
http://www.hpcalc.org
http://move.to/hpkb
to find *old* postings search:
http://groups.google.com/advanced_group_search
Jonathan Busby
This is interesting. It appears you may have stumbled upon a real
rarity : a bug in the 48-R :D . The problem stems from the fact that
xPi is not a number. Rather, it is a small secondary that determines
( based on the system flags 2 and 3 ) whether it should push the real
number %PI to the stack or the symbolic SYMBOL xPi ;. This causes no
problems when you hit the keys for Pi because in that case the
secondary is evaluated. But when you enter Pi into a list at the
command prompt it is not evaluated so that when x* encounters xPi in
the list it errors out because a secondary is not a valid argument
type.
Hope this clears things up...
----------------------------------------------------------------------------------
Jonathan Busby - <jdb@UH!ESPRLhouston.rr.com>
Remove the random permutation of "HPRULES!" from my e-mail address
before replying.
On Sat, 13 Oct 2001 13:42:00 GMT, 20...@karpfenteich.net (Peter Karp)
wrote:
----------------------------------------------------------------------------------
Jonathan Busby - <jdb@UH!ESPRLhouston.rr.com>
Remove the "UH!ESPRL" from my e-mail address before replying.
Robert Tiismus
> This is interesting. It appears you may have stumbled upon a real
> rarity : a bug in the 48-R :D . The problem stems from the fact that
> xPi is not a number. Rather, it is a small secondary that determines
> ( based on the system flags 2 and 3 ) whether it should push the real
> number %PI to the stack or the symbolic SYMBOL xPi ;. This causes no
> problems when you hit the keys for Pi because in that case the
> secondary is evaluated. But when you enter Pi into a list at the
> command prompt it is not evaluated so that when x* encounters xPi in
> the list it errors out because a secondary is not a valid argument
> type.
>
> Hope this clears things up...
>
> ----------------------------------------------------------------------------------
Heh! I got the same result, typing e, i, MAXR or MINR in list. => Bad Argument Type
:(
Robert Tiismus
John H Meyers
produces a "Bad Argument Type" error [48G or 49G]
The keystroke \pi either executes immediately,
or else is entered into the command line,
where it is recognized only by the built-in compiler,
which transforms it into a function (object type 18),
the same as for other symbols in the MTH CONST menu
(i, e, MAXR, MINR); only when that function is evaluated
(with flag -2 clear), does the symbolic expression '\pi' result.
If quoted, '\pi' generates an expression (symbolic, object type 9),
much like 'SIN(30)' -- the only difference is that \pi,
unlike more common functions like SIN, takes no argument.
In a list, however, a function name like \pi is not
automatically enclosed in a symbolic object, i.e.
unless you explicitly type quotes,
you get { \pi } rather than { '\pi' }, just as the compiler treats
{ + SIN etc. } for any other function names in a list.
As a consequence, the function object type (18) is invalid during
a multiplication of the whole list, just as { + } 2 * is invalid.
The built-in compiler never inserts the function \pi
into a symbolic, unless it is explicitly quoted. In most cases
this works out all right, because eventually the function
\pi gets evaluated before being used, but if you include \pi
in a list and then invoke automatic list processing, then
\pi never gets evaluated before further use, as it needs to be.
Note that { \pi } 1 GET 2 * will also error, so in the end,
the problem can be attributed to user error -- not appreciating
the subtle point that \pi (and the other symbolic constants) are
actually *functions*, rather than "symbols" or symbolic expressions,
and need to be evaluated before using their result.
If you think about it, what other object type could \pi be,
after all? So it's not a bug -- it's an inevitability!
You can type { '\pi' } directly into the command line, however,
in which case the compiler will produce the necessary symbolic
object type directly within the list, which is what you must do
if you want to perform other functions on symbolic list elements.
-[]-
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
John H Meyers
> Isn't Pi in a mathematical sense always an "expression"
> and should "deserve" a SYMBOL in all situations?
Consider expressions like 'SIN(\pi)' or 'COS(\pi+180)' etc.
If \pi itself were always again enclosed
inside another internal symbolic object during compilation,
instead of just being a no-argument function [object type 18],
this would always generate extra bytes and execution time overhead.
Sooner or later, \pi must execute a function, because flags
-2 and -3 (Constants/Results -> numeric or symbolic) must be tested,
to decide what kind of result the "symbol" should produce.
The only occasions where the function is not "naturally"
evaluated before further use seem to be where the name
\pi (or i, e, etc.) is all by itself in a list,
and then the individual list element is extracted
and another function is attempted to be performed on it;
this is quite a rare event, and might not be deemed
worth the trouble of expanding all other objects, programs,
and their execution times.
The only other way out of this, as far as I can see,
would be to have made a completely different object type
for "symbolic constants" -- if that had been done, however,
it could have cost even more internal OS execution time
overhead, evaluating what objects are "symbolic class"
(test nibble A [hex] in SysRPL), and -- heaven forbid --
if just one more nibble-code had been used up by the HP48G,
ACO would have run out of object-type nibble-codes for the HP49G
(all codes are now in use), and that would have been a real tragedy ;-)