28 views

Skip to first unread message

Jun 9, 2001, 2:04:41 PM6/9/01

to

Hi!

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

Jun 9, 2001, 8:44:21 AM6/9/01

to

to convert or represent numbers in different formats go here:

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...

Jun 9, 2001, 1:08:51 PM6/9/01

to

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.

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

-------------------------------------

Jun 9, 2001, 9:47:54 PM6/9/01

to

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.

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...

Jun 9, 2001, 1:42:30 PM6/9/01

to

yeap, you are right. it does change everything. i am new with the 49(a couple of

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. :-)

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...

Jun 9, 2001, 1:53:01 PM6/9/01

to

did you try this after the comma?:

[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

[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...

Jun 9, 2001, 11:28:58 PM6/9/01

to

[ALPHA] [RIGHT-SHIFT] [6] was what I ment by the angle-sign (or the <).

However, using this it gives me a syntax error wether I'm in polar og rect.

mode.

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...

Jun 9, 2001, 8:19:11 PM6/9/01

to

Jesper Noer wrote:

>

> 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.

>

> 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

Jun 10, 2001, 2:04:11 AM6/10/01

to Jesper Noer

Questions and carps:

> 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! =-----

Jun 10, 2001, 3:04:26 AM6/10/01

to Jesper Noer

Continuing from:

http://groups.google.com/groups?ic=1&selm=3B230DDB...@miu.edu

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/

Jun 10, 2001, 6:00:34 AM6/10/01

to

"J.R. Chaffer" wrote:

> 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 :)

Jun 10, 2001, 2:56:38 PM6/10/01

to

THANK YOU!!

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...

Jun 10, 2001, 9:49:51 AM6/10/01

to Jesper Noer

Previous suggestion:

> 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 }

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu