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."