My wish list for an improved 50g - Hewlett Packard

This is a discussion on My wish list for an improved 50g - Hewlett Packard ; Hardware -------- 1. Large ENTER key, just like in the older models (and the HP-35s). 2. Tactile keys like those on the HP-35s with the same key shape. Software -------- 1. Digit separators in Standard display mode (like the HP-35s). ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: My wish list for an improved 50g

  1. My wish list for an improved 50g

    Hardware
    --------
    1. Large ENTER key, just like in the older models (and the HP-35s).
    2. Tactile keys like those on the HP-35s with the same key shape.

    Software
    --------
    1. Digit separators in Standard display mode (like the HP-35s).
    2. A B->I function (yes, I can use B->R and then R->I, but why not
    just combine them).

    The software should be relatively easy to implement. I won't hold
    my breath for the hardware changes, but it would be nice.

    On another note, what is the deal with the mushy HP-20b keys? Why
    did HP take a step backward when they are capable of producing a
    decent keypad like the one on the HP-35s? Why is HP having so much
    issues with fundamentals like keys on a calculator?

    Thanks for reading.

    John

  2. Re: My wish list for an improved 50g

    In article ,
    John Nguyen wrote:

    > Hardware
    > --------
    > 1. Large ENTER key, just like in the older models (and the HP-35s).
    > 2. Tactile keys like those on the HP-35s with the same key shape.
    >
    > Software
    > --------
    > 1. Digit separators in Standard display mode (like the HP-35s).
    > 2. A B->I function (yes, I can use B->R and then R->I, but why not
    > just combine them).


    Actually there are binaries that would have to convert to integers of
    more than 12 significant decimal digits, so they get rounded off to 12
    significant digits by the B->R command. Like the binary for 2^64 -1.

    To get the full 64 bit binary numbers converted exactly to integer
    format is possible on an hp49/hp50, but not by the sequence B->R R->I.

    E.g., when compiled in in exact mode, this user program seems to work:

    \<< 0 1 \-> x y
    \<< WHILE DUP # 0h >
    REPEAT
    IF DUP # 1H AND # OH >
    THEN 'X' Y STO+
    END
    'Y' 2 STO* SR
    END
    DROP X
    \>>
    \>>
    >
    > The software should be relatively easy to implement. I won't hold
    > my breath for the hardware changes, but it would be nice.
    >
    > On another note, what is the deal with the mushy HP-20b keys? Why
    > did HP take a step backward when they are capable of producing a
    > decent keypad like the one on the HP-35s? Why is HP having so much
    > issues with fundamentals like keys on a calculator?
    >
    > Thanks for reading.
    >
    > John


  3. Re: My wish list for an improved 50g

    "Virgil" wrote in message
    news:Virgil-B9E348.01433021082008@comcast.dca.giganews.com...
    > In article ,
    > John Nguyen wrote:

    X
    > Actually there are binaries that would have to convert to integers of
    > more than 12 significant decimal digits, so they get rounded off to 12
    > significant digits by the B->R command. Like the binary for 2^64 -1.
    >
    > To get the full 64 bit binary numbers converted exactly to integer
    > format is possible on an hp49/hp50, but not by the sequence B->R R->I.
    >
    > E.g., when compiled in in exact mode, this user program seems to work:
    >
    > \<< 0 1 \-> x y
    > \<< WHILE DUP # 0h >
    > REPEAT
    > IF DUP # 1H AND # OH >
    > THEN 'X' Y STO+
    > END
    > 'Y' 2 STO* SR
    > END
    > DROP X
    > \>>
    > \>>

    X
    slight modifications:
    \<< \-> b @ use as a function
    \<< b 0 1 \-> x y
    \<< WHILE DUP # 999999999999d >
    REPEAT @ no need to loop smaller
    IF DUP # 1h AND # 0h > @ corrected OH
    THEN 'x' y STO+
    END
    'y' y STO+ SR @ + faster than *
    END
    B\->R R\->I y * x +
    \>> b DROP @ save LASTARG
    \>> @
    \>> @ note small letters usage



  4. Re: My wish list for an improved 50g

    On Aug 21, 1:00*pm, "Veli-Pekka Nousiainen"
    wrote:
    > "Virgil" wrote in message
    >
    > news:Virgil-B9E348.01433021082008@comcast.dca.giganews.com...
    >
    > > In article ,
    > > John Nguyen wrote:

    > X
    > > Actually there are binaries that would have to convert to integers of
    > > more than 12 significant decimal digits, so they get rounded off to 12
    > > significant digits by the B->R command. Like the binary for 2^64 -1.

    >
    > > To get the full 64 bit binary numbers converted exactly to integer
    > > format is possible on an hp49/hp50, but not by the sequence B->R R->I.


    How about string processing?

    B\->I
    \<< PUSH DEC \->STR 3. OVER SIZE 1. - SUB OBJ\-> POP \>>

    I\->B
    \<< "# " SWAP + "d" + OBJ\-> \>>

    -wes

  5. Re: My wish list for an improved 50g

    Veli-Pekka Nousiainen kirjutas:
    > "Virgil" wrote in message
    > news:Virgil-B9E348.01433021082008@comcast.dca.giganews.com...
    >> In article ,
    >> John Nguyen wrote:

    > X
    >> Actually there are binaries that would have to convert to integers of
    >> more than 12 significant decimal digits, so they get rounded off to 12
    >> significant digits by the B->R command. Like the binary for 2^64 -1.
    >>
    >> To get the full 64 bit binary numbers converted exactly to integer
    >> format is possible on an hp49/hp50, but not by the sequence B->R R->I.
    >>
    >> E.g., when compiled in in exact mode, this user program seems to work:
    >>
    >> \<< 0 1 \-> x y
    >> \<< WHILE DUP # 0h >
    >> REPEAT
    >> IF DUP # 1H AND # OH >
    >> THEN 'X' Y STO+
    >> END
    >> 'Y' 2 STO* SR
    >> END
    >> DROP X
    >> \>>
    >> \>>

    > X
    > slight modifications:
    > \<< \-> b @ use as a function
    > \<< b 0 1 \-> x y
    > \<< WHILE DUP # 999999999999d >
    > REPEAT @ no need to loop smaller
    > IF DUP # 1h AND # 0h > @ corrected OH
    > THEN 'x' y STO+
    > END
    > 'y' y STO+ SR @ + faster than *
    > END
    > B\->R R\->I y * x +
    > \>> b DROP @ save LASTARG
    > \>> @
    > \>> @ note small letters usage
    >
    >

    The first one is 148.5 bytes and over 1s with #FFFFFFFFFFFFFFFh, the
    other one 191 bytes and 400ms with the same input.

    What about:
    \<< \-> n
    \<< RCLF DEC -105 CF
    n \->STR DUP SIZE 1 - 3 SWAP SUB STR\->
    SWAP STOF
    \>>
    \>>

    68.5 bytes and 60ms with the same input as above.

    Results are different, because first two programs assume user binary
    integers to be signed I assume

    Best wishes,

    Robert Tiismus

  6. Re: My wish list for an improved 50g

    In article ,
    Virgil wrote:

    > In article ,
    > John Nguyen wrote:
    >
    > > Hardware
    > > --------
    > > 1. Large ENTER key, just like in the older models (and the HP-35s).
    > > 2. Tactile keys like those on the HP-35s with the same key shape.
    > >
    > > Software
    > > --------
    > > 1. Digit separators in Standard display mode (like the HP-35s).
    > > 2. A B->I function (yes, I can use B->R and then R->I, but why not
    > > just combine them).

    >
    > Actually there are binaries that would have to convert to integers of
    > more than 12 significant decimal digits, so they get rounded off to 12
    > significant digits by the B->R command. Like the binary for 2^64 -1.
    >
    > To get the full 64 bit binary numbers converted exactly to integer
    > format is possible on an hp49/hp50, but not by the sequence B->R R->I.
    >
    > E.g., when compiled in in exact mode, this user program seems to work:
    >
    > \<< 0 1 \-> x y
    > \<< WHILE DUP # 0h >
    > REPEAT
    > IF DUP # 1H AND # OH >
    > THEN 'X' Y STO+
    > END
    > 'Y' 2 STO* SR
    > END
    > DROP X


    A much better program is (again compiled in exact mode)

    \<<
    4294967296 @ equals 2^32
    DUP2 / B\->I OVER *
    UNROT 1 - R\->B AND
    B\->R R\->I +
    \>>

    Note that 4294967296 can actually be any integer between 2^32 and
    10^12 inclusive.

  7. Re: My wish list for an improved 50g

    On Thu, 21 Aug 2008 00:52:51 -0500, John Nguyen wrote:

    > Digit separators in Standard display mode (like the HP-35s).


    It would have to done, however, without affecting \->STR
    (currently both the STD mode stack display and \->STR
    share one common decompiler function);
    otherwise \->STR would produce strings
    which STR\-> could not re-compile,
    which might "break" lots of existing software.

    Doing the above also expands the maximum length
    of the display string by three characters:

    "-8,888,888,888.88"

    In some other calculators, each display digit
    includes the annunciators for "." and ","
    so that no string expansion is required to show decimals
    and separators, but note that in the HP48/49/50 series,
    every character occupies its own position.

    You could easily create your own function, however,
    for displaying numbers exactly as you desire
    (just remove trailing zeros from normal FIX mode display);
    in the HP49/50 series you can even
    automatically "overlay" this display on stack level 1,
    whenever there is a real number on that level.


    > a B->I function (yes, I can use B->R and then R->I
    > but why not just combine them)


    The combination of the two existing functions is not even adequate,
    because the range of both "user binary" and "integer" data types
    exceeds the range of uniquely representable "real" integers
    (which are limited to twelve significant digits), e.g.

    #123456789012345d B\->R R\->I produces 123456789012000

    Therefore, B\->I and I\->B ought to have been suggested
    during HP49G development or early deployment, but no one did
    (I must myself have been taking a nap at the time

    Although much simpler-looking programs than the following
    can be constructed to operate on one value at a time,
    the following are not only faster,
    but also accommodate input lists:

    \<< 8. SQ STWS DUP B\->R R\->I DUP R\->B ROT - 8. ALOG
    SWAP OVER R\->B ADD B\->R SWAP - R\->I - \>> 'B\->I' STO

    \<< 8. SQ STWS 0 MAX 18446744073709551615 MIN DUP R\->B DUP B\->R
    R\->I ROT - I\->R 8. ALOG SWAP OVER ADD SWAP R\->B - - \>> 'I\->B' STO

    Notes:

    These don't restore any smaller original "binary word size"
    (which is "good form" to do, but can also make results look wrong).

    In keeping with R\->B, I\->B has the same minimum (zero)
    and maximum (2^64-1) output, indicating no "range" errors.

    "Exact mode" must be set before compiling the above; otherwise
    18446744073709551615 will be misinterpreted as a "real" number.

    > Why is HP having so much issues
    > with fundamentals like keys on a calculator?


    These are fundamentally difficult times

    "Back to basics," I say
    (but not "Back to BASIC"

    [r->] [OFF]

  8. Re: My wish list for an improved 50g

    On Thu, 21 Aug 2008 10:14:06 -0500, Wes wrote:

    > How about string processing?


    > B\->I
    > \<< PUSH DEC \->STR 3. OVER SIZE 1. - SUB OBJ\-> POP \>>


    You must also make sure to get into "Exact" mode before OBJ\->
    or else the result will be a "real" type,
    which might not even represent exactly the same value
    (although it would be the same as produced by I\->R)

    > I\->B
    > \<< "# " SWAP + "d" + OBJ\-> \>>


    Watch out for inputs which are either too large or negative.

    The above methods employ the internal compiler,
    which is often slower than using just calculation.

    Avoidance of using the internal compiler is in fact
    why perfectly valid numeric "port tags" (e.g. :2.0:X STO)
    which would have worked fine in the HP48S[X]/G[X] series
    do not work in the HP49/50 series -- the earlier series
    first compiled any port tag and checked for a real result,
    while the later series, concerned about execution time
    even for relatively infrequent port operations,
    recognizes only :2:X and :2.:X
    (this can "break" some programs when in FIX or SCI display mode,
    for example).

    Even :2.:X was originally not recognized in early HP49G ROMs,
    but the necessity of allowing this was eventually conceded

    [r->] [OFF]

  9. Re: My wish list for an improved 50g

    I wish HP or BP can make an HP49/50 ROM that could work with
    delimiters (thousands, millions, etc) when working WITH UNITS. Now
    its just impossible, when you set any kind of unit the commas are
    cleared.

    Daniel

+ Reply to Thread