part calculation algorithm for jminer

I could need some help, what would be a good algorithm for the following problem:
 i have to split a number (staggersize) in equal parts.
 the size of a single part should be as close as possible to a given value (chunkPartNonces).
 i need the number of parts
simple example:
what number of parts would be perfect for 168 if single part should be close to 10.currently i do the following
168/10 leads to floating point? than add 1
168/11 leads to floating point? than add 1
and so on ... until it not leads to floating point.
168/12 does not lead to floating point! number of parts = 12you can imagine, thats far from perfect

@luxe far from perfect but should work!
Personally i would do the same.
I'll think something that could be a bit more elegant

@ccminer yep i want it more elegant
a real live case i had ... 7629448 in parts of 320000 ... what leads to 953681 parts of 8

@luxe floor( staggersize / chunkpartnonce) would give you a rounded down number, so actual number of actions would be floor( staggersize / chunkpartnonce) + partial chunkpartnonce read

@haitch thanks, but i need equal parts ... thats the challenge
(the reader code depends on equal parts, and i do not want to touch it)

@luxe stealing some pseudo code from StackOverflow:
You don't need to calculate all factors, but you can go in both directions from the number to find its closest number which is the factor of given number
Pseduo code will be:
n= given number(dividend);
x= second number( whose closest number is required)
i=0;
if(n%x==0) print x;
else
while(true){
if(n%(xi)==0){
print xi
break
}
else if(n%(x+i)==0){
print x+i;
break
}
else i=i+1
}

@haitch thanks again, yes thats a improvement, calculate in both directions and take the best/first hit from both. I posted the problem here, cause maybe is a math genius around ... i can not belive there is no algoritm solution/formular except from testing ...

@luxe yeah I was thinking that both direction would have improved the speed of the script
but still I think I get what you want! ELENGANT

@luxe If the plotters were modified to always convert the stagger to a power of two, then the # of parts would be trivial  the power of two number equal to or greater than the chunkpartnonce  but optimized plots would break that. It's feasible that the the staggersize could be prime, so the only valid values are 1 and stagger.
If chunkpartnonce can be highly variable, then: X = floor ( sqrt (staggersize)); while staggersize mod X != 0, dec(x)

@haitch staggersize is always a multiple of 8 (should be)
i will need some time to understand that formular, thanks.

@luxe the formula will find the two highest factors of staggersize.Sqrt(staggersize) will give the highest possible factors, but most likely noninteger, floor makes it integer, then the decrement loop takes that integer down until it's a factor of Staggersize. If staggersize mod X = 0 then X is a factor and Staggersize div X is the other factor.
Lets me think if it can be optimized if staggersize is always a multiple of 8

@haitch ok i will try to implement/test that

@luxe Given staggersize being a multiple of 8, then this should work:
X = (sqrt(staggersize / div * 8 // gives you the largest multiple of 8 possible factor < sqrt(Staggersize / 8);
If X != 0 then while ((Staggersize div != 0) & (X > 0) do dec(X,8);
If X = 0 then X = 8;// When we exit the loop X will be a multiple of 8 factor of Staggersize, or 8

@haitch ahh you are too fast for me i just implemented your previous suggestion:
int highestFactor = (int) Math.floor(Math.sqrt(staggeramt)); while(staggeramt % highestFactor != 0) { highestFactor; } System.out.println(highestFactor);
And on my real life example it leads to 8
But it is surely better than always take 8 by default, thanks.I will also check your improvement ... but first i want to make something to eat

@luxe when Brain digs into a problem it moves fast sometimes .....
Let me know how the improved version goes  haven't tested it but it should be 8x faster.