Remark:
The larger the number the longer time it takes to give result even on HP-12C+
when the display show "running" and keep going that always is a prime number since
the result when it is not a prime number will show 0 instantly.

Unless I'm mistaken, for an input of X, you're testing all numbers 2 through X. But you only need to check 2 through the INTG of the square root of X. This would make the program finish much faster for primes. For example, for an input of 101, you can stop checking at 10 instead of going all the way up to 101.

(09-10-2018 04:16 PM)Joe Horn Wrote: But you only need to check 2 through the INTG of the square root of X. This would make the program finish much faster for primes. For example, for an input of 101, you can stop checking at 10 instead of going all the way up to 101.

You can also check whether the input is even (=> no prime) and then only test the odd divisors. For the 101 example this means that not 99 divisors have to be checked but only five: 2, 3, 5, 7 and 9 (as 11 already is > √101). That's a speedup by a factor of almost 20.

What happens if no calculator ?
From book "Dead Reckoning: Calculating without Instrument", Fermat have a way that required no divisions !

Assume N is odd, the trick is start from the middle, integer X slightly bigger than sqrt(N):
If N had any factors, it must be in the form N = (X - Y)(X + Y) = X^2 - Y^2, X > Y
Rearrange, we get Y^2 = X^2 - N

The problem now is to recognize valid Y^2: last 2 digits must be 00, e1, e4, 25, d6, e9
Another validity check: Y^2 % 9 must be 0, 1, 4, 7

If N is prime, when to stop the search ? Let P be minimum prime to be tested:

As Thomas already pointed out, the problem is the 12C's 10-digit precision. Here 9.000.000.001 divided by 2 simply is 4.500.000.001 – an integer, so the program thinks that the input is divisible by 2 and thus not a prime. The same would also happen when dividing by 3, 5, 7 or 9 and even 25.

As already discussed in the other thread with the program that checks whether one integer is a power of another, the 12CP does not seem to round its results to 10 significant digits. Which means that here a fractional part exists and thus the test performs correctly.

But this seems to be a bug in the 12CP emulator. I don't know much about the physical 12CP. How does it work? Does it have the same 10-digit precision as the 12C? Or does it use a higher precision while only 10 (out of 12 or 15) digits are displayed?

You may try this: calculate 4.444.444.444 / 3 and get 1.481.481.481. Now subtract 1.481.481.481 (or press g FRAC). On a real 12C the result is 0. But what do you get on the 12CP emulator? 0,3? 0,333? Please post all digits (i.e. as displayed in FIX 9).

Having said that, the largest input for a number to test is 1.999.999.999.
So the largest prime is 1.999.999.973. How long does this take on your various devices?

But the essential point here is not the internal precision but what is returned to the user. Do the 12C Platinum or 12C+ (real hardware) return 10 or 12 digits? In both cases the display has 10 digits. What do you see after 3 [1/x] 30 [x] in FIX 9 mode? 10,00000000 or 9,999999999 ?

Also, could you or someone else please do the following test on a hardware 12C Platinum or 12C+? As already mentioned in my previous post:

Quote:You may try this: calculate 4.444.444.444 / 3 and get 1.481.481.481. Now subtract 1.481.481.481 (or press g FRAC). On a real 12C the result is 0. But what do you get on the 12CP emulator? 0,3? 0,333? Please post all digits (i.e. as displayed in FIX 9).

I really would like to know what results are produced both by the real (hardware) calculators as well as the emulators (please state which one).

(09-13-2018 06:35 PM)Dieter Wrote: But the essential point here is not the internal precision but what is returned to the user. Do the 12C Platinum or 12C+ (real hardware) return 10 or 12 digits? In both cases the display has 10 digits. What do you see after 3 [1/x] 30 [x] in FIX 9 mode? 10,00000000 or 9,999999999 ?

(09-13-2018 06:35 PM)Dieter Wrote: Also, could you or someone else please do the following test on a hardware 12C Platinum or 12C+? As already mentioned in my previous post:

Quote:You may try this: calculate 4.444.444.444 / 3 and get 1.481.481.481. Now subtract 1.481.481.481 (or press g FRAC). On a real 12C the result is 0. But what do you get on the 12CP emulator? 0,3? 0,333? Please post all digits (i.e. as displayed in FIX 9).

I was curious, which answer you preferred most ?
The wink, wink can be intepreted either way

there is beauty in what you see is what you get ... but, more precision is better

0.330000000 is without question the right answer. The emulator, by definition, must return the exact same results as the machine it is emulating, even if the emulator's answer is theoretically more accurate.

Sorry if my Python quote was misleading, it's just what popped into my head when I saw the result, 'no need to say any more'.

Thank you, Bob. Very enlightening, indeed. So the emulator does not seem to round the internal 15-digit result back to 12 digits. I wonder if this also applies to other functions. What does frac(sqrt(2E8)) return? 0,1356237 or are there more decimals? In the latter case the final digit(s) may be slightly off. 15 digits internal precision does not mean that in the end all 15 are correct.

Anyway, the emulator obviously does not emulate a 12C Platinum. This means that it can and will produce results that do not match those from a hardware calculator.

As the 12C and 12C Platinum have different precision this also means that 12C programs can give other results if run on the 12C Platinum. I wonder if this also applies to the working range: usually the 12-digit calculators operate in a domain of 1E–499 to 9,999...E+499. Is this also true for the 12C Platinum? Does e^500 produce an overflow error or does it return 1,40359...E+217 ?

(09-14-2018 12:18 PM)Dieter Wrote: Thank you, Bob. Very enlightening, indeed. So the emulator does not seem to round the internal 15-digit result back to 12 digits. I wonder if this also applies to other functions. What does frac(sqrt(2E8)) return? 0,1356237 or are there more decimals? In the latter case the final digit(s) may be slightly off. 15 digits internal precision does not mean that in the end all 15 are correct.

12C+: 0.135620000 (Note: I am using the preceding "E" to be clear, but these are not actually displayed, there is simply a space)
12C Emulator: 0.135620000
12CP: 0.135623700
12CP Emulator: 0.135623731 <=== Again, deviation from correct behavior

(09-14-2018 12:18 PM)Dieter Wrote: As the 12C and 12C Platinum have different precision this also means that 12C programs can give other results if run on the 12C Platinum. I wonder if this also applies to the working range: usually the 12-digit calculators operate in a domain of 1E–499 to 9,999...E+499. Is this also true for the 12C Platinum? Does e^500 produce an overflow error or does it return 1,40359...E+217 ?

From the 12C Manual on p. 84 (exact same content is also in the 12CP manual):

Quote:Overflow and Underflow. If a calculation results in a number
whose magnitude is greater than 9.999999999 X 10^99 the
calculation is halted and the calculator displays 9.999999 99 (if
the number is positive) or -9.999999 99 (if the number is
negative).

If a calculation results in a number whose magnitude is less than 10-99,
the calculation is not halted, but the value 0 is used for that
number in subsequent calculations.

I never noticed this before, but I don't see any specific description of the supported numeric range in either manual.

(09-14-2018 04:19 PM)rprosperi Wrote: 12C+: 0.135620000 (Note: I am using the preceding "E" to be clear, but these are not actually displayed, there is simply a space)
12C Emulator: 0.135620000
12CP: 0.135623700
12CP Emulator: 0.135623731 <=== Again, deviation from correct behavior

...but at least correctly rounded. There should be one more digit on the 12C Platinum emulator. What do you get if you multiply the result by 10? The true value of sqrt(2) is 1,4142135623730950488... so the emulator should show 1,356237310 (when correctly rounded up) or at least 1,356237309 (when truncated after the 15th digit, as the internal routines often do – think of the 5^2 – 25 example).

(09-14-2018 06:33 PM)Dieter Wrote: What do you get if you multiply the result by 10? The true value of sqrt(2) is 1,4142135623730950488... so the emulator should show 1,356237310 (when correctly rounded up) or at least 1,356237309 (when truncated after the 15th digit, as the internal routines often do – think of the 5^2 – 25 example).

When multiplied by 10, the result is 1.356237309, so it appears truncation rather than rounding is used on the 12CP emulator. Most likely though is this is just an error, retaining the full value from the underlying C math; unlike the 12c emulator running the original ROM, perhaps the 12CP was recompiled for the new Android cpu, "bringing along" the extra digits which are then crammed into the 10-digit display routines.