Gregory Crosswhite writes:
> On Feb 2, 2010, at 7:11 PM, Jon Harrop wrote:
>
>> I doubt programming paradigms live or die according to whether or not they
>> can
>> implement Conway's Game of Life simply and efficiently.
>
> This makes an awesome quote. :-)
You mean Jon actually said somethin
On Tue, Feb 2, 2010 at 7:33 PM, Gregory Crosswhite <
gcr...@phys.washington.edu> wrote:
> On Feb 2, 2010, at 7:11 PM, Jon Harrop wrote:
>
> > I doubt programming paradigms live or die according to whether or not
> they can
> > implement Conway's Game of Life simply and efficiently.
>
> This makes
On Feb 2, 2010, at 7:11 PM, Jon Harrop wrote:
> I doubt programming paradigms live or die according to whether or not they
> can
> implement Conway's Game of Life simply and efficiently.
This makes an awesome quote. :-)
- Greg
___
Haskell-Cafe mail
On Wednesday 03 February 2010 01:08:33 Richard O'Keefe wrote:
> On Feb 3, 2010, at 3:04 PM, Jon Harrop wrote:
> > Fair enough. If you want to model either an infinite board or a very
> > sparse one then a sparse data structure will be asymptotically faster. But
> > they won't be simpler and asympto
On Tuesday 02 February 2010 18:44:25 David Leimbach wrote:
> On Tue, Feb 2, 2010 at 11:54 AM, Jon Harrop wrote:
> > I meant the scalability and speed. An imperative solution should be
> > simpler, more scalable and faster than any purely functional solution.
>
> That's a pretty strange comment. W
On 3 Feb 2010, at 02:04, Jon Harrop wrote:
On Tuesday 02 February 2010 23:54:58 Richard O'Keefe wrote:
One message in this thread has already pointed to a
solution (in C) that in effect uses a bit-packed sparse
representation
to achieve high speed. The point is that that approach takes time
On Tuesday 02 February 2010 23:54:58 Richard O'Keefe wrote:
> I understood the ""simple but not scalable and not particularly fast"
> claim *NOT* as a claim about imperative languages but in context as
> a claim about using two-dimensional arrays of booleans to implement
> Conway's Life.
Fair enou
Thanks for the replies.
I have heard of Hash Life, but I thought I'd try a more naive approach
first, build up some type-classes, then create some more interesting
implementations (although I think I'd struggle with implementing Hash
Life in haskell at this point).
> What is the meaning of fuzzy
I understood the ""simple but not scalable and not particularly fast"
claim *NOT* as a claim about imperative languages but in context as
a claim about using two-dimensional arrays of booleans to implement
Conway's Life. One message in this thread has already pointed to a
solution (in C) that in
On Tue, 2 Feb 2010, ed...@ymonad.com wrote:
> http://dotat.at/prog/life/hslife.hs
Er, yes, I didn't link to that in my earlier message because it's a
half-completed attempt. I think I got to the stage of realising that I
needed to write a monad or a monad transformer to thread the hash cons
state
http://dotat.at/prog/life/hslife.hs
[],
Edgar
On Tue, 02/Feb/2010 at 21:10 +0100, Arne D Halvorsen wrote:
>
> Den 2. feb. 2010 kl. 19.26 skrev Jon Harrop :
>
> >On Tuesday 02 February 2010 16:10:05 Serguey Zefirov wrote:
> >>Actually, your solution with arrays is the most often occured
> >>solu
On Tue, 2 Feb 2010, Serguey Zefirov wrote:
>
> Creation of new Array is (without knowing some subtle details) is
> O(max coordinates difference between live cells). Creation of new Set
> (X,Y) is O(NlogN) (N = number of live objects). Most of the cells in
> Life are empty, so the Set/Map approach i
On Tue, 2 Feb 2010, Arne D Halvorsen wrote:
>
> If I may butt in here: to get a scalable, fast Game of Life, you should look
> into Hashlife (by Gosper?) as exemplified in the open source application
> Golly. It gives an astonishing speedup, and it would be interesting to see it
> expressed in Hask
Den 2. feb. 2010 kl. 19.26 skrev Jon Harrop :
On Tuesday 02 February 2010 16:10:05 Serguey Zefirov wrote:
Actually, your solution with arrays is the most often occured
solution
an imperative programmer will come with. It is simple but not
scalable
and not particularly fast.
What gave you
leimy2k:
>
>
> On Tue, Feb 2, 2010 at 11:54 AM, Jon Harrop wrote:
>
> On Tuesday 02 February 2010 18:23:59 Serguey Zefirov wrote:
> > 2010/2/2 Jon Harrop :
> > > On Tuesday 02 February 2010 16:10:05 Serguey Zefirov wrote:
> > >> Actually, your solution with arrays is the most of
2010/2/2 Jon Harrop :
>> Or, you're asking about scalability and speed?
>
> I meant the scalability and speed. An imperative solution should be simpler,
> more scalable and faster than any purely functional solution.
So, please, provide any and we'll discuss difference between ours.
Mine is here:
On Tue, Feb 2, 2010 at 11:54 AM, Jon Harrop wrote:
> On Tuesday 02 February 2010 18:23:59 Serguey Zefirov wrote:
> > 2010/2/2 Jon Harrop :
> > > On Tuesday 02 February 2010 16:10:05 Serguey Zefirov wrote:
> > >> Actually, your solution with arrays is the most often occured solution
> > >> an impe
On Tuesday 02 February 2010 18:23:59 Serguey Zefirov wrote:
> 2010/2/2 Jon Harrop :
> > On Tuesday 02 February 2010 16:10:05 Serguey Zefirov wrote:
> >> Actually, your solution with arrays is the most often occured solution
> >> an imperative programmer will come with. It is simple but not scalable
2010/2/2 Jon Harrop :
> On Tuesday 02 February 2010 16:10:05 Serguey Zefirov wrote:
>> Actually, your solution with arrays is the most often occured solution
>> an imperative programmer will come with. It is simple but not scalable
>> and not particularly fast.
>
> What gave you that impression?
D
2010/2/2 Lyndon Maydwell :
> I'm avoiding hard-coding bools anywhere as I intend to allow
> fuzzy-representations at some point.
What is the meaning of fuzzy Game of Life? Where can I read about?
Or you're planning to average field over some time interval?
In the latter case you still will be fa
On Tuesday 02 February 2010 16:10:05 Serguey Zefirov wrote:
> Actually, your solution with arrays is the most often occured solution
> an imperative programmer will come with. It is simple but not scalable
> and not particularly fast.
What gave you that impression?
--
Dr Jon Harrop, Flying Frog
I'm avoiding hard-coding bools anywhere as I intend to allow
fuzzy-representations at some point.
On Wed, Feb 3, 2010 at 12:10 AM, Serguey Zefirov wrote:
> 2010/2/2 Lyndon Maydwell :
>> I chose the array mainly for the fast lookup time compared to lists,
>> are you suggesting something like creat
2010/2/2 Lyndon Maydwell :
> I chose the array mainly for the fast lookup time compared to lists,
> are you suggesting something like creating a "Map (X,Y) Health"? I'm
> not currently updating any structures, rather creating the successor
> from scratch. I can see how the map may work very well fo
I chose the array mainly for the fast lookup time compared to lists,
are you suggesting something like creating a "Map (X,Y) Health"? I'm
not currently updating any structures, rather creating the successor
from scratch. I can see how the map may work very well for the sparse
nature of non-early li
2010/2/2 Lyndon Maydwell :
> Hi Cafe.
>
> I've made a basic game of life implementation with Haskell and OpenGL:
> https://github.com/sordina/Life/
>
> I'm intending to improve the performance, and add more advanced
> features, but I thought I'd get some feedback first. Can anyone see a
> way to ma
Hi Cafe.
I've made a basic game of life implementation with Haskell and OpenGL:
https://github.com/sordina/Life/
The basic premise is to generate a random snapshot, then iterate the
successor function on it to create an infinite list of snapshots, then
output them using OpenGL. I haven't really r
26 matches
Mail list logo
