** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **
04-19-2012
, 11:30 PM
can you just quickly explain it please? i understand all the values etc, just not 'how it comes together'
rd0 [] = []
rd0 (x:xs) = x: rd0([c | c <- xs, c /= x])
it works
thankyou! For someone whos wanted to be programming and go into field of computers all my life, i havent got a very good mind for it ha!
Last edited by Burnss; 04-19-2012 at 11:35 PM.
04-20-2012
, 12:28 AM
Quote:
yehh pretty sure i can!
can you just quickly explain it please? i understand all the values etc, just not 'how it comes together'
rd0 [] = []
rd0 (x:xs) = x: rd0 [c | c <- xs, c /= x]
it works thankyou! For someone whos wanted to programming and go into field of computers all my life, i havent got a very good mind for it ha!
can you just quickly explain it please? i understand all the values etc, just not 'how it comes together'
rd0 [] = []
rd0 (x:xs) = x: rd0 [c | c <- xs, c /= x]
it works
thankyou! For someone whos wanted to programming and go into field of computers all my life, i havent got a very good mind for it ha!
Code:
Prelude> [x*2 | x <- [1,2,3,4]] [2,4,6,8] Prelude> [x*2 | x <- [1,2,3,4], x == 4] [8] Prelude> [x*2 | x <- [1,2,3,4], x /= 4] [2,4,6] Prelude>
We have our input list (x:xs) which is split into it's head element (x) and tail elements (xs) so this, "rd0 [c | c <- xs, c /= x]", means call rd0 again with all of the elements that are not the current head element (x).
So x : rd0 [c | c <- xs, c /= x] builds up a new list by taking the head element and the tail elements filtered to remove the head element. Since we reduce the size of the input list on every recursive call to rd0 eventually we get an empty list at which point we're done.
Sorry, this explanation sucks as I have a very tough time articulating how recursive functions works
Here is the exact same thing in Python which is more verbose and maybe easier to understand:
Code:
def rd(x):
print "Input:", x
if len(x) == 0:
return x
else:
head, tail = x[0],x[1:]
return [head]+ rd([c for c in tail if c != head])
print "result : ", rd(list("dgheihhdi"))
#and its output
Input: ['d', 'g', 'h', 'e', 'i', 'h', 'h', 'd', 'i']
Input: ['g', 'h', 'e', 'i', 'h', 'h', 'i']
Input: ['h', 'e', 'i', 'h', 'h', 'i']
Input: ['e', 'i', 'i']
Input: ['i', 'i']
Input: []
result : ['d', 'g', 'h', 'e', 'i']
FWIW I have about 5 hours experience programming Haskell so I am definitely not the person to ask for advice about Haskell
Also it sounds like you're maybe just getting into proramming? Haskell is a very tough introduction to programming imo.
04-20-2012
, 06:04 AM
04-20-2012
, 10:23 AM
a basic game engine is typically going to look like this...
1. draw stuff
2. get player input
3. apply game "rules" (move game pieces, apply physics, etc...)
4. goto 1
This pretty much works whether you're making a chess game or a 60fps console shooter...
Try to keep things simple. Because a game "world" can be such an abstract concept, it can be easy to go overboard with object oriented design.... and before you know it, you're running the main game loop from "inside" a UI widget. Dont even begin to think that something like that is a good idea.
What kind of game are we talking about?
1. draw stuff
2. get player input
3. apply game "rules" (move game pieces, apply physics, etc...)
4. goto 1
This pretty much works whether you're making a chess game or a 60fps console shooter...
Try to keep things simple. Because a game "world" can be such an abstract concept, it can be easy to go overboard with object oriented design.... and before you know it, you're running the main game loop from "inside" a UI widget. Dont even begin to think that something like that is a good idea.
What kind of game are we talking about?
04-20-2012
, 10:33 AM
04-20-2012
, 11:48 AM
04-20-2012
, 12:20 PM
I am not a chess expert so could be wrong
04-20-2012
, 01:33 PM
Thanks Bertie!
04-20-2012
, 01:39 PM
04-20-2012
, 01:48 PM
04-20-2012
, 02:46 PM
04-20-2012
, 02:54 PM
Quote:
a basic game engine is typically going to look like this...
1. draw stuff
2. get player input
3. apply game "rules" (move game pieces, apply physics, etc...)
4. goto 1
This pretty much works whether you're making a chess game or a 60fps console shooter...
Try to keep things simple. Because a game "world" can be such an abstract concept, it can be easy to go overboard with object oriented design.... and before you know it, you're running the main game loop from "inside" a UI widget. Dont even begin to think that something like that is a good idea.
What kind of game are we talking about?
1. draw stuff
2. get player input
3. apply game "rules" (move game pieces, apply physics, etc...)
4. goto 1
This pretty much works whether you're making a chess game or a 60fps console shooter...
Try to keep things simple. Because a game "world" can be such an abstract concept, it can be easy to go overboard with object oriented design.... and before you know it, you're running the main game loop from "inside" a UI widget. Dont even begin to think that something like that is a good idea.
What kind of game are we talking about?