Re: new here, my lang project...

From: cr88192 (cr88192_at_NOSPAM.hotmail.com)
Date: 01/19/05 

Date: Wed, 19 Jan 2005 04:25:28 GMT

"H. S. Lahman" <h.lahman@verizon.net> wrote in message
news:QOcHd.6071$Vx2.785@trndny01...
> Responding to Cr88192...
>
>> I guess it is ok, win98 only crashed occasionally. windows nt4, 2k, and
>> xp are a lot more stable, so I generally had preference for them over 98
>> (even though for other reasons I still habitually use fat32 for many
>> things).
>
> Win98 still had code in it that was left over from MS-DOS, much of it for
> game back compatibility. (Note that older games simply won't run on NT,
> 2K, and XP.) WinNT was the first MS OS that was a new, ground-up design
> and construction (new for MS; the chief architect was one of the
> architects of DEC's VMS).
>
yes.

>> but yes, the lower the level of the bug, the less tolerated it is.
>> a bug in the os or runtimes is not as well, tolerated as, say, an app
>> bug.
>>
>> the os crashes on you, it is a bit of a hassle.
>> an app crashes on you, it is a slight annoyance, one has to start it
>> again and resume what they were doing (or at least assuming they are like
>> me, saving continuously).
>>
>> of course, in cases where there is an os crash, it is rather annoying
>> when the end of a file one was working on has been trauncated or turned
>> to garbage...
>
> I agree. For some reason the industry still categorizes OSes as
> commercial software when it really should be regarded as mission-critical.
> There is something wrong with the picture where one tests the hell out of
> a critical application and then executes it in the field on a commercial
> OS.
>
it is a mystery isn't it.

for whatever reason people seem to imagine that the os is totally stable, oh
well.

>>>void* is fragile because you can't let the compiler/interpreter do type
>>>checking. So when the Skyscraper shows up in the midst of one's Pristine
>>>Landscape, one has no clue how it got there. The problem isn't the
>>>specific mechanism so much as it is diagnosis and recovery. Or, better
>>>yet, seeing the error as you write the code because you know you won't be
>>>able to get it past the compiler. So you end up going to the effort of
>>>"writing around" the strong typing but then the defect never gets into
>>>the software in the first place.
>>>
>>
>> well, it is pretty fragile, so that is why there is a lot of runtime
>> infrastructure and controlled segfaults set up for the case when things
>> go wrong with these pointers...
>>
>> things going wrong here is pretty well expected, but imo it is still
>> safer and more convinient than overloading long, and relying, eg, on the
>> nature of the pointers generated by the os or other parts of the code.
>>
>> one also doesn't have to worry as much about the case where
>> sizeof(long)!=sizeof(void *)...
>
> One way to at least isolate such problems to one location is to #define
> critical definitions like pointer size in a common header file, along with
> TRUE, NULL, and all the rest of that nuts & bolts stuff. That will at
> least provide consistency throughout the code.
>
> But I would still look for a way to take advantage of the type checking
> that C does offer by avoiding void*.
>

well, that is only really possible in the staticly typed case.
I use more normal types when possible (though many of my structures are
dynamic type aware, namely, I can cast them to 'void *' and pass them along
through the dynamic type system).

>>>My point was at a higher level of abstraction, though. I am arguing that
>>>in an OO context one thinks about objects and relationships differently.
>>>Object associations are binary so each relationship would be implemented
>>>independently and one would provide code for collaborations that would
>>>navigate the relationship path (i.e., daisy-chaining from one connected
>>>array to the next). So by the time such a model got to OOP there would
>>>be no temptation to even think about a single array of pointer arrays to
>>>handle things.
>>>
>>
>> ok.
>>
>> still in less-than-oo c-land here.
>
> However, there is nothing to prevent you from /designing/ the application
> in an OOA/D fashion. Translation engines that do full code generation
> from OOA models routinely target straight C as the implementation language
> for performance reasons. (When you don't have to maintain the code, it
> doesn't matter what language it is.) So there is nothing written in stone
> that says an OO application has to be implemented in an OOPL; the OOness
> is a product of OOA/D, not OOP.
>
ok.

>>>>>Game graphics is a tough place to go. It is usually leading edge
>>>>>technology and nowadays one needs an advanced degree in math to even
>>>>>understand modern techniques.
>>>>>
>>>>
>>>>err, I don't have a math degree, but it is not that hard really.
>>>
>>>At the Wolfenstein level (Sprites moving across panning backdrops) that
>>>might be true. But if you don't have a problem with the modern 3D tensor
>>>analysis stuff then you are a better man that I am, Gunga Din.
>>>
>>
>> well, I know about tensors, but I am not really fammiliar with the term
>> "tensor analysis".
>
> I was thinking specifically of the N-dimensional (N > 3) visualization
> necessary to "see" how the more exotic optimization algorithms work. Just
> the thread management when playing off game time vs. refresh time vs.
> computation time to provide smooth transitions tends to get pretty
> esoteric. For example, the speed at which the shadow moves on the ground
> depends on the direction, speed, and angle of descent the plane is flying,
> so one may need to dynamically allocate the time-slice share that the
> shadow algorithm has. One needs to resolve that stuff for multiple game
> artifacts simultaneously rather than serially and such mathematical models
> are nontrivial.
>
err, maybe.

for the N>3 case, I don't know, I can just somehow imagine these cases
without too much difficulty I guess.

err, usually one doesn't worry about the rate shadows move or other such
details. more commonly one would use the position of the sun and distance
and directly project the plane on the ground.

I have seen plenty of different approaches to shadows before though.

typically games are also only single threaded, and work by going in a
costant loop doing everything.

>>
>> mostly it is crap like lots of matrix and vector math, and to a lesser
>> extent quaternions and such.
>>
>> physics mostly consists of a lot of checking, and some math, and a lot
>> more checking, and more math, for the sake of detecting and handling
>> interactions between objects.
>>
>> I, though, am still left with a lot of things I don't fully understand,
>> eg:
>> I don't fully understand quaternion math;
>> even matrices can be anomolous sometimes, eg, why doing something one way
>> works as expected, but doing it the other does not work;
>> cases where one wonders if the "which side of the plane of the front";
>
> [Apocryphal anecdote. Years ago in my Operations Research Era I decided
> to solve an optimization problem using the Ford-Fulkerson Out Of Kilter
> algorithm. I had a book with all the equations and sequencing mapped out
> in cookbook fashion, so I thought it would be a snap. It didn't work even
> though I was positive I can transcribed the equations correctly. Alas,
> the Out Of Kilter algorithm is not at all intuitive (in fact, I am dazzled
> that Ford & Fulkerson ever discovered it). I spent a couple of weeks
> trying to debug it and even got so desperate that I rewrote it from
> scratch. Eventually I read another description of the algorithm
> (unfortunately rather qualitative) and I finally got suspicious that the
> algorithm was wrong and made a couple of changes. It worked. It turns out
> the book had a typo in it where a '+' should have been a '-'! Moral:
> Murphy's Law requires that one will get screwed if one doesn't fully
> understand what is going on.]
>
ok.

usually, in my case it is more lots of misc crap, like weirdness in
transforming between spaces (eg: translate by one matrix to get in a local
space, and by another composite matrix to get back to world).

one can do the products horizontally or vertically, usually one for one
transform and the other for the other, and adding or subtracting some
components representing the origin.

now, one would think that going horizontally and subtracting for the first,
and vertically and adding for the second would work.
no, one has to go vertically and subtract, then horizontally and add.

and the other issue is getting confused about the front side of planes, and
often having to flip normals because of them comming up "backwards" (mind
you, I know how cross product works, this is more subtle).

I think the issue is deciding whether the outward facing is positive or
negative. it gets more complex when csg operations get involved.

I end up with a system where the positive direction is inward, and flipping
it would likely require altering a lot of stuff.
the net cost, however, is sometimes things come up counter-intuitive, and a
lot of times I end up having to invert the normals when going to other
subsystems...

>> ...
>>
>> dunno about "gunga din" though.
>
> Ah, a commentary on the sorry state of education for the younger
> generation. <sigh>
>
ok.

> A classic line from a poem, "Gunga Din", by Rudyard Kipling. Gunga Din
> was a "lowly" water boy in India who ended up saving an English officer's
> ass through an extraordinary demonstration of courage and duty. The line
> was the officer's response, replete with lots of social commentary.
>
ok.

>>>>eg: an "order-0" association could probably only really associate being
>>>>hungry with eating. this could be helpful, eg, if it is atop a scripted
>>>>ai that knows to go twards any food and eat it if it is getting an eat
>>>>impulse. an "order-1" association would be needed to associate, eg, the
>>>>presence of food, being hungry, and the impulse of eating, or choosing
>>>>what to eat, ...
>>>
>>>...this seems to me to be several different interactions are involved.
>>>
>>>hungry -> look for food.
>>>food sighted -> chase
>>>food caught -> eat
>>>satiated -> sleep
>>>
>>>The behavior responsibilities for looking for food, chasing it, and
>>>eating it are likely to be largely unrelated (i.e., they are
>>>self-contained and logically indivisible). So each activity is triggered
>>>by a very specific change to the state of the application that maps to a
>>>postcondition of some other <self-contained and logically indivisible>
>>>activity. So events like 'hungry' reflect a very specific result of some
>>>particular activity.
>>>
>>
>> a lot of associative power would probably be needed for something like
>> that...
>>
>> this would not be a system of accurate or developed thought, my
>> expectation (as an upper limit) would be something roughly emulating
>> basic behaviors (maybe even if not very reliably or only approximately).
>>
>> humans seem to have an almost arbitrary-order associative ability afaik.
>
> Actually, this sort of thing tends to Just Work when one uses state
> machines to describe behavior (particularly object state machines for
> individual objects). That's because one can apply design-by-contract
> (DbC) to rigorously sort out where the events should go.
>
> Before any behavior (state action), X, can execute, some precondition in
> the overall algorithm must prevail. That may be as simple as having
> behavior Y execute first in an algorithmic sequence. Or it can be more
> complicated and include conditions on certain data being updated in a
> timely fashion. However, the precondition is usually fairly easy to
> identify.
>
> That precondition will always be the postcondition of executing some other
> behavior. That's because only behaviors can change the state of the
> application, so some behavior must execute to produce the precondition
> state for executing X. Therefore one has a rigorous technique for
> determining who cares about announcement events. One takes a given
> behavior, X, and determines the precondition. One finds the behavior, Y,
> whose postcondition matches that precondition. Then it is Y's
> announcement event that X cares about, so one sends the event to X when Y
> executes.
>
> The point here is that the sender/receiver associations aren't arbitrary.
> They are rigorously defined by the overall problem solution. [Of course
> there is a catch. This only works if behaviors are logically indivisible
> and self-contained. It is also very convenient if behaviors access the
> data that they need directly rather than having it passed to them. The
> reason is that one just needs to look at the behavior to know what state
> variables must be properly updated as part of its precondition. That
> allows one to daisy-chain behaviors to ensure the data is good when the
> behavior generating the event is good. (One can ensure data integrity for
> data that is passed around, but it becomes a major pain in a concurrent
> implementation.)]
>
err, but I don't get how this really applies to human thought processes and
learning though (or emulating them).

>>>In this case it seems like BigCat is the single object doing everything;
>>>it looks for food, it chases food, it eats food, and it sleeps. But in
>>>practice the actual activities are likely to be delegated to other
>>>objects or even subsystems. Thus the "behavior" of looking for food may
>>>really just involve sending a message to somebody who knows where all the
>>>critters are relative to the local map. They do the actual looking and
>>>respond with a "food sighted" message. Maybe the chase behavior makes an
>>>evaluation: if the candidate food is not acceptable, it sends the "keep
>>>looking" message back; otherwise it sends a message to whoever manages
>>>chases over the terrain announcing that this Big Cat is chasing that
>>>Food. And so on...
>>>
>>
>>
>> well, the problem is that the ai is not all that well structured.
>
> I suspect there may be another problem. (More precisely, there is a
> special form of being unstructured.) Ideally the game elements should do
> their thing independently of whether they are player controlled or AI
> controlled. That is, the AI should be just as externalized as the player.
> The player communicates with the game via a UI, which is usually isolated
> in its own subsystem or layer. The same thing should apply to the AI; it
> should be encapsulated in its own subsystem or layer. In addition, the AI
> should issue exactly the same messages that the UI does to control the
> game artifacts. [The AI, though, needs to do a lot more accessing of data
> for the state of the game than the player, though, because it doesn't have
> a "free" display. So it may need a different interface than the UI for
> that sort of <synchronous> data access. But that is a one-way,
> synchronous data access.]
>
> IOW, the AI should be an application unto itself that encapsulates all the
> smarts that the player provides and it should be completely substitutable
> with the player UI for controlling any given game artifact. I'll bet that
> isn't the case.
>
dunno.

>> largely it just that different aspects of state generate messages, which
>> can trigger actions, ...
>> what actions are triggered by what events has to be "learned", ...
>>
>> of course, divulging from just coding up what is supposed to happen is
>> itself dubious, but if the algo is sound, and it allows sufficiently
>> complex associations, then it should be possible to learn basic
>> behaviors, possibly near that of what can currently be done with
>> hard-coded ai's (possibly, though, at the cost of a lot more processing).
>>
>> an interesting test could be combining something like this with something
>> like genetic algorithms to try to come up with a fairly good model of the
>> ai (eg: you have a number of ai's competing with each other and possibly
>> humans). those that do best live on, and the rest are replaced by
>> combinations of those that did best, ...
>>
>> assuming a sufficiently good model, this may eventually result in
>> something that could compete effectively.
>>
>> maybe, maybe not.
>>
>> there are so many things that were not explained, or at least I haven't
>> got to them yet.
>>
>> something else like this should sensibly exist, but I don't know.
>> of course, the whole idea could be worth nothing as well...
>
> Carrying the point above further, I would expect the subsystem that
> encapsulates AI strategy to be a unique problem space that is exclusively
> devoted to emulating high level human thought. That is a daunting
> undertaking and I would expect the AI to have a complex scope. Thus I
> would actually expect it to be composed of multiple subsystems, each
> devoted to a particular aspect of that emulation (e.g., strategic vs.
> tactical algorithms; economic vs. military goals; etc.).
>
this is a conventional ai, where the ai is coded to do something or think
some way.
I am talking about exhibiting abstract learning behavior.

in the case of a learning ai, it is not as easy to divide.

> If one partitions like that, then one gets the advantages of
> divide-and-conquer problem decomposition. Since each subject matter is
> tailored to specific problems, it becomes easier to recognize invariants.
> That, in turn, makes it easier to pick one spots for where specific
> techniques (e.g., genetic algorithms) may be appropriate. IOW, separating
> the concerns makes it easier to see the specific trees in the <local>
> forest.
>
ok.

>> another idle thought is that something like this may also be sensible for
>> language processing, maybe if not to get the meaning, but possibly a
>> behaviorally relevant "gist" impulse.
>> just to me language seems organized such that more related things are
>> closer together, and less related ones are further.
>> of course, average word associative weights is something I am unsure how
>> it would really be useful, or portray any meaningful info.
>>
>> it is concievably possibly though that word associative weights could be
>> used as a kind of natural language text compressor, eg: by predicting
>> what words likely come next (or previous). dunno though.
>
> Fine. But what you are doing is recognizing invariant patterns that allow
> techniques to be applied across problem spaces. I would push back with
> two thoughts.
>
> (1) Separating concerns via application partitioning into subsystems with
> narrowly defined, cohesive subject matters makes it much easier to
> recognize such invariants for particular aspects of complex problems.
>
> (2) The OO view of messages as announcements, peer-to-peer communications,
> abstracting around logical indivisibility at a particular level of
> abstraction, DbC, and a bunch of other basic OOA/D methodological stuff
> all play to together to provide exactly these sorts of generally
> applicable problem solving techniques.
>
ok.

I appologize if my responses aren't that great, right now I am lacking in
time.