35S INPUT (I) bug


I did a search and did not find this.

Here is a snip of code I tried to work yesterday. It is at the top of
my program and has only two inputs before it:

a couple of direct inputs

According to the manual (FWIW) I should be able to do it. I get
Invalid I instead. Or J if I swap index pointers. My Upper limit is
set to 70 previously so I am in range.

This works however:


Anyone else trip over this?


Ralph, I get the same thing. Looks like they goofed the INPUT (i) function.


After the P<>R desaster, I would think a lot more bugs will be unveiled. If one is that careless about the design, how crappy might be the implementation?


Sorry all, that was a bit harsh :-(


INPUT does not work for indirect registers, only for A to Z e.g. -1 to -26


Reth, that's good to know, and I imagine that will be sufficient for most folks' purposes. But the manual is misleading.


Someone in this forum mentioned that the manual seems like a rework of the HP-33S manual, which was a rework of the 32SII manual.

I guess if you photocopy a photocopy of a photocopy, the picture becomes less clear.

I suspect if they had a new team in place to write a new manual from scratch, we might be paying more than $60 USD for it.

Honestly, though, it appears to me that most of us have been somewhat jumpy, as in jumping at the first hint of HP design negligence, real or imagined.

Since Reth posted that INPUT does not work for the indirect register addresses, it sure does look like a design decision to make it (leave it?) that way. We might discuss whether it was a good or bad design segment, but I think we might be just a little more circumspect in declaring bugs.


I guess INPUT was declared that way after finding out that it doesn't work on indexed registers. A design decision like that makes no sense to me.


Ed, what is a bug? If the manual says that something works a certain way, and it doesn't, that's a bug. Page 14-22 of the manual clearly states that indirection includes any number from -32 to 800, and page 14-23 clearly shows INPUT (i) and (j) as valid instructions. Nowhere does it state that indirection for the INPUT command is limited to -32 to -1.

I think members of this forum need to feel free to discover these *bugs* and point them out so that we all know the real limitations in this device.


It could also be a mistake in the manual.

I do agree that people should publicize things that do not appear to work as indicated, certainly.

Keep in mind that the manual might also be mistaken, as it appears to be in this case.

Hey, not everyone will like the 35s.


Gene, this raises an interesting point. If I program INPUT A, the top line of the display shows A? as a prompt for the user. How would it prompt for INPUT (I) if I was, say, 46? Would it say 46? That would be weird.


True that...

... but I suppose if they wanted to, there'd be some kind of scheme, like [46] or .46 or some such.

And your point about bug discovery is well taken; it IS a very public service!


It could say R46? -- that's what happens when you do this on the HP-42S.

- Thomas


I would guess it would prompt as "(46)?" if that functionality were included.

Weird? maybe. Different? Yes, but that's at the benefit of having all those indirect registers available.

I can't tell you guys how excited I was when I first realized we'd have 800+ registers available.

I also can't tell you how excited I was when the indirect data packing program worked so well. It actually takes fewer keystrokes to store and recall indirectly using the indirect data packing program in the learning modules than doing it manually.

Line number GTO and XEQs that STAY will the instruction when a program is edited? Wonderful!

There is much to like in this machine!

Are there some things I wish were improved? Sure, but by the time I'd be finished offering suggestions for improvement, I'd have spec'd out an HP42s replacement machine...

which is not what the 35s is intended to be. It is from the 32s, 32s2, 33s line.

I'll gladly use it compared to those guys.


Yes, Gene, it does have that 32SII-ish feel to it: a similarity in features, a similarity in visual appearance... at least in the geometric layout of keys, thin, lightweight... I must say though that I like the colors of the 35s more even than the scheme used on the 32SII.

Is it fair to say that with the inclusion of the 33S constants and equation libraries and expanded memory capabiilites, it is a bit more powerful than the 32SII (which I still love to use)?


Thanks Gene. I agree with you, there is VERY much to like about this machine. I never took much interest in the solver before, but I have been playing around with it with some quadratic and cubic equations, and it gives me the right answer no matter what I throw at it. And the 800 registers open this machine up to many problems that would have been impossible on a machine with, for instance, 20 registers (like my venerable 12c). I'm planning on rewriting a BASIC program for solving a cube puzzle for the 35s.

I think the thing I like best is discovering uses that I don't even know about now, based upon discoveries by all the forum folks. I imagine I speak for many when I say we are looking forward to learning all there is to know about this device.


Since someone asked for the 12c articles from the HHC2006 gathering and since the 12c programming style is similar (somewhat) to that of the 12c, here is part of my presentation on the 12c.

HHC 2006 12c

and a short one page "How to..." for the 12c platinum.

12c basics

There are ALWAYS lots of presentations much more enjoyable than this one was at HHC gatherings. :-) Registration is still open! We're nearly at 55 registered attendees for HHC2007 held at HP's calculator division itself!

Lots of great information and fun.


Line number GTO and XEQs that STAY will the instruction when a program is edited? Wonderful!

While this is true in most cases, it's not true when you edit (delete/add) a line that is the target of a GTO or XEQ. In that case the GTO's and XEQ's all have to be reexamined and most likely changed. This wouldn't be so bad if you knew all the target lines of GTO and XEQ instructions so you'd know if a reexamination is in order -- but you don't know which they are and you can't flag them as such.

I've been extremely frustrated by this and it makes program editing as difficult as not having the auto line number changing feature. Sometimes it's worse, so I'm back to mostly using the limited 26 labels that existed before.


Edited: 6 Aug 2007, 3:14 p.m.


Sorry to hear that, Katie.

Compared to the 12c way of things, the 35s is a godsend. I'd bet you'd agree to that...

It is the ONLY way I would ever want to program with line number GTO and XEQ statements.

Yes, yes, local labels would be much nicer, but that just wasn't in the cards given the legacy platform of this machine. Not going to happen. Period.

So, either 26 labels as before, or a very good compromise that has already allowed for much more complicated programming than would otherwise be possible.

As you say, it can always be ignored and just programmed as if only global labels were available.

But, the only time I have seen a problem is when you need to change the function at the destination of a GTO or XEQ. Does that really happen all that often with programs you write? It hasn't with me. Usually it is in the body of a calculation that I find something left out.

But then, I also write out my programs on paper if they are longer than 20 or 30 lines, and work through the GTO and XEQ destinations that way.




Another thought. The destination instructions could be default instructions that never need to be deleted.

If a program isn't going to use the angle mode, make the instruction at all GTO/XEQ destinations be DEG or RAD.

That way, it would never be deleted. Sure, uses an extra 3 bytes but big deal.

Or, some other harmless instruction. Kinda a Pseudo-label.

Just a thought.


Very clever. Wish I thought of that ! :-)


I've suggested something like the following for the 33s. Of course it takes more memory, and assumes that Flag 10 is clear. But it provides a clear GTO/XEQ destination, and documents it to boot.

E102 FS? 10



Some other NNOP (Nearly No-OPeration) candidates:

FS 6

FS 9

FC 10

-- depending upon your program requirements.

I've long thought that the COMMENT is the fundamental statement of any programming language, and the NOP is the fundamental operation of any CPU. They're just too darned useful to be left out.


We might also consider what would be the worst command to use as a NNOP. I nominate "DSE (I)".

Edited: 6 Aug 2007, 6:23 p.m.



As you suggested, I thought about using NOP-like instructions for exactly that purpose. They would do the trick then could be deleted once the program is complete and (I think) the calculator would auto-renumber GTO's and XEQ's to the right place. A "RADIX." or "RADIX," instruction would probably be a good choice for a NOP. It's hard to imagine a program that ever needed to use them.

Ultimately, using paper for longer programs is probably the way to go though. I'm usually able to do 32Sii programming entirely on the calculator because the space is sufficiently limited that 26 labels is more than enough. OTOH even though the program space on the original 12C is smaller I still need to write programs on paper first.



I too have been stung by this very behaviour a multitude of times over the past week :-(

Also got stung badly last night when I decided to add a chunk of code at the start of my program. All the forward references were valid at the time of entry and got merrily relocated :-( I gave up and cleared memory and started typing anew. And yes, I wrote this out first -- in fact I've written a mini-assembler that lets me write code out and it fills in the line numbers for me.

However, as Gene pointed out, it is much better than traditional line number based programming.

- Pauli


I do believe it is much better than traditional line number based programming...

and I believe it is much better to have this *option* compared to the 32s, 32SII and 33S programming style.

Is it as nice as the HP41 / HP42 style?



When inserting a line, you can avoid grief as follows. Say you want to insert a line between lines 100 and 101. If you're sure that line 101 is not currently a GTO/XEQ target, there's nothing to worry about. If line 101 is a GTO/XEQ target, then you have to ask yourself whether the line you're inserting should become the target of those GTOs/XEQs or not; if not, again, nothing to worry about; if the new line *should* become the jump target, then

1) Insert the new line *after* the current jump target

2) Re-enter the current jump target *after* the line you just created

3) Delete the original jump target

It's a little bit awkward, but since the calculator has no way of knowing how to treat insertion before a jump target, you have to help it a little bit anyway.

(It would be perfect if the calculator would detect insertion before a jump target, and then ask the user what to do!)

UPDATE: Of course you'd still be in trouble if you are dealing with a jump target that is reached by multiple GTO/XEQ instructions, and you want the inserted instruction to be reached by some of those, but not others. On a calculator with labels, that would be analogous to inserting an instruction between two labels. To cope with this kind of thing reliably, you'll have to use pseudo-labels (NOP instructions) as jump targets exclusively, as others have already suggested.

- Thomas

Edited: 6 Aug 2007, 5:21 p.m.


I just completed a port of my XRD Miller indices program from the HP-48G to the new 35s.

Ignoring (rather, taking into account!) the limitations in the four-level stack 35s calculator as compared to the open stack of the RPL 48G calc, I saw now firsthand the automatic GTO line number changes as I edited the program.

It was slightly alarming and somewhat annoying to me at first, but if the program isn't too long (mine really isn't) then you can keep in mind where all your redirection statements are and then go back and check to see if the target lines are indeed the ones given on the branching command line. I did have to go back and change a few of them... more than once.

Maybe I am a naive programmer, but so far, this seems mainly to be a slight annoyance rather than a major distraction.

What do you all think?


I guess the prompt would be similar to the output of VIEW -
The manual says on p.14-23 "you can not solve or integrate for unnamed variables or statistic registers" and INPUT should be included; also INPUT() and VIEW() shouldn't be grouped together in the sentence on p.14-22 which I miss to understand anyway.
All in all I don't see that as a big problem cause I wouldn't by punching in dozens of numbers in those indirect registers.
Another interesting thing I noticed. Suppose you've allocated 51 registers 0-50 and run the following code in order to free the memory.

GTO E005

before the first run system reports 51 regs, after it - 50 (only 50th unavailable) and after the second run - 0 as expected. Am I missing something?




Nobody seems to have bought this up yet, but the calculator lets you enter INPUT (I) as an instruction. Which then fails to work. I don't see how this can be classified as anything but a bug in the calculator. Either the instruction should have been omitted from the machine or it should operate properly. Either way bug in calculator.

- Pauli

[edit to fix typo "but" -> "bug"]

Edited: 6 Aug 2007, 4:39 p.m. after one or more responses were posted


Ah, now THAT does look like a bug...


Paul, INPUT (I) works in a program, but only if register I contains a value between -26 (register Z) and -1 (register A). The manual, as Gene pointed out, is erroneous by implying that all 800 indirect registers can be used with INPUT (I).

Possibly Related Threads...
Thread Author Replies Views Last Post
  INPUT for HP Prime Eddie W. Shore 3 1,096 11-17-2013, 04:46 PM
Last Post: Michael de Estrada
  HP Prime Tutorial #4 is up (CASE/CHOOSE/INPUT) Eddie W. Shore 1 849 11-15-2013, 07:32 AM
Last Post: Davi Ribeiro de Oliveira
  HP Prime Programming Tutorial #3: WHILE, INPUT, KILL, REPEAT, GETKEY Eddie W. Shore 5 1,561 11-07-2013, 12:25 AM
Last Post: Han
  minor visual bug in INPUT Han 0 649 10-03-2013, 01:13 PM
Last Post: Han
  Input syntax on the Prime Gilles Carpentier 6 1,496 08-23-2013, 04:31 AM
Last Post: Gilles Carpentier
  Input CAS var on HP Prime Mic 2 925 08-22-2013, 02:29 PM
Last Post: Mic
  Is the HP-35S bug free? Matt Agajanian 22 4,307 07-01-2013, 04:03 PM
Last Post: Andrés C. Rodríguez (Argentina)
  HP 85 Serial Interface; INPUT Example? inaki 1 858 06-12-2013, 11:09 PM
Last Post: Paul Berger (Canada)
  HP33E how to input numbers RalfGeiger 6 1,396 05-07-2013, 02:41 PM
Last Post: Ron Ross
  HP 35s - multiple program input values? Arno 3 1,160 04-29-2013, 11:27 AM
Last Post: Gerson W. Barbosa

Forum Jump: