HP Forum Archive 19

[ Return to Index | Top of Index ]

On the missing comma as thousand-separator Message #1 Posted by Luca on 4 Sept 2009, 5:25 p.m. I really like how, on older calculators, the comma (used as thousands-separator) moves as you input a large number. It makes it very easy to enter such numbers quickly and without errors. This has been eliminated in newer calculators, including the HP-50g and the HP-35s. I have heard repeated that new calculators cannot use this as they accept a more general form of input on the stack. But I think this explanation does not really hold up. It would be very easy to write an algorithm that places commas properly even for arbitrary stack input: simply check that to the left of the cursor you only have digits until a whitespace, and if so, place commas every three digits (taking into account of the decimal point). When a non-digit (such as E, or -, etc) is inserted, freeze the commas where they are, and continue getting input. Why would this not work? In fact, it would be quite simple to encode the above as a state-machine. Luca

Re: On the missing comma as thousand-separator Message #2 Posted by Gerry Schultz on 4 Sept 2009, 6:42 p.m., in response to message #1 by Luca I have both RPN and RPL machines and I have always preferred the RPN style with a 4-level stack. I do understand the issue in the RPL machine where the command line needs to parse an entry for its data type and extra commas can confuse it. But aren't we dealing with two separate issues? On a 41 when you type in a number, the commas are inserted automatically and maintained by the display but are not a part of the number itself. In the RPL machines, commas are never displayed for either integers or real numbers (as I remember). So, the issue is, as I see it, inputting of numeric data verses the display of numeric data. As a compromise, why not disallow commas when inputting a real (it has a radix displayed in a 50g) number or integer (no radix in a 50g) number so the command line can properly parse the input. Then, after the number type is identified, have the calculator firmware put commas in the display of those number types only. It's not perfect but it would be a step getting the commas back in a number. It does raise the question of if you have large numbers in the real and imaginary axises of a complex number, can the firmware also insert display commas? I don't see why it couldn't but I'm no expert. The displaying of all numeric data types would have to be rewritten. Sounds like a lot of work and that would cost. My 2 cents. Gerry

[ Return to Index | Top of Index ]

Go back to the main exhibit hall