Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!mit-eddie!uw-beaver!milton!sumax!polari!rwing!eskimo!nanook
From: nanook@eskimo.celestial.com (Robert Dinse)
Newsgroups: comp.unix.programmer
Subject: Re: comp_t
Summary: comp_t - this actually makes sense
Keywords: Accounting, comp_t, funny floats...
Message-ID: <599@eskimo.celestial.com>
Date: 10 May 91 23:57:00 GMT
References: <512@eskimo.celestial.com> <9105060921.aa11316@art-sy.detroit.mi.us>
Organization: ESKIMO NORTH (206) 367-3837 SEATTLE WA.
Lines: 30

In article <9105060921.aa11316@art-sy.detroit.mi.us>, chap@art-sy.detroit.mi.us (j chapman flack) writes:
# In article <512@eskimo.celestial.com> nanook@eskimo.celestial.com (Robert Dinse) writes:
# >"comp_t", which is packed into an unsigned short (16 bits). The
# >comments say:
# >
# >	/* 13-bit fraction, 3-bit exponent */
# 
# I just messed with that recently myself.  By running a bunch of commands that
# took known amounts of time (sleep(1) is handy for that) and trying to make
# sense of the resulting comp_ts, I came up with the following theory:
# 
# mantissa = comp_t & 0x1FFF
# exponent = comp_t & 0xE000
# 
# double ticks = ldexp( (double)mantissa, 3*exponent)
# 
# The extra factor of 3 in the exponent bothers me, but it was consistent with
# the various values I tried.  You'll probably want to run a number of trials
# yourself.  I would be delighted, actually, to learn that I'm wrong and have
# someone provide a more sensible explanation.

     Actually this makes perfect sense. I found an include file on a
different system that had notes that were just a tad more explicit.
Specifically they stated that the exponent was base 8. Now, ldexp takes
an exponent in base 2, 2 to the third power is 8, and so that adjustment
of exponent * 3 does exactly what you need, effectively converting ldexp
from base 2 to base 8.

     I am curious how you arrived at that formula, but now all things
considered it makes sense. Thanks for following up on my post!