golly-test Mailing List for Golly

Hello all,

I've committed a new Python script: RuleTableToTree.py. It's a port of
RuleTableToTree.cpp but also supports emulation. This means that the
rule table format now supports new neighborhoods: hexagonal,
triangularVonNeumann, triangularMoore, oneDimensional, along with
Margolus and new variants: square4_figure8h, square4_figure8v,
square4_cyclic. The tri and hex emulation approach follows Andrew
Trevorrow's work in this area. The permute symmetry is also now
supported for all neighborhoods, including vonNeumann and Moore.

If you want to try it out, either update to the latest CVS version or
download the script and the 8 new glife files from here:
http://golly.cvs.sourceforge.net/viewvc/golly/golly/src/Scripts/Python/
http://golly.cvs.sourceforge.net/viewvc/golly/golly/src/Scripts/Python/glife/

Attached are some rule tables that demonstrate some of the fun things
we can now do. (The color icons generated for TriBZ won't render
correctly unless you've got Golly 2.2 or later (only available as CVS
source code at the moment).)

I'm keeping the Rule Table Repository updated with these changes, e.g.:
http://code.google.com/p/ruletablerepository/wiki/RoadMap

At the moment, the RuleTable algorithm doesn't support as many options
as this script. I'll work on extending this support to the 1D
neighborhood and the permute symmetry but I'll leave the other
neighborhoods for now at least. This is the area I'm least sure of,
and I wanted to ask for input.

Let's look at TriBZ as an example. We *could*  have Golly load
TriBZ.table and have it appear not as a 5-state rule as in the .table
file but in its emulated form as a 25-state Moore neighborhood rule
using the split-square triangular icons. One 'pro' is that it makes
life easy: an .rle could just say rule:TriBZ and the rule would load,
without having to manually run an emulation script first. One 'con' is
that the difference between the rule as in the .table file and as
rendered by Golly would be confusing for the user - the state values
wouldn't match. Another 'con' is with the .colors/.icons. The
emulation script for the tri neighborhood produces new .icons to have
the result look correct, using any existing TriBZ.colors as a guide.
If we had Golly load TriBZ natively, it would attempt to use *both*
TriBZ.colors *and* TriBZ.icons and they wouldn't match (one would be
for 5 states, other other 25). That's why in the emulation script I
rename the rule as TriBZ_emulated.tree, so that only
TriBZ_emulated.icons loads and not TriBZ.colors.

Similar considerations apply to Margolus emulation: we would want
DLA.colors to correspond to DLA.table but when emulated we need to
load DLA_emulated.colors, not DLA.colors. (We could say
rule:DLA_emulated in the .rle but then the rule wouldn't update when
the user changed DLA.table.)

The only thing that would work is if we had a unified 'RuleLoader'
algorithm (as has been brought up before). For any given rule request
it could work out what to do and take control of what loads. This
might be worth considering because it opens the door to Python-script
rules, as we were discussing. It also makes it possible to have tri
and hex rules render with nice triangles and hexagons - the RuleLoader
would know that you've loaded a triangular neighborhood rule since the
.table would specify that. (The .tree files produced by the emulation
script no longer contain that information.)

Thoughts?

Tim

-- 
Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com

As has been mentioned, I've been running Generations 345/3/6 aka LivingOnTheEdge (LOTE) on 1-3 computers for what is now 18 months, using what has become a three level strategy, with the levels mostly segregated to their own computer.

On my workhorse machine I concentrate on running new viable seeds for 100,000 iterations. For typical cases with none of the occasional strong growth accelerators, this means one run overnight or while I'm out for the day. (The other machines run selected patterns beyond 100,000.) This past week I needed to identify a new batch of viable seeds so that I could extend the 100,000 survey beyond the 250 odd run to date.

The other bit of context is that LOTE is in many ways dominated by two slightly different orthogonal spaceships which are generated at a consistent statistical rate by the admixtures of patches of active chaos scattered within shoals of mostly stable and oscillating forms which together form LOTE's final persistent state.

Over the past 18 months my runs have produced around ten million such ships with a few rare to very rare variants, all moving orthogonally. So I'd long given up thinking about finding glider-like diagonal ships.

But when I got home Saturday evening and checked on a pattern left running at 16:1 there were some isolated pixels in a spot which I expected would indicate a sequence of events that is rare enough to be worth double checking, but what I found was something else entirely:
x = 10, y = 9, rule = 345/3/6
3.C$2.DABC$.BAEADE$2AC3ABCE$.B3AD2AD$4.AE.A.E$3.2ACAE$3.4A$4.3A!

More a wobbler than a glider, this pattern basically moves 3 cells in 6 iterations, before repeating flipped diagonally. This makes its average speed identical to LIfe's iconic glider, but the similarity ends there.

I've uploaded a short animation of the diagonal ship weaving between some common LOTE ships for comparison to:
http://www.thewildca.com/anim/shipsloop.gif




Tony Smith
Complex Systems Analyst
Meme Media
Melbourne, Australia
http://www.meme.com.au/
Giving thanks to the space, time, energy, matter and other lives that have allowed me to tell my lies on this old and damp ball of rock.

Glad to hear it!  I hope he's suitably impressed, too, by the speed.

On Tue, Apr 20, 2010 at 3:55 AM, Tim Hutton <tim...@gm...> wrote:

> On 3 October 2008 00:31, Tom Rokicki <ro...@gm...> wrote:
> > I've added RuleTreeGen programs in Java, Perl, and C++.
>
> Tom, I don't know if you spotted it but Grant Bakker's new loop (on
> the RTR) started from RuleTreeGen.java that he modified with a java
> version of his rule. His java code is in the zip file. So that
> approach of providing multiple languages has been useful already,
> allowing users to program rules in whatever language they're most
> comfortable in.
>
> --
> Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out Golly at http://golly.sf.net/

On 3 October 2008 00:31, Tom Rokicki <ro...@gm...> wrote:
> I've added RuleTreeGen programs in Java, Perl, and C++.

Tom, I don't know if you spotted it but Grant Bakker's new loop (on
the RTR) started from RuleTreeGen.java that he modified with a java
version of his rule. His java code is in the zip file. So that
approach of providing multiple languages has been useful already,
allowing users to program rules in whatever language they're most
comfortable in.

-- 
Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com

Howdy!

I must have goofed this up, and checked in local-win.mk as such, rather than
as local-win.template.  I'll fix this tonight.  In the meantime, just edit
the
local-win.mk for your system, and save a copy so CVS doesn't destroy it.

-tom

On Wed, Apr 14, 2010 at 3:28 AM, Tim Hutton <tim...@gm...> wrote:

> On 6 October 2008 00:34, Andrew Trevorrow <an...@tr...> wrote:
> > Tom:
> >
> >> Clearly we want a short file that is under the builder control but not
> under
> >> CVS control; yet we want a template/example such file in CVS.  Further
> >> we want the makefile to not only include it, but if it's not there, tell
> the
> >> user what to do.  So how about we include
> >>
> >>    local-win.template
> >>
> >> but not
> >>
> >>    local-win.mk
> >>
> >> and the makefile tries to make local-win.mk first thing, and if it
> doesn't
> >> exist it echos "please copy local-win.template to local-win.mk and edit
> >> it for the paths relevant on your system"?
> >
> > Yep, that would be much nicer.
> >
> > Andrew
>
> Did this change ever happen? Just now I tried to build from the
> 2.1-src.tar.gz on Windows and it failed because local-win.mk was
> missing. And there was no local-win.template to refer to.
>
> I see local-win.mk *is* in the CVS repository (but no .template), so
> did it just get left out of the source distribution?
>
> Regards,
>
> Tim
>
> --
> Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out Golly at http://golly.sf.net/

On 6 October 2008 00:34, Andrew Trevorrow <an...@tr...> wrote:
> Tom:
>
>> Clearly we want a short file that is under the builder control but not under
>> CVS control; yet we want a template/example such file in CVS.  Further
>> we want the makefile to not only include it, but if it's not there, tell the
>> user what to do.  So how about we include
>>
>>    local-win.template
>>
>> but not
>>
>>    local-win.mk
>>
>> and the makefile tries to make local-win.mk first thing, and if it doesn't
>> exist it echos "please copy local-win.template to local-win.mk and edit
>> it for the paths relevant on your system"?
>
> Yep, that would be much nicer.
>
> Andrew

Did this change ever happen? Just now I tried to build from the
2.1-src.tar.gz on Windows and it failed because local-win.mk was
missing. And there was no local-win.template to refer to.

I see local-win.mk *is* in the CVS repository (but no .template), so
did it just get left out of the source distribution?

Regards,

Tim

-- 
Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com

Id like to thank Jeronimus for his help.

I'm LF help on the WWEJ3 computer. It is not built yet but fairly detailed
plans exist.


The computer is very parallel and can rewire itself.

It is coded in three parts:
1. component tape, stores each component, a component is able to be created
as many times as is needed wherever required, they can also create other
components, they can store pointers to each other and send each other
information, they are a bit like objects in an object oriented language.
2. operations tape I shall describe in detail later.
3. content tapes, that contain high level instructions and\or data and
aren't required for every operations tape.

I came up with the idea quite some time ago and posted to the list. My idea
was on a per icon bases, so you would have a color that represents the
background color, a color that represents the color specified in the colors
file and any other color would use that exact color. At the time there was
no interest in implementing it. It didn't make it onto my list of ideas on
the RTR.

It's possible Tim beet me to it though.


On 10 April 2010 03:40, Andrew Trevorrow <an...@tr...> wrote:

> Alan:
>
> > I'm not Tim.
>
> Huh?
>
> Andrew
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

Alan:

> I'm not Tim.

Huh?

Andrew

I'm not Tim.


On 10 April 2010 00:42, Tom Rokicki <ro...@gm...> wrote:

> Sweet!
>
>
> On Fri, Apr 9, 2010 at 4:37 PM, Andrew Trevorrow <an...@tr...>wrote:
>
>> Prompted by some ideas from Tim, I've added support for multi-colored
>> icons.
>> If Golly sees a .icons file that uses more than two colors then it will
>> display the icons using the given colors and without doing any
>> substitutions
>> (except for black areas of course -- they are still converted to the color
>> for state 0).
>>
>> Even better, if there is no corresponding .colors file then Golly will use
>> the icon colors to automatically create the colors used in non-icon
>> displays.
>> It does this by averaging the non-black pixels in each icon.  For example,
>> if an icon contains an equal number of red and blue pixels then the
>> non-icon
>> color for that state will be purple.  This minimizes "color shock" when
>> toggling between icon and non-icon display mode.
>>
>> Also, you can optionally set the color of state 0 by adding an extra icon
>> at the right end.  If it's not supplied then Golly will use the current
>> algorithm's default color for state 0 (this is equivalent to having a
>> .colors
>> file that doesn't set the color of state 0).
>>
>> So you can now store both icon and color information in the one file.
>>
>> I've documented this in Help > Formats and added an example of
>> multi-colored
>> icons.  Let me know if any further clarification is needed.
>>
>> Andrew
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Golly-test mailing list
>> Gol...@li...
>> https://lists.sourceforge.net/lists/listinfo/golly-test
>>
>
>
>
> --
> Check out Golly at http://golly.sf.net/
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>
>

Sweet!

On Fri, Apr 9, 2010 at 4:37 PM, Andrew Trevorrow <an...@tr...>wrote:

> Prompted by some ideas from Tim, I've added support for multi-colored
> icons.
> If Golly sees a .icons file that uses more than two colors then it will
> display the icons using the given colors and without doing any
> substitutions
> (except for black areas of course -- they are still converted to the color
> for state 0).
>
> Even better, if there is no corresponding .colors file then Golly will use
> the icon colors to automatically create the colors used in non-icon
> displays.
> It does this by averaging the non-black pixels in each icon.  For example,
> if an icon contains an equal number of red and blue pixels then the
> non-icon
> color for that state will be purple.  This minimizes "color shock" when
> toggling between icon and non-icon display mode.
>
> Also, you can optionally set the color of state 0 by adding an extra icon
> at the right end.  If it's not supplied then Golly will use the current
> algorithm's default color for state 0 (this is equivalent to having a
> .colors
> file that doesn't set the color of state 0).
>
> So you can now store both icon and color information in the one file.
>
> I've documented this in Help > Formats and added an example of
> multi-colored
> icons.  Let me know if any further clarification is needed.
>
> Andrew
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out Golly at http://golly.sf.net/

Prompted by some ideas from Tim, I've added support for multi-colored icons.
If Golly sees a .icons file that uses more than two colors then it will
display the icons using the given colors and without doing any substitutions
(except for black areas of course -- they are still converted to the color
for state 0).

Even better, if there is no corresponding .colors file then Golly will use
the icon colors to automatically create the colors used in non-icon displays.
It does this by averaging the non-black pixels in each icon.  For example,
if an icon contains an equal number of red and blue pixels then the non-icon
color for that state will be purple.  This minimizes "color shock" when
toggling between icon and non-icon display mode.

Also, you can optionally set the color of state 0 by adding an extra icon
at the right end.  If it's not supplied then Golly will use the current
algorithm's default color for state 0 (this is equivalent to having a .colors
file that doesn't set the color of state 0).

So you can now store both icon and color information in the one file.

I've documented this in Help > Formats and added an example of multi-colored
icons.  Let me know if any further clarification is needed.

Andrew

On 3 April 2010 22:38, Dean Hickerson <dea...@ya...> wrote:
> When I create a rule table, I like to define symbolic names for the states so I don't have to remember the numbers.  E.g. for my pressure rule the 4 types of spaceship were defined by:
>
> var N={1}
> var E={2}
> var S={3}
> var W={4}
>
> I used N, E, S, and W for the 9 input states in a transition rule, but I couldn't use them for the output state (unless the output also occurred as in input).  So I still had to remember or look up the numbers for most of the transition rules.
>
> My suggestion is that if a "var" definition has only one state in the set, then it should be allowed as the output of a rule.  This wouldn't affect any existing rule tables, so there's no problem of backward compatibility.

The CVS version of Golly now implements these features:
1) Single-state variables are now permitted as the output of a transition.
2) Variables can now be used inside later variables.
3) Comments can now be written after a variable declaration.

Attached is a version of pressure.table that demonstrates all of these features.

Thanks to Dean for the suggestions!

Tim

-- 
Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com

Why don't those of you who have interest in the work of
Zan Pan just write him an email, and ask questions.

wrb

> -----Original Message-----
> From: Dean Hickerson [mailto:dea...@ya...]
> Sent: Sunday, April 04, 2010 2:41 PM
> To: golly test list
> Subject: Re: [Golly-test] arXiv paper mentioning Golly
> 
> Alan Tennant wrote:
> 
> > Doesn't sub-rule 1 suggest this?
> >
> > D = dead
> > A = alive
> > D, D, D, D, D, D, D, D, D, A
> 
> Yeah, the wording isn't very clear, but examples in the paper (e.g.
> Figure 6) show that that transition doesn't happen.
> 
> Actually rule 1 talks about a cell coming "back to life", which
> suggests to me that dead cells keep track of whether they've been alive
> at some previous time, and only become alive (from rule 1) if they've
> been alive before.  But again Figure 6 rules that out.
> 
> I wonder how much experimentation Zan Pan has actually done.  In Sec.
> 2.4 he writes "To realize some similar features to Golly, such as an
> infinite universe, extremely fast generation and unbounded zooming out
> for astronomical patterns, it is still under development.".  So maybe
> he's only run the rule on a small array, and hasn't realized how
> chaotic it usually is.
> 
> Dean Hickerson
> 
> 
> 
> 
> -----------------------------------------------------------------------
> -------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test

Alan Tennant wrote:

> Doesn't sub-rule 1 suggest this?
>
> D = dead
> A = alive
> D, D, D, D, D, D, D, D, D, A

Yeah, the wording isn't very clear, but examples in the paper (e.g. Figure 6) show that that transition doesn't happen.

Actually rule 1 talks about a cell coming "back to life", which suggests to me that dead cells keep track of whether they've been alive at some previous time, and only become alive (from rule 1) if they've been alive before.  But again Figure 6 rules that out.

I wonder how much experimentation Zan Pan has actually done.  In Sec. 2.4 he writes "To realize some similar features to Golly, such as an infinite universe, extremely fast generation and unbounded zooming out for astronomical patterns, it is still under development.".  So maybe he's only run the rule on a small array, and hasn't realized how chaotic it usually is.

Dean Hickerson


      

ty, will take a look later.

Doesn't sub-rule 1 suggest this?

D = dead
A = alive
D, D, D, D, D, D, D, D, D, A


On 3 April 2010 01:46, Dean Hickerson <dea...@ya...> wrote:

> > I couldn't understand the paper. Is
> > there a specific rule he's talking
> > about? Could someone make a .table/.tree of it?
>
> A rule table file is attached.
>
> Zan Pan's definition of the rule is this:
>
> 1. A dead cell comes back to life when its neighbors are symmetrically
> distributed.
>
> 2. A living cell with symmetrically distributed neighbors survives to the
> next generation.
>
> 3. A living cell with asymmetrically distributed neighbors transitions
> distinctively in two cases: if activating one dead neighbor would get to a
> meta-configuration, it just introduces such a desired change; otherwise, it
> becomes a dead cell.
>
> "Symmetric" means centrally symmetric.  Rule 1 does not apply if all of the
> neighbors of a live cell are dead.  For rule 3, a cell needs to look at
> cells at distance 2 from it, since one of its nearest neighbors may tell it
> to turn on or survive.
>
> In my implementation, each generation in LSDP is simulated as 2 generations
> in Golly.  In one step, a cell may decide to be born or survive, or it may
> decide to tell one of its neighbors to turn on.  In the next step, cells
> check to see what their neighbors are telling them.
>
> Here are a few sample patterns from Zan Pan's article:
>
> #C Glider and lightweight spaceship
> x = 15, y = 6, rule = lsdp
> A8.A$2A6.2A.A$2.A8.A$12.2A$13.A$14.A!
>
> #C Figure 8(h)
> #C Makes isolated particles along a diagonal
> x = 4, y = 4, rule = lsdp
> A$A2$2.2A!
>
> #C Figure 8(i)
> #C Appears to be chaotic
> x = 4, y = 3, rule = lsdp
> A$A$2.2A!
>
> Dean Hickerson
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>
>

Tom:

> A simpler change would be to simply disallow spaces in rules, and
> check this in setrule(), and then we're done.  ...

Hmm, we can certainly add a check for spaces in rules entered via the
Set Rule dialog, but I don't see how checking for spaces in setrule()
would help in Dean's case because when readrle() sees "rule=a b" it
ignores the stuff after the 1st space and calls setrule("a").

If we want to try and detect such rules and report them as an error
I think it would actually require more code changes than fixing
Golly to allow them!

Maybe we just add a note to the table/tree sections in Help > File Formats
that Golly does not support rule names with spaces and leave it at that?
(Along with a suitable warning in the Set Rule dialog if they attempt
to enter a space.)

> Frankly, I'm still not yet comfortable with *filenames* with spaces in them.

Me too -- I never use spaces in any of my file names as it tends to
cause all sorts of annoying problems.  So I'm actually quite happy
if we decide not to support them in Golly.

Andrew

Andrew Trevorrow wrote:

> Basically just bundle up your .table/tree/colors/icons/rle
> files in a .zip file and email it to me or Tim.

Thanks.  I'll work on it in a day or two.

> So in your rle files make sure you use "rule=LSDP" to match
> LSDP.table.

I'm not planning to submit that one; it's too chaotic for my taste.  (But I wonder if there's some simple variant that shares its interesting features without the chaos.)

> Also, we have a convention that rule names are
> capitalized, so we'd prefer to see file names
> like Pressure.table, etc.

OK, I'll change it.

Dean Hickerson


      

Dean:

> ... Somewhere I saw a description of what I should do to add a rule to the
> rule table repository, but I can't find that now.  Can you tell me what to do?

The details are here:

http://code.google.com/p/ruletablerepository/wiki/SubmittingNewRules

Basically just bundle up your .table/tree/colors/icons/rle files in
a .zip file and email it to me or Tim.  Zip format is preferred because
Golly can open a .zip file and automatically install any included
table/tree/colors/icons, and users can then simply click on links
to the rle files.

But before you do that, a couple of reminders:

Rule names need to be case-sensitive so Golly can find the matching
table/tree/colors/icons files on case-sensitive systems like Linux.
So in your rle files make sure you use "rule=LSDP" to match LSDP.table.

Also, we have a convention that rule names are capitalized,
so we'd prefer to see file names like Pressure.table, etc.
This helps to stress that rule names are important.

Hmm, I just noticed we don't mention these points in the submission
guidelines so I'd better add them!

Andrew

A simpler change would be to simply disallow spaces in rules, and
check this in setrule(), and then we're done.  Frankly, I'd prefer
that.  Downside is people won't be able to name rules

   "Tom's fancy rule from Christmas 2011 after a few mugs of eggnog"

or perhaps more realistically

   "Hutton's third attempt at a dishwashing rule"

Frankly, I'm still not yet comfortable with *filenames* with spaces in them.
(They break all my find . | xargs scripts.)

-tom

On Sat, Apr 3, 2010 at 8:26 PM, Andrew Trevorrow <an...@tr...>wrote:

> Tom:
>
> > How important is it that we support rules with spaces in them?
>
> It's not something I'd encourage but if people really want to do that
> then I guess we should allow it.
>
> > The main problem would be parsing rules out of files where the format
> specifies the
> > rule with additional stuff on the line.  I think RLE is one of these,
> where you can
> > specify x, y, and rule all on the same line.
> >
> > We could always assume the rule has to be the last thing and always parse
> the
> > rule until the end of the line.
>
> Yep, looking at the readrle() code I'm pretty sure doing that will fix
> the bug Dean reported.  There may be one or two other places where
> we need to do a similar change.
>
> The only problem will be any existing non-standard rle files that have
> headers like "rule=foo ...".  Do such files exist, and would it matter
> if Golly can no longer load them?  Actually, looking at readrle() more
> closely it seems we do try to handle headers with comma-terminated
> rules like "rule=foo, ...".  So if we want to continue reading those
> files then we'll need to be careful.  Maybe the best approach is:
>
> Parse rule until end of line and call setrule().  If that succeeds
> then we're done.  But if setrule() fails then parse rule until the
> first comma.  If a comma is found then strip it off the end (as we
> do now) and call setrule().  I think that will handle all cases.
>
> > Do we want to permit then things like "B2 S234"?
>
> I don't think qlife/hlife should recognize that as B2/S234, so no
> changes to those algos.  But if someone creates "B2 S234.table" then
> we should handle that.  Again, not something I'd recommend!
>
> Andrew
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out Golly at http://golly.sf.net/

Tom:

> How important is it that we support rules with spaces in them?

It's not something I'd encourage but if people really want to do that
then I guess we should allow it.

> The main problem would be parsing rules out of files where the format specifies the
> rule with additional stuff on the line.  I think RLE is one of these, where you can
> specify x, y, and rule all on the same line.
> 
> We could always assume the rule has to be the last thing and always parse the
> rule until the end of the line.

Yep, looking at the readrle() code I'm pretty sure doing that will fix
the bug Dean reported.  There may be one or two other places where
we need to do a similar change.

The only problem will be any existing non-standard rle files that have
headers like "rule=foo ...".  Do such files exist, and would it matter
if Golly can no longer load them?  Actually, looking at readrle() more
closely it seems we do try to handle headers with comma-terminated
rules like "rule=foo, ...".  So if we want to continue reading those
files then we'll need to be careful.  Maybe the best approach is:

Parse rule until end of line and call setrule().  If that succeeds
then we're done.  But if setrule() fails then parse rule until the
first comma.  If a comma is found then strip it off the end (as we
do now) and call setrule().  I think that will handle all cases.

> Do we want to permit then things like "B2 S234"?

I don't think qlife/hlife should recognize that as B2/S234, so no
changes to those algos.  But if someone creates "B2 S234.table" then
we should handle that.  Again, not something I'd recommend!

Andrew

> Oh, OK, sure thing, not hard to implement.

Thanks.

> I see you instead used comments on the end of
> each transition:
> NS,n,m,e,notWe0,0,notEw0,w,a,1 # N

Yeah, that at least makes them easier to read.

> Nice rule tables, by the way.

Thanks.  Somewhere I saw a description of what I should do to add a rule to the rule table repository, but I can't find that now.  Can you tell me what to do?

> I'm guessing you'd also want to include variables inside
> others:
> var N={1}
> var a={0,N,3}

That would be nice too.

Dean Hickerson


      

> How important is it that we support rules
> with spaces in them?

It's not important to me, as long as Golly is consistent and rejects them in all situations.

It took me quite a while to figure out what was going on.  I had two similar rules with names related like "a" and "a b", and couldn't understand why a pattern behaved differently after an Undo command.

Dean Hickerson


      

Oh, OK, sure thing, not hard to implement.

I see you instead used comments on the end of each transition:
NS,n,m,e,notWe0,0,notEw0,w,a,1 # N

Nice rule tables, by the way.

I'm guessing you'd also want to include variables inside others:
var N={1}
var a={0,N,3}
I'll have to check how hard that would be to enable. Again probably
quite easy. At the moment the file is parsed line by line (no
back-tracking) so there's no danger of recursion:
var a = {0,b,3}
var b = {1,a,4}


On 3 April 2010 22:38, Dean Hickerson <dea...@ya...> wrote:
> When I create a rule table, I like to define symbolic names for the states so I don't have to remember the numbers.  E.g. for my pressure rule the 4 types of spaceship were defined by:
>
> var N={1}
> var E={2}
> var S={3}
> var W={4}
>
> I used N, E, S, and W for the 9 input states in a transition rule, but I couldn't use them for the output state (unless the output also occurred as in input).  So I still had to remember or look up the numbers for most of the transition rules.
>
> My suggestion is that if a "var" definition has only one state in the set, then it should be allowed as the output of a rule.  This wouldn't affect any existing rule tables, so there's no problem of backward compatibility.
>
> Dean Hickerson
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com

How important is it that we support rules with spaces in them?

The main problem would be parsing rules out of files where the format
specifies the
rule with additional stuff on the line.  I think RLE is one of these, where
you can
specify x, y, and rule all on the same line.

We could always assume the rule has to be the last thing and always parse
the
rule until the end of the line.

Do we want to permit then things like "B2 S234"?

On Sat, Apr 3, 2010 at 6:10 PM, Dean Hickerson <dea...@ya...>wrote:

> Golly has some problems with spaces in rule table filenames:  Suppose
> there's a rule table file called "a b.table".  Doing a "Set Rule..." command
> in Golly loads the rule, and you can enter a pattern and run it.  But if you
> try to do an Undo command, you get an error message:
>
>    Golly warning:
>    File could not be loaded by any algorithm
>    (probably due to an unknown rule)."
>
> Also, if you save a pattern to a file and then try to reload it, the same
> error occurs.
>
> If there happens to also be a file named "a.table", then instead of an
> error, Golly just switches to that rule.
>
> Dean Hickerson
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out Golly at http://golly.sf.net/