Retesting the words like that does find some: REPAPER/5305958597, DUD/2551, DID/2239, LEMEL/5105267, PEEWEEP/4683479543.

With this hackish code to interpret the text as base 26, rebase that to base10, test primality, I can't test the sentences (I think it might be overflowing on the higher value words, even). I think it's not so fun if the base 10 numbers are not palindromic.

Thanks for trying! I was thinking of creating a set of digits for base 26 using emoji or other Unicode characters. Then the numbers would at least look like palindromes. But I don't know how interesting palindromes in an ad hoc character set would be.

My view on that is that DEIFIED is seven symbols, and I was treating those as the 'Unicode' set of digits for base 26. Swapping them out for different symbols would only change the presentation, e.g. adding a +600 offset in Unicode codepoints to each character gives ʜʝʡʞʡʝʜ but ... the same thing just in a different presentation, so not a very useful transform.

Treating the word as a base 26 number means that if the word is palindromic, the number is too since they're the same thing, so that's a single test, and primality is a second test. In the original idea with a=1, b=2, if the word is a palindrome in letters, the number form might not be (zz -> 2525), so that's two different palindrome tests and a primality test which "deified" passes. (Incidentally: if the digits don't need to being a palindrome, then: "Live not on evil, Madam, live not on evil" is prime).

This has been a mishmash of PowerShell which has convenient string/char code handling, SWI Prolog which has implicit bignums and a builtin fast probabalistic prime test with bignum support in "crypto_is_prime/2"; Dyalog APL which has excellent base conversion: 26⊥⎕A⍳'WORD'. Each language doesn't have the other things: C#/PowerShell/APL/Python have no builtin fast bignum-supporting prime test, Prolog has awkward or tedious file/string handling, APL has no bignums or prime test.