How do I get Prime numbers 1-100

I'd like to propose a very different, scalable, very Appian equivalent of prime number detection:

1. Confirm that the business needs prime numbers 1-100 and assess the future risk that 100 is simply too low.
   1. If you presume that one day they will need number > 100 then you can likely solve all of their future use cases with another 20 minutes of effort.
   2. Recognize that if you miscalculate this risk, performance will significantly degrade very quickly
2. Pre-load a sync'ed record with with your dataset of the first N prime numbers.
   1. See the attached sync expression JS_primes for a dynamic calculation where N = 13,848(testing numbers 1-150k); however this is not the only approach, and YMMV with this approach if the business truly needs a gargantuan set of prime numbers to choose from.
   2. The nightly sync is disabled - this data never changes after deployment anyways
   3. N is <= the maximum record allowance (we'll say 4 million rows for most of us). If you're sure you only want primes between 1-100, then N = 25. Update the record sync expression or data loading approach accordingly.
   4. The prime integer can be stored as an integer for record sync purposes since the 10,000,000th prime integer is 179,424,673 - thus we don't need to worry about integer overflow for now. If Appian increases the max record sync'ed rows beyond 50,000,000, then this could change.
   5. No non-prime number should exist in the sync'ed record
3. Run a!queryRecordType() on the table with a!queryFilter(field: integer_int, operator:"<=", value: 100)

Sync Expression:

Optimized isPrime calculation:

Since this exercise is usually brought up as a way to teach complexity of calculations / compute time vs tradeoffs of storage / memory:

I'd like to propose a very different, scalable, very Appian equivalent of prime number detection:

1. Confirm that the business needs prime numbers 1-100 and assess the future risk that 100 is simply too low.
   1. If you presume that one day they will need number > 100 then you can likely solve all of their future use cases with another 20 minutes of effort.
   2. Recognize that if you miscalculate this risk, performance will significantly degrade very quickly
2. Pre-load a sync'ed record with with your dataset of the first N prime numbers.
   1. See the attached sync expression JS_primes for a dynamic calculation where N = 13,848(testing numbers 1-150k); however this is not the only approach, and YMMV with this approach if the business truly needs a gargantuan set of prime numbers to choose from.
   2. The nightly sync is disabled - this data never changes after deployment anyways
   3. N is <= the maximum record allowance (we'll say 4 million rows for most of us). If you're sure you only want primes between 1-100, then N = 25. Update the record sync expression or data loading approach accordingly.
   4. The prime integer can be stored as an integer for record sync purposes since the 10,000,000th prime integer is 179,424,673 - thus we don't need to worry about integer overflow for now. If Appian increases the max record sync'ed rows beyond 50,000,000, then this could change.
   5. No non-prime number should exist in the sync'ed record
3. Run a!queryRecordType() on the table with a!queryFilter(field: integer_int, operator:"<=", value: 100)

Sync Expression:

Optimized isPrime calculation:

Since this exercise is usually brought up as a way to teach complexity of calculations / compute time vs tradeoffs of storage / memory: