[HP49] Converting complex numbers
Jesper Noer
How do I convert a complex number in the form 283<32degrees (where the <
represents an angle-symbol) to the form 239,998+149,967*i ??
Regards...
Jesper Noer
rc...@eng.morgan.edu
PRG -> press NXT -> MODES -> ANGLE
** note:cylindrical coordinates = polar coordinates
you can also type in the command CYLIN
or to convert to cartesian use type the command RECT
Easy? :-)
In article <3b21e7af$0$193$ba62...@nntp01.dk.telia.net>, Jesper Noer says...
J.R. Chaffer
it completely changes the calculator display mode, for
all numbers displayed on the stack, and for all future
displays, until changed again. What is wanted is the
actual conversion function, standard on almost all of
the older HP calculators (i.e, "R->P, P->R". These
conversion functions take a single pair (or complex
number) as argument, and return the (cylindrical) polar
representation of that number only, and the inverse.
The mode changes "CYLIN" or "RECT", do not do that,
(see above) and have a number of side effects which
frequently are not desired. It seems awkward to
have to write separate little utilities to recapture
previous performance features.
But - as frequently happens - I may have missed some-
thing in the 49 with its sadly lacking documentation.
So I ask, IS there an actual conversion function, other
than the complex ARG and ABS function ? (again, not
exactly the same thing as the desired function - more
steps required.)
?
jrc
-------------------------------------
Jesper Noer
Entering: CYLIN(239.998+149.967*i) gives the ansver (283.0,<32) which is
correct (again the < is the angle-sign from the CHARS menu).
However, what I wanted was to be able to enter:
RECT(238.0,£32) where the £ is some symbol, and get the
result: (239.998+149.967*i)
On the place of the £, I have tried using the angle-sign from the
CHARS-menu, but this gives me an "Invalid Syntax" with the angle-sign
highlighted as the problemcauser.
I have also tried using RECT(238.0,32) but this only gives me: (283.0 32)
which wasn't what I needed...
What am I supposed to write at the place og the £ to convert the polar
(283.0,<32) to the rect. (239.998+149.967*i) or (239.998,149.967)??
Regards..
Jesper
<rc...@eng.morgan.edu> wrote in message
news:FSoU6.1910$pb1....@www.newsranger.com...
rc...@eng.morgan.edu
months) and i never had a 48, but you can divide the complex number in two parts
with ABS and ARG and then make an array (or vector). the other way around you
would have to be in cylin mode(the calc converts automatically to whatever
format you are using, that is won't let you write a number with an angle while
in XYC mode) and do the reverse operations.
probably there is a 'menu call' that you can perform (using a number call). I
have seen this before with menus that belonged to the 48 model (reading this
newsgroup). in other words, i don't know how, but you should be able to get the
same menu that you had in your 48. perhaps one of the experts can tell us. i
want to know too. :-)
In article <3B225823...@mcn.net>, J.R. Chaffer says...
rc...@eng.morgan.edu
[ALPHA] [RIGHT-SHIFT] [6]
mine works, but again, it will automatically change the format to XYZ
(cartesian)mode (if that is the mode you are on).
it won't let you keep the < if that is what you wanted
In article <3b225440$0$261$ba62...@nntp01.dk.telia.net>, Jesper Noer says...
Jesper Noer
However, using this it gives me a syntax error wether I'm in polar og rect.
mode.
But what i want is, what J.R. Chaffer describes as R->P, P->R functions...
Does anyone know how that can be done??
<rc...@eng.morgan.edu> wrote in message
news:1otU6.2091$pb1....@www.newsranger.com...
Tom Sears
>
> Hmm... wouldn't call it easy... because:
>
> Entering: CYLIN(239.998+149.967*i) gives the ansver (283.0,<32) which is
> correct (again the < is the angle-sign from the CHARS menu).
>
> However, what I wanted was to be able to enter:
>
> RECT(238.0,£32) where the £ is some symbol, and get the
> result: (239.998+149.967*i)
>
> On the place of the £, I have tried using the angle-sign from the
> CHARS-menu, but this gives me an "Invalid Syntax" with the angle-sign
> highlighted as the problemcauser.
Complex numbers are enclosed in parentheses, so try RECT((283.0,<32))
where < is the angle-sign. RECT and CYLIN really just change the
coordinate mode of the display -- complex numbers are always actually
stored in rectangular coordinates.
You can enter complex numbers using either rectangular coordinates
_or_ with magnitude and angle, _whichever_ display mode is in effect!
They will then be displayed in the current coordinate mode.
Just remember to enclose in parentheses and separate the parts with
a comma for rectangular input or the angle sign for polar.
Remember also to set the correct angle mode: degrees, radians,
or grads, when entering angles.
In RPN mode you can separate the x and y values with a space instead
of a comma, but you need the comma in algebraic mode on the hp49.
Since complex numbers can be added, multiplied,etc just like
ordinary numbers (no matter what the display mode) there is less
need to switch modes than in early hp calculators where the parts
had to be manipulated to do calculations. You can also use the
MODE menu and select Rectangular or Polar to change the display
of numbers on the history stack.
Hope this helps.
Tom
John H Meyers
> How do I convert a complex number in the form
> 283 \<) 32 degrees
> (where the \<) represents an angle-symbol, Alpha Right 6)
> to the form 239,998+149,967*i ??
Set display mode and angle unit (once is enough):
RECT DEG
Now enter complex numbers in polar form:
(283\<)32)
Complex coordinates entered in polar form
(meaning with the \<) symbol)
are always *automatically* converted to the rectangular components
of the "complex number object" which ends up on the stack,
which is what will be displayed on the stack in RECT display mode.
If some other time you want to enter rectangular components
and see polar form displayed, do a CYLIN command to change
the display mode and enter rectangular coordinates, e.g.
(3 4)
Now you *automatically* see the polar form on the stack.
That's why there are no P->R and R->P commands -- because
all "conversion" has become *automatic* !!
During input, the mode (polar or rectangular) of your input
is indicated by whether you include or omit the \<) symbol.
During display, the polar or rectangular display of
complex numbers (and 2D or 3D vectors) is determined by
commands, and shown on the screen by the presence or absence
of the same \<) symbol. The display mode commands are:
RECT, CYLIN, or SPHERE
(either of the latter is "polar," differing only in 3D vector displays)
If you'd like the angle symbol to be assigned to, say, the
left-shifted zero key, to make it handier to type polar input,
then the one-time setup would be:
128 CHR 102.2 ASN
To make persistent user key assignments take effect, you must
also press left-shift USER until USR shows at the top of the screen
(but it won't show if you completely turned off the "status header")
To get '3+2i' instead of (3,2) see also:
http://groups.google.com/groups?ic=1&selm=6csh0q%24i16%241%40news.iastate.edu
And now, onward to J.R. (wasn't he shot, years ago?)
Now, J.R. has used HP calcs for so long that I'm sure he knows
exactly when the transition began to occur from calculators
whose "registers" or "stack levels" could contain only
plain numbers (now called "real numbers")
to calcs whose stack levels could contain other objects as well.
For me, my HP15C is the first such calc I encountered;
in default mode, each stack level contains a real number
(or a matrix, but we're not interested in that just now),
and the P->R and R->P commands necessarily require
two separate stack levels to operate, because
complex numbers each require two components.
In complex mode (SF 8), the story changes, because each
stack level now contains *both* parts of a complex number,
and the P->R and R->P commands likewise change -- they now only
work with both parts of the complex object on the *same* stack level,
which is just as it is in the HP48/49.
And why do we need these P->R and R->P commands, anyway?
We use P->R during input, when we need to convert from polar to the
only form in which the internal math functions accept complex numbers,
and we use R->P for final output, if we need to represent
the final output of math operations in polar form, once again.
If those two steps could be done automatically for us,
then we wouldn't need those extra commands, after all.
By the time the HP48 and HP49 come along, that's exactly what
has happened -- we now enter or display both components
at the same time, on the same stack level,
and the \<) symbol has been introduced,
which distinguishes polar coordinates from rectangular
at all times, both while entering and displaying.
All "conversion" now occurs automatically,
during input (compiler) and output (decompiler),
so all manual "conversion" is obsolete;
the unambiguous \<) symbol also removes all doubt
as to which form we are dealing with at any time,
so we even can't trip ourselves up by forgetting.
But old habits die hard; it's like when the steel braces
are removed from the polio victim's legs -- even though
he can now walk without them, he keeps looking around
for something that he's so used to that at first,
it bothers him that they are missing.
Still, there's the paradox that a GUI, although more
"user friendly," may also slow us down, if we are well
accustomed to using older commands and raw data arguments.
For those who want the good old P->R and R->P functions anyway
(and why shouldn't everyone have what he wants?)
well, these have only been posted a few dozen times before,
and if you'd just bookmark these for once, J.R.,
you'd have no more excuse for complaining about their loss ;-)
Two-level input, two-level output:
( real real ==> real real )
P->R: \<< -16. SF \->V2 -16. CF V\-> \>>
R->P: \<< -16. CF \->V2 -16. SF V\-> \>>
To preserve original flag state, if desired,
insert RCLF UNROT at beginning and ROT STOF at end.
One-level input, one-level output:
( complex or vector ==> complex or vector )
[assuming that "polar" flag -16 is now never set]
P->R: \<< V\-> -16. SF \->V2 -16. CF \>>
R->P: \<< -16. SF V\-> -16. CF \->V2 \>>
The fabulous HP15C:
http://www.hpmuseum.org/hp15.htm
http://www.finseth.com/~fin/hpdata/hp15c.html
The "Titan" was too expensive for me:
http://www.hpmuseum.org/hp71.htm
http://www.finseth.com/~fin/hpdata/hp71b.html
-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>
-----= 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
http://groups.google.com/groups?ic=1&selm=3B230DDB...@miu.edu
Oh, I plumb forgot to include the "polar [display] toggle"
function, which the HP48G provides as the POLAR function
on the keyboard:
\<< -16. DUP IF FS? THEN CF ELSE SF END \>>
This, of course, toggles the display between
rectangular and polar style, e.g. (with angles in degrees):
(3.,4.) <==> (5.,\<)53.1301023542)
You don't need any such "toggle" function for input,
because you decide whether to separate the entered components
with either a space or an "angle" character,
and the calc interprets it exactly as you dictate.
"Space" may also mean the [,] key, of course.
A little space may mean a lot:
"Creature Comforts" (Nick Park, Peter Lord, Boris Kessmehl)
1991 Academy Award for Best Short Film (Animated)
http://www.rottentomatoes.com/movie-1077679/about.php
http://www-viz.tamu.edu/thelab/tutorials/sajan/
John H Meyers
> The problem with this 'conversion' on the 49 is that
> it completely changes the calculator display mode, for
> all numbers displayed on the stack, and for all future
> displays, until changed again. What is wanted is the
> actual conversion function, standard on almost all of
> the older HP calculators (i.e, "R->P, P->R". These
> conversion functions take a single pair (or complex
> number) as argument, and return the (cylindrical) polar
> representation of that number only, and the inverse.
> The mode changes "CYLIN" or "RECT", do not do that,
> (see above) and have a number of side effects which
> frequently are not desired. It seems awkward to
> have to write separate little utilities to recapture
> previous performance features.
Actually, it was previous NON-performance features which
made necessary the P->R and R->P functions; what was missing
from early calculators was the ability to distinguish the type
of coordinates which were being manually entered (now detectable
by the presence or absence of the \<) symbol between the values),
and there was also no inherent ability to display objects in
alternate ways, making "conversion" (actually changing the
original internal data) necessary, whereas now we leave the
internal objects alone, and just display them the way we want.
We are thus now protected from making the mistake of using
a complex number when it is in the wrong, "converted" form
(internal functions of complex numbers all require the
rectangular coordinate form, and will deliver meaningless results
if you "convert" to polar and then try to add/subtract/multiply/etc.)
That's what used to happen in HP15C etc., for example, if the user
forgot which way he had last left some complex stack value, and
kept on calculating anyway (maybe that's why the bridge collapsed :)
In the HP48 and HP49, any "complex number object" can exist
in only one form, by definition, and that is in rectangular
coordinate form. When you input a complex value, you indicate
by presence or absence of \<) which type of coordinates you
are feeding in, and no matter which it is, the compiler builds
an internal object containing rectangular coordinates.
When you view results, you also have your choice of which way
you want to *see* them; there is no internal "conversion"
of the object at all -- just a convenient *presentation*
to show you the type of coordinates you want to see,
while the internal object is never endangered by being
changed to values which are incorrect for further processing.
You may say that you can't display the whole stack showing half
the complex values in rectangular form and the other half of
the complex values in polar form all at the same time;
this is certainly true, but you can certainly display
the values yourself in text form instead, specifying
the presentation mode differently for different values.
You can also toggle the display mode at will (more easily on the
HP48G, where a POLAR keyboard function was provided, but thanks to
the continuing customizing ability of the 49, you can still make it
act like a 48 by re-defining some key). Do you engineers really
feel that you need to switch *display* modes that often?
Now, don't confuse this with what you remember as how you had
to "convert" each polar input value separately, perform your
calculations, and then "convert" each output value separately;
with the HP48/49, in this same situation, you would never need
to "convert" anything -- you would simply type entries with
a \<) symbol when entering polar coordinates, and you would
do *nothing* after your calculations, because you could leave
the display in its polar presentation mode all the time,
if that's the form in which you need to get your results.
For many people, this is actually easier than before,
but convincing them is often as difficult as telling anyone
long addicted to algebraic mode that RPN might be useful :)
It is also much safer than before, because you never destroy the
correct internal values of complex numbers, just to display them,
as you had to do on any older calc, so you can always continue
calculating with previous results, without ever fearing that
you may have forgotten which form you had left them in.
> But - as frequently happens - I may have missed some-
> thing in the 49 with its sadly lacking documentation.
> So I ask, IS there an actual conversion function, other
> than the complex ARG and ABS function ? (again, not
> exactly the same thing as the desired function -
> more steps required.)
When IBM wanted to win government computer system contracts,
they once influenced the specifications to require COBOL
as the source language, thereby eliminating
some of the more modern competition :)
The more modern way of calculating with actual complex-number objects,
instead of pairs of real numbers simulating each complex number,
changes the rules on the playing field. If you keep insisting
on the old ground rules, you'll keep getting old-style computing,
with all its extra burdens, including making more mistakes, as above.
ARG and ABS are used to isolate *single* polar components of
a complex value; this is exactly analogous to RE and IM being used
to isolate *single* rectangular components of a complex value.
When you want *both* components separated out, use C\->R or V\->
C\->R will always separate out the rectangular coordinates,
regardless of current display mode, while V\-> will separate
out components corresponding to the current display mode --
now wasn't that a mighty clever idea?
Conversely, R\->C always uses its arguments as rectangular
coordinates, while \->V2 and \->V3 assume that their arguments
correspond to the current display mode. Brilliant!
The previously posted little P->R and R->P functions utilize
the commands above to do the trick, and also preserve the
highest accuracy, for it is the same original P->R and R->P
calculations of older calcs which V\-> and \->V2 are performing.
The state of flag -19 actually doesn't matter for the P->R and R->P
which utilize two stack levels, but to use the one-level version,
set flag -19 to get a complex number object type result, or
clear flag -19 to get a vector result with identical components.
Previous article, containg P->R and R->P:
http://groups.google.com/groups?ic=1&selm=3B230DDB...@miu.edu
What else have I forgotten this time?
Oh well, we'll find out next time :)
Jesper Noer
The double-parentheses did the trick!!
Thanks again... and also thanks to all the other participaters in this
thread!
Regards... Jesper
"Tom Sears" <toms...@sockets.net> wrote in message
news:3B22BCFF...@sockets.net...
John H Meyers
> Alg mode: RECT((283.0,\<)32))
Effort-saver:
RECT is needed only once to set the display mode
(and only if it isn't already in this default mode);
thereafter, just enter the complex values, e.g.
RECT
(283.0,\<)32)
(123,\<)45)
Etc.
RECT doesn't actually use any arguments.
It's a kind of fluke that any extra arguments you supply
to a command in Algebraic mode are just left on the stack,
and become part (or all) of the returned answer!
E.g.:
RECT ==> NOVAL
RECT() ==> NOVAL
RECT(12.345) ==> 12.345
SWAP(1,2,3) ==> { 1 3 2 }