Start with a few simple primes, such as local!primes:{2,3,5,7,13}
forEach( items: enumerate(100) +1
expression: if
any(local!candidate = fv!item, /*any() function returns true if any of the elements in a boolean array are true*/
forEach( items: local!primes)
expression: mod(fv!candidate, fv!item) = 0 /*if a prime evenly divides your candidate number, it's not prime)
true, /*true in this case means it's true that it's not prime*/
false
), /*the for loop inside the any() function is just the first parameter of the if, if any are true, then it's not prime*/
null, /*so if it's not prime, don't return it, or if none of the primes we picked out divide it, maybe it's prime, return it*/
fv!item
)
Take the output of this and append it to local!primes to refine it. You can keep adding more and more to get more and more primes. It starts to get time consuming up into the 4 and 5 digit primes, but it will continue to work if you continue to add to the starting primes.
You could also just go to wolfram alpha and copy and paste the answer into a constant.
I'd like to propose a very different, scalable, very Appian equivalent of prime number detection:
Confirm that the business needs prime numbers 1-100 and assess the future risk that 100 is simply too low.
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.
Recognize that if you miscalculate this risk, performance will significantly degrade very quickly
Pre-load a sync'ed record with with your dataset of the first N prime numbers.
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.
The nightly sync is disabled - this data never changes after deployment anyways
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.
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.
No non-prime number should exist in the sync'ed record
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: