Algorithm writing tips?

the isPrime function is not fully functional (in fact, it's horribly slow), as of right now;
- all primes apart from 2 and 3 can be written as 6k+/-1 (But all numbers written as 6k +/- 1 are not primes!)
[COLOR="DarkOrange"]- even numbers, apart from 2 can be taken out. Since you're not going to include 2 anyway, we may look at every number in binary-form: Every even number has its last bit as 0. Thus:
if ((n & 1) == 1) return false;
This is way faster than returning the modulo of the number. Thing is, you should just skip even numbers anyway. More handy. Faster.[/COLOR]

As a sieve looping-technique for this (pseudo):

Code:

long nextPrime(){
-     sets n to the last number stored in sieve,
    solves the 6k +/- 1 = n equation
    if the equation's 6k + 1, set n equal to n + 4 (which makes n = 6k + 5, or 6k - 1)
    else, check if n + 2 is a prime. If it is, add n into the sieve and return n
    
    loop for n = n, then n + 6{
        if n is a prime, add n into the sieve and return n
        if n + 2 is a prime, add n into the sieve and return n
    }
    [color=Magenta]//oh. Do I have to tell you, if you pineapple the code up, you'll get a free cookie and a never-ending loop? ^,~ Just as a 'lil notice.[/color]
    
}

boolean isPrime(long n){
    // if (n < 2) //Hopefully not needed.
        //return false;
    //if ((n & 1) == 1) //skipp'd. Won't be checked by the nextPrime-function anyway.
        //return false;
    if ((n % 5) == 0)
        return false;
    int square of n = (int) Math.sqrt(n); //Most likely no need to be a long.
    loop for prime in prime-sieve until square of n is lower than prime,
        if ((n % prime) == 0)
            return false;
    return true;
}

That's a pattern that's been eluding me all this time xD Your parenthetical statement seems to be in conflict though...

Having seen that, I'm smacking myself in the head for such a stupid oversight. I've come to the conclusion that I should only check for input % n, where n is a prime number. I'm not familiar with the code (n & 1), but I understand what you mean.

Oyas! That's why I use the debugger (whatever works) and check each section of code that I write in a progressive sequence, and I ask the computer for an appropriate output to make sure that my code works before moving on. Personally my worst enemies are recursions methods.

For comparison purposes.

[COLOR="Black"]ex 3 & 7 & 109 & 673 -> true for 3, 7, 109 and 673 (since all 4 numbers have a true in each of those 4 primes) -> they are a correct set of 4 primes.

Setting it true for itself just kinda indicates which number the array represents, instead of the normal "can concat with this number".


On further thought it might be worth the size hit to make the array of bits include all odd numbers (or all numbers of the form 6*k +- 1), for easier back conversion to what number an index represents. Not sure how often you'd use that function, though.

[COLOR="Blue"]

Code:

                for(int j = 0; j < list.length && isCompatible; j++){
                    String num1 = "" + list[j] + nextPrime;
                    String num2 = "" + nextPrime + list[j];
                    long n1 = Long.parseLong(num1);
                    long n2 = Long.parseLong(num2);
                    if((primesTable.contains(n1) || isPrime(n1)) &&
                    (primesTable.contains(n2) || isPrime(n2))){
                        primesTable.put(n1, true);
                        primesTable.put(n2, true);
                    }

This is the main thing it should hopefully speed up, you don't need to concat the same number multiple times (say "3" is in 50 different 4-tuples, or even 1000 since you said you're working into the 4 and 5 digit numbers, you'd check it with nextPrime once, instead of for each set)[/COLOR]

Code:

get nextPrime
for i in Primes
    compare nextPrime+i, i+nextPrime
    if both prime
        i.cat[nextPrime.index] = true
        nextPrime.cat[i.index] = true
put nextPrime in Primes
nextPrime.cat[nextPrime.index] = true

Code:

check(n-tuple) returns n+1 tuple
for prime j in n-tuple
    [COLOR="Lime"]if(j.cat[nextPrime.index] && nextPrime.cat[j.index])
        do nothing[/COLOR]
    else
        return null
return nextPrime+n-tuple

[/color]

[COLOR="Black"]Hmm, still seems sketchy to me. Especially if you're thinking about using that boolean as an "array representative" since after the calculations are done and over with, there's no way to know whether it was n.cat(n) unless you say if(i == j) in some double looping of indexes, in which case there really isn't much of a point in setting a boolean. Or am I missing something else?

Just to make it clear though, I'm okay without having to think about the "array representative".[/COLOR]

This was one of the original concerns I addressed in the OP, and I haven't really thought up of a reliable way how to prevent duplicate calculations according to my current algorithm. Especially considering that by the time nextPrime reaches ~2500, there are well over 4000 sets of two primes!

Is this allowed in conventional code writing? Silly question, but I've always wondered xD (my guess is yes)