Another weirdest hp50g thing...
usenet1....@spamgourmet.com
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
Bob Blaylock
usenet1....@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."
Massimo Santin (at GMail)
is able to find the solution before reaching the limit.
MS
TW
Wonderful searching in google groups!
TW
Don
<BobHat...@Blaylock.to> wrote:
>In article <1176658041.9...@n59g2000hsh.googlegroups.com>,
> usenet1....@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
It worked as you said it should on my TI voyage 200; 193707721 *
761838257287 was the answer I got.
FYI
Don
John H Meyers
> 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).
-[ ]-
Jean-Yves Avenard
> 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?
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
Massimo Santin (at GMail)
"John H Meyers" <jhme...@nomail.invalid> wrote in message
news:op.tqupl...@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
Massimo Santin (at GMail)
"TW" <timwe...@gmail.com> wrote in message
news:1176673695.5...@e65g2000hsc.googlegroups.com...
I'm happy to know that I'm right: time limit! :-) But the news aren't good
because there isn't any indication.
Tom Lake
> 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
Joe Horn
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-
Massimo Santin (at GMail)
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
John H Meyers
> 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 :)
-[ ]-
bokubob
> 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
Wes
This number actually has some historical significance. Check out the
following:
http://en.wikipedia.org/wiki/Frank_Nelson_Cole
-wes
Massimo Santin (at GMail)
:-( 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
usenet1....@spamgourmet.com
> 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
Steen Schmidt
> 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.
Which HP CAS team?
Cheers,
Steen
Massimo Santin (at GMail)
"Steen Schmidt" <ssch...@nospam.dk> wrote in message
news:xn0f51b3...@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
Joe Horn
> 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-
John H Meyers
> 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.
-[ ]-
Steen Schmidt
> 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?
Exactly. Today there are no one to work on the CAS, just as there are
no one* to work on the rest of the OS.
* No one that really are able to, that is.
> The VER command credits other original authors,
> whose participation may have long since faded away.
That is a safe bet.
Cheers,
Steen
Massimo Santin (at GMail)
> Exactly. Today there are no one to work on the CAS, just as there are
> no one* to work on the rest of the OS.
>
> * No one that really are able to, that is.
"Sarà quel che sarà"
"E la Texas si userà"
Translated: What will be will be/And we will use Texas (Instruments)!
In Italian the sound is better, but my poetry is very bad.
MS