Challenge for you...
#31
(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.
Reply
#32
@eoredson
it takes 21 digits of floating point precision to get 7 primes, about 38 digits to get 10 primes
Reply
#33
@mnrvovrfc
I would like to see you compute 100 primes using the formula in any language
Reply
#34
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.
Reply
#35
(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.
Reply
#36
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
Reply
#37
(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!!!
b = b + ...
Reply
#38
1001 prime is 104743

06-06-2022, 08:15 PM

https://staging.qb64phoenix.com/showthre...45#pid2945

long read

https://rosettacode.org/wiki/10001th_prime
Write name of program in 1st line to copy & paste & save filename.bas
Insert program pictures: press print-screen-shot button
Open paint & Paste & Save as PNG
Add picture file to program topic

Russia looks world from future. Big data is peace data.
I never recommend anything & always write only about myself
Reply
#39
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.p...#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. :/
Reply
#40
(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.p...#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.
b = b + ...
Reply




Users browsing this thread: 11 Guest(s)