A New Kind of Science: The NKS Forum (http://forum.wolframscience.com/index.php)
- Pure NKS (http://forum.wolframscience.com/forumdisplay.php?forumid=3)
-- Probleme with impaire totalistioc codes (http://forum.wolframscience.com/showthread.php?threadid=1647)

Probleme with odd code number

Thank you for all your explanation. It's very clear.
So but the new problem is that all rules or codes implaire(445,447,449,951,953,955,957....) can't be generated, despite applying exactly what you explained.
This is the java code of the rule:
calculGlobal=oldCell[i][left]+oldCell[i][right]+oldCell[top][j]+oldCell[bottom][j];
switch (calculGlobal)
{
case 4:{
switch(oldCell[i][j]){
case 1:{cell[i][j]=digitbinary[9];break;}
case 0:{cell[i][j]=digitbinary[8];break;}
}
break;
}
case 3:{
switch(oldCell[i][j]){
case 1:{cell[i][j]=digitbinary[7];break;}
case 0:{cell[i][j]=digitbinary[6];break;}
}
break;
}
case 2:{
switch(oldCell[i][j]){
case 1:{cell[i][j]=digitbinary[5];break;}
case 0:{cell[i][j]=digitbinary[4];break;}
}
break;
}
case 1:{
switch(oldCell[i][j]){
case 1:{cell[i][j]=digitbinary[3];break;}
case 0:{cell[i][j]=digitbinary[2];break;}
}
break;
}
case 0:{
switch(oldCell[i][j]){
case 1:{cell[i][j]=digitbinary[0];break;}
case 0:{cell[i][j]=digitbinary[1];break;}
}
break;
}
}

I don' know if the problem in my code or are here some exceptions.

Thanks in advance.

Well, first thing I notice is that your 1 and 0 digits for the last 2 cases are reversed (when the outer total is 0) - depending on what you put in your "digitbinary" array, to be sure.

I assume your left, right, top and bottom variables just add or subtract one from an index and wrap, and that digitbinary properly contains the 10 binary digits of the rule number, just stored as 0th through 9th positions.

Another pitfall is to be sure you have leading 0s in the binary expansion for rule numbers less than 512, but you've probably already addressed wherever you fill up "digitbinary".

Well, it's clear.
i don't understand just this :
'Another pitfall is to be sure you have leading 0s in the binary expansion for rule numbers less than 512, but you've probably already addressed wherever you fill up "digitbinary".'

because the 'digitbinary' just stores the binary digits in the array of 10 digits, for example with the number 454, it makes that(111000110).

Another thing, rules with pair number code upper than 512 are generated correctely (like 942,1022...), impair can't be generated.
but with pair number code less than 512 are not generated correctely(like 454,446,...), impair can't be generated too.

Thanks in advance.

111000110 isn't 10 digits. It is 9 digits.

0111000110 is 10 digits.

The rule requires 10 possibilities filled out in the correct order.

As long as you correctly have 0s in the array unless there is a 1 in the binary expansion, you would be fine. But e.g. rule number 1 has a rule table of 10 clauses of the form "0000000001", not a rule table of 1 clause of form "1". That is all I meant about that "pitfall". Since you report incorrect behaviors for rule numbers with leading digit 0, this may well be your problem.

You appear to have 9 values where you need 10, perhaps a result of prior confusion about how the rule table was structured, and thinking it had something to do with 9 locations etc.

In any event, digitbinary needs to have 10 distinct 0s or 1s within it, not 9. Whether those are positions 1 through 10, or 0 through 9, depends on how you set up your array and loops and other such procedural-code (java) details you haven't shown me your code for, so I don't know where the problem is precisely. But if you try to fill out a 10 digit rule number with only 9 values, clearly you can misalign them.

In Mathematica, one simply asks for -

IntegerDigits[rulenumber, 2, 10]

And the last item, that 10, ensures that you will be given back a 10 digit list, including any leading zeros for smaller values of rulenumber.

My remaining problem with your questions is I have no idea what you mean by "impair", in "impair can't be generated".

If you mean modifying the rule number by flipping single bits within it, then obviously those just have new rule numbers related to the old by adding or subtracting a single power of 2 from the original rule number, once for each bit flipped. Or you can just operate directly on the digitbinary array of values after first creating it correctly.

Okey;

Sorry for my bad English .
I mean by ‘impair number ’ the odd numbers like(3,5,7,9,11…).
So the odd code numbers can’t be generated
(like 455,457,617,1023…)(it generates full black lattice)
I don’t know what’s the problem.

For the digitbinary, this is the java code:
public void retourBinaire(int decimal)
{
if (digitbinary==null)
{digitbinary=new int[10];}
for(int i=(9);i>=0;i--)
{ int dinominateur=(int)(Math.pow(2, i));
if (dinominateur !=0)
{
binary=(decimal) % dinominateur;
if(binary<decimal)
{digitbinary[i]=1;
decimal=binary;
}
}
}
}

For example, with this numbers ,it generates that :
942(1110101110),
947(1110110011).
(There are 10Digits).

For application of rules this my java code:

for(int i=0;i<Pheight;i++)
{
for(int j=0;j<Pwidth;j++)
{
int left=j-1;if(left<0)left=Pwidth+left;
int right=j+1;if(right>=Pwidth)right=right-Pwidth;
int top=i-1;if(top<0)top=Pheight+top;
int bottom=i+1;if(bottom>=Pheight)bottom=bottom-Pheight;

calculGlobal=oldCell[i][left]+oldCell[i][right]+ oldCell [top][j]+ oldCell [bottom][j];

switch (calculGlobal)
{
case 4:
{
if(oldCell [i][j]==1)cell [i][j]=digitbinary[9];
else cell [i][j]=digitbinary[8];
}break;

case 3:
{
if(oldCell [i][j]==1)cell [i][j]=digitbinary[7];
else cell [i][j]=digitbinary[6];
}break;

case 2:
{
if(oldCell [i][j]==1)cell[i][j]=digitbinary[5];
else cell [i][j]=digitbinary[4];
}break;

case 1:
{
if(oldCell [i][j]==1)cell [i][j]=digitbinary[3];
else cell [i][j]=digitbinary[2];
}break;

case 0:
{
if(oldCell [i][j]==1)cell [i][j]=digitbinary[1];
else cell [i][j]=digitbinary[0];
}break;

}
}
}

So are there any problem with that???

Thanks in advance

OK, I think I get you now.

First point, all of the odd numbers will send a white background to black. This is just a function of the last item in their rule table, which says

if the outer total is 0 and the center cell is 0, center cell becomes 1

Odds correspond to that behavior, of sending uniform white to uniform black.

They will return said backgrounds to all white on the next step if the clause

if the outer total is 4 and the center cell is 1

end in "then the center cell becomes 0". Since that is the clause with the highest value in the enumeration, this is equivalent to saying, the odd rule numbers below 512 will have a background that cycles from white to black and back, on alternate steps.

Indeed, a rule number being below 512 corresponds to the behavior "sends all-black backgrounds to all-white".

But there will still be a pattern wherever you have a starting field that isn't uniform. And if you look at it only on alternate steps (after 2, 4, 6, 8 steps e.g.) you will factor out the background cycle, effectively.

Not sure yet if you are doing anything else wrong, but perhaps you just hadn't expected those behaviors...

I hope this helps.

If there is not any wrong, so why my pictures are not as in the NKS.

For that will be more clearly, i show you what i obtain with code numbers, and you can compaire it with the pictures shown in the page 173.

(My pictures behaviors are obtained in 22 steps time )

and this

This

and this pictures

this piture too

this picture

And that

So, when you compare my picture with this page
www.wolframscience.com/nksonline/page-173?firstview=1
you observe some behaviors are not correct, and the odd numbers are totally incorrect, like the 451.

Sure i have some wrongs. But in my java code there is not any error, as you seen(About binarycode or rule application).

How must i behave toword all this wrong behaviors????


Have you any idea??????!!!!!!!!!

Thank you.

First, for those with Mathematica, a single modern line of code to regenerate those evolutions as they are in the book is -

Grid[Partition[ArrayPlot[
     Last@CellularAutomaton[
     {#,{2, {{0, 2, 0}, {2, 1, 2}, {0, 2, 0}}}, {1, 1}}, 
     {{{1}}, 0}, {22, All, All}], 
     ImageSize -> 90, PlotLabel -> #] &
     /@ Range[450, 498], 7]]

Notice that most of that is just formating for the ArrayPlots and putting them into a nice Grid. The Last@ says only show us the image on the last step; the next line is the rulespec for an outer totalistic 2 color 2D CA with the # slot for the rulenumber, the next bit is the rest of the CellularAutomaton arguments, the initial condition of a single "1" on an infinite sea of "0"s and 22 steps with all X and Y cells that could have been affected by the evolution returned; then the options to ArrayPlot, and the last bit maps this image-maker over the Range of rulenumbers between 450 and 498. The Partition[... , 7] just breaks the 49 evolutions up into rows of 7 for the Grid.

There is a reason this is all much easier to do in Mathematica, rather than re-implementing all of it from before the wheel was invented.

Next I'll look for your specific problems...

So the next question is to see what your digitbinary function is filling in for numbers in the range you are actually plotting, less than 512, and specifically 450 to 498.

Then I assume your boundary conditions are right (they are if your array is consistently indexed from 0 to width-1 and 0 to height-1, not e.g. 1 to width or 1 to height). Then that you are keeping the whole old array and generating the whole new array from it, not replacing as you go into the same array.

Then that the array size you are using for the early steps is sufficient to incorporate the correct alternating outer boundary cells for the odd rule numbers, up to the full size you reach at step 22 (a likely culprit - if you "wrap" a smaller initial condition instead of having a sea of background 0s updated correctly, etc).

Perhaps your problem is that you are evaluating the behavior of the right CA rules on a wrapped-boundary field of fixed width, and that width may be small - but that you are not evaluating its behavior on an infinite white background, correctly.

For evaluating 22 steps using a fixed sized array, you'd need to start from a 45 by 45 field of 0s with a single 1 at position {23,23}. Then you'd see the same evolution as the single 1 on an infinite field of 0s (up to step 22 I mean). One thing to check, at any rate.

Sorry, unfortunately i don't understand.
And what's the relation of width or height for all that(i have a gride (400,400),with initial condition single black at (200,200)).

In my programm, there is a textField where i can put the code of rule as i want .

The pictures 450 to 498 are just an examples of 1024 examples of outer totalistic as you know.

See you this pictures correct? if not, so where is the problem?

And why the code 942,1022 are generated correctlly, but 451,453 not at all for examples???

Really it's verry crazy to be blocked with problems of this kinds?

???????????????????????????????????????????????

Your code has a bug, I just don't know where because I didn't write it.

A large array like that won't give you the wrapping problem so it is something else.

That some of the rule numbers work correctly implies that only one or a few digits of the rule are affected by whatever bug you have. That it occurs for odd rule numbers suggests it is the lowest bit. I pointed out previously that one version of the code you posted had the 0 and 1 cases reversed for the lowest case of the rule, for example. That would certainly do it, if uncorrected.

And yes I can see the pictures you are posting, and I can see that they are wrong. I can also generate the right pictures in one line of Mathematica - so you can be quite certain the problem is somewhere in your own code. This is sort of why we encourage people working on NKS to use Mathematica. Recoding it from scratch is simply asking for your own special bugs and the trouble you are experiencing.

Certainly, Mathematica is fast to worl with it to genetate this pictures in one line because it contains the libraries for that.

But java doesn't not, perhapse one day java will contain a packages and classes specilly for cellular automata and their applications.

about the bugs, i'll try to repeat all again.

Thank you for all.

Problem resolved.

Thank you verry much !!

I'm getting the same pictures for page 173 as M.Abdeldjal. I'm writing in C++ and not using Mathematica.

I've staretd a new thread on this subject.

__________________
The unteleported man