+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: QB64 Rising (https://staging.qb64phoenix.com/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://staging.qb64phoenix.com/forumdisplay.php?fid=3)
+---- Forum: Programs (https://staging.qb64phoenix.com/forumdisplay.php?fid=7)
+---- Thread: Challenge for you... (/showthread.php?tid=1629)
RE: Challenge for you... - mnrvovrfc - 04-21-2023
(04-21-2023, 01:34 AM)Jack Wrote: @mnrvovrfc
go right ahead and complete the challenge and compute 100 primes using the formula, put your money where your mouth is, I seriously doubt that you would even compute 20 primes
I was merely pointing out something about 64-bit integer because somebody else asked for it, instead of using _FLOAT. Which is a data type useless in my programming endeavors.
Also I was trying to go along with the first post. Indeed it is a challenge which indicates QB64(PE) is a general-purpose programming language which is less impressive with dedicated scientific-strength math than some other option, maybe Julia, and without requiring a third-party library.
RE: Challenge for you... - Jack - 04-21-2023
@eoredson
it takes 21 digits of floating point precision to get 7 primes, about 38 digits to get 10 primes
RE: Challenge for you... - Jack - 04-21-2023
@mnrvovrfc
I would like to see you compute 100 primes using the formula in any language
RE: Challenge for you... - eoredson - 04-21-2023
I am closing this Challenge for the reason that it is unsolvable.
The formula is invalid and produces incorrect results.
Thanks for your time and effort.
Erik.
RE: Challenge for you... - mnrvovrfc - 04-21-2023
(04-21-2023, 02:09 AM)eoredson Wrote: Actually, modifying your nthprime program slightly with Double extended to _Float it still returns the 7th prime as 129..
This is because one of the numeric types is wrapping around somewhere. Recompile the program with "debug" enabled (scratch head), I had only known it was possible to do that with the BC.EXE compiler so that it returns an "Overflow" runtime error in that case.
_FLOAT seems to be unable to do any better than _INTEGER64 with only 18 or 19 places of precision, when 21 are needed like Jack just said.
RE: Challenge for you... - Jack - 04-21-2023
it's unsolvable not because the formula is wrong but because it's simply impractical, I am guessing that to compute 100 primes using the formula within our lifetime would take a very fast super computer, if it's even possible
RE: Challenge for you... - bplus - 04-21-2023
(04-21-2023, 02:33 AM)eoredson Wrote: I am closing this Challenge for the reason that it is unsolvable.
The formula is invalid and produces incorrect results.
Thanks for your time and effort.
Erik.
No the formula is correct, we just don't have the precision to do the math in it with QB64 without some serious math library code.
And as Jack says, it still may take a super computer to make a calculation in our lifetime.
Like I said before, sieving is way, way, way faster!!!
RE: Challenge for you... - DANILIN - 04-21-2023
1001 prime is 104743
06-06-2022, 08:15 PM
https://staging.qb64phoenix.com/showthread.php?tid=310&pid=2945#pid2945
long read
https://rosettacode.org/wiki/10001th_prime
RE: Challenge for you... - mnrvovrfc - 04-21-2023
Could this be doable in "string math"?
Code: (Select All)
double Fast_Pow(double a, double b) //fastpower originally developed by Martin Ankerl
{
int tmp = (*(1 + (int *)&a));
int tmp2 = (int)(b * (tmp - 1072632447) + 1072632447);
double p = 0.0;
*(1 + (int * )&p) = tmp2;
//p = p * a / 2.71828F ; failed attempt to auto correct the accuracy
return tmp;
}from:
https://qb64phoenix.com/qb64wiki/index.php/C_Libraries#Fast_Math
EDIT: I was responding to bplus saying something about "power" function being difficult to implement if it involves fractions, is that right? But this function might not be a solution because it seems to force a cast from double-precision to same-size integer. That first statement is ugly. :/
RE: Challenge for you... - bplus - 04-21-2023
(04-21-2023, 02:18 PM)mnrvovrfc Wrote: Could this be doable in "string math"?
Code: (Select All)double Fast_Pow(double a, double b) //fastpower originally developed by Martin Ankerl
{
int tmp = (*(1 + (int *)&a));
int tmp2 = (int)(b * (tmp - 1072632447) + 1072632447);
double p = 0.0;
*(1 + (int * )&p) = tmp2;
//p = p * a / 2.71828F ; failed attempt to auto correct the accuracy
return tmp;
}
from:
https://qb64phoenix.com/qb64wiki/index.php/C_Libraries#Fast_Math
EDIT: I was responding to bplus saying something about "power" function being difficult to implement if it involves fractions, is that right? But this function might not be a solution because it seems to force a cast from double-precision to same-size integer. That first statement is ugly. :/
That 2.71828F looks like e so doing powers with natural logarithm. That e does not look nearly precise enough for long digit math but maybe it doesn't need to be, I doubt it though. The rest of that code is Greek to me ;-))
My problem with powers is cutting down the digits to only significant amounts because my calc's use everything in multiplication, so keep multiplying long digits numbers and double their lengths in digits each time basically.
Still that crazy formula is summing long calculations and as the Prime number increases you expand on digits (more than? is that possible?) exponentially but you need more and more digits to get nice pretty integer answers.