Thread for those receiving 35s calculators to post what they think

[Gene Wright]

Now that these are making their way into lucky people's hands, what does everyone think?

Post good things and things you may not like. :-)

Gene

[Monte Dalrymple]

Great machine. But having to press the blue arrow, then 1 (base),
and the 6 ("h" data type) gets old really fast when I am working
with hex numbers. And you get "syntax error" if you forget to tag
the number this way. I much preferred the 33s in this regard,
where I could just press "enter" after the digit entry was done.

And I had to look in the manual to find which keys to use for
the ABCDEF digits... it isn't labelled on the keyboard.

Monte

[Eric Smith]

Just got the pair of 35s' I ordered from HP on Tuesday (paid a bit extra for overnight shipping). The first thing I did was switch into RPN mode, and the second was to try hex. I wasn't able to figure it out without consulting the manual.

The suffix approach (same as the 28/48/49/50) is extremely annoying when simply trying to do calculations on the stack, but I suppose it was necessary to support use of non-decimal bases in equations and such.

[Monte Dalrymple]

I agree. It gets very annoying, very fast. While I understand the rationale behind this requirement, I would have much preferred at least a "dedicated" mode that assumed everything in hex mode was hex.

I think that this is an example of making something general enough for all cases (like mixing bases on entry) that it interferes with the "normal" case. Kind of anti-KISS...

Monte

[Howard Owen]

The Datafile special issue on the 35s contains an article by Wlodek that gives a possible explanation for this and other misfeatures. Due to cost constraints, the ROM and RAM sizes were the same as the 33s. HP crammed a fair amount of new functionality into the same space the 33S code occupied. Wlodek doesn't mention the base weirdness to show how HP had to "cut corners." He points out that you can enter all sorts of nonsense on the command line without a problem. Only when you press ENTER do you get an error message. But the base stuff may also be a result of cutting corners to save bytes. And the Ax + Bi unavailability in RPN mode could also have the same cause. It would explain what otherwise seems to me to be a series of purposeless limitations or awkwardnesses in an otherwise well-conceived machine.

Regards,
Howard

[Namir]

Gene,

I got my order from HP. Wooohoooo! The machine looks nice and the manual is good too. I think I will dive in reading it this weekend.

Namir

[Mark W Paris]

Argh - still waiting for HP to ship my order - placed on 12 July! A "problem with the inventory."

My hopes for low serial numbers seem dashed.

[Seth Morabito]

Yup -- I think I was one of the first handful of people to find the HP ordering link on Tuesday after the announcement. And mine hasn't shipped yet either.

I'm a bit peeved :)

[Alain Mellan]

There's hope! I ordered mine from HP on 7/12, and I found out today that it has shipped. HP gave me a tracking #, and my calc just left Indianapolis. Should be here on July 23. Can't wait!

[Howard Owen]

A very preliminary impression: nobody has mentioned the DVD yet. Titled "The HP Calculator Story, 1972-2007," it sounds like it ought to be interesting.

Regards,
Howard

Edited: 19 July 2007, 7:33 p.m.

[Howard Owen]

Unfortunately, the video doesn't want to play on my laptop.

Other first impressions:

The keys are as advertised, nice and snappy. Their shapes are very reminiscent of older machines.

The manual seems well organized and thorough.

The case is not a traditional type, but a clamshell. One hald of the shell has netting very much like a PSP case. The PSP uses mini CDs for which the netting is very useful, but I can't imagine what this is for in calculator terms. There is no quick reference guide supplied with the calculator, which might give the netting a reason for being. Note paper, perhaps? The other side of the clamshell is better thought out. It has two elastic bands strategically placed so you can put the calculator in the case facing either direction. One of the elastic bands will reach across the machine between the display and top row of keys. The other band stays unused beneath the calculator. In this mode the machine is usable while in the case. I give this arrangement fairly high marks.

I'm off to learn more about the features of the calculator, before writing my first program. I'll post more as I go.

Regards.
Howard

[Don Shepherd]

Quote:

---

Note paper, perhaps?

---

For documenting the the labels of programs you write, no doubt!

[Allen]

Quote:

---

I give this arrangement fairly high marks.

---

Try it with the case opening to the left.. you will find (and likely be annoyed) that while the case is advertised as ambidextrous, changing the direction leaves the HP logo conspicuously upside down.

If they were going to make this arrangement, they should have put the logo on both sides (to be symmetric) and arranged them like this:

-----------------------------------------

|                                       |

|                                       |

|                 ----                  |

|                 |hp|                  |

|                 ----                  |

|                                       |

|                                       |

|                                       |

|ZZZZZZZZZZZZZZZZZZZZZIIIIIPPPPPPPPPPPPER

with both logos facing the zipper. ( relative position of the HP is somewhat irrelevant.. centered here to show orientation with respect to the opening.)

Edited: 19 July 2007, 8:56 p.m.

[Allen]

p.s. The case does not work very well with Palmtop or Voyager series, but I did find that a 41C/CV/CX will fit without much effort.. We could use the webbing for ZENGRANGE modules maybe?

[Howard Owen]

Yes, I noticed that. Left hand discrimination strikes again! 8)

Regards,
Howard (right handed)

[Howard Owen]

More impressions. Many of the following (and preceding) have been mentioned by others.

This calculator has some oddities whose causes aren't immediately apparent. For example, you can't use A+Bi format for complex numbers in RPN mode, but you can in ALG mode. The example for entry in ALG mode is 'A + B i' which clearly won't work in RPN mode. But surely that can't be why it isn't supported?

A more egregious example of mysterious limitation is the hash made out of base number entry. Blue->base->6 to tag a number as hex is anti-ergonomic. If you are in hex mode, why not assume numbers are in hexadecimal? It's true that this way you can add 44h and 1000100b and get the result in the current base. But I'd far rather have easy entry of data than the ability to mix bases in calculations.

The manual is well organized and thorough, but it's full of errors. This can be expected for a brand new manual, but it detracts from the overall impression the calculator gives the new user.

Note that I'm quite pleased with this machine so far. I'm whining about things that are no big deal, in my view. But I can't help it, I'm a critic at heart.

Regards,
Howard

[Gene Wright]

Hi Howard.

As you read through the manual, please consider collecting errors you find and post them here. I have a list about a page and a half long that I will post soon of ones that have been found so far.

[Howard Owen]

Sure thing, Gene. Here's one, not an error, but a style point. The typography of subscripted variables is poor, in at least one case. That is on on page 9-3, where the numbers in "z1 + z2" are much larger than the "z" characters. The number's base lines are lower than the z characters, yet the tops of both characters are aligned, so the numbers don't appear to be subscripts. The numbers are too large to be elegant looking as subscripts anyhow. Elsewhere, the same font sizes are used for superscripts, and that works fine. But in this case, the result is nearly illegible.

Regards,
Howard

[Howard Owen]

I just worked up a couple of subroutines on my new 35S in order to get a feel for how it is to program. Here's the commented code, followed by some additional thoughts.

This routine will prompt for four successive decimal numbers constituting 4 octets of an IP address. It will store them in a contiguous block of 4 registers starting with the register number passed in the X register.

I001  LBL I

I002  DEC                     Ensure decimal entry

I003  SF 10                   Inhibit evaluation of the "equation"

I004  ENTER OCTET RS 4 TIMES  Long, hey?

I005  CF 10                   1st octet entered is now in X

I006  (REGY+3)/1E3+REGY       ALG, complete with parentheses. Weird.

I007  STO I                   Loop counter and address pointer

I008  x<>y                    Get the first octet back

I009  STO(I)                  STOre it in the base register

I010  ISG I                   Second register is next

I011  DEG                     No-op. Thanks Gene. 8)

I012  SF 10                   Loop entry point

I013  NEXT OCTET              Not so long.

I014  CF 10                   Octet is nw in X

I015  STO(I)                  Store it in the next register

I016  ISG I

I017  GTO I012                My 1st line addressed GTO in 20 years. (Not really 8)

I018  RTN                     Done

The following routine retrieves an IP address from registers whose base is pointed to by the number in X

I019  (REGX+3)/1E3+REGX       ALG here is more programmer-efficient

I020  STO I

I021  RCL(I)                  The first octet

I022  ISG I

I023  DEG

I024  1E3                     "E3" produces "INVALID DATA"

I025  X                       Shift the IP 3 places to the left

I026  RCL(I)                  Get the next octet

I027  +                       And add it into the IP

I028  ISG I

I029  GTO I024

I030  RTN

The comment on line I006 says ALG mode is "weird." I mean that it feels weird to me in the context of an RPN program. The construct if far tidier than the corresponding RPN sequence would have been. I don't know if there are differences in execution time between the two forms. One of Gene's recent articles suggests that ALG may be less efficient. Nonetheless, these subroutines are not time critical, so even a large difference in execution time shouldn't matter. At the same time, fewer line numbers and succinct expression make it easier for this programmer to read the code, despite having to scroll right to see most equations. Six or seven fewer lines is a big advantage on a machine where you can only see two lines at a time, and can't print anything out.

It's also weird to be using indirect addressing for access to the main bank of storage registers. It makes the whole language feel more like assembly. I'm appreciative of the large jump in storage, but it has been implemented inelegantly, no doubt because of cost constraints. The same goes for line oriented GTOs. I actually have coded in line mode BASIC more recently than 20 years ago. (Last year in fact, on the 9816 and HP8X) but doing a GTO to a line number gives me a case of 1980s nostalgia. (I was miserable through the first two thirds of that decade, so nostalgia isn't a good thing. 8) Once again, the designers have found a creative way to address a shortcoming of the 33S, but constrained by cost to inadequate ROM space, they've had to compromise deeply to achieve it.

So, what will it take for HP to turn those very creative and skilled folks loose with a reasonable budget to create an RPN calculator without so many compromises? Is the HP 35S likely to change the economics of the calculator market and allow such a move? I hope so, but I fear not.

Regards,
Howard

[Namir]

Howard,

I wrote the following program to test the speed of summing integers using pure RPN and hybrid AL/RPN commands:

LBL A

INPUT N

0

STO I

STO S

LBL B

1

STO+ I

RCL I

STO+ S

RCL N

x>y?

GTO B001

RCL S

STOP

0

STO I

STO S

LBL C

I+1

STO I

I+S

STO S

RCL I

RCL N

x>y?

GTO C001

RCL S

RTN

When I enter 1000 at the prompt, teh first loop takes about 31 seconds while the second loop takes 84 seconds. The ratio is about 2.8. Using ALG expressions slows down calculations.

Namir

PS: I used the timer of an HP41CX

Edited: 20 July 2007, 7:23 p.m.

[Howard Owen]

Yes, that's what Gene's article reports too. That is a good reason to stick with pure RPN in time critical code.

I guess the difference must be due to the overhead of parsing the equation. That would imply they don't cache the decoded expressions.

Regards,
Howard

[Howard Owen]

Actually, it's not only ALG code that differs between the two approaches. In the RPN case, you are entering an increment value into X, then doing STO+ <var>. In the ALG case, you are recalling the value of the variable into X and incrementing in one step, then storing the result. Reads and writes between the alpha variable registers and the stack may not be equivalent in terms of the time they take.

It's not as easy as I first thought to formulate expressions in RPN and ALG that are equivalent with respect to register moves and so forth. The two models differ pretty sharply in how they use the stack in particular. If you have a RCL+ in RPN, for example, it will do the addition and replace the previous X contents with the result, without enabling stack lift. But if you do an ALG expression like 'I+1', the addition is carried out somewhere, and then the result is pushed on the stack. That necessitates an extra stack manipulation if you want to leave the number of iterations on the stack, like you can in RPN mode. (That is, you can do RCL+ <var> and then X?Y compare for loop control, since Y stays put.)

Regards,
Howard

[Gene Wright]

Good job, Howard! Couple of thoughts:

1 ) NOP - DEG is good unless you need to do trig in radians of course. I'd be glad to have other options that are as easy to put in.

2 ) ALG mode use in RPN programs is very neat, particularly when it saves the RPN stack! It would have been much harder to write the indirect register store/recall program while saving the stack without the ALG tricks. By the way, anyone keyed that in to try it yet?

3 ) I do think this is about as good as it could get as an RPN calculator extension of the 32s line. Putting in these indirect registers and line number GTO and XEQs probably allowed the rom to be slightly changed, which allowed for faster development. Resources these days are scarce!

4 ) And you guys know this, but in most cases, there is no need to ever put a line like GTO B001 in a program. Execution can probably in most cases pick up at line 002 of the destination program. It will be a tad faster that way.

[Allen]

Quote:

---

doing a GTO to a line number gives me a case of 1980s nostalgia

---

It could be much WORSE!

Edited: 21 July 2007, 9:23 p.m.

[Trent Moseley]

I guess it's a case of what you don't know can hurt you. But if you learned to program on the the 25C there's no recourse.

tm

[Howard Owen]

That should stand as a warning to us all.

Regards,
Howard

[Don Shepherd]

Howard, the NOP in line I011. Did you do this because you really only want to increment register I (without actually skipping anything), but you don't know the increment amount until execution time?

[Howard Owen]

Yes, I do just want to increment, but no, I know in advance that the increment will be 1. I could use 1, STO+ I, but that would then require a RDN to restore the stack.

Regars,
Howard

[Don Shepherd]

OK, I see your logic. I was thinking about that last night. I know that the HP-65 has a NOP instruction, but it is needed because an X=Y executes the next *2* instructions if true (because a Goto occupies 2 instructions in that machine). So if you only wanted to do one thing, a NOP was required.

It's kind of like the old BALR instruction on the IBM 360. That instruction was typically used at the beginning of the program, not to branch, but to initialize the index register.

[Howard Owen]

OK, so now I want the input routine to either prompt as before, or else decompose a number in the form:

ABCDEFGHIJKL

Where the letters are the decimal digits of an IP address. For example, 192.160.20.1 would be encoded as 192168020001. This is a form I plan to use for manipulating addresses in various ways. I need a way to "explode" such a number into its octets. (I already have the routine to compose a number like that from its octets, the second one above.)

I'll use flag 0 to decide which mode to use on input. Flag 0 set will mean do the non-prompting routine. Conversely, flag 0 clear will do the original prompting method. I will make heavy use of ALG mode shortcuts in the new code, just to see if I can reach their limits. (Sneak peek: I can.)

To decompose a 10 to 12 digit number into "trigraphs" representing octets, I need to divide the whole number by a divisor that will leave the digits of interest lying just to the right of the decimal place. I will then take the fractional portion (FP), multiply the result by 1000, and take the integer portion. Hey presto! The octet is then left standing on its own. (This technique is surely not original, though I developed it independently. I have no idea who is responsible for the first use, or I'd give them credit here.)

So that means I need to compute the proper divisor to get the octet I'm interested down to the right of the decimal. What I have on hand is the loop counter in I. In the loop, which skips the first octet, since that is a special case, The loop counter's integer portion varies from B+1 to B+3, where B is the base register number passed in. What I need to start is the loop counter integer portion minus the base register value. The following ALG code gets me that:

IP(I)-B

Assuming the base is stored in B.

That gives me the following mapping of loop counters to three digit groups of interest:

000 000 000 000 

     1   2   3

And what I need is a series of divisors, 1E9, 1E6 and 1E3. this equation gets me that:

ALOG(3+(3-N)*3)

Where ALOG() is what you get when you press 10^X in equation mode, and N is the loop counter normalized into the range 1..3.

Finally, I will implement the algorithm given above to isolate the octet of interest:

IP(FP(A/D)*1E3

Where A is the IP address and D is divisor computed in the last step.

Now, what about ALG mode limits? Well, the preceding expressions could be combined (if I'm not mistaken, and heaven knows I might be,) into this:

IP(FP(A/10^(3+(4-IP(I)+B)*3))*1E3)

What a mess! What does it do? Are the parentheses balanced correctly? RPN is much simpler. I might have errors in that expression, but since I'm not actually using it, I refuse to debug it! I'll implement the algorithm in its broken up form to save my sanity in working with the code later.

One last word before the code: I discovered (or rediscovered, actually,) the weaknesses in an auto-renumbering system that relies on the numbers as branch targets. Consider this code:

A001  FS? 0

A002  GTO A005

A003  SOMETHING OR OTHER (EQUATION)

A004  GTO A007

A005  ISG A

A006  GTO A005

A007  DEG

This is a two way branch skeleton waiting for the code to be filled in. I have a loop set up to go on line A005. But now I realize I need some set up before the loop, so I enter it. This is the result:

A001  FS? 0

A002  GTO A006

A003  SOMETHING OR OTHER (EQUATION)

A004  GTO A008

A005  STO A

A006  ISG A

A007  GTO A006

A008  DEG

Do you see the problem? Two out of three GTO lines renumbered as I expected. However the first one, on line A002, followed the ISG A command to line A006. I'll have to manually correct that one or leave a perhaps subtle bug in the code.

Now, the revised subroutine:

    Subroutine to store the octets of an input IP Address

    Copyright (C) 2007 Howard Owen

    This program is free software: you can redistribute it and/or modify

    it under the terms of the GNU General Public License as published by

    the Free Software Foundation, either version 3 of the License, or

    (at your option) any later version.

    This program is distributed in the hope that it will be useful,

    but WITHOUT ANY WARRANTY; without even the implied warranty of

    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License

    along with this program.  If not, see <http://www.gnu.org/licenses/>.



Input an IP address in one of two forms, and place its separated 

octets in four contiguous registers starting at the base register in 

X. If flag 0 is clear, prompt for each successive octet before 

storing it. If flag 0 is set, decompose the 10-12 digit integer 

passed in Y into its constituent octets. Store these in the same way 

as the flag 0 clear code does.

The address in Y is formatted as follows. If the octets are labeled 

from left to right as 1, 2, 3 and 4, then the packed decimal IP 

address is: 111222333444. For example, '192.168.20.1' would be 

encoded as '192168020001'.



I001  LBL I

I002  DEC                     Ensure decimal entry

I003  FS? 0                   Set = don't prompt. IP address is in Y

I004  GTO I009

I005  SF 10                   Inhibit evaluation of the "equation"

I006  ENTER OCTET RS 4 TIMES  Long, hey?

I007  CF 10                   1st octet entered is now in X, base in Y

I008  GTO I014

I009  STO B                   Non-prompting needs base (in X) and address (in y) saved. Base register

I010  x<>y

I011  STO A                   IP address encoded as a 10-12 digit decimal integer

I012  RDN                     Base back in X 

I013  IP(A/1E9)               Leftmost (first) octet in X, base in Y

I014  (REGY+3)/1E3+REGY       Back together. Compute loop control number

I015  STO I                   Loop counter and address pointer

I016  x<>y                    Get the first octet back in X

I017  STO(I)                  STOre it in the base register

I018  ISG I                   Second register is next

I019  DEG                     No-op. Thanks Gene. 8)

I020  FS? 0                   Loop entry point Non prompt?

I021  GTO I026

I022  SF 10                   Do octet-at-a-time prompting

I023  NEXT OCTET              Not so long.

I024  CF 10                   Octet is now in X

I025  GTO I029

I026  IP(I)-B                 Loop counter normalized to the range 1..3

I027  ALOG(3+(3-REGX)*3)      Divisor to bring the current octet just to the right of the decimal            

I028  IP(FP(A/REGX)*1E3)      The octet, masked out from the IP address

I029  STO(I)                  Back to common code. Store the octet in the next register

I030  ISG I

I031  GTO I020                NOT My first line addressed GTO in 20 years.

I032  RTN                     Done

[Ralph]

I have had mine for a little over a day now.

I like:
the keyboard; layout (mostly) and color scheme.
the display; better decimal readability and the LCD layer does not float so high over the backplate to cast drop shadows that made reading the 33S screen difficult.

Jury's out on:
case, I like slipcases personally.
The wonky way to define the range of the indirect registers. I had to read the manual several times on that one. Shades of Casio's changing list and matrix dimensioning on each model it seems.
still don't like the text tag setup but I have a 32SII, 33S and this one so I must just get over it.

It seems slow. It took over 6 minutes to crank out the benchmark test posted here longer than on the 32. That might just need some tweaking as it does my pet program as fast as the 33S.

I don't know if I like the current trend of putting the serial number on a sticky tape. Then I've never sent one back for repair so I can't say a permanent ID is all that either.

All in all I give it a thumbs up and hope it points to better things to come. I can't wait till the 70th year model for them to get it right again ;p

[mjcohen]

(This is a copy of a post to comp.sys.hp48)

In the 33s, indirect addressing is done with an independent register called i, distinct from the regular variables A to Z. A value is stored into i (from 1 to 32), and you store or recall (i) to access what it points to.

In the 35s, the ordinary variables I and J are used for indirect addressing. Values are stored into I or J (-1 to -26 for A to Z, positive values for the newly available memory array) and (I) and (J) are used to store or recall the location pointed to.

In my opinion, THIS IS A SERIOUS MISTAKE.

Essentially, this prevents any use of A through Z as an array if it includes I and J. As a simple example, consider trying to write code that copies A through Z to (1) through (26). What happens when you hit I and J?

Here are some examples of code I have written for the 33s that is no longer possible on the 35s:

1) Input values into A through L. This is for a 3x3 linear equation solver that stores the coefficients in A through L.

2) Solve the equations referred to above.

3) Sort the first n elements of A through Z. This can now only be done if N < 8 (or 9 if J is used).

This architectural deficiency forces any code that needs an array to either put it in the (1) through (800) area or restrict its use of A to Z variables to A to H and K to Z.

Again, in my opinion, it would have been far better to have separate i and j indirect variables completely distinct from A through Z.

The current system makes the natural use of A through Z as an array difficult, if not impossible.

True, in the 3x3 solver referred to above, the coefficients could be stored in K through V, but, to me, A through L is much more natural. Also, how would you do a 4x4 system?

I would be quite interested to see how those more knowledgeable in programming the 35s would handle these problems.

Thank you,

Martin Cohen

[Gene Wright]

Gene: Hi Martin. Here's the reply I posted to comp.sys.hp48 to your post there which was identical to your post here. :-)

The way you would do these things on the 35s is that you would use indirect registers 0 through 15 or higher. You have to change your way of thinking and your past personal preferences to take advantage of the great new features of the 35s.

Don't use A through Z for things like this any longer. Use the
numbered indirect registers. On the 35s, it will be possible to write a matrix program capable of finding the determinant of at least an 18x18 matrix. How would you do that using only A through Z? You wouldn't. You also couldn't do it at all on the 33s.

HP made the design choice to use I and J as they did. They also made
the design choice to give us 801 indirect registers. IMO, it is not an architectural deficiency so much as a changed architecture. The fix is to quit using A through Z in this manner. Use the 801 indirect registers. Use A through Z to store final or intermediate results.

I discussed the indirect addressing space in the 35s review found
here: http://hpcc.org/datafile/V26Special/the35s.pdf

Early on, I had posted responses to you on comp.sys.hp48 pointing you to the review and other learning modules available in response to your posts on comp.sys.hp48, but never got a reply or email. I hope you saw those posts?

The matrix utilities program I have already converted to the 35s (and which is in the current 35s Datafile special issue) uses the indirect registers and is very easy. Once a port of the HP41 PPC ROM RRM matrix program is done, matrices will be amazingly easy to use on the 35s without using any of the A through Z variables.

It is often this way when new versions of calculators come out. When
the HP41 arrived, many HP67 users were very upset that HP no longer
used the primary/secondary register arrangement they were used to on
the HP67, for example.

Would looping through A ... Z be easier if the I and J index registers were not in the middle of the address space? Sure. But having 801 indirect registers to loop through is better still, IMO. I'll take that change any day.

[Thomas Radtke]

Btw, why did HP stick to specialized index registers anyway? Why not using an IND keyword as found on TI programmables? That, along with the ability to partition the available memory, was really an advanced feature.

[Howard Owen]

Hemlock Stones: "No, Watson, you might as well ask who's behind the Giant Rat of Sumatra!"

Watson: "Very well, whose behind is the Giant Rat of Sumatra?"

Regards,
Howard

[db (martinez, ca.)]

howard; watson should ask dr. science.

[Walter B]

Quote:

---

Why not using an IND keyword as found on TI programmables?

---

Hallo Thomas,

you don't have to walk as far: also the 42s has this IND keyword, and you may use each and every register or variable for indirect addressing.

Grüße, Walter

[Paul Dale]

From the viewpoint of the keyboard and its layout, I'd prefer to have (I) and (J) on the keyboard than i and (i) even if it means one less directly addressable register. Wanting a second indirection capable register while programming has happened to me a lot of times over the years since my original 34c.

Of course an IND or equivalent would be better again...

- Pauli

[Gene Wright]

It could have been many things.

Keyboard space and layout

ROM space

Preference of the designer even.

The way it was done allows for only 2 additional keyboard locations for (I) and (J) and does not require an additional 2 spaces for the store instructions to store the index value.

Yes, it does break any routines that want to loop through A ... Z, but it does seem a very small price to pay IMO for 801 indirect registers and two index registers.

Remember, on the 33s, the index was in the middle of the 33 registers which caused headaches trying to loop through only 30 something registers.

Now, on the 35s, you can loop through 801. Big improvement all around.

[mjcohen]

imho, it is a real pain to not be able to use A..Z as an array. It is far easier to enter and recall values from A..Z than the indirect values.

E.g., rcl A is much easier than 1 sto I rcl (I).

[mjcohen]

How this could fit on the keys:

On one key have "IND" which brings up a menu of I, J, (I), and (J), where I and J are NOT part of A..Z. You could even heve K and (K).

Then, on the other available key, have it COMPLEX which brings up a menu of REAL, IMAG, CONJ, ABS, ARG.

It is so stupid not being able to get the real and imaginary parts of a complex number, especially with the known bugs in COS.

Martin Cohen

[sjthomas]

Granted, two index registers are better than one, and 801 loopable registers are better than 26-ish, but I just don't see the programming issues which would preclude ANY register from being used as an index register. They had to program it for I and J. Why not any register?

Edited: 24 July 2007, 2:20 a.m.

[Valentin Albillo]

Hi, Gene:

After having used the HP35S for a while, I must say I am very pleased with it.

It certainly looks and
feels much better than what I expected. It is light but firm, appears quite solid
and well built, the colors and form factor are really attractive, the display has good readability with a decent decimal point, and the keys feel good and positive as well, except for the cursor
keys which, in my unit, do have a different, rather stiff feel to them, but never mind, the bottom line is I really like it very much, it looks and feels better than expected, and I'm all for promoting it among my HP-aware friends.

I'll certainly write programs for it and articles about it, matter of fact I intend to dedicate my efforts to it in full for the next months, in an attempt to generate interest for the machine and provide some useful software for it.

All in all, I think the community is up to enjoy great HP-calc times again. HP certainly has done its part, in spades, by releasing such a nice machine as the HP35S, and we must now do our best to
support their effors by trying and
generating enthusiasm among HP-fans. A new golden era is dawning and we're fortunate
for it !

"May you live in interesting times", as Russell said the Chinese say ... Indeed ! Count me in ! :-)

Best regards from V.

[bill platt]

First Impression:

WOW!

Not only do the buttons work, but they are noticeably better than the 33s. They have less bounce, but really nice pivot and snap action. Of course they feel different from a Singapore 48GX, but I think they are actually better than a voyager.

All of my "wishes" as it were circa "the end of the 32sii" have been fulfilled:

1. Keyboard
2. Display
3. Functions.
4. Reasonalbe size

All of these requirements have been met or exceeded. Only one function (for me) is missing: the "regualr" rectangular-polar conversion--which leaves real numbers in the stack. But this is minor and easily coded as a program.

I am very impressed.

[David McDonald (Atlanta)]

I got my HP-35 last night from the local Walmart via their ship to store program. It's not my old HP-34C but I like it. I wrote a program today on it to calculate the EGT ( exhaust gas temperature) margin for a jet engine . Cool, who needs excel.

[David McDonald (Atlanta)]

I forgot to mention my S/N CNA 72102299

Edited: 26 July 2007, 9:03 a.m.

[Greg Whitfield]

I received my HP 35s on Tuesday, July 24th from Wal-mart using the Site-to-Store method. The cost was $49.99 plus local sales tax; shipping was free. The serial number of the calculator is CNA 72101939.

I haven't had much time to work with it yet, but overall I'd say that it appears to be solidly built and much more professional looking than many of HPs other recent calculators.

The first thing I did when turning it on was note the mode: it was RPN. Then I ran the self-test. It was on the first press of any key when I noticed that the annunciators seemed higher on the left than on the right. Apparently the LCD is crooked in my HP 35s, but not so much as to make me call HP on it. Has anyone else noticed this with theirs?

Also, I was initially a little confused by the left-shifted (yellow) and right-shifted (blue) function terminology in the user manual. The blue functions are on the bottom left side of the keys! The yellow functions are on the top center. It appears that the LCD of the HP 35s is identical to that of the HP 33s which had true left-shifted and right-shifted functions (and horrible colors). Apparently, the left and right shift symbols correspond to the annunciators and one must match the yellow and blue colors to the proper shifted keys. Perhaps it would have been better to leave the direction (left or right) out of the manuals and describe the keys in the documentation by color only.

Why did they use I and J for indirect addressing? Why not lowercase i and j? (the complex notiation for i could have been a cursive type i like on the LCD)

Well, despite my minor complaints, I still am glad HP released this calculator and I plan to show it and RPN off whenever I can. However, I'm still looking forward to the 25th Anniversary HP 15c calculator and the successor to the HP 42s.

Cheers,

Greg

[Wayne Brown]

Quote:

---

Also, I was initially a little confused by the left-shifted (yellow) and right-shifted (blue) function terminology in the user manual. The blue functions are on the bottom left side of the keys! The yellow functions are on the top center. It appears that the LCD of the HP 35s is identical to that of the HP 33s which had true left-shifted and right-shifted functions (and horrible colors). Apparently, the left and right shift symbols correspond to the annunciators and one must match the yellow and blue colors to the proper shifted keys. Perhaps it would have been better to leave the direction (left or right) out of the manuals and describe the keys in the documentation by color only.

---

I've seen several people mention the shift keys being confusing, either because of the arrows pointing left and right, or because they both point upward. That confusion was surprising to me, because I've always used the color-coding to match functions with the shift keys on HP calculators. I'd always assumed that these keys were called "shift" keys as a reference to the shift keys on computer (and before that, typewriter) keyboards. Such keys are used to shift "upward" to upper-case letters, so it made sense to me for them both to have upward-pointing arrows (as the shift keys on many computer and typewriter keyboards do). Also, since the shift keys on calculators aren't physically located on the left and right sides of the keyboard, I thought the left- and right-pointing arrows were simply meant to be ways of distinguishing the keys from each other: "We know these keys are located one above the other, but this is is the key that would have been on the left side if this were a typewriter keyboard, and that other key would have been on the right side." I thought that was the only reason for the "left-shift" and "right-shift" terminology.

It never occurred to me that the "left" and "right" designations had anything to do with how the labels were placed on the keys. But I just checked my HP48GX, and sure enough, the left-shifted labels are on the left, and the right-shifted labels are on the right! Funny that I never noticed that before. I just always matched the colors without paying any attention to the physical orientation of the labels.

[Don Shepherd]

I, also, use the colors as my guide. But some folks are color-challenged, so the arrows are the only thing they can use to distinguish between the two.

[Walter B]

And under these circumstances, arrows pointing in the wrong direction are extremely confusing, as you can imagine. To use your terms, HP was quality-challenged in this detail ;-)

BTW, I love political correctness as it has grown overseas, e.g.: When the horizontally-challenged person in its best age could not keep his attention at an appropriate level (due to above-average long-wave radiation from above) next the urban area of the vertically-challenged people, they made him mobility-challenged by elongated textile products. I.e. when big old Gulliver slept in the sun next the city of the dwarfs, they tied him down with ropes.

In other languages you call such a person "color-blind", and that's what it is.

[Steve Myers]

Quote:

---

...In other languages you call such a person "color-blind", and that's what it is.

---

Most of us are not completely devoid of seeing any color.

It's more can't tell Red from Green, Blue from Purple (and I have no idea what Teal is..)

This is why we prefer it be Color Deficient, not Color Blind.

It's not being politically correct, just correct. :)

[Walter B]

Sorry Steve, that was the short and simple version. AFAIK the most frequent deficiency concerns red and green, and in fact it's called "rot-grün-blind" (blind for red and green). It was said to have been the reason behind some traffic lights not only showing different colors, but these also in different shapes. Nowadays, however, everybody knows green is at the bottom ;-)

So "blind" is a short word indicating some visual deficiency, not meaning I would see nothing at all.

[Steve Myers]

Quote:

---

Sorry Steve, that was the short and simple version. AFAIK the most frequent deficiency concerns red and green, and in fact it's called "rot-grün-blind" (blind for red and green). It was said to have been the reason behind some traffic lights not only showing different colors, but these also in different shapes. Nowadays, however, everybody knows green is at the bottom ;-)

---

No offence taken Walter.

I know it as "Top Stop, Low Go" but that doesn't work on those sideways lights in Texas..

The lack of seeing Red is why I can't tell Blue from Purple. Unless I've been lied to all this time, Purple is Blue+Red and I'm "blind" to the red part.

All my friends know when I do my own laundry.
"Shirt looks grey to me", how would I know it's bright pink.

I'm happy its not so bad as I can still see the difference in the shift keys on my 32SII ;)

[Ed Look]

Quote:

---

... and I have no idea what Teal is...

---

It's a bird.

;)

[Paul Dale]

Quote:

---

It's a bird.

---

A type of duck in fact :-)

- Pauli

[Paul Brogger]

Fabulous! I loved the 33s (I had to get past its appearance) and so find the 35s a really welcome upgrade.

I share the woe of several regarding the BASE handling, and would rather the roll down & swap keys were adjacent to ENTER.

Taken as a whole, it's not as near-perfectly-realized as was, say, the 15c, but it's a really nice, readily available, programmable, shirt-pocket RPN calculator. Thanks to all involved!

Edited: 26 July 2007, 2:23 p.m.

[Katie Wasserman]

My first impression is that I like it better than the 33S, but nowhere near as much as the earlier machines.

pros:

- The function set is good as is the memory access.

- The case seems like more thought went into it than for the 12C anniversary edition.

- The keyclicks are okay.

- The manual seems complete and well written.

cons:

- There's a lot of LCD segment shadowing on the display.

- The keys themselves are really cheap feeling.

- The calculator is too large -- why should it be any bigger than a 32SII?

- The window reflection is annoying.

- I really hate having to press ENTER after XEQ <letter> and <right arrow> before STO.

- The ALL display mode should not overflow the display area it should cut back on the number of places displayed in order to fit the exponent in. I view this as a bug, I see no advantage in it working the way it does.

Summary:

The prices of the 32SII on ebay are going to keep going up!

-Katie

Edited: 26 July 2007, 10:17 p.m.