Talk:Wireworld: Difference between revisions
Content added Content deleted
(→Performance: new section) |
|||
| Line 15: | Line 15: | ||
:Hi Michael, check your installation as I just executed it on Python 2.6 and 3.1 on Windows. It uses only standard modules, and I would expect it to work, unchanged, on full installations of those versions of Python on Mac and *nix too. --[[User:Paddy3118|Paddy3118]] 07:05, 10 September 2009 (UTC) |
:Hi Michael, check your installation as I just executed it on Python 2.6 and 3.1 on Windows. It uses only standard modules, and I would expect it to work, unchanged, on full installations of those versions of Python on Mac and *nix too. --[[User:Paddy3118|Paddy3118]] 07:05, 10 September 2009 (UTC) |
||
::It does use the namedtuple class factory though, which is new to 2.6 and 3.x. --[[User:Paddy3118|Paddy3118]] 07:14, 10 September 2009 (UTC) |
::It does use the namedtuple class factory though, which is new to 2.6 and 3.x. --[[User:Paddy3118|Paddy3118]] 07:14, 10 September 2009 (UTC) |
||
== Performance == |
|||
Many years ago, I built an implementation of this task in [[Pascal]] (specifically Turbo Pascal) that used a number of tricks to go much faster. The source to that code is now long lost, but IIRC it used a ring-buffer of cell coordinates so that scans through the set of cells only needed to handle those cells with potential to change. This meant that the code could rapidly (15-20fps) process problems up to about the 300k cell mark (i.e., 640x480) which was a size capable of performing interesting calculations. Not bad for a 16MHz 386SX computer with less than 640kB available memory. :-) I do ''not'' remember all the details, but I presume that someone will be able to use this sort of hint/memory to come up with something equally amazing. —[[User:Dkf|Donal Fellows]] 19:45, 10 September 2009 (UTC) |
|||