Pattern viewer for forum threads

[muzik]

On the three toroidal glider examples posted above: crank the speed up to 50, and run each of them. Why is it that the LtL version of the rule seems to run the fastest out of the three (until hitting a corner), despite all three rules being equivalent?

[rowett]

On the three toroidal glider examples posted above: crank the speed up to 50, and run each of them. Why is it that the LtL version of the rule seems to run the fastest out of the three (until hitting a corner), despite all three rules being equivalent?

It's almost certainly because each rule has a different algorithm which have different performance characteristics.

Please run the three tests below twice each. At the end of the first run ignore the result, reset the pattern and press play. Take the result from the second run. The reason for this is during the first run the Javascript optimizer will determine which functions are hot and optimize them during the test which skews the results.

What you then need to look at is the fps and load% display in the top right. If during the run it goes red and below 60fps then that run couldn't make a STEP of 50 and the glider will be slower.

On my development machine the first test runs at 60fps with a load of 20%, the second is red and runs at around 49fps with a load of 100% (anything <60fps is a load of 100%), and the final test is red and runs at around 43fps.

Code: Select all

x = 3, y = 3, rule = R1,C0,M0,S2..3,B3..3,NM:T1000,1000
o$obo$2o!
[[ SHOWTIMING STOP 1950 STEP 50 ]]

Code: Select all

x = 3, y = 3, rule = B3/S23:T1000,1000
o$obo$2o!
[[ SHOWTIMING STOP 1950 STEP 50 ]]

Code: Select all

x = 3, y = 3, rule = 23/3/2:T1000,1000
o$obo$2o!
[[ SHOWTIMING STOP 1950 STEP 50 ]]

[muzik]

For the first one my load goes into the seventies, the second knocks the fps down to the mid-30s, as does the third. Am getting slightly different results on mobile, which doesn't yet have the latest update (it's on build 264): the first send load up to the mid 40s, second has fps in the fifties, and third has load in the late forties. The PC tests were done with minecraft running paused in the background, though, so that might have affected things.

---

Unnecessarily minor nitpicks (which I seem to be getting the hang of now): the HROT algorithm does not seem to understand B0 correctly in hex format, and as such does not throw up the correct error like the second does:

Code: Select all

x = 1, y = 1, rule = r1baazs55
o!

Code: Select all

x = 1, y = 1, rule = R2,C2,S1,3,5,7,9,11,13,15,17,19,21,23,B0,2,4,6,8,10,12,14,16,18,20,22,24
o!

It also doesn't convert strobing and black-white reversal rules with B0 into their non-B0 counterparts, even for range 1:

Code: Select all

x = 1, y = 1, rule = R1,C2,S0,2,4,6,8,B0,2,4,6,8
o!

Code: Select all

x = 1, y = 1, rule = B02468/S02468
o!

[rowett]

The HROT algorithm does not seem to understand B0 correctly in hex format

It's throwing the correct error. It's not valid for hex format HROT rule to have "z" for the births part of the rule. The error message says: "HROT expected 'S' got 'Z'". It had decoded the births part and was expecting survival next but found an illegal z character.

It also doesn't convert strobing and black-white reversal rules with B0 into their non-B0 counterparts, even for range 1

Correct, that's not supported.

[muzik]

The HROT algorithm does not seem to understand B0 correctly in hex format

It's throwing the correct error. It's not valid for hex format HROT rule to have "z" for the births part of the rule. The error message says: "HROT expected 'S' got 'Z'". It had decoded the births part and was expecting survival next but found an illegal z character.

It still seems reasonable (at least to me) to assume that a z in this position would still indicate a zero/B0, so that error message feels off still. (Unless, of course, Adam comes along and proposes something completely contrary to this...)

It also doesn't convert strobing and black-white reversal rules with B0 into their non-B0 counterparts, even for range 1

Correct, that's not supported.

Even for range 1? This seems odd, I thought it would be reasonable to expect that HROT would behave the same with a range of 1, since it's equivalent to normal notation. Also consider the fact that LifeViewer can simulate this pattern fine, despite B0 not being supported by the Generations algorithm for g3 or higher:

Code: Select all

x = 1, y = 1, rule = 1357/02468/2
o!

[muzik]

A bit of an inconsistency I noticed with Generations rulestrings:

Code: Select all

x = 4, y = 3, rule = g3b34s12
A2.A$A2.A$.2A!

Code: Select all

x = 4, y = 3, rule = G3/B34/S12
A2.A$A2.A$.2A!

The one directly above isn't interpreted as a valid rulestring. I suggest that it should be, since the following two are also supported:

Code: Select all

x = 3, y = 3, rule = b3s23
o$obo$2o!

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!

[wildmyron]

Thanks again for your continuing work on this great project.

I have one issue to report which I'm not sure if it's a bug or I'm doing something wrong. I am unable to get LifeViewer to respect the MAXGRIDSIZE 14 setting. viewtopic.php?p=67968#p67968 shows an example pattern with this command (at the end of the RLE). The "show in viewer" link does not show up for this pattern. It also doesn't show when I put the command at the top of the code block. I tried a

Code: Select all

block in place of the code block (in preview) and LifeViewer reported "Pattern too big (maximum size 8192x8192)".

I verified that I am using build 276. Firefox 60.4.0esr (64bit) on Win 10.

[muzik]

When loading a pattern on a toroidal universe, instead of zooming into the pattern as usual, the whole universe is displayed at once. Is this intentional? I find having to scroll into the patterns slightly irritating.

viewtopic.php?f=11&t=2933

[rowett]

I have one issue to report which I'm not sure if it's a bug or I'm doing something wrong. I am unable to get LifeViewer to respect the MAXGRIDSIZE 14 setting.

Yes it's a bug - thanks for reporting! Patterns can grow to > 8192x8192 with this setting they just can't start there. I will fix it for the next release.

[rowett]

When loading a pattern on a toroidal universe, instead of zooming into the pattern as usual, the whole universe is displayed at once. Is this intentional? I find having to scroll into the patterns slightly irritating.

Yes it is intentional. If a bounded grid is defined then LifeViewer autofits to the grid and not the pattern. The assumption is if a bounded grid is defined you probably want to see it. It actually slightly annoys me that Golly doesn't do this.
However that's just my preference. If enough people want it changed or made an option I'm happy to reconsider.

[muzik]

As you said you’d just be limited to 255 state patterns.
Actually it would be helpful to limit to 254 states since there’s already an issue with Bounded Grids which use state 255 but no one has spotted it yet.

Just to be sure: can we be completely% certain that Generations rules with more than the current maximum amount of states won't be supported again in the near future? Currently Catagolue throws up an error when trying to simulate a pattern in such a rule; if these aren’t going to be supported soon then I can suggest to Adam to only make lifeviewer run for Generations-type rules with a low enough state count.

(I can provide a list of every Catagolue-supporter rule family which throws up such an error as well, if you’re interested.)

[rowett]

Just to be sure: can we be completely% certain that Generations rules with more than the current maximum amount of states won't be supported again in the near future?

The current maximum is 256 states. I wasn’t aware that more than that had been supported before.

[muzik]

Just to be sure: can we be completely% certain that Generations rules with more than the current maximum amount of states won't be supported again in the near future?

The current maximum is 256 states. I wasn’t aware that more than that had been supported before.

Aren't 256-state rules going t be removed due to the undisclosed bug and to accommodate the history state for Generations-type rules?

[rowett]

Aren't 256-state rules going t be removed due to the undisclosed bug and to accommodate the history state for Generations-type rules?

No. I’ll fix the "bug" and the history state will only be available if the rule specified has less than 256 states.

[muzik]

Is there a place where rule aliases can be contributed? For reference, here's the list of rules that Catagolue currently lists names for. If there's a place where LifeViewer aliases can also be publicly contributed, then I could add some of these in.

Also, anything new on the realm of isotropic non-totalistic hexagonal rules? Since Catagolue is capable of storing patterns in such rulestrings, but lifeviewer cannot run them, we end up with errors. Of course, LifeViewer does support non-isotropic hexagonal MAP rulestrings, so these do feel like somewhat of a low hanging fruit. The specification can be found here.

[rowett]

Is there a place where rule aliases can be contributed?

Yes this is the right place to contribute. I'll add them at some stage.

Also, anything new on the realm of isotropic non-totalistic hexagonal rules?

It's on the backlog. Don't know when it will get done.

[muzik]

There are some identically-named rules on the list, which could pose problematic. I'd say that Bosco's Rule should refer to the LTL R5 rule, and Bugs the range-1 outer-totalistic rule. I'm not sure as to how the rules named Majority should be handed though, anyone else willing to give suggestions?

[muzik]

There's no way to cancel out of this error in LifeViewer on a mobile device aside from closing it (which can only be done with the one on the top right, which can be difficult) or switching to another lifeviewer:

Code: Select all

x = 10, y = 13, rule = B3/S23
4b2o$3b4o2$2b6o$3b4o2$2b2o2b2o$2obo2bob2o$3bo2bo3$4b2o$4b2o!
[[ THEME 12 ]]

[rowett]

There's no way to cancel out of this error in LifeViewer on a mobile device

True. I’ll probably allow the bottom right menu to show the close button. Thanks for reporting!

[muzik]

Not sure exactly if I know how to reproduce this consistently, but sometimes, embedded thumbnail viewers seem to do a weird blanking thing when using the shrink back to normal option in the menu. Again, tested on an ipad, and i'm not entirely sure how to always get this to happen.

Code: Select all

# [[ THUMBNAIL ]]
x = 3, y = 3, rule = B3/S23:T76,78
o$obo$2o!

Here's an example of it happening: https://cdn.discordapp.com/attachments/ ... image0.png

[rowett]

... sometimes, embedded thumbnail viewers seem to do a weird blanking thing when using the shrink back to normal option in the menu.

Sorry I can't reproduce this. I suspect it's a browser issue on the iPad. Are you using Safari?

[muzik]

Yes.

[muzik]

I noticed that the following two notations for Generations rules aren't currently accepted:

Code: Select all

x = 1, y = 1, rule = B123/S/G3
A!

Code: Select all

x = 1, y = 1, rule = B123/S/C3
A!

I've seen these used occasionally from time to time, and the wiki does acknowledge them as valid notations, so I thought I'd bring this up.

Also, can the "shrink viewer-embedded-in-post" button be moved to the area where the close button in pop-up viewers would be? They serve similar enough functionality and I tend to reach for that area when attempting to "close" embedded viewers, so that might be useful (especially since I don't recall embedded viewers actually having close buttons).

[rowett]

I noticed that the following two notations for Generations rules aren't currently accepted...

Added, thanks.

Also, can the "shrink viewer-embedded-in-post" button be moved to the area where the close button in pop-up viewers would be?

Yes, good idea.

[muzik]

Thank you! (Yes, it has occurred to me that I should probably be doing a bit more thanking than I have been.)

One thing I've noticed is that the circular neighbourhood used by LifeViewer is actually different to the L² neighbourhood shown here.

Can this "Euclidean distance" neighbourhood also be supported (with suffix NL, say)? I can't think of any other programs that actually handle rules using this neighbourhood, so maybe this could be a first. I don't think it's particularly high priority to add support for this, though.

----

Another thing: try clicking on the T: box and reading the rulestrings provided. They don't seem very accurate.

Code: Select all

x = 1, y = 2, rule = B2-a2a/S0
o$o!

Code: Select all

x = 1, y = 2, rule = B2a2-a/S0
o$o!