This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: time.g weirdness


On Thu, 12 Aug 2004, Jim Kingdon wrote:

> > (set relative-infinity 9999)
> 
> Is this better than adding infinity to the lisp object system (with
> infinity getting its own value in enum lisptype)?  

I don't know. I haven't forgotten that you have suggested adding 
an actual infinity quantity before, but I have some qualms about 
that too, some of which you bring up below.

>I guess for the
> latter you'd need to figure out comparisons, arithmetic, etc, anew,
> which might be a bit of a pain.  And of course there would be the
> problem of when it is brought into C code, does it turn into TABHI, or
> does the code need to check for it specifically, or what?

In the case of tables, the only storage type that they currently 
support is 'short'; even TABDICE are just shorts. Even in the case 
of properties, assignments of varying types are not supported, and 
so if there is an integer property it could not be bound to an 
'Obj* lispinf' or whatever.

> What I had in mind was something much less deep.  If
> mp-to-enter-terrain says you need 99 movement points, and
> acp-per-turn, free-mp, etc, say that a unit can never get 99 movement
> points in a turn, then have the help report it as infinite.  The big
> problem with that is that it is very case-by-case, and it would be
> easy for this computation to be out of sync with the action code.  

Exactly. This is not such a big deal as long as one writes 
functions that are common to both.

>So
> maybe one of the infinity variants would make more sense anyway.

The relative infinity idea would be the easiest to code, in my 
estimation, but it is also the crudest. The case-by-case logic 
probably makes the most sense in the long run. I have already been 
heading in this direction with the common ACP and MP arithmetic 
functions that I have been written (with more to come). Hans has 
already created some fairly decent volume checking functions that 
can be used rather ubiquitously as well.

Eric


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]