Another weirdest hp50g thing... - Hewlett Packard

This is a discussion on Another weirdest hp50g thing... - Hewlett Packard ; Now this is strange... I wonder if I'm dumb or if I always stumble onto peculiar things... Take this number: (2^67)-1 And try to factor it with a 50g (3rd item on the "Alg" menu). After a lengthy time, it ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Another weirdest hp50g thing...

  1. Another weirdest hp50g thing...

    Now this is strange... I wonder if I'm dumb or if I always stumble
    onto peculiar things...

    Take this number: (2^67)-1
    And try to factor it with a 50g (3rd item on the "Alg" menu).
    After a lengthy time, it returns the input number, as if it can't be
    factored. But its factors are actually
    193707721 * 761838257287 .
    Now the (even weirdest) thing... If I try it with the emulator (flags
    set like the actual calc), if the emulator is set to "Authentic
    calculator speed", I get the same result as the actual calc;
    if instead I run the emulator full speed, unchecking the "Authentic
    calculator speed" option, then the emulator gives the correct
    answer!!! ?!? What's going on? Is the 50g "quitting", aborting, after
    too much time has passed and no solution is found? Can someone explain
    this?

    Sorry to always ask weird questions... But these things keep bugging
    me until I find a solution!

    TIA
    Cristian


  2. Re: Another weirdest hp50g thing...

    In article <1176658041.980159.145450@n59g2000hsh.googlegroups. com>,
    usenet1.20.quaxo@spamgourmet.com wrote:

    > Now this is strange... I wonder if I'm dumb or if I always stumble
    > onto peculiar things...
    >
    > Take this number: (2^67)-1
    > And try to factor it with a 50g (3rd item on the "Alg" menu).
    > After a lengthy time, it returns the input number, as if it can't be
    > factored. But its factors are actually
    > 193707721 * 761838257287 .
    > .
    > .
    > .
    > Can someone explain this?


    Yes, someone can explain that.

    Perhaps I can, in fact. Is it possible that you're running up against
    a limitation on the number of significant digits that the calculator is
    using?

    I'm not sure how different the HP50G is from the HP48G, but if, on my
    HP48G, I take 2 and raise it to the 67th power, I get 1.4757395259E+20.
    That's eleven digits of precision. Written out the long way, this
    number is 147,573,952,590,000,000,000. Obviously, this isn't really the
    true representation of 2^67, but it's as close as this calculator is
    capable of representing it.

    And with this limit of precision, subtracting one doesn't change it at
    all. I verified this by doing 2 67 ^ DUP 1 - -, which ought to have
    given me a result of one if there were no precision limits, and instead,
    it gives me zero.

    I'm a bit surprised that your HP50G, in trying to factor this, seems
    to decide that it's a prime number. Perhaps it does do because it
    recognizes that it's a number that exceeds its precision limits, and
    that it therefore knows that it cannot produce a correct result; but it
    seems that if that were the case, then it would come to this conclusion
    quickly, and not take as long as you say it is taking.

    When I try to factor this result on my HP48G, I get
    2^29*5*229*457*525313. This is rather surprising. I know that I
    couldn't possibly get the correct answer that you're looking for,
    because my calculator doesn't have nearly enough precision to do so. I
    expected a correct factoring of what I thought was being represented,
    which was 147,573,952,590,000,000,000; but since that number is a
    multiple of 10^10, there should be at least ten fives in the result, and
    there is only one. I suppose my error here was to assume that with a
    number that has more digits than the calculator can represent, that the
    extra unrepresented digits would be treated as being zeros.


    > Now the (even weirdest) thing... If I try it with the emulator (flags
    > set like the actual calc), if the emulator is set to "Authentic
    > calculator speed", I get the same result as the actual calc;
    > if instead I run the emulator full speed, unchecking the "Authentic
    > calculator speed" option, then the emulator gives the correct
    > answer!!! ?!? What's going on? Is the 50g "quitting", aborting, after
    > too much time has passed and no solution is found?


    I'm not familiar, as I said, with the HP50G, and I am even less
    familiar with whatever emulator you are running. A guess I might make
    here is that when the emulator is set to "Authentic calculator speed"
    that it feels obligated to be as true as possible to the calculator that
    it is emulating, but that when it is set otherwise, it takes some
    liberties to try to be "better" than the genuine calculator in ways
    other than speed. Apparently, one of these other liberties that it
    takes is to implement a much higher degree of precision, that allows it
    to give you the true answer that you are looking for.

    --
    "Today, we celebrate the first glorious anniversary of the Information
    Purification Directives. ... Our Unification of Thoughts is more powerful
    a weapon than any fleet or army on earth. ... Our enemies shall talk
    themselves to death and we will bury them with their own confusion."

  3. Re: Another weirdest hp50g thing...

    Pheraps there is a time limit in the algorithm: in fast mode the emulator
    is able to find the solution before reaching the limit.

    MS


  4. Re: Another weirdest hp50g thing...

    On Apr 15, 3:37 pm, "Massimo Santin \(at GMail\)"
    wrote:
    > Pheraps there is a time limit in the algorithm: in fast mode the emulator
    > is able to find the solution before reaching the limit.
    >
    > MS


    http://groups.google.com/group/comp....rch+this+group

    Wonderful searching in google groups!

    TW


  5. Re: Another weirdest hp50g thing...

    On Sun, 15 Apr 2007 21:04:09 GMT, Bob Blaylock
    wrote:

    >In article <1176658041.980159.145450@n59g2000hsh.googlegroups. com>,
    > usenet1.20.quaxo@spamgourmet.com wrote:
    >
    >> Now this is strange... I wonder if I'm dumb or if I always stumble
    >> onto peculiar things...
    >>
    >> Take this number: (2^67)-1
    >> And try to factor it with a 50g (3rd item on the "Alg" menu).
    >> After a lengthy time, it returns the input number, as if it can't be
    >> factored. But its factors are actually
    >> .
    >> .
    >> .
    >> .
    >> Can someone explain this?

    >
    > Yes, someone can explain that.
    >
    > Perhaps I can, in fact. Is it possible that you're running up against
    >a limitation on the number of significant digits that the calculator is
    >using?
    >
    > I'm not sure how different the HP50G is from the HP48G, but if, on my
    >HP48G, I take 2 and raise it to the 67th power, I get 1.4757395259E+20.
    >That's eleven digits of precision. Written out the long way, this
    >number is 147,573,952,590,000,000,000. Obviously, this isn't really the
    >true representation of 2^67, but it's as close as this calculator is
    >capable of representing it.
    >
    > And with this limit of precision, subtracting one doesn't change it at
    >all. I verified this by doing 2 67 ^ DUP 1 - -, which ought to have
    >given me a result of one if there were no precision limits, and instead,
    >it gives me zero.
    >
    > I'm a bit surprised that your HP50G, in trying to factor this, seems
    >to decide that it's a prime number. Perhaps it does do because it
    >recognizes that it's a number that exceeds its precision limits, and
    >that it therefore knows that it cannot produce a correct result; but it
    >seems that if that were the case, then it would come to this conclusion
    >quickly, and not take as long as you say it is taking.
    >
    > When I try to factor this result on my HP48G, I get
    >2^29*5*229*457*525313. This is rather surprising. I know that I
    >couldn't possibly get the correct answer that you're looking for,
    >because my calculator doesn't have nearly enough precision to do so. I
    >expected a correct factoring of what I thought was being represented,
    >which was 147,573,952,590,000,000,000; but since that number is a
    >multiple of 10^10, there should be at least ten fives in the result, and
    >there is only one. I suppose my error here was to assume that with a
    >number that has more digits than the calculator can represent, that the
    >extra unrepresented digits would be treated as being zeros.
    >
    >
    >> Now the (even weirdest) thing... If I try it with the emulator (flags
    >> set like the actual calc), if the emulator is set to "Authentic
    >> calculator speed", I get the same result as the actual calc;
    >> if instead I run the emulator full speed, unchecking the "Authentic
    >> calculator speed" option, then the emulator gives the correct
    >> answer!!! ?!? What's going on? Is the 50g "quitting", aborting, after
    >> too much time has passed and no solution is found?

    >
    > I'm not familiar, as I said, with the HP50G, and I am even less
    >familiar with whatever emulator you are running. A guess I might make
    >here is that when the emulator is set to "Authentic calculator speed"
    >that it feels obligated to be as true as possible to the calculator that
    >it is emulating, but that when it is set otherwise, it takes some
    >liberties to try to be "better" than the genuine calculator in ways
    >other than speed. Apparently, one of these other liberties that it
    >takes is to implement a much higher degree of precision, that allows it
    >to give you the true answer that you are looking for.


    It worked as you said it should on my TI voyage 200; 193707721 *
    761838257287 was the answer I got.
    FYI

    Don

  6. Re: Another weirdest hp50g thing...

    On Sun, 15 Apr 2007 16:37:40 -0500, Massimo Santin wrote:

    > Perhaps there is a time limit in the algorithm:
    > in fast mode the emulator is able to find the solution
    > before reaching the limit.


    You are most perceptive!

    It is unfortunate that no flag is set, say,
    for detecting whether the result was terminated by time;
    after all, not only might there be some system flag
    still unused, but some commands even set a user flag
    to indicate some result condition,
    so this could still have been provided,
    and would better have protected the product
    against getting a bad reputation for "wrong answers."

    It would be much more acceptable to be able to say
    something like "this has no prime factors less than xxxxx"
    or "this has passed probable-prime tests for this many
    terms in sequence yy, zz..." than to just "stonewall" as it does;
    given that a reserved variable name 'IERR' is used to return
    extra information about the results of numeric integration,
    perhaps another variable (or even the same one!)
    could be used to return some such information
    about where a prime test had to stop.

    A user-settable time limit would also have been
    a most valuable addition -- after all, there's an optional
    TOFF variable to set a non-default "auto off" time,
    an optional \->KEYTIME command
    to store a non-default key-debounce time,
    so if only there were also an optional factoring time limit,
    most easily done via a reserved-name variable,
    then all this "hey, my TI voyage 200 can get it right
    but your crummy HP not only can't do it but lies"
    bad publicity could be avoided, and product confidence increased.

    Put it down for rom 2.11,
    along with various things "already fixed in 2.10"
    (which has unfortunately not seen the light of day,
    even though what's been fixed and improved in it
    has been described in detail).

    -[ ]-

  7. Re: Another weirdest hp50g thing...

    Bob Blaylock wrote:
    > Perhaps I can, in fact. Is it possible that you're running up against
    > a limitation on the number of significant digits that the calculator is
    > using?

    Think about it: it just can't be...
    For once, calculation is made in exact mode, not floating point here.
    2nd, it only depends on how fast the calculator is...

    Why would this be linked in any way to how internal floating point
    calculations are performed?

    JY

  8. Re: Another weirdest hp50g thing...


    "John H Meyers" wrote in message
    newsp.tqupluznnn735j@w2kjhm.ia.mum.edu...
    > On Sun, 15 Apr 2007 16:37:40 -0500, Massimo Santin wrote:
    >
    >> Perhaps there is a time limit in the algorithm:
    >> in fast mode the emulator is able to find the solution
    >> before reaching the limit.

    >
    > You are most perceptive!


    Many many years of professional software development (and more if you
    consider when I purchased my HP-34C) can help to enhance your perception!
    ;-)

    > It is unfortunate that no flag is set, say,
    > for detecting whether the result was terminated by time;
    > ...


    These aren't good news!

    > given that a reserved variable name 'IERR' is used to return
    > extra information about the results of numeric integration,
    > perhaps another variable (or even the same one!)
    > could be used to return some such information
    > about where a prime test had to stop.
    >
    > A user-settable time limit would also have been
    > a most valuable addition
    > ...


    I agree with you completely. I own myself a TI-89 (Don't ask! It is my
    second TI in my life!) and I think that HP is much better because the
    superior programming model and some clever algorithms but I understand why
    an high school or college student can be attracted to the TI world. In the
    real world I don't see a practical use to factorize 2^67-1 but school isn't
    real world or, perhaps, I'm wrong about that.

    Massimo Santin


  9. Re: Another weirdest hp50g thing...


    "TW" wrote in message
    news:1176673695.520679.310890@e65g2000hsc.googlegr oups.com...
    > On Apr 15, 3:37 pm, "Massimo Santin \(at GMail\)"
    > wrote:
    >> Pheraps there is a time limit in the algorithm: in fast mode the
    >> emulator
    >> is able to find the solution before reaching the limit.
    >>
    >> MS

    >
    > http://groups.google.com/group/comp....rch+this+group
    >
    > Wonderful searching in google groups!
    >
    > TW


    I'm happy to know that I'm right: time limit! :-) But the news aren't good
    because there isn't any indication.


  10. Re: Another weirdest hp50g thing...

    > I agree with you completely. I own myself a TI-89 (Don't ask! It is my
    > second TI in my life!) and I think that HP is much better because the
    > superior programming model and some clever algorithms but I understand why
    > an high school or college student can be attracted to the TI world. In the
    > real world I don't see a practical use to factorize 2^67-1 but school
    > isn't
    > real world or, perhaps, I'm wrong about that.


    Just the other day I was asking myself, "Gee, what is 2^67-1 factored?"
    Now I know! It will help me with my taxes, credit card payments and
    computing the number of deaths in Iraq.

    Tom Lake



  11. Re: Another weirdest hp50g thing...

    > It is unfortunate that no flag is set, say,
    > for detecting whether the result was terminated by time...


    Hypothesis:

    This can *usually* be determined in a simple manner by the user: If
    FACTOR (or FACTORS or COLLECT) takes *over one minute* to return the
    input integer unfactored, then the input is composite and the
    factoring timed out. The reason for this is that FACTOR checks its
    input with ISPRIME? before attempting to factor it, and ISPRIME? can
    identify composite numbers rather quickly. It returns 0 for inputs
    that are definitely composite, such as 2^67-1, which ISPRIME?
    identifies as composite in 3 seconds. ISPRIME? *never* identifies a
    prime as composite, although the reverse can occur for large pseudo-
    primes.

    Examples:

    2^67+3 FACTOR --> returns the input in 5 seconds. That means that
    the input is actually prime, and that FACTOR didn't just give up
    trying.

    2^67+1 FACTOR --> returns 3*bignum in 95 seconds. That means that
    bignum is composite, but FACTOR gave up trying to factor it.

    2^67+5 FACTOR --> product of 4 numbers in 6 seconds. That means
    that all those factors are actually prime.

    Bottom line: If FACTOR takes less than 1 minute, then its output is
    completely factored. If it takes more than 1 minute, then its output
    is incompletely factored.

    If this hypothesis is incorrect, please post a counterexample.
    Thanks!

    -Joe-


  12. Re: Another weirdest hp50g thing...

    Joe,

    Why one minute?

    I think there two problems with your guess:

    1. The time is dependent from the platform. What happens if you overclock
    your calculator? Or when you underclock it to save battery? Or if HP will
    release a new fantastic calculator much faster?

    2. If you write programs you need to encapsulate the factorization code into
    a TEVAL sequence or similar and you need to take decision on that. Not
    elegant.

    It would be better to have a flag or an error variable.

    Another problem is that beahviour isn't documented (I just checked the
    FACTOR command in CAS section of HP-49g+ Advanced User's Reference Manual).
    Question: are there other parts/commands/algorthms that suffer of the same
    problem/design decision?

    Massimo Santin


  13. Re: Another weirdest hp50g thing...

    On Mon, 16 Apr 2007 05:40:14 -0500, Massimo Santin wrote:

    > Why one minute?
    > The time is dependent from the platform.
    > What happens if you overclock your calculator?
    > Or when you underclock it to save battery?
    > Or if HP will release a new fantastic calculator much faster?


    What happens when you use a computer emulator,
    which is very "overclocked" -- did it finish factoring,
    or did it stop, based on how many *operations* it performed?

    If it were based on total clock cycles,
    the "give up" point should be about the same,
    rather than capability increasing with (emulated) CPU speed.

    A 50G/49G+/48Gii should likewise beat a slow old 49G.

    I'm really most impressed with the "quantum computer"
    that just a few years ago managed to factor the number 15 into 3*5

    Maybe that's why the CAS gang felt so satisfied, even with
    less capacity than TI -- they beat a quantum computer, after all

    -[ ]-

  14. Re: Another weirdest hp50g thing...

    On Apr 16, 8:40 am, "John H Meyers" wrote:
    > I'm really most impressed with the "quantum computer"
    > that just a few years ago managed to factor the number 15 into 3*5


    To be fair, a quantum computer is only able to give some probability
    less than 1 that these are valid factors.

    -Jonathan


  15. Re: Another weirdest hp50g thing...

    > 2^67-1

    This number actually has some historical significance. Check out the
    following:

    http://en.wikipedia.org/wiki/Frank_Nelson_Cole

    -wes


  16. Re: Another weirdest hp50g thing...

    I can understand your thinking. I'm disappointed about this problem, too.
    :-( The HP/CAS team needs to address this and other questions, I think.

    But is there an answer to my question about other parts/commands/algorithms
    that suffer of the same
    problem/design decision?

    Massimo Santin


  17. Re: Another weirdest hp50g thing...


    > But is there an answer to my question about other parts/commands/algorithms
    > that suffer of the same
    > problem/design decision?
    >
    > Massimo Santin


    I think it would be important to know exactly the limits of our
    machines. HP should clearly state these.
    And I think it's rather bad to implement a function that "sometimes"
    gives correct result. This isn't dependable... either make a function
    that always works, or a function that when it doesn't work fails in a
    clear way (i.e. an error message), or remove that function
    altogether... HP should really address this...

    Cristian



  18. Re: Another weirdest hp50g thing...


    "Steen Schmidt" wrote in message
    news:xn0f51b3s49q5v001@news.tele.dk...

    > Which HP CAS team?


    The single guy? Or you are telling me that in my future there will be only
    TI calculators?

    MS


  19. Re: Another weirdest hp50g thing...

    Massimo Santin wrote:

    > Why one minute?


    Because that's the hard-coded time-out used by FACTOR. It first
    checks ISPRIME?, and if the number is NOT prime, then it begins its
    search for factors. If none are found after one minute (according to
    the system clock), it gives up.

    > I think there two problems with your guess:
    >
    > 1. The time is dependent from the platform. What happens if you overclock
    > your calculator? Or when you underclock it to save battery? Or if HP will
    > release a new fantastic calculator much faster?


    The "one minute" is *actual time*, so a faster machine will find more
    factors than a slower machine. More iterations per minute yields more
    factors found before timing out. This has already been demonstrated by
    the fact that 2^67-1 does not factor at all on a real HP50g but it
    *does* factor on the emulator running on a fast computer.

    > 2. If you write programs you need to encapsulate the factorization code into
    > a TEVAL sequence or similar and you need to take decision on that. Not
    > elegant.


    I totally agree.

    > It would be better to have a flag or an error variable.


    I certainly agree with you and John Meyers about that. My hypothesis
    stands, however: it's *POSSIBLE* to know when FACTOR times out. Nobody
    has posted a counterexample to my hypothesis yet.

    > Another problem is that beahviour isn't documented (I just checked the
    > FACTOR command in CAS section of HP-49g+ Advanced User's
    > Reference Manual).


    HP hasn't produced a good manual in many years. I hope that their
    interest in rediscovering "The Old HP" will eventually lead to better
    documentation.

    > Question: are there other parts/commands/algorthms that suffer of the same
    > problem/design decision?


    Are you referring to secretly timing out, or to the more general
    problem of secretly making decisions for the user which the user
    should really know about? The latter would be very difficult to
    enumerate, since there are so many, and since "should really know
    about" is impossible to define precisely. As for the former, I
    *think* that FACTOR, FACTORS, and COLLECT (on an integer) are the only
    commands that time out without notification, except of course for the
    commands whose *purpose* includes timing out without notification
    (e.g. WAIT and some I/O commands). Anybody know of any other math
    functions that secretly give up after a hard-coded amount of time?

    -Joe-


  20. Re: Another weirdest hp50g thing...

    On Mon, 16 Apr 2007 14:58:44 -0500, Steen Schmidt wrote:

    > Which HP CAS team?


    Wasn't that originally the BP team,
    before HP stopped supplying it with gas?

    The VER command credits other original authors,
    whose participation may have long since faded away.

    -[ ]-

+ Reply to Thread
Page 1 of 2 1 2 LastLast