hp49g+/50g - Del operator only in Cartesian coords?
Mike Markowski
As far as I can tell on my hp49g+, the vector analysis functions based on the
Del operator only work in Cartesian coords. Putting the calc in cylindrical or
spherical doesn't change anything.
For instance, in cylindrical coordinates the Laplacian of Rcos(T)+Z = 0. But if
I put the calc in polar mode and do:
R * cos(T) + Z
['R' 'T' 'Z']
LAPL
yields
-R*COS(T)
I can write my own functions but just wonder if I'm missing something to make
the calculator do vector analysis in other coordinate systems.
Thanks,
Mike
John H Meyers
> As far as I can tell on my hp49g+,
> vector analysis functions based on the Del operator
> work only in Cartesian coords.
> Putting the calc in cylindrical or spherical doesn't change anything.
By definition, the _internal_ components of vectors
across the entire HP28/48/49/50 series of calculators
are always _rectangular_ coordinates.
RECT/CYLIN/SPHERE modes govern the convenient _display_
of converted _numeric_ coordinates on the screen
(with cute "angle symbols" attached to angular values),
and for the potential _numeric_ coordinate transformations
between internal (always rectangular) coordinates
and a set of display coordinates,
implied by the numeric-only commands V\-> \->V2 and \->V3
V\-> \->V2 and \->V3 are those new commands
which replace the R->P and P->R found in older calc series;
those old commands, in turn, had operated on pairs of real numbers
on two stack levels, before the HP28/48/49/50 series
had even introduced the concept of multi-component "objects"
that occupy only a single stack level, plus other changes
which significantly altered the general paradigm
of how we use our calculators.
As far as I am aware, the CAS never undertook to display expressions
for what would be the transformed _symbolic_ coordinates of a _symbolic_ vector,
which is still internally always expressed in rectangular coordinates,
in any sort of analog of what it does with purely numeric vectors
(and complex numbers) -- is that what you miss seeing?
(along with the lack of those same cute "angle symbols"
in front of symbolic expressions for angular components?)
[r->] [OFF]
John H Meyers
By definition, the _internal_ components of vectors
across the entire HP28/48/49/50 series of calculators
are always _rectangular_ coordinates.
While the calculator is automatically displaying the stack,
if a complex number or vector of two or three
real-valued components is to be displayed,
the stack displayer considers the implicit
RECT/CYLIN/SPHERE (coordinate display) mode,
and displays a set of coordinates appropriate to that mode,
also prefixing a cute "angle symbol"
to each angular component displayed.
The \->STR command also does the same thing,
displaying, in the string, the kinds of components called for
by the RECT/CYLIN/SPHERE (coordinate display) mode.
While the calculator is parsing input from the
command line, if a complex number or vector
of two or three real-valued components is encountered,
in which a cute "angle symbol" prefixes the second
(and possibly third) component, the parser likewise
converts all coordinates into purely rectangular coordinates,
to store in the internal object;
the STR\-> command (compile a string) likewise does the same thing.
Note that in the case of command line (or string) parsing,
the presence or absence of angle symbols
explicitly determines the input's "coordinate mode,"
ignoring any implicit RECT/CYLIN/SPHERE display mode.
The V\-> command gives user programs direct access
to the internal "coordinate conversion" function
which takes a single object's internal rectangular coordinates
as input, and outputs separate individual coordinates,
appropriate to the current RECT/CYLIN/SPHERE display mode.
When string or screen output is created from those coordinates,
cute "angle symbols" are automatically prefixed as appropriate,
but when you use V\-> yourself, it's left to you
to be aware of which values represent angles.
The \->V2 and \->V3 commands give user programs direct access
to the inverse "coordinate conversion" function,
in which the implicit RECT/CYLIN/SPHERE mode tells these functions
which (if any) of the separate input components are angles;
the output consists of a single object,
whose internal coordinates are always rectangular.
It should be evident that V\-> is the inverse of \->V2 or \->V3
It should also be evident that V\-> is not a shortcut for
ARRY\-> DROP or OBJ\-> DROP; if you want to split a vector
into its actual (rectangular) components, use one of the latter,
because the former could produce completely different outputs,
in which some values might actually represent angles.
Likewise, do not use \->V2 or \->V3
as shortcuts for 2 \->ARRY or 3\->ARRY
because only in RECT mode will the effect be the same.
Finally, note that the DEG/RAD/GRAD mode affects every operation
mentioned above, where either the input or output involves angles,
whose values can be expressed in either degrees, radians, or grads.
Example:
First set these modes: SPHERE RAD STD
Input [ 2. 3. 6. ] and press ENTER, see screen display:
[ 7. \<).982793723247 \<).541099525957 ]
which are equivalent "spherical polar" coordinates.
Note that the vector object was NOT internally "converted,"
but remains the same; only the _display_ changes in appearance.
Apply V\-> to the above, get three separate stack outputs:
7. .982793723247 .541099525957
having the same numeric values as the coordinates just displayed;
this operation actually does "convert" internal coordinates
to coordinates suitable for display, in the implied mode.
Apply \->V3 to these stack arguments, see screen re-display:
[ 7. \<).982793723247 \<).541099525957 ]
having re-assembled the separate components into the
single object which would display with those components,
two of which, in this case (SPHERE mode) were interpreted as angles;
the object's real _internal_ components have, however,
been converted to rectangular by the command just performed.
Press cursor-down to invoke the [matrix] editor, verifying
that the object's real _internal_ (rectangular) components
are actually [ 2. 3. 6. ]
as they will also appear again on screen after a RECT command.
To demonstrate parsing (and command line input):
RAD "[ 7. \<).982793723247 \<).541099525957 ]" STR\->
(or typing the entire vector expression into the command line)
always results in the same actual object,
regardless of the current RECT/CYLIN/SPHERE mode,
because parsing considers only explicit "angle symbols"
as indicators of which values are angles,
although the current RECT/CYLIN/SPHERE mode
still influences how the object is then re-displayed,
either by automatic stack display or by \->STR
Is the following (on HP49G/50G) a counter-example?
Set "Exact" mode (-105 CF), then input [ 2 3 6 ] SPHERE
Why does it still display as [ 2 3 6 ] ?
Answer: because the object is currently a _symbolic_ matrix,
and the automatic stack displayer (decompiler) does not attempt
to display more complex _symbolic_ expressions for spherical coordinates,
nor to insert cute "angle symbols" in front of any such expressions,
neither of which is likely to be either desired or useful to most users.
However, performing V\-> on this particular object will convert
its "integer" components to "real," and will then convert
to numeric spherical coordinates, just as above;
you may optionally follow with \->V3
to obtain what you might have been expecting to begin with.
You can also input [ 2 3 6 ] SPHERE in _Approximate_ mode,
to directly produce a _numeric_ vector, which displays as before.
If you want to create expressions for symbolic spherical coordinates,
however, you can perfectly well do so, by applying formulas
to the symbolic original components which OBJ\-> will separate for you.
[r->] [OFF]
Mike Markowski
reread shortly to be sure I've absorbed it all!
John H Meyers wrote:
> On Thu, 01 May 2008 10:52:02 -0500, Mike Markowski wrote:
>
>> As far as I can tell on my hp49g+,
>> vector analysis functions based on the Del operator
>> work only in Cartesian coords.
>
> By definition, the _internal_ components of vectors
> across the entire HP28/48/49/50 series of calculators
> are always _rectangular_ coordinates.
>
> RECT/CYLIN/SPHERE modes govern the convenient _display_
> of converted _numeric_ coordinates on the screen
> (with cute "angle symbols" attached to angular values),
This is the key bit of info I wasn't aware of - that vectors are always rectangular.
> As far as I am aware, the CAS never undertook to display expressions
> for what would be the transformed _symbolic_ coordinates of a _symbolic_ vector,
> which is still internally always expressed in rectangular coordinates,
> in any sort of analog of what it does with purely numeric vectors
> (and complex numbers) -- is that what you miss seeing?
I miss a little more than display differences. When problems have certain
symmetries, they're easier to solve in one coordinate system versus another.
The challenge is that the del vector operator doesn't have a specific form in
other coordinate systems. The divergence function, for example, in Cartesian is
the good ol':
div D = d/dx Dx + d/dy Dy + d/dz Dz
yet in cylindrical is
div D = (1/p) d/dp (p Dp) + (1/p) d/do Do + d/dz Dz
where p is distance rho, o is angle phi, and z is distance. So the calculation
for div itself is different, and of course is different again in spherical. I
was hoping, not knowing just what coord mode choice implied, that when I put the
hp49 in cylindrical mode that it would perform vector analysis for that system.
:-) Easy enough to write my own functions, but I didn't want to reinvent the
wheel unnecessarily.
Thanks again for your very helpful replies!
Mike