intelligence is a search for satisfaction

G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

42. :)

And yes, it's cross-posted for a reason.

I've been doing a lot of voter registration lately... which is boring, and
low paying, which causes me to goof off once I'm done working. So, quite a
lot of Galactic Civilizations and not a lot of OCaml progress. It is not a
loss though. I've been keeping a notebook of all the ways GalCiv is boring,
and how I'm going to fix them. This has led me to a profound insight on the
nature of intelligence and searching, not to mention game design.

GalCiv suffers from the "unit pushing problem." As a human being, I spend
the vast majority of my time futzing with whether this unit is 7 squares
away from that enemy unit. In a world of better game AI, it wouldn't be so
hard to compute regions of safety from enemy units. However, then I'd still
have to make a lot of decisions about where to put my units. I envision an
architecture with lotsa set operations on regions. While planning the
architecture, I notice its O(bad) algorithmic behavior, where 'bad' might be
n^4, some higher polynomial, or maybe exponential. All depends on how much
thinking I want to do, and how much I'm willing to limit the scope of my
problems. Maybe I can have my clean architecture if I settle for a board of
only 16x16 squares. Maybe that is what a current PC can handle.

The operations required are all rather rote, basic computations. Just
computing distances from one thing to another. This makes me consider how
much the human brain is simply a more powerful computer, with better analog
sensing equipment, and thus able to leverage physics (light, heat, contact
forces) as part of the computing process. We do lotsa things that aren't
very complicated, it's just gazillions of operations in parallel. Our
brains point out how puny our computers really are, great as they may seem
for problems we're not so good at.

Some day we'll have enough silicon gates to equal a human brain. If Moore's
Law holds we'll have 'em soon. Even if Moore's Law fails at some point in
the future, there is too much industrial interest in the capability. It'll
happen, even if we have to go back to building-sized computers to get things
done. Of course, each and every one of us has working proof of concept that
these computers need not be building-sized. If silicon computing doesn't do
it, biological computing will.

Given the gates, will we have 'intelligence' ? What is 'intelligence' ?

I say, we will. Because 'intelligence' is merely a search for satisfaction.
We have been trying to get satisfaction for millions of years. That's why
we're at where we're at on the food chain. Searching for satisfaction is an
evolutionary advantage; we have been "selected for" our willingness to
search.

Searches take the form of trial and error until better methods are refined.
The first searches weren't rocket science: pick up a stick and bash another
monkey in the head with it. Good way to secure your food, water, and mates.
But refined for generations upon generations, with brains proving more adept
at storage and symbolic manipulations, and you arrive at the ICBM. Of
course there are many other evolutionary stimulants besides warfare. My
point is just that the seemingly complicated modern forms of 'intelligence'
have their bootstrapping root in fairly simple animal behaviors. That's the
magic of evolution: it gets more complicated as life goes on.

We are also not so complicated if you thought about humanity from the
perspective of a 'God'. By 'God' I just mean something much higher up the
evolutionary ladder than we currently are. Notice all the tedious,
repetitive tasks in your life? Notice how humanity's problems are so basic?
Like "Gee we don't feed everybody" even though we grow enough food to do so.
Notice how few people aspire to much of anything? Notice that even the ones
that do, will mostly be erased by history in 100 years or so? Maybe 1000
years if they're particularly profound. Education being the province of the
wealthy, there was less philosophical competition in Aristotle's time. ;-)

Do you see the cockroach in your own life? Where is your 'intelligence' ?
You are simply searching for satisfaction, at the evolutionary level you are
capable of doing so.

If intelligence is about searching for satisfaction, and everyone wants to
be satisfied, why aren't more people smarter? Well, the species doesn't
really need everyone to be smart to propagate. In fact, it's probably
advantageous to the species, or at least to its smarter members, to have a
lot of dumber drones doing their bidding. There's probably an optimum smart
/ dumb ratio under any given economic regime. The current regime is global
capitalism; has the ratio changed that much from provincial monarchs
ordering uneducated peasants around? Probably not by so much, considering
how much of the world is still in poverty while producing goods and services
for industrialized nations. Not trying to grind a political axe here, just
trying to point out what 'intelligence' in our species really is.

At any rate, the 'smartest' among us are just algorithmically compulsive.
We search because we have a biological drive to search. Many searches are
tried. Some 'succeed', meaning they displace paradigms.

Even global capitalism might be displaced someday. What would we do with a
technology that allowed us to easily grow food anywhere? Or get energy
cheaply anywhere? Or manufacture lotsa things cheaply anywhere? Of course,
we could also use these things to edit ourselves out of existence. :)
Natural Selection at least has the benefit of promoting stable designs
rather than wild experiments!

How does this relate to OCaml?

Well, I've said before, I'm not sure that 'programming languages' are really
the answer as far as productivity goes. I've wondered if OCaml is not the
answer, but the thing that will lead me to the answer.

Maybe what we really need are architectures that can handle massive search
spaces. Profoundly stated, all programming language research as we know it
today may be an evolutionary dead end. Why should we tie algorithmic search
to the quaintness of what human beings can type at a keyboard and see on a
2D screen? Why do things with our parochial human notions of 'syntax' or
other linguistic constructs? Just so that human beings can understand and
verify what's going on? Isn't that always going to be a 'cottage industry'
approach to computation?

Ok, so, let's say you're more interested in the here and now than 20 years
hence. I will be thinking about what OCaml does or doesn't do to handle
search problems. Turn Based Strategy games are the particular search
problems I'm working on right now. They're difficult; it'll be interesting
to see how much of the architecture is better done in a higher level
language, and how much as inflexible but massively high performance low
level computation.


Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

In article <2nnk2fF2nut4U1@uni-berlin.de>,
try_vanevery_at_mycompanyname@yahoo.com says...
>
> I say, we will. Because 'intelligence' is merely a search for satisfaction.
> We have been trying to get satisfaction for millions of years. That's why
> we're at where we're at on the food chain. Searching for satisfaction is an
> evolutionary advantage; we have been "selected for" our willingness to
> search.

According to the 'Hitchhiker's Guide to the Galaxy', flying was simply a
matter of throwing yourself at the ground - and missing. Maybe
intelligence is searching for satisfaction, and missing? Okay, enough
philosophy.

> Searches take the form of trial and error until better methods are refined.
> The first searches weren't rocket science: pick up a stick and bash another
> monkey in the head with it. Good way to secure your food, water, and mates.
> But refined for generations upon generations, with brains proving more adept
> at storage and symbolic manipulations, and you arrive at the ICBM.

> Maybe what we really need are architectures that can handle massive search
> spaces. Profoundly stated, all programming language research as we know it
> today may be an evolutionary dead end. Why should we tie algorithmic search
> to the quaintness of what human beings can type at a keyboard and see on a
> 2D screen? Why do things with our parochial human notions of 'syntax' or
> other linguistic constructs? Just so that human beings can understand and
> verify what's going on? Isn't that always going to be a 'cottage industry'
> approach to computation?

Well, our programming techniques are a bit more complicated than that.
One way of looking at programming something complicated like a game is
that is is a case of creating a new language that is appropriate to the
problem. C++ and Ocaml don't have GetShortestPath keywords, but your
map manipulation class (in either) will have a function that does it.
When you use it you are writing in a higher level language that is good
for war games.

Of course, shortest path algorithms [or maybe for this example,
influence map algorithms] are trivial, but once you have them you can
start working on the trickier GetSafeLocation() functions. At that
point you'll be into real AI...

> Ok, so, let's say you're more interested in the here and now than 20 years
> hence. I will be thinking about what OCaml does or doesn't do to handle
> search problems. Turn Based Strategy games are the particular search
> problems I'm working on right now. They're difficult; it'll be interesting
> to see how much of the architecture is better done in a higher level
> language, and how much as inflexible but massively high performance low
> level computation.

Every journey begins with a single step. If you only know roughly where
you are going, you can still start building the basic components of your
new language.

One reason I like C++ is that it gives you a relatively free hand with
the syntax of the languages you build with it!

Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, and Screensavers
Try Chomp! - the new game of logical deduction
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Gerry Quinn wrote:
>
> Of course, shortest path algorithms [or maybe for this example,
> influence map algorithms] are trivial, but once you have them you can
> start working on the trickier GetSafeLocation() functions. At that
> point you'll be into real AI...

Not really. It's just more map crunching. It all depends on what is meant
by 'real' here. I did say we should embrace our inner cockroach. "We're
all just crunching."

> One reason I like C++ is that it gives you a relatively free hand with
> the syntax of the languages you build with it!

I think the OCaml guys would scoff at that. OCaml is proven at creating
domain-specific languages; it is definitely a "language maker's" tool.
That's part of why I've thought it may not be the answer, but it may lead me
to the answer. So I'll keep going with it for awhile, even if something
turns sour.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

<snip>

Sorry to ignore the point of most of your post, but how are you finding
OCaml? I had a brief look at it recently, but not enough to judge it.
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

On Tue, 10 Aug 2004, Peter Ashford wrote:

> In what way does OCaml eclipse that kind of tool creation ability that
> you get from OO languages?
>

I'll answer for Haskell, as I don't use ML much, but some of the points
still stand:

1) There are excellent parsing tools available - in particular, this seems
to be where Spirit got its inspiration from

2) The pattern-matching facilities, which operate on any data type. They
make mildly complicated transformations on trees and graphs an absolute
doddle.

3) Higher-order functions make it easier to build up code at run-time.

4) Techniques such as monads and monad transformers make it even easier -
you can build the semantics of your DSL piece-by-piece.

5) The type systems are more suited to this kind of work.

--
flippa@flippac.org
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

>
>>One reason I like C++ is that it gives you a relatively free hand with
>>the syntax of the languages you build with it!
>
>
> I think the OCaml guys would scoff at that. OCaml is proven at creating
> domain-specific languages; it is definitely a "language maker's" tool.
> That's part of why I've thought it may not be the answer, but it may lead me
> to the answer. So I'll keep going with it for awhile, even if something
> turns sour.
>

That's interesting. I was agreeing with Gerry insofar as any OO
language kind of is building up a language to solve your problem (if you
accept that the objects you build become effectively an extension to the
core language)

In what way does OCaml eclipse that kind of tool creation ability that
you get from OO languages?
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

In article <2npsk1F3gnj8U1@uni-berlin.de>,
try_vanevery_at_mycompanyname@yahoo.com says...
> Gerry Quinn wrote:
> >
> > Of course, shortest path algorithms [or maybe for this example,
> > influence map algorithms] are trivial, but once you have them you can
> > start working on the trickier GetSafeLocation() functions. At that
> > point you'll be into real AI...
>
> Not really. It's just more map crunching. It all depends on what is meant
> by 'real' here. I did say we should embrace our inner cockroach. "We're
> all just crunching."

It's not obvious to me how to define a safe location, or that such a
definition is even possible. What is safe depends on a lot of
circumstances. It's a fuzzy problem, whereas a shortest path analysis
just involves plugging in a standard algorithm.

> > One reason I like C++ is that it gives you a relatively free hand with
> > the syntax of the languages you build with it!
>
> I think the OCaml guys would scoff at that. OCaml is proven at creating
> domain-specific languages; it is definitely a "language maker's" tool.
> That's part of why I've thought it may not be the answer, but it may lead me
> to the answer. So I'll keep going with it for awhile, even if something
> turns sour.

Well, maybe both C++ and Ocaml have this property. My own view is that
designing and programming games is hard, and so long as your language is
powerful, scales well, and is not too awful, it's not the problem. Of
course you think C++ is too awful - I'm happy to stick with it.

- Gerry Quinn
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Gerry Quinn wrote:
> In article <2npsk1F3gnj8U1@uni-berlin.de>,
> try_vanevery_at_mycompanyname@yahoo.com says...
>> Gerry Quinn wrote:
>>>
>>> Of course, shortest path algorithms [or maybe for this example,
>>> influence map algorithms] are trivial, but once you have them you
>>> can start working on the trickier GetSafeLocation() functions. At
>>> that point you'll be into real AI...
>>
>> Not really. It's just more map crunching. It all depends on what
>> is meant by 'real' here. I did say we should embrace our inner
>> cockroach. "We're all just crunching."
>
> It's not obvious to me how to define a safe location, or that such a
> definition is even possible. What is safe depends on a lot of
> circumstances. It's a fuzzy problem, whereas a shortest path analysis
> just involves plugging in a standard algorithm.

Having more constraints, and not being completely solveable, doesn't make it
any more than a number crunching problem. From a goal oriented standpoint,
all that really matters is that it's computed to be "safe enough to win the
game." And if that doesn't pan out in practice, it just has to be "safe
enough to have seemingly put up a good fight." Look at a real war. You
know the joke about Military Intelligence, right?

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Philippa Cowderoy wrote:

>
> 3) Higher-order functions make it easier to build up code at run-time.
>

3.1 - An example: you have this foreach in C#

foreach (<TYPE> <IDENTIFIER> in <COLLECTION>)
{
do something with IDENTIFIER
}

can you write a similar construct named map

map (<TYPE> <IDENTIFIER> in <COLLECTION> to <COLLECTION>)
{
return (something calculated using IDENTIFIER)
}

which collects the return values into a destination collection? No, your
best choice is to use delegates, so that you have to declare a new type for
the delegate, and write a separate function representing the body of the
"map". Compare this with the simplicity of the map operation in OCaml or
Haskell :) And think that you can rewrite map yourself if you like.

V.
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

On Wed, 11 Aug 2004, Peter Ashford wrote:

> Philippa Cowderoy wrote:
> > 3) Higher-order functions make it easier to build up code at run-time.
> >
> > 4) Techniques such as monads and monad transformers make it even easier -
> > you can build the semantics of your DSL piece-by-piece.
>
> Could you give an example?
>

A fun one's the List monad - it represents computations that can return
zero or more results, instead of functions that always return one
result[1]. Makes it easy to write code that maintains a list of
possibilities and filters them down, for example - but more interestingly,
if you only want one result then under lazy evaluation it's equivalent to
backtracking.

Supposing you want to bolt exceptions on top of this, you could apply the
ErrorT monad transformer to it. Alternatively, you could apply a ListT
transformer to the Error monad - these produce two different results.
ErrorT on top of List yields a semantics where an exception appears within
the list of possible results and can be caught appropriately, whereas
ListT on top of Error produces a system where an exception stops the whole
computation.

Prolog, anyone?

> > 5) The type systems are more suited to this kind of work.
> >
>
> I really must get around to playing more with OCaml. I really love LISP
> but that's as far as I've ever gone with Functional Languages (except
> for dabbling briefly with Erlang) and I have to say the 'hard core'
> functional languages freak me out somewhat :eek:) I just don't get them.
> Which is all the more reason to put the effort in a learn one properly :eek:)
>

Any idea what bugs you? It's a bit weird working without state at first,
certainly. Well, until you find all the tricks for providing state when
you really really need it (gee, I'm talking a stateful protocol over the
network here...).

If you decide to learn Haskell, you might find these two links useful:
http://www.haskell.org/tutorial/ (general tutorial)
http://www.nomaware.com/monads/html/ (a decent tutorial on monads)

I'm afraid somebody else'll have to provide equivalent links for OCaml,
I've not really used it any.

[1] Monads effectively provide means to embed a semantics that's
higher-order[2] into Haskell, and Haskell within that semantics. There's
an Identity monad that represents Haskell semantics on top of which you can
apply monad transformers, for example. A more generic framework called
Arrows relaxes the higher-order restriction.

[2] By which I mean that computations can take computations as
parameters and return computations as results - if there's an existing
use of the term that differs from this, could somebody enlighten me
btw? - this has a consequence, which is that any data the monad keeps
(state being the classical example) won't branch any - this allows the IO
monad to represent a function of type world->world without ever trying to
duplicate the world, thus allowing a pure (if not complete) language to
express interaction with the outside world without giving too many
physicists big headaches.

--
flippa@flippac.org
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Philippa Cowderoy wrote:

> On Tue, 10 Aug 2004, Peter Ashford wrote:
>
>
>>In what way does OCaml eclipse that kind of tool creation ability that
>>you get from OO languages?
>>
>
>
> I'll answer for Haskell, as I don't use ML much, but some of the points
> still stand:
>
> 1) There are excellent parsing tools available - in particular, this seems
> to be where Spirit got its inspiration from
>
> 2) The pattern-matching facilities, which operate on any data type. They
> make mildly complicated transformations on trees and graphs an absolute
> doddle.

Okay, that'll explain the language creation benefits that Brandon was
talking about,

> 3) Higher-order functions make it easier to build up code at run-time.
>
> 4) Techniques such as monads and monad transformers make it even easier -
> you can build the semantics of your DSL piece-by-piece.

Could you give an example?

> 5) The type systems are more suited to this kind of work.
>

I really must get around to playing more with OCaml. I really love LISP
but that's as far as I've ever gone with Functional Languages (except
for dabbling briefly with Erlang) and I have to say the 'hard core'
functional languages freak me out somewhat :eek:) I just don't get them.
Which is all the more reason to put the effort in a learn one properly :eek:)
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

>
> Well, maybe both C++ and Ocaml have this property. My own view is that
> designing and programming games is hard, and so long as your language is
> powerful, scales well, and is not too awful, it's not the problem. Of
> course you think C++ is too awful - I'm happy to stick with it.

That's my point of view as well (of course, insert Java for C++ :eek:) )

I don't often find myself with programming issues which I can figure out
how fix but can't really express cleanly with the language I'm using. I
suppose that's part of the reason I'm a little dubious about the
advantages of using a functional language.

<uninformed opinion>
FL's seem to have lots of benefits that seem very high level and obscure
whereas the problems I end up solving usually don't seem to require
especially complex or unusal programming approaches to defeat. The real
work is figuring out what I want to do and a good algorithm to do it
rather than wrangling with the language.
</uninformed opinion>
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

In article <BabSc.11649$N77.518130@news.xtra.co.nz>, me@here.there.com
says...
> >
> > Well, maybe both C++ and Ocaml have this property. My own view is that
> > designing and programming games is hard, and so long as your language is
> > powerful, scales well, and is not too awful, it's not the problem. Of
> > course you think C++ is too awful - I'm happy to stick with it.
>
> That's my point of view as well (of course, insert Java for C++ :eek:) )

Java is way too awful for me - but at least we each have one reasonably
capable language we can stand...

> I don't often find myself with programming issues which I can figure out
> how fix but can't really express cleanly with the language I'm using. I
> suppose that's part of the reason I'm a little dubious about the
> advantages of using a functional language.
>
> <uninformed opinion>
> FL's seem to have lots of benefits that seem very high level and obscure
> whereas the problems I end up solving usually don't seem to require
> especially complex or unusal programming approaches to defeat. The real
> work is figuring out what I want to do and a good algorithm to do it
> rather than wrangling with the language.
> </uninformed opinion>

I agree entirely. My recent game 'Chomp' was quite challenging
algorithmically (in an 'arrays of vectors of lists of vectors' kind of
way) but I don't think expressing the search algorithms was the main
difficulty.

Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, and Screensavers
Try Chomp! - the new game of logical deduction
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

>>I really must get around to playing more with OCaml. I really love LISP
>>but that's as far as I've ever gone with Functional Languages (except
>>for dabbling briefly with Erlang) and I have to say the 'hard core'
>>functional languages freak me out somewhat :eek:) I just don't get them.
>>Which is all the more reason to put the effort in a learn one properly :eek:)
>>
>
>
> Any idea what bugs you? It's a bit weird working without state at first,
> certainly. Well, until you find all the tricks for providing state when
> you really really need it (gee, I'm talking a stateful protocol over the
> network here...).


I think it's just that I've very much settled into the OO way of viewing
the world - solving a problem is creating a bunch of objects which
simulate the problem domain with appropriate behaviours. I think that
philosphically that view point appeals to me since I've always viewed
understanding and theories as a modelling task (you build a model, try
it out and refine it or replace it when it doesn't match obverved /
desired behaviour) FP seems a long way away from that - nothing
neccessarily wrong with FP, more to do with how I think about code.

I guess the other thing is that FP tends to be littered with
mathematical terms and I'm not fond of maths. :eek:)
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

On Wed, 11 Aug 2004, Peter Ashford wrote:

> I think it's just that I've very much settled into the OO way of viewing
> the world - solving a problem is creating a bunch of objects which
> simulate the problem domain with appropriate behaviours. I think that
> philosphically that view point appeals to me since I've always viewed
> understanding and theories as a modelling task (you build a model, try
> it out and refine it or replace it when it doesn't match obverved /
> desired behaviour) FP seems a long way away from that - nothing
> neccessarily wrong with FP, more to do with how I think about code.
>

The approach I take in FP isn't all that different. In a (classed) OO
language, classes form a little language with its own semantics. Monads
also do something similar - I've been trying to figure out the exact
relationship, in some ways monads seem to generalise classes. I suspect
(but may be wrong) that objects are effectively the closure of a monadic
computation.

The main difference this seems to make is that you're encouraged to
rewrite the rules that objects and the like sit on top of - the List monad
being a great example thereof.

--
flippa@flippac.org
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

On Wed, 11 Aug 2004 00:59:24 +0100, Philippa Cowderoy
<flippa@flippac.org> wrote:

>[2] By which I mean that computations can take computations as
>parameters and return computations as results - if there's an existing
>use of the term that differs from this, could somebody enlighten me
>btw? - this has a consequence, which is that any data the monad keeps
>(state being the classical example) won't branch any - this allows the IO
>monad to represent a function of type world->world without ever trying to
>duplicate the world, thus allowing a pure (if not complete) language to
>express interaction with the outside world without giving too many
>physicists big headaches.

Is that like a statically typed version of Scheme's continuations? If
not, what (apart from the static typing) is the difference?

--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Philippa Cowderoy wrote:

> On Wed, 11 Aug 2004, Peter Ashford wrote:
>
>
>>I think it's just that I've very much settled into the OO way of viewing
>>the world - solving a problem is creating a bunch of objects which
>>simulate the problem domain with appropriate behaviours. I think that
>>philosphically that view point appeals to me since I've always viewed
>>understanding and theories as a modelling task (you build a model, try
>>it out and refine it or replace it when it doesn't match obverved /
>>desired behaviour) FP seems a long way away from that - nothing
>>neccessarily wrong with FP, more to do with how I think about code.
>>
>
>
> The approach I take in FP isn't all that different. In a (classed) OO
> language, classes form a little language with its own semantics. Monads
> also do something similar - I've been trying to figure out the exact
> relationship, in some ways monads seem to generalise classes. I suspect
> (but may be wrong) that objects are effectively the closure of a monadic
> computation.
>
> The main difference this seems to make is that you're encouraged to
> rewrite the rules that objects and the like sit on top of - the List monad
> being a great example thereof.
>

I'm clearly going to have to just try this stuff. I read what you're
saying and it may as well be written in Swahili :eek:) I'm just a simple
programmer - I have no idea what Monads and closures are. And you know,
I think it's that element of FP - the language used to describe it and
it's benifits - that keeps dumasses like me from being drawn to giving
FP a go :eek:)

That said, I will give it a go. ;-) I clearly need to broaden my horizons.
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Philippa Cowderoy wrote:
>
>>I think it's just that I've very much settled into the OO way of viewing
>>the world - solving a problem is creating a bunch of objects which
>>simulate the problem domain with appropriate behaviours. I think that
>>philosphically that view point appeals to me since I've always viewed
>>understanding and theories as a modelling task (you build a model, try
>>it out and refine it or replace it when it doesn't match obverved /
>>desired behaviour) FP seems a long way away from that - nothing
>>neccessarily wrong with FP, more to do with how I think about code.
>
> The approach I take in FP isn't all that different. In a (classed) OO
> language, classes form a little language with its own semantics. Monads
> also do something similar - I've been trying to figure out the exact
> relationship, in some ways monads seem to generalise classes. I suspect
> (but may be wrong) that objects are effectively the closure of a monadic
> computation.

Have to disagree here. You don't have to go all the way to monads to
find some analogy for objects in FP. Monads are powerful but pretty
advanced abstractions and I do not see a close relation to the everyday
use of objects.

Above all, objects (or rather, classes) are good old ADTs and ADTs are
plain simple in FPLs. I design in terms of ADTs all the time. Mind you,
objects give you a bit more than basic ADTs, but often this add-on is
not needed, or available by different means. In any case, the way of
thinking about them is not so much different.

Cheers,

- Andreas

--
Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies! -- TB
 
G

Guest

Guest
Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

"Brandon J. Van Every" wrote:

> 42. :)
>
> And yes, it's cross-posted for a reason.
>
> I've been doing a lot of voter registration lately... which is boring, and
> low paying, which causes me to goof off once I'm done working. So, quite a
> lot of Galactic Civilizations and not a lot of OCaml progress. It is not a
> loss though. I've been keeping a notebook of all the ways GalCiv is boring,
> and how I'm going to fix them. This has led me to a profound insight on the
> nature of intelligence and searching, not to mention game design.
>
> GalCiv suffers from the "unit pushing problem." As a human being, I spend
> the vast majority of my time futzing with whether this unit is 7 squares
> away from that enemy unit. In a world of better game AI, it wouldn't be so
> hard to compute regions of safety from enemy units. However, then I'd still
> have to make a lot of decisions about where to put my units. I envision an
> architecture with lotsa set operations on regions. While planning the
> architecture, I notice its O(bad) algorithmic behavior, where 'bad' might be
> n^4, some higher polynomial, or maybe exponential. All depends on how much
> thinking I want to do, and how much I'm willing to limit the scope of my
> problems. Maybe I can have my clean architecture if I settle for a board of
> only 16x16 squares. Maybe that is what a current PC can handle.
> ....
>
> Cheers, www.indiegamedesign.com
> Brandon Van Every Seattle, WA
>
> "The pioneer is the one with the arrows in his back."
> - anonymous entrepreneur



For your NxN (high N) collision/effect radius problem -- shouldnt some kind
of zonal or quadtree type mechanism be a good way to knock down the
number of comparisons required ??? (Zone membership sets to limit comparisons

to current zone set and any overlapped adjacent zones... ie- your 16x16
implemented
as zones would lower required comparisons by a factor of 256...)
I favor a cartesian zone method myself, but also make use of those zones for
rollin/rollout of a world map thats too big to fit in memory and large areas of
the
map that can run in an abstract (low detail) mode (while rolled out).
 
G

Guest

Guest
Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Eternal Vigilance wrote:
>
> For your NxN (high N) collision/effect radius problem -- shouldnt
> some kind of zonal or quadtree type mechanism be a good way to knock
> down the
> number of comparisons required ??? (Zone membership sets to limit
> comparisons
>
> to current zone set and any overlapped adjacent zones... ie- your
> 16x16 implemented
> as zones would lower required comparisons by a factor of 256...)
> I favor a cartesian zone method myself, but also make use of those
> zones for rollin/rollout of a world map thats too big to fit in
> memory and large areas of the
> map that can run in an abstract (low detail) mode (while rolled out).

My study of AI map problems indicates that there's no such thing as
hierarchical compression of pathfinding. If you want correct paths, you
must retain all information. If you are willing to accept loss of
information, you can have a hierarchy. That's actually militarily
realistic - you could justify units screwing up when they get to a new area
that they haven't scouted before and don't have any maps. Still, my current
thinking is I'd like an architecture that can 'globally, flatly' handle a
map of a given size. With that requirement, it might have to be a pretty
small map.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
 
G

Guest

Guest
Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:

> My study of AI map problems indicates that there's no such thing as
> hierarchical compression of pathfinding. If you want correct paths, you

Have you looked at Hierarchical A* by Holte et al?

http://www.csi.uottowa.ca/~holte/Publications/tr-95-18.ps

--
mail1dotstofanetdotdk
 
G

Guest

Guest
Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

"Bjorn Reese" <breese@see.signature> wrote in message
news:pan.2004.08.14.12.46.46.82396@see.signature...
> On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:
>
> > My study of AI map problems indicates that there's no such thing as
> > hierarchical compression of pathfinding. If you want correct paths, you
>
> Have you looked at Hierarchical A* by Holte et al?
>
> http://www.csi.uottowa.ca/~holte/Publications/tr-95-18.ps

That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18.ps
As in OttAwa.
 
G

Guest

Guest
Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Alan Bal jeu wrote:
> "Bjorn Reese" <breese@see.signature> wrote in message
> news:pan.2004.08.14.12.46.46.82396@see.signature...
>> On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:
>>
>>> My study of AI map problems indicates that there's no such thing as
>>> hierarchical compression of pathfinding. If you want correct
>>> paths, you
>>
>> Have you looked at Hierarchical A* by Holte et al?
>>
>> http://www.csi.uottowa.ca/~holte/Publications/tr-95-18.ps
>
> That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18.ps
> As in OttAwa.

I believe I have, but it has been awhile. Does the paper say you can
hierarchize without losing path info?

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
 
G

Guest

Guest
Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Brandon J. Van Every" wrote:

>
> Not sure I understand what is meant by this. Array bounds are checked. I
> don't know about stack growth.
>
> I know all you 'real programmers' just shake your heads at how I approach
> problems, but my strategy right now is just not to write code. Instead, I
> keep reading other people's documentation and code until "something sticks."

Your approach is not that bad. If I had made a similar approach to Clean I
wouldn't have had that many troubles to turn away. Surely, my time was not
wasted and Clean introduced me into the functional programming world.

How did your CommonLisp experience turn out? If I recall it right wasn't there
some flames on comp.lang.lisp?

What, just in case, if you encounter that ML/OCaml will never fullfill what you
plan to produce. Will you distain the languages then? What will you say
nowadays to someone who asks you about your opinion on CommonLisp.

Fensterbrett
 
G

Guest

Guest
Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Siegfried Gonzi" <siegfried.gonzi@kfunigraz.ac.at> wrote in message
news:411F4760.6E557519@kfunigraz.ac.at...
> "Brandon J. Van Every" wrote:
>
>>
>> Not sure I understand what is meant by this. Array bounds are checked.
>> I
>> don't know about stack growth.
>>
>> I know all you 'real programmers' just shake your heads at how I approach
>> problems, but my strategy right now is just not to write code. Instead,
>> I
>> keep reading other people's documentation and code until "something
>> sticks."
>
> Your approach is not that bad. If I had made a similar approach to Clean I
> wouldn't have had that many troubles to turn away. Surely, my time was not
> wasted and Clean introduced me into the functional programming world.
>
> How did your CommonLisp experience turn out? If I recall it right wasn't
> there
> some flames on comp.lang.lisp?
>
> What, just in case, if you encounter that ML/OCaml will never fullfill
> what you
> plan to produce. Will you distain the languages then? What will you say
> nowadays to someone who asks you about your opinion on CommonLisp.
>
hmm...
I am unsure of my oppinion of scheme and common lisp anymore...

imo they were decent, albeit the syntax was in general more of a negative
point than a positive one (yes, cool things were possible, but at the cost
that it is difficult to get people to use it...).
oh well, this may not matter much.

many of the other features can and have been duplicated in others (the
syntax is one of the main distinguishing factors, well, along with "apply
everything" and the macro system, but these are related to the syntax...).

or something...