The Museum of HP Calculators

HP Forum Archive 17

[ Return to Index | Top of Index ]

run time type info on the hp-35s?
Message #1 Posted by Arne Halvorsen (Norway) on 4 Sept 2007, 8:01 a.m.

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

      
Re: run time type info on the hp-35s?
Message #2 Posted by Thomas Klemm on 4 Sept 2007, 9:05 a.m.,
in response to message #1 by Arne Halvorsen (Norway)

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 HP-35s at hand so I can't test but the following might do the trick:

(REGX*0+1)*(REGX*0+1)

            
Re: run time type info on the hp-35s?
Message #3 Posted by Arne Halvorsen (Norway) on 4 Sept 2007, 9:26 a.m.,
in response to message #2 by Thomas Klemm

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!

                  
Nope :-P
Message #4 Posted by Valentin Albillo on 4 Sept 2007, 9:31 a.m.,
in response to message #3 by Arne Halvorsen (Norway)

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

                        
Re: Nope :-P [NT]
Message #5 Posted by Arne Halvorsen (Norway) on 4 Sept 2007, 9:34 a.m.,
in response to message #4 by Valentin Albillo

Darn

                              
Re: Nope :-P [NT] --> an interesting problem
Message #6 Posted by Katie Wasserman on 4 Sept 2007, 9:57 p.m.,
in response to message #5 by Arne Halvorsen (Norway)

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 1-D 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

                                    
Re: Nope :-P [NT] --> an interesting problem
Message #7 Posted by Paul Dale on 5 Sept 2007, 4:08 p.m.,
in response to message #6 by Katie Wasserman

It also doesn't seem to work for complex numbers...

I've not been able to come up with anything truly discerning either.

- Pauli

                                    
Re: Nope :-P [NT] --> an interesting problem
Message #8 Posted by Arne Halvorsen (Norway) on 6 Sept 2007, 6:38 a.m.,
in response to message #6 by Katie Wasserman

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 q-p to be, so use your method on that vector (if abs(q-p)=0 the user failed to give valid input anyway...).

Edited: 6 Sept 2007, 6:41 a.m.

                                          
Re: Nope :-P [NT] --> an interesting problem
Message #9 Posted by Valentin Albillo on 6 Sept 2007, 7:05 a.m.,
in response to message #8 by Arne Halvorsen (Norway)

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.
                                                
Re: Nope :-P [NT] --> an interesting problem
Message #10 Posted by Arne Halvorsen (Norway) on 6 Sept 2007, 7:12 a.m.,
in response to message #9 by Valentin Albillo

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.

                                                      
Re: Nope :-P [NT] --> an interesting problem
Message #11 Posted by Katie Wasserman on 6 Sept 2007, 10:48 a.m.,
in response to message #10 by Arne Halvorsen (Norway)

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.

                                    
Serendipity
Message #12 Posted by Thomas Klemm on 7 Sept 2007, 2:24 a.m.,
in response to message #6 by Katie Wasserman

So we still don't have the DIM? for vectors but your clever trick gives us a way to calculate the L1-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

                                          
Re: Serendipity --> Another HP35s bug -- TANH/SINH/COSH
Message #13 Posted by Katie Wasserman on 9 Sept 2007, 12:00 p.m.,
in response to message #12 by Thomas Klemm

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

                                                
Re: Serendipity --> Another HP35s bug -- TANH/SINH/COSH
Message #14 Posted by Karl Schneider on 10 Sept 2007, 11:28 p.m.,
in response to message #13 by Katie Wasserman

Hi, Katie --

Interesting findings. Of course, you are right that the HP-33s/35s repsonses are incorrect in two ways: Inconsistent "OVERFLOW" result value, and temporary display of "OVERFLOW" for a quotient-function 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 HP-33s (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 intermediate-step result was displayed in both cases instead of the correct "final value".

Those rock-solid Saturn-processor mathematical routines are to be appreciated.

-- KS


[ Return to Index | Top of Index ]

Go back to the main exhibit hall