HP Forums
run time type info on the hp-35s? - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: run time type info on the hp-35s? (/thread-124120.html)



run time type info on the hp-35s? - Arne Halvorsen (Norway) - 09-04-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


Re: run time type info on the hp-35s? - Thomas Klemm - 09-04-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 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? - Arne Halvorsen (Norway) - 09-04-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!


Nope :-P - Valentin Albillo - 09-04-2007

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] - Arne Halvorsen (Norway) - 09-04-2007

Darn


Re: Nope :-P [NT] --> an interesting problem - Katie Wasserman - 09-04-2007

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 - Paul Dale - 09-05-2007

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 - Arne Halvorsen (Norway) - 09-06-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 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 - Valentin Albillo - 09-06-2007

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 - Arne Halvorsen (Norway) - 09-06-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.


Re: Nope :-P [NT] --> an interesting problem - Katie Wasserman - 09-06-2007

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 - Thomas Klemm - 09-07-2007

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 - Katie Wasserman - 09-09-2007

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 - Karl Schneider - 09-10-2007

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