----------------

gives all the prime numbers

P_checkPrime

a!localVariables(
local!testWith:enumerate(tointeger(sqrt(ri!number)))+2,

local!test:remove(local!testWith,local!testWith[length(local!testWith)-1]),

where(a!forEach(
items: local!test,
expression:if(mod(ri!number,fv!item)=0,true,false())
)
)

)

------------------------------------------------------

P_getPrimenumbers

a!forEach(
items: enumerate(100)+3,
expression:
if(length(rule!P_checkPrime(fv!item))>0
,
{},
fv!item
)

)

I would like to tweak the logic as the below code does not exclude 1 which is not a prime number since 1 has less than one factor, A prime number needs to have exactly two factors.

sum(mod(ri!number, enumerate(ri!number) + 1) = 0) <= 2

Do this instead! 

length(
  wherecontains(true, mod(ri!number, enumerate(ri!number) + 1) = 0)
) = 2

OR

sum(mod(ri!number, enumerate(ri!number) + 1) = 0) = 2

Feel free to correct me if I am wrong.

a!localVariables(
local!value: enumerate(ri!number) + 1,
a!forEach(
items: local!value,
expression: if(
length(
wherecontains(
0,
tointeger(mod(fv!item, local!value))
)
) = 2,
fv!item & " is Prime Number",
{}
)
)
)

for optimizing, we don't have to check for all integers (1-n), we only need to check for 1 - sqrt(n) 

sum(mod(ri!n, enumerate(sqrt(ri!n)) + 1) = 0) <= 1

Hi Please check out this solution,

As according to the definition of prime number that it should be divisible by itself creates the logic. Bellow is the code

a!localVariables(
     local!listOfNumbers: enumerate(ri!number),
     a!forEach(
         local!listOfNumbers,
         {
             a!localVariables(
                   local!currentItem: fv!item,
                   if(
                      count(
                      a!forEach(
                            local!listOfNumbers,
                            if(mod(local!currentItem, fv!item) = 0, 1, {})
                            )
                       ) > 2,
                       {},
                       fv!item
                     )
                )
          }

      ) 

)

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: