Question on ->V2 and ->ARRY
Herve Chappe
I notice a strange behaviour common to HP 48g, 49g, 49g+, and I would
like to understand - just curious :
- if I put two reals on the stack, say 1 and 2, then I can build the
array [1 2] either using ->V2 or 2 ->ARRY
- now, if I put two complex on the stack, say (1,2) and (3,4) and I want
to build the array [(1,2) (3,4)], then ->V2 does not work any more but 2
->ARRY still works.
Any idea ?
Best Regards from Paris, France
Herve
Khanh-Dang
> - now, if I put two complex on the stack, say (1,2) and (3,4) and I
> want to build the array [(1,2) (3,4)], then ->V2 does not work any
> more but 2 ->ARRY still works.
This is because ->ARRY and ->V2 don't have the same purpose.
->ARRY is used to build an array of any size.
->V2 is used when you want to build a two-dimensional vector, this
vector having a few representations. According to flag -19, a 2D vector
can be either a complex number or a { 2 } array (with ->ARRY notations).
According to the chosen "coord. system" (rectangular, polar or
spherical), the vector can be expressed and displayed in different ways.
To put it in a nutshell, just use ->V2 when you want to deal with
2D vectors, converting them easily from rectangular to polar coord.
system, or from polar to rectangular coord. system.
John H Meyers
> Hello group
Think bigger: "Hello, World" :)
> I notice a strange behaviour common to HP 48g, 49g, 49g+, [and 50G]
> and I would like to understand - just curious :
> if I put two reals on the stack, say 1 and 2, then I can
> build the array [1 2] either using ->V2 or 2 ->ARRY
Try the following and compare:
CYLIN 1 2 \->V2 RECT
CYLIN 1 2 2 \->ARRY RECT
So, which would you rather rely on?
> now, if I put two complex on the stack, say (1,2) and (3,4)
> and I want to build the array [(1,2) (3,4)],
> then ->V2 does not work any more but 2 ->ARRY still works.
Well, you've already seen above which works and which doesn't;
this is just additional confirmation :)
> Any idea ?
The commands V\-> and \->V2 and \->V3 are what replaced
R->P and P->R (Rectangular <-> Polar coordinate conversion)
from older HP calculator series -- they are for
the express purpose of Coordinate Transformation,
and not for decomposing or building vectors,
for which ARRY\-> and \->ARRY are provided
(OBJ\-> also acts like ARRY\-> when applied to arrays).
Therefore, NEVER use the "V" commands unless you mean
to transform between rectangular/polar/spherical coordinates;
if you mean to decompose or compose vectors, use *only* ARRY commands!
V\-> accepts only a *numeric* vector (or complex number) argument,
and for arguments having 2 or 3 components,
V\-> will return to the stack the same individual numeric
*coordinate* values which had been shown in the *display*
for the original argument, which in turn depend on
the current coordinate *display* mode.
If the current coordinate *display* mode
is CYLINdrical, or SPHERE (rather than RECTangular),
then V\-> transforms the original rectangular coordinates
into "Polar" (cylindrical or spherical) coordinates,
giving completely different results than ARRY\->
(more different than just appending the size of the array :)
Likewise, commands \->V2 and \->V3 do the inverse of V\->,
i.e. they create a vector (or a complex number, see flag -19)
having the given 2 or 3 *numerical* coordinate values
when *displayed* in the current coordinate display mode.
If the current coordinate *display* mode
is CYLINdrical, or SPHERE (rather than RECTangular),
then this transforms the "Polar" (cylindrical or spherical)
arguments into internal rectangular coordinates, producing
a completely different result than 2 \->ARRY or 3 \->ARRY
(more different than just requiring the extra argument 2 or 3 :)
If the current coordinate display mode happens to be RECTangular,
then you've "lucked out," and it *seems* as if you've
found a "cheap shortcut" for ARRY\-> and \->ARRY
(at least for purely numeric arguments),
but if the current coordinate display mode is any other,
then each of the above commands transforms between rectangular
and cylindrical (polar) coordinates (involving an *angle*)
or spherical 3-D cordinates (involving two *angles*);
in those cases the angle mode (DEG, RAD, GRAD) also plays a role,
giving different results for each angle mode as well!
Although this is all in the manuals, it may have become lost
to civilization already, because, well, who can learn to read
all those microscopic shiny dots on a plastic disc, anyway?
There's going to be no "Rosetta Stone"
to help future archaeologists who dig up our CDs;
actually, they'll never last that long anyway --
they decompose in just a few years, and there goes
all of modern civilization's records of itself (perhaps thankfully :)
Viva Stonehenge!
[r->] [OFF]
John H Meyers
\->V2 and \->V3 assemble two or three separate coordinates,
taken from the stack, into a single result object,
while V\-> disassembles a single stack object
into its respective separate coordinates.
However, the "single object"
always contains rectangular coordinates,
while the *separated* coordinates
may be either Rectangular or Polar
(Cylindrical or Spherical in a 3-dimensional object),
according to the current coordinate mode,
so a transformation of coordinate systems
is implied in all of these commands.
If the current coordinate mode is CYLINdrical or SPHERE, then:
\->V2 and \->V3 convert Polar (or Cylindrical or Spherical)
coordinates found in the stack arguments
to rectangular coordinates in the final object which results.
V\-> converts rectangular coordinates found in the argument object
(if it has 2 or 3 elements)
to Polar (or Cylindrical or Spherical) coordinates
which are returned on the stack.
If you watch the display before and after the "V" commands,
it always *looks*, even in CYLIN/SPHERE coordinate mode,
as if no values were converted at all -- the exact same numbers
appear in the separated coordinates as in the single object.
However, that's because the single object is always being
*displayed* in the current coordinate system, which shows
exactly the same values as when the single object is split up
into components in that same coordinate system;
the *real* components of the single combined object, however,
remain in rectangular coordinates,
as ARRY\-> or OBJ\-> will always prove to you.
These commands all demand real-valued original coordinates,
and produce only real-valued converted coordinates --
no symbolics, no complex-valued individual components, etc.
For anyone who misses the old R->P and P->R commands
from earlier HP calculators (each of which
takes two real args and returns two real results),
here they are, in terms of the new commands:
R->P: \<< -16 CF \->V2 -16 SF V\-> \>>
P->R: \<< -16 SF \->V2 -16 CF V\-> \>>
In the 49/50 only (not in 48),
V\-> accepts a complex-valued vector, which appears to be a bug
(if not, explain the results in CYLIN/SPHERE modes?)
The new AUR also declares "Thus, V\-> is equivalent to OBJ\->
for vectors with four or more elements" (a documentation "bug";
it should have said OBJ\-> DROP).
[r->] [OFF]
Herve Chappe
what seemed rather dark to me...
Best Regards,
Herve
John H Meyers a écrit :
John H Meyers
HP48/49/50 Coordinate Representation and Conversion
Complex numbers and 2-component real vectors
can represent coordinates in a plane;
3-component real vectors can represent spatial coordinates;
note that single objects each contain *all* the coordinates.
2-component objects can be visualized in Rectangular or
Polar coordinates; 3-component objects in Rectangular [XYZ],
Cylindrical [R@Z] or Spherical [R@@] "Polar" coordinates,
where we're using "@" here for the "angle character" (128 CHR)
Input and stack display notation:
Mode Complex 2-vector 3-vector
RECT ( x, y ) [ x y ] [ x y z ]
CYLIN ( x, @t ) [ x @t ] [ x @t z ]
SPHERE ( x, @t ) [ x @t ] [ x @t @p ]
x, y, z Rectangular coordinates
t (theta) Polar angle in xy plane
p (phi) Angle from z-axis
[Angles are interpreted per angle mode: DEG, RAD, GRAD]
Although internal object coordinates
are always rectangular, the display itself
always shows coordinates in the user-selected mode;
user input can also be in any mode (see above),
and is automatically converted while parsing.
Thus coordinate conversion is so automatic
that ordinarily no special commands are required;
just set the coordinate mode (RECT, CYLIN, SPHERE)
to what you want to see displayed,
type new input using the obvious similar syntax above
(or assemble it from parts using commands below),
and let the calculator manage the rest for you; just
change the display mode at any time to see the results
displayed in different coordinate systems.
However, user commands are also provided
to split single objects
(having two or three real-valued components)
into suitable components for different coordinate systems,
and to combine similar components into single objects,
exactly duplicating the decompiler (display)
and parser (input) automatic conversions:
V\-> transforms left column to right column,
\->V2 and \->V3 transform right column to left column,
according to coordinate modes shown:
( x y ) <-> x y [RECT]
[ x y ] r t [CYLIN, SPHERE] "Polar"
[ x y z ] <-> x y z [RECT]
r t z [CYLIN]
r t p [SPHERE]
V\-> input can be a complex number or a real-valued vector.
Flag -19 determines \->V2 result type [0:Vector, 1:Complex]
What about splitting and combining components
which have nothing to do with coordinate systems?
Complex -> Components C\->R or OBJ\->
Components -> Complex R\->C
Vector -> components ARRY\-> DROP
Components -> Vector 2 \->ARRY or 3 \->ARRY
In 48/49/50, the ARRY commands can handle complex elements;
in 49/50, the ARRY commands can handle symbolic elements;
OBJ\-> also acts like ARRY\-> if its argument is an array.
NOTE:
V\-> \->V2 \->V3 are NOT meant for these purposes, because
their actions are sensitive to Coordinate and Angle modes,
as well as handling only real-valued object components;
use these *only* for Coordinate Conversions!
What about the old R->P and P->R commands
found in earlier HP calculators (each of which
takes two real args and returns two real results)?
Here they are, in terms of the new commands:
R->P: \<< -16 CF \->V2 -16 SF V\-> \>>
P->R: \<< -16 SF \->V2 -16 CF V\-> \>>
Those calculators, however, had basically only one kind
of object (real numbers), and when you consider what it took
to even add two vectors of two or three components each,
particularly if they had been entered in "polar" form,
and desired to have the sum returned in that form as well,
the present system of automatic parsing, simple addition
of single vector objects, and automatic result display
may be appreciated as significant progress :)
Happy Polar Dreams (need any reindeer?)
"In Alaska, reindeer herders use satellite telemetry
to track their herds, using online maps and databases
to chart the herd's progress" [Wikipedia]
But not a lone person traveling 1100 miles with her dog team:
Susan Butcher (1954-2006)
http://www.susanbutcher.com
http://library.thinkquest.org/11313/Iditarod/susan.html
[r->] [OFF]
Virgil
On the 49/49+ one may also use \->COL DROP or \->ROW DROP
to split a vector into its rectangular components
> Components -> Vector 2 \->ARRY or 3 \->ARRY
Or 2 COL\-> or 2 ROW\->, or 3 COL\-> or 3 ROW\-> to assemble a vector
from its components.
Note the different positioning of the arrows
COL\-> and ROW\-> emulate \->ARRAY
\->COL and \->ROW emulate ARRAY\->
John H Meyers
Typos found, correction:
(some "x" should have been be "r")
Input and stack display notation:
Mode Complex 2-vector 3-vector
RECT ( x, y ) [ x y ] [ x y z ]
CYLIN ( r, @t ) [ r @t ] [ r @t z ]
SPHERE ( r, @t ) [ r @t ] [ r @t @p ]
[r->] [OFF]