Factorization of an integer with constraints

[Kirill Streltsov]

Hello!

I want to palce particles with constant displacements in x and y from
each other on a rectangular area. The displacements in x and y must be
different because the area is not square but rectangular.

I want the conditions:

nx*ny = n
nx/ny = x/y

to hold. Here x and y are the width and height and n the total number of
particles.

The first condition can not be fulfilled if n is a prime number. But it
gets worse. I get

nx = (int) sqrt(n * x/y)
ny = (int) n / nx

So even if it were possible to split n in two integers this is not the
way to do it because of the roundofs.

Intuitively I would say that its impossible to find a factorization of a
given number that fulfils a given ratio. But one certainly could find
the closest to that ratio. Does anybody have an idea how to do that?

Here is an idea:

nx = sqrt(n * x/y)
ny = (int) n / nx = n/nx - c

where c � [0,1]

nx * ny = nx * (n/nx - c) = n - c*nx

nx'= nx + c*nx/ny
nx' * ny = n

But I guess nx' does not have to be an integer in that case...I am still
thinking about it but I am not sure whether this is a trivial or a very
hard problem.

[Andreas Ipp]

I'm sure there are many possible ways to arrange a given number of particles in a clever way, but they would all lead to some defects where the placement of the particles is not regular.

The easier problem is to demand a number of particles per unit area, and then place as many particles as you need to fill the whole region.

E.g. you specify 1 particle per unit square, i.e. nx = 1 and ny = 1. If you region is x=50 and y=100 in size, you know you need n=5000 particles.

If x is not divisible by nx, there is some problem at the border, so the pattern will be irregular there. The program could print a warning message such that the user can adjust x and y properly.

Wouldn't nx=ny make most sense physics-wise (if I think of equally distributed charges)?

[Kirill Streltsov]

If x is not divisible by nx, there is some problem at the border, so the pattern will be irregular there. The program could print a warning message such that the user can adjust x and y properly.

If I am allowed to demand restrictions on the x/nx ratio then I can use the equations from my first post directly. I wanted to write the code in the most general way...
 

Wouldn't nx=ny make most sense physics-wise (if I think of equally distributed charges)?

In situations where the user wants to model a uniform distribution, yes. In that case the user would choose a square simulation area and the same number of cells in x and y directions anyway. Well actually the user might choose a rectangular simulation but at least the cells would be square. In that case the code should reduce to nx=ny automatically. At the moment it is done this way. I just wanted to know whether there is a way to do it in a less restricting manner.

Our simulation has a rectangular grid, hence an x and y translation symmetry but no rotational symmetry and in the general case no mirror (as in interchanging x and y) symmetry. Therefore I would like to adjust the code to the present symmetries. Actually this is just the beginning. The loader should load the particles into each cell separately so that the conditions are the same in each cell and not just averaged over all the cells. I think Morse and Nielson 1971 and Gitomer 1971 were considering individual cells also but I havent looked into the papers yet.

I am also a bit hesitant in using printouts to the console somewhere outside of the UI....But in general: we can either demand that the user knows what the app can do and what not and let the app crash if the user mistreats it. Or we check whether the conditions set are meeting the requirement and terminate the program with an error message if they do not. I would prefer the second option but that would require us to include check-functions in the constructors of all the components...or even worse in the methods!

[Andreas Ipp]

Ah, by nx and ny you mean the number of particles in each direction? I was assuming it meant the distance in x or y direction between the particles. Sorry for my confusion.

So, if I call the distance between particles deltax and deltay (such that nx*deltax = x and ny*deltay=y), then I meant to keep deltax = deltay = 1 (or some other number), and calculate nx=x/deltax.

If you want to do it the way you proposed it originally, then nx and ny have to be integers, right?

nx = Math.floor(sqrt(n * x/y)) 
ny = Math.floor(sqrt(n * y/x))

newn = nx * ny.

Then you have integer nx and ny, and newn < n and it works always somehow.

(It may be that deltax=x/nx does not equal deltay=y/ny. In this case one could adjust x or y slightly so that deltax=deltay. Also if nx=0 or ny=0 one should also adjust properly.)

[Kirill Streltsov]

Then you have integer nx and ny, and newn < n and it works always somehow.

Yes, but I have to initialize n particles...otherwise I will have to adjust the number of particles set in the settings class. I might initialize the number of particles that I can fit properly and then put the ones that I can not fit on random positions. This would be a workaround till we find a general way how each component of the simulation can enforce its requirements.
Or we figure out how to find a proper factorization. :-)

(It may be that deltax=x/nx does not equal deltay=y/ny. In this case one could adjust x or y slightly so that deltax=deltay. Also if nx=0 or ny=0 one should also adjust properly.)

Yes I will take care of the =0 cases. Thanks! But I dont see a reason for adjusting deltax=deltay. I do not want them to be equal...I assume that if the user does not choose x=y (by this I mean the dimensions of a single cell now NOT the whole simulation area) then s/he does not want to have deltax=deltay...isnt it a reasonable assumption? If the user does not choose x=y then the simulation will have different properties in x and y directions and the uniformity of charge distribution will be destroyed anyway.

Is there any difference in using Math.floor() compared to casting (int)? Considering that all arguments are positive there shouldnt be a difference right?

[Andreas Ipp]

Yes, but I have to initialize n particles...otherwise I will have to adjust the number of particles set in the settings class. 

It should be possible to remove the (n-newn) particles that you don't need. (In the parallel version particles are frequently removed and added when they move across boundaries, so the methods should exist already.)

 

But I dont see a reason for adjusting deltax=deltay.

Yes, it is not necessary. If a user requires this, they can ensure it by a proper choice of parameters.

 

Is there any difference in using Math.floor() compared to casting (int)? Considering that all arguments are positive there shouldnt be a difference right?

 

You are right, both is fine.