Half O.T.(Keypad Functions On Sharp) - Hewlett Packard

This is a discussion on Half O.T.(Keypad Functions On Sharp) - Hewlett Packard ; I sat, after class, with a cup and my stuff, on a sunny bench. Lay before me on my bag was the Sharp EL-506W. First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th, the functions ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Half O.T.(Keypad Functions On Sharp)

  1. Half O.T.(Keypad Functions On Sharp)


    I sat,
    after class,
    with a cup and my stuff,
    on a sunny bench.

    Lay before me on my bag
    was the Sharp EL-506W.

    First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th,
    the functions y^x, x^2, and x^3, with over-legends of
    x(Root), (Sqrt), and 3rd(Root).

    Um, Y^x, and x(root) would solve any values the others offer..
    Why waste Space on the keypad?


    Second, I noted the base functions commonly found there too;
    ->HEX, ->BIN, ->DEC, ->OCT, and ->PEN .

    Again, Um, a function ->N(base) would solve any number,
    -and why waste space on the keys again?


    Even HP does the extra "Power Keys", and yes, the "bases" also.
    Anyone know why these funcs aren't addressed more efficently?


    -just musing, sitting on my bench, avoiding my literature book..




  2. Re: Half O.T.(Keypad Functions On Sharp)

    On Mar 6, 11:09*am, Publicly Anonomous Use
    wrote:
    > First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th,
    > the functions y^x, x^2, and x^3, with over-legends of
    > x(Root), (Sqrt), and 3rd(Root).
    >
    > Um, Y^x, and x(root) would solve any values the others offer..
    > Why waste Space on the keypad?
    >
    > Second, I noted the base functions commonly found there too;
    > ->HEX, ->BIN, ->DEC, ->OCT, and ->PEN .
    >
    > Again, Um, a function ->N(base) would solve any number,
    > -and why waste space on the keys again?
    >
    > Even HP does the extra "Power Keys", and yes, the "bases" also.
    > Anyone know why these funcs aren't addressed more efficently?
    >
    > -just musing, sitting on my bench, avoiding my literature book..


    Probably just for convenience. The square, cube, square root, and cube
    root are used more often than other powers or roots. Similarly, the
    bases 2, 8, 10, and 16 are the most common (and will be as long as we
    use binary computers). This can save a few keystrokes when doing
    common calculations (Similarly, one can argue the redundancy of having
    both common log and natural log keys).

    It might also be because of public ignorance of the relationship
    between the functions. Texas Instruments tried leaving everything out
    except for a single "Y^X" key (represented by a carat) on the TI-89
    and high school students complained about the lack of an XROOT key.
    They just didn't know that x^(p/q) is equal to the q-th root of x^p.

    S.C.

  3. Re: Half O.T.(Keypad Functions On Sharp)

    sc_usenet@hotmail.com wrote in news:8a8b1e0d-71e7-4667-b2a9-727f9b7f1c91
    @y77g2000hsy.googlegroups.com:

    > On Mar 6, 11:09*am, Publicly Anonomous Use
    > wrote:
    >> First, I resolved on the 2nd row; on the keys 2nd, 3rd, and 4th,
    >> the functions y^x, x^2, and x^3, with over-legends of
    >> x(Root), (Sqrt), and 3rd(Root).
    >>
    >> Um, Y^x, and x(root) would solve any values the others offer..
    >> Why waste Space on the keypad?
    >>
    >> Second, I noted the base functions commonly found there too;
    >> ->HEX, ->BIN, ->DEC, ->OCT, and ->PEN .
    >>
    >> Again, Um, a function ->N(base) would solve any number,
    >> -and why waste space on the keys again?
    >>
    >> Even HP does the extra "Power Keys", and yes, the "bases" also.
    >> Anyone know why these funcs aren't addressed more efficently?
    >>
    >> -just musing, sitting on my bench, avoiding my literature book..

    >
    > Probably just for convenience. The square, cube, square root, and cube
    > root are used more often than other powers or roots. Similarly, the
    > bases 2, 8, 10, and 16 are the most common (and will be as long as we
    > use binary computers). This can save a few keystrokes when doing
    > common calculations (Similarly, one can argue the redundancy of having
    > both common log and natural log keys).
    >
    > It might also be because of public ignorance of the relationship
    > between the functions. Texas Instruments tried leaving everything out
    > except for a single "Y^X" key (represented by a carat) on the TI-89
    > and high school students complained about the lack of an XROOT key.
    > They just didn't know that x^(p/q) is equal to the q-th root of x^p.
    >
    > S.C.
    >


    So it saves some "Rigor"...


    I don't take my 48 outside much.(too rare,too curious) and
    my 35s is currently behind my desk. If there were more steel in the
    thing, I could retreive it with a magnet. But I'll get it back soon.
    RPN just rocks, and I miss it.

    The Sharp, is a fairly solid, unremarkable, inexpensive unit with some
    very convienent continous memory features. It needs more CAS function.

    Although, everything needs more CAS functions in my mind.


  4. Re: Half O.T.(Keypad Functions On Sharp)

    On Thu, 06 Mar 2008 18:09:47 -0600, S.C. wrote:

    > Texas Instruments tried leaving everything out
    > except for a single "Y^X" key (represented by a carat) on the TI-89
    > and high school students complained about the lack of an XROOT key.
    > They just didn't know that x^(p/q) is equal to the q-th root of x^p.


    On various Casio and HP,
    "Xroot" is a bit more than just "1/X power,"
    because odd integer roots of negative real values
    produce negative real results,
    rather than the errors (or complex results)
    that "1/X power" would produce.

    My Casio calcs also "fudge" many results to simulate
    greater accuracy for special values (e.g. integers)
    than the general functions actually have over their full range.

    -[ ]-

  5. Re: Half O.T.(Keypad Functions On Sharp)

    On Mar 7, 6:47*pm, "John H Meyers" wrote:
    > On various Casio and HP,
    > "Xroot" is a bit more than just "1/X power,"
    > because odd integer roots of negative real values
    > produce negative real results,
    > rather than the errors (or complex results)
    > that "1/X power" would produce.


    In Exact mode, -8 3 XROOT on the 50g automatically switches to complex
    mode and returns 1+i\sqrt{3}. In approx mode however, it returns -2.

    > My Casio calcs also "fudge" many results to simulate
    > greater accuracy for special values (e.g. integers)
    > than the general functions actually have over their full range.
    >
    > -[ ]-


    You mean that the Casio "snaps" to integers; i.e. if the calculated
    result is 8.99999999 it will return 9?

    S.C.

  6. Re: Half O.T.(Keypad Functions On Sharp)

    On Fri, 07 Mar 2008 20:09:08 -0600, S.C. wrote:

    > In Exact mode, -8 3 XROOT on the 50g automatically switches to complex
    > mode and returns 1+i\sqrt{3}. In approx mode however, it returns -2.


    -8. 3. XROOT does result in -2.

    -8. 3. INV ^ results, however, in (1.,1.73205080757)

    On my older Casios ("real" mode), the former gives the same result,
    and the latter produces an error message.

    That's why XROOT is not quite the same as "reciprocal, then power"

    > You mean that the Casio "snaps" to integers; i.e. if the calculated
    > result is 8.99999999 it will return 9?


    Sort of. For full details (re older calculators), see:
    http://groups.google.com/group/comp....5b0aec9c4918c2

    Even some HP calcs do the same thing:
    http://groups.google.com/group/comp....464ea257f530ee

    The above thread also speculates that the calculator mentioned
    is actually using *binary* internal floating point,
    instead of decimal floating point, which introduces further complications,
    especially when it comes to "splitting hairs"
    at an "exactly halfway" rounding situation
    (note that dividing by 5 is absolutely exact in base 10,
    but leads to an infinitely long "fractional part" in base 2,
    requiring either truncation or rounding -- what to do when
    converting the result back to decimal?)

    [r->] [OFF]

  7. Re: Half O.T.(Keypad Functions On Sharp)

    On Mar 8, 6:21*pm, "John H Meyers" wrote:
    > > You mean that the Casio "snaps" to integers; i.e. if the calculated
    > > result is 8.99999999 it will return 9?

    >
    > Sort of. *For full details (re older calculators), see:http://groups.google.com/group/comp....5b0aec9c4918c2
    >
    > Even some HP calcs do the same thing:http://groups.google.com/group/comp....ead/thread/e54...
    >


    My 12-digit Casio fx-260 can't decide when to round and when to
    truncate in the display. It truncates whenever |result|<1 and rounds
    otherwise. For example, when I try 2/3 on it, it displays:

    0.666666666

    Then I add 1 to the answer and it shows:

    1.666666667

    Subtracting 1 returns back to the 0.666666666 earlier.

    Similarly, pi returns 3.141592654, but subtracting 3 from that leaves
    0.141592653.

    However, my Casio does not appear to fudge calculations. Performing 9
    SIN COS TAN ATAN ACOS ASIN returns 9.000015685(47), not exactly 9. It
    does appear to truncate intermediate calculations though, since pi LN
    LN LN EXP EXP EXP pi - returns -5e-11.

    Anyway, I agree with you in that Casio makes good, inexpensive
    calculations with much better keyboards than those on TI's.

    S.C.

  8. Re: Half O.T.(Keypad Functions On Sharp) [rounding by Casio vs. HP]

    On Sat, 08 Mar 2008 18:26:29 -0600, S.C. wrote:

    > My 12-digit Casio fx-260 can't decide when to round and when to
    > truncate in the display. It truncates whenever |result|<1
    > and rounds otherwise.


    Is that the only explanation?

    > For example, when I try 2/3 on it, it displays:
    >
    > 0.666666666
    >
    > Then I add 1 to the answer and it shows:
    >
    > 1.666666667
    >
    > Subtracting 1 returns back to the 0.666666666 earlier.
    >
    > Similarly, pi returns 3.141592654, but subtracting 3 from that leaves
    > 0.141592653


    What you are expecting is "round in the display,
    to the number of significant digits actually displayed"
    (as the HP48/49/50 series generally does),
    but it appears that your Casio first rounds an internal
    12-digit result to a constant 10-digits,
    and then displays as much of that as it can,
    dropping off the last digit when "0." is prefixed as an afterthought.

    Thus, 2/3 when rounded to ten mantissa digits is .6666666667
    but if prefixing "0." pushes the last digit off the display,
    then you would see only 0.666666666

    However, 2/3 plus 1, rounded to ten digits, would display 1.666666667

    pi minus 3, when rounded to ten digits, is .1415926536
    but if prefixing "0." pushes the last digit off the display,
    then you would see only 0.141592653

    But pi itself, rounded to 10 digits, is 3.141592654
    (calculators using 11-digit internal mantissas
    tend to use 3.1415926536 as an internal value for pi,
    or 3.14159265359 for 12-digit internal mantissas).

    The HP48/49/50 series calculators display pi as 3.14159265359
    but there is a lot more to what goes on internally,
    not only because they internally calculate every numerical function
    to 15 digits (with 5-digit exponent) and then deliver the rounded
    12-digit result (with 3-digit exponent) to be stored, rounding *that* again,
    for display purposes only, if fewer digits are actually shown,
    but also because they analyze functions a bit more deeply,
    to deliver more accurate results than most common 12-digit calculators.

    For example, in the HP48/49/50 series, RAD 3.14159265359 SIN
    results in -2.06761537357E-13, adding which to the original argument
    (on paper, to get the exact sum) yields
    3.141592653589793238462643, which is the accurate value of pi
    to 25 significant digits -- any calculator which can do that
    is effectively using an internal value of at least that precision for pi
    (what does your Casio get?)

    The thread "HP4x internal digi accuracy" (March 21-24,2007)
    suggests that doing the above in SysRPL produces pi to 31 digits,
    and other cases illustrating more careful and thorough numerical workmanship:
    http://groups.google.com/group/comp....a6ddfb49e34eb/

    [r->] [OFF]

  9. Re: Half O.T.(Keypad Functions On Sharp) [Casio behaviors]

    On Sat, 08 Mar 2008 18:26:29 -0600, S.C. wrote:

    > my [12-digit] Casio does not appear to fudge calculations. Performing
    > 9 SIN COS TAN ATAN ACOS ASIN returns 9.000015685(47), not exactly 9.
    > It does appear to truncate intermediate calculations though,
    > since pi LN LN LN EXP EXP EXP pi - returns -5e-11.


    Take the numeric square roots of many non-square real integers (e.g. 7),
    then square those, and compare with the same on HP48/49/50;
    do the same with taking reciprocals twice (e.g. 7 INV INV).

    If the Casio gets more "exact" results than HP (also 12-digit calc),
    then it is either keeping results of more than 12 mantissa digits
    or it is artifically improving the results.

    Calculators using 80-bit binary floating point can be more accurate,
    since 2^80 exceeds 10^24 (effectively nearly 24-digit decimal precision,
    if done properly); even 64-bit mantissas represent 19-digit precision,
    56-bit mantissas represent 16-digit precision, Etc. -- "overkill"
    in mantissa size can give unsophisticated algorithms a wider berth,
    after rounding, like cosmetic make-up, hides some of their flaws.

    [r->] [OFF]

  10. Re: Half O.T.(Keypad Functions On Sharp) [rounding by Casio vs. HP]

    On Mar 9, 2:41*am, "John H Meyers" wrote:
    > For example, in the HP48/49/50 series, RAD 3.14159265359 SIN
    > results in -2.06761537357E-13, adding which to the original argument
    > (on paper, to get the exact sum) yields
    > 3.141592653589793238462643, which is the accurate value of pi
    > to 25 significant digits -- any calculator which can do that
    > is effectively using an internal value of at least that precision for pi
    > (what does your Casio get?)
    >


    My Casio stores pi to 11 digits, so consequently RAD 3.141592653 SIN
    returns 6e-10. (it's one of those old one-line scientifics, so it runs
    in pseudo-RPN mode with a 2-level stack)

    Anyway, this is much better than the cheap TI scientifics that return
    garbage. The TI-30Xa stores pi to 12 digits (3.14159265359), but RAD
    3.141592653 SIN returns 5.93411945678e-10, of which only the first
    digit is correct and the second is rounded. It's better to get no
    digits than to get wrong digits.

    S.C.

  11. Re: Half O.T.(Keypad Functions On Sharp) [Casio behaviors]

    On Mar 9, 3:16*am, "John H Meyers" wrote:
    > On Sat, 08 Mar 2008 18:26:29 -0600, S.C. wrote:
    > > my [12-digit] Casio does not appear to fudge calculations. Performing
    > > 9 SIN COS TAN ATAN ACOS ASIN returns 9.000015685(47), not exactly 9.
    > > It does appear to truncate intermediate calculations though,
    > > since pi LN LN LN EXP EXP EXP pi - returns -5e-11.

    >
    > Take the numeric square roots of many non-square real integers (e.g. 7),
    > then square those, and compare with the same on HP48/49/50;
    > do the same with taking reciprocals twice (e.g. 7 INV INV).
    >
    > If the Casio gets more "exact" results than HP (also 12-digit calc),
    > then it is either keeping results of more than 12 mantissa digits
    > or it is artifically improving the results.
    >
    > Calculators using 80-bit binary floating point can be more accurate,
    > since 2^80 exceeds 10^24 (effectively nearly 24-digit decimal precision,
    > if done properly); even 64-bit mantissas represent 19-digit precision,
    > 56-bit mantissas represent 16-digit precision, Etc. -- "overkill"
    > in mantissa size can give unsophisticated algorithms a wider berth,
    > after rounding, like cosmetic make-up, hides some of their flaws.
    >
    > [r->] [OFF]


    The LongFloat library on hpcalc.org seems to have good algorithms even
    at high precision. For example, running the 9 SIN COS TAN ATAN ACOS
    ASIN operation with 25 digits results in 9.000000000000000000249569,
    showing that no "fudging" is going on.

    The library also uses Chudnovsky to calculate pi to as many digits as
    you would like, since storing pi to arbitrary precision would be a
    waste of memory.

    S.C.

+ Reply to Thread