From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31151 invoked by alias); 12 Aug 2004 04:03:51 -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 31142 invoked from network); 12 Aug 2004 04:03:49 -0000 Received: from unknown (HELO mail1.panix.com) (166.84.1.72) by sourceware.org with SMTP; 12 Aug 2004 04:03:49 -0000 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id B585648735; Thu, 12 Aug 2004 00:03:48 -0400 (EDT) Received: (from kingdon@localhost) by panix5.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id i7C43mu24086; Thu, 12 Aug 2004 00:03:48 -0400 (EDT) Date: Thu, 12 Aug 2004 08:42:00 -0000 Message-Id: <200408120403.i7C43mu24086@panix5.panix.com> From: Jim Kingdon To: mcdonald@phy.cmich.edu Cc: xconq7@sources.redhat.com In-reply-to: (message from Eric McDonald on Wed, 11 Aug 2004 12:34:45 -0400 (EDT)) Subject: Re: time.g weirdness References: X-SW-Source: 2004/txt/msg00877.txt.bz2 > (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 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? 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. So maybe one of the infinity variants would make more sense anyway.