Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 15572 invoked by uid 500); 15 Jul 2002 20:32:42 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 15561 invoked from network); 15 Jul 2002 20:32:42 -0000 Message-ID: <3D33316E.8050102@apache.org> Date: Mon, 15 Jul 2002 13:32:46 -0700 From: Brian Pane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cliff Woolley CC: APR Development List Subject: Re: approximating division by a million Re: Why not POSIX time_t? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Cliff Woolley wrote: >On Mon, 15 Jul 2002, Brian Pane wrote: > > > >>seconds = (t >> 20) + (t >> 24) >> >>That probably isn't accurate enough, but you get the basic idea: >>sum a couple of t/(2^n) terms to approximate t/1000000. >> >>What do you think? >> >> > > >Sounds like the right idea. But I'm still not sure this isn't too >complicated. ;-] > > At least this localizes the complexity, though: instead of a redesign of the time representation, we'd just need a new macro for retrieving seconds. If that macro looks like #define apr_macro_name_TBD(t) "(t >> 20) + (t >> 24) + (2 >> 29)" (or whatever the right series might be), it's still less complicated than many of the other designs we've been considering. --Brian