▼
Posts: 151
Threads: 18
Joined: Aug 2007
Hi,
I know this may very well be RTFM question, feel free to tell me so or ignore, my only excuse (again) is that my manual is in the mail and no pdf of manual put up by the ordinary nice company HP.
Right... been programming the machine in head, one thing I'am wondering about is there a way to tell the dimension of a vector, if it is 2D or 3D vector, propper or trick?
The use I can think of is making user friendly programs; some problems are similar in 2D or 3D, it could then be userfriendly to have the same program solve both the 2D and 3D case even if need to compute differently: The program first looks at what the user has given: 2D or 3D input.
I expect this may not be possible, but perhaps?
Regards,
Aha
▼
Posts: 735
Threads: 34
Joined: May 2007
Quote:
is there a way to tell the dimension of a vector, if it is 2D or 3D vector, propper or trick?
I don't have my HP35s at hand so I can't test but the following might do the trick:
(REGX*0+1)*(REGX*0+1)
▼
Posts: 151
Threads: 18
Joined: Aug 2007
Ofcourse... Only allow for destruction of the vector content (that is okey, save the orginal or work on a copy), should be possible to wrap up in a nice utility routine.
Shall be known as Klemm's vector dim trick!
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Nice try but you can't add a scalar value to a vector,
so the "+1" part gets you an enthusiastic "INVALID DATA" message
to cheer up your efforts :)
Best regards from V.
Edited a typo out
Edited: 4 Sept 2007, 10:25 a.m. after one or more responses were posted
▼
Posts: 151
Threads: 18
Joined: Aug 2007
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
This is a tricky problem because there is so little you can do with
vectors on the 35s but here's a code fragment that will return 1, 2 or 3 showing the number of elements in a vector:
assumes DEC mode and RPN mode with the vector in X.
CF 5 don't stop on overflow
1E499
* cause an overflow, most likely
LASTx
* make sure of an overflow!
HEX produce a TOO BIG number
7FFFFFFFFh
/ produce a vector filled with 7FFFFFFFFh
LASTx
/ produce a vector filled with 1h
ENTER
* dot product
DEC
unfortunately this has two problems:
1) It doesn't count elements of vectors that are exactly zero.
2) It will give a one for both 1D vectors and scalars. Ideally you'd want this code to return a zero for a scalar, I would think.
Can anyone do better?
Katie
Edited: 6 Sept 2007, 10:35 a.m. after one or more responses were posted
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
It also doesn't seem to work for complex numbers...
I've not been able to come up with anything truly discerning either.
 Pauli
Posts: 151
Threads: 18
Joined: Aug 2007
Looking forward to try your trick once I get the machine!
Thinking about that it does not work for [0, 0],[0, 0, 0]: May not turn out to be an issue in most problems. That vector has no direction or length will in many contexts be 'illegal'. The positional vectors [0, 0],[0, 0, 0] are ofcourse legal.
However there is not that much to be done for a single point, take for example a program that accepts a line defined by two points p and q and need to check if user is in 2D or 3D space. One of p or q may be the all zero vector but it will be illegal for qp to be, so use your method on that vector (if abs(qp)=0 the user failed to give valid input anyway...).
Edited: 6 Sept 2007, 6:41 a.m.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Arne:
Arne wrote:
"Thinking about that it does not work for [0, 0],[0, 0, 0]: May not turn out to be an issue in most problems. That vector has no direction or length will in many
contexts be 'illegal'."
[0],[0,0], and [0,0,0] are not the only vectors which won't work but actually any vector having one or more 0 components, such as [0,3], [1, 0, 7], [2, 0, 0], [3.14, 2.71, 0], etc.
As soon as your vector has a 0 component, the reported dimension will be wrong. This will surely play havoc with the subsequent computations, unless the input to Katie's routine is guaranteed not to include 0 components.
Best regards from V.
▼
Posts: 151
Threads: 18
Joined: Aug 2007
Sure, but you can do the abs(v)=0 test first not caring about the dimension of v before trying to find out it's dimension, right? So if the '0' vector is illegal then method may be usable, I think...
Or are you saying method does not work if 'a' 0 in v? That would be show stopper, sorry do not have machine....
I see that I may have missed that... sorry...
Edited: 6 Sept 2007, 7:16 a.m.
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
Yes, that's correct any element of the vector equal to zero will cause this routine to return a value less than the actual size of the vector. For example [3.14, 2.71, 0] will return a value of 2 not 3.
The more I play with this problem, including complex numbers and scalars as well, the harder it seems. In thinking about this more and generalizing a bit...
A good test (ie, necessary function) for any programmable calculator that can handle more than one type of data is that it should be able to determine the type of data pragmatically. HP, please add this to your list of things to keep in mind for the next version of whatever.
Posts: 735
Threads: 34
Joined: May 2007
So we still don't have the DIM? for vectors but your clever trick gives us a way to calculate the L^{1}Norm x_{1} of a vector x:
N001 LBL N
N002 ENTER
N003 CF 5
N004 c
N005 !
N006 *
N007 LASTx
N008 *
N009 LASTx
N010 /
N011 x<>y
N012 *
N013 RTN
It doesn't work for complex numbers though!
PS: While searching for a simple way to produce an OVERFLOW I stumbled across the following phenomenon:
TANH(x) for 30000 <= x produces an OVERFLOW but gives 1 as a result.
What could be the reason for this special limit?
Edited: 11 Sept 2007, 7:23 p.m. after one or more responses were posted
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
Quote:
TANH(x) for 30000 <= x produces an OVERFLOW but gives 1 as a result.
I think that you found yet another 35s bug, congratulations (or condolences)!
The 32SII and the 33S don't generate this error message. Even if the answer is correct on the 35s, the OVERFLOW message is very misleading.
More investigation reveals genuine bugs for the SINH and COSH functions with large values. For example:
SINH 25000 = OVERFLOW > 1E500
SINH 30000 = OVERFLOW  >3E499
What seems to happen when the argument is greater than 29999.999... is that the the mantissa is kept and the characteristic is changed to 499.
The 33S behaves this way too (was this previously known?), although the 32SII does it right of course.
Katie
Edited: 10 Sept 2007, 11:41 p.m. after one or more responses were posted
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Katie 
Interesting findings. Of course, you are right that the HP33s/35s repsonses are incorrect in two ways: Inconsistent "OVERFLOW" result value, and temporary display of "OVERFLOW" for a quotientfunction value (TANH) that asymptotically approaches unity, even though each individual term of the quotient might represent "OVERFLOW" conditions.
The inconsistent "OVERFLOW" result values might be related to a bug in the HP33s (corrected in later models), in which a combination or permutation that was too large ("OVERFLOW") displayed what might have been the last value in the running product, rather than 1E500. That is, an intermediatestep result was displayed in both cases instead of the correct "final value".
Those rocksolid Saturnprocessor mathematical routines are to be appreciated.
 KS
