From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3489 invoked by alias); 12 Aug 2004 16:53:16 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 3476 invoked from network); 12 Aug 2004 16:53:15 -0000 Received: from unknown (HELO ob2.cmich.edu) (141.209.20.21) by sourceware.org with SMTP; 12 Aug 2004 16:53:15 -0000 Received: from egate1.central.cmich.local ([141.209.15.85]) by ob2.cmich.edu (8.12.10/8.12.10) with ESMTP id i7CGmKP8022196; Thu, 12 Aug 2004 12:48:20 -0400 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Aug 2004 12:50:40 -0400 Received: from localhost (localhost [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 665B470021; Thu, 12 Aug 2004 12:53:10 -0400 (EDT) Date: Thu, 12 Aug 2004 16:55:00 -0000 From: Eric McDonald To: Jim Kingdon Cc: xconq7@sources.redhat.com Subject: Re: time.g weirdness In-Reply-To: <200408120403.i7C43mu24086@panix5.panix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 12 Aug 2004 16:50:40.0883 (UTC) FILETIME=[80426C30:01C4808C] X-CanItPRO-Stream: default X-Spam-Score: -0.9 () X-Bayes-Prob: 0.0001 X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004/txt/msg00883.txt.bz2 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