Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #591

Re: The Lisp Curse

Cross-posted to 2 groups.

Show all headers | View raw

On 7/2/2011 11:47 AM, Dmitry A. Kazakov wrote:
> On Sat, 02 Jul 2011 10:03:57 -0700, BGB wrote:
>
>> On 7/2/2011 6:29 AM, Dmitry A. Kazakov wrote:
>
>>> No, graphics can be measured (fps, pixels, color depth). AI lacks
>>> quantitative measurement to know if it is good enough and what need to be
>>> done to have it good. Once you had AI you could measure its quality in
>>> "intelligent decisions" per second. But there is no any in any time.
>>
>> not really, in non-cases, such as the quality of a 3D rendered scene,
>> ... it as well depends on subjective properties.
>
> More fps, higher resolution, etc do it better. (I don't consider cases when
> things rendered are not ones one actually wanted to show)
>

past a certain point there is not much of a point (much past 1920x1080 
and 60fps, with the present technology, there is not much to gain).

for example, plain Quake2 in 1920x1080 and pulling 60 fps will still 
look like Quake2...


then one ends up in the land of adding detailed lighting and shadowing 
(phong lighting and stencil shadows or shadow-mapping) and using pixel 
shaders on damn near everything, which can improve aesthetics at a cost 
to the framerate.

a different direction is to have really big scenes, or to have lots of 
complex detail in the geometry. sadly though, it is "take your pick", 
since one can't have a huge scene with complex geometry and lots of 
pixel-shader effects, as then the framerate is teh-suck...

however, LOD can help, an example of this would be falling back to a 
simpler lighting strategy for geometry past a certain distance (say, 
vertex lighting and no shadows, or use of large low-resolution light-maps).



>>>>> 2. How do you know that any relevant aspect is computable?
>>>>
>>>> this can determined sufficiently well in context, usually by beating at
>>>> the behaviors of something long enough that it is "sufficiently not stupid".
>>>>
>>>> relevant aspects would be, say:
>>>> responds to player;
>>>> shoots at player;
>>>> doesn't run off ledges.
>>>
>>> These are just actions. Intelligence is in how actions are performed, not
>>> in what is done. The same action can be considered intelligent or
>>> unintelligent depending on the context. Relevant here is the choice of an
>>> action, not the action itself.
>>
>> for many of these AIs, the intelligence and behavior are equivalent.
>
> Possibly for all. Behavior is a function of intelligence and the only way
> intelligence can be observed.
>

yes, but behavior need not have much actual intelligence behind it.


>> usually, the logic that drives the behaviors is good old procedural
>> logic. then, the only difference between an AI and a traditional piece
>> of code, is that people usually have an AI as an anthropomorphic entity,
>> rather than sitting off invisibly in the background somewhere.
>
> Yes, any finite number of states can be programmed by a FSM in a
> brute-force way. The problem is that we don't want to go this way. A more
> intelligent approach is as intelligent as it is.
>

but, it is another tradeoff:
brute force works now;
if the number of possible states is small enough to be within what the 
developer can code for, then there is little problem with hard-coding 
the entire set of states.

for example, if an NPC has, say, 10 general states (stand, walk, run, 
dead, melee attack, ranged attack, ...), and a limited number of 
possible state transitions, then little stops someone from hard-coding 
it. then other more subtle variations can be controlled by flags 
(hostile/passive/player-aligned/...).



>>>>> The relation between "weak-AI" and "strong-AI" is unknown. Turing believed
>>>>> them comparable, but the relation can be any. (Somebody said, that two
>>>>> unintelligent persons can produce an intelligent one in just 9 months
>>>>> without any mental efforts. (:-))
>>>>
>>>> well, there is a difference:
>>>> "weak AI" is "good enough for the task at hand" WRT basic behaviors and
>>>> functionality;
>>>> "strong AI" possess some form of actual intelligence, and can build on
>>>> this, potentially eventually exceeding its creators.
>>>
>>> I don't think this is a workable distinction. For example, sweeping floor
>>> with a broom is a task requiring much more general intelligence than
>>> playing chess. (Thirty years ago people believed otherwise) I doubt that an
>>> average office-cleaner exceeds his creators.
>>
>> sweeping a floor need only require a robot that can operate a broom and
>> move around, and probably several layers of bitmaps, and some more
>> procedural logic.
>
> It requires classification of things into valuable stuff vs. rubbish/dirt.
> No procedural logic would help here.
>

a sweeping robot need not have valuation, rather it would just sweep up 
anything on the floor just the same. if a person worried about it, they 
could create a mechanism to separate dust from non-dust and have someone 
manually evaluate the non-dust later (say, robot has a container for any 
pieces of clothing/shoes/wallets/... it runs across)

or, it could use basic computer-vision algorithms to classify common 
object types (say, an object is encountered, and then a long list of 
photos is searched for a matching object, or similar), with rules for 
how to handle them (say, "wallet -> put in drawer", "plastic bottle -> 
send to trash", ... with an edge case, say, "unknown -> put in drawer").


>> but, the point is that "weak-AI" is within the reach of non-adaptive
>> procedural logic (IOW: hard-coded logic), whereas "strong-AI" is not.
>
> Yes, if you define "weak" as "programmable by average programmer", but that
> would make the classification useless.
>

actually, it is more defined as "programmable by people in general".
for example, an "average programmer" also lacks the skills to implement 
a compiler either, but the minority of people who can implement 
compilers make up for the rest.

however, if something can't be reasonably implemented in-general, or 
performance would not be acceptably good, then it has a problem.


>>>>>> what if it is, instead, say:
>>>>>> speech recognition and NLP;
>>>>>> and a contextual menu-like interface.
>>>>>>
>>>>>> for example, the AI may seem chatty and friendly enough, and can answer
>>>>>> questions and similar, but at its core it is a menu-driven system, and
>>>>>> its "mind" is simply collecting various pieces of information and
>>>>>> navigating between various pre-made menu-forms?...
>>>>>
>>>>> The magic is blown away? But whatever intelligence be, if computable, there
>>>>> is no magic in it, just many, many tiny cogwheels! (:-))
>>>>
>>>> no, a menu-driven AI would be notably inferior to a real human, as it
>>>> would not have sentience.
>>>
>>> It is only a question of reflection, i.e. if you include the states of the
>>> menu in the menu. Fake consciousness should not be harder than fake
>>> decision making, the difference is only in what is considered the input,
>>> the outer word or the inner one.
>>
>> this may not be sufficient, and depending on the implementation could be
>> prone to crashing (say, an infinite recursion takes place and leads to a
>> stack overflow).
>
> You can prune the search tree, which many algorithms do anyway. If
> exceptional states were the only problem...
>

fair enough, one can use recursion and infinite-loop protection strategies.


>> the more immediate concern though is that humans lack the mechanisms by
>> which to experience a GPF or stack overflow or buffer overflow.
>
> Human brain is a massively parallel system, if an exception occurs
> somewhere in such a system it stays local (unless you try to keep
> everything synchronized).
>

I think it is more likely that it has no such mechanisms in the first place.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: The Lisp Curse Mentifex <mentifex@myuw.net> - 2011-06-29 15:41 -0700
  Re: The Lisp Curse "Fuschia, President-Elect of the Bright Purplish-Green Council" <fp-eotbp-gc@ibm.com> - 2011-06-29 19:16 -0400
  Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-06-30 09:47 +0200
    Re: The Lisp Curse BGB <cr88192@hotmail.com> - 2011-06-30 02:27 -0700
      Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-06-30 14:28 +0200
        Re: The Lisp Curse BGB <cr88192@hotmail.com> - 2011-06-30 14:06 -0700
          Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-01 23:25 +0200
            Re: The Lisp Curse "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-07-02 00:32 +0200
              Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-02 09:49 +0200
                Re: The Lisp Curse "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-07-02 12:23 +0200
                Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-02 15:30 +0200
                Re: The Lisp Curse "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-07-02 17:06 +0200
                Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-02 18:09 +0200
                Re: The Lisp Curse James Waldby <not@valid.invalid> - 2011-07-02 17:23 +0000
                Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-02 20:50 +0200
                Re: The Lisp Curse luser droog <mijoryx@yahoo.com> - 2011-07-17 22:14 -0700
                Re: The Lisp Curse Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-18 14:10 +0100
                Re: The Lisp Curse Willem <willem@toad.stack.nl> - 2011-07-18 14:13 +0000
                Re: The Lisp Curse Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-18 16:18 +0100
                Re: The Lisp Curse "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-07-02 19:47 +0200
                Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-02 20:56 +0200
                Re: The Lisp Curse "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-07-02 23:01 +0200
                Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-03 10:45 +0200
                Re: The Lisp Curse BGB <cr88192@hotmail.com> - 2011-07-02 10:00 -0700
                Re: The Lisp Curse luser droog <mijoryx@yahoo.com> - 2011-07-17 04:09 -0700
                Re: The Lisp Curse "James" <no@spam.invalid> - 2011-07-03 12:06 -0700
            Re: The Lisp Curse BGB <cr88192@hotmail.com> - 2011-07-01 21:22 -0700
              Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-02 09:47 +0200
                Re: The Lisp Curse BGB <cr88192@hotmail.com> - 2011-07-02 02:10 -0700
                Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-02 15:29 +0200
                Re: The Lisp Curse BGB <cr88192@hotmail.com> - 2011-07-02 10:03 -0700
                Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-02 20:47 +0200
                Re: The Lisp Curse BGB <cr88192@hotmail.com> - 2011-07-02 20:29 -0700
                Re: The Lisp Curse "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-07-03 10:53 +0200
                Re: The Lisp Curse tm <thomas.mertes@gmx.at> - 2011-07-03 23:42 -0700
        Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-03 14:40 +0200

csiph-web