chap@art-sy.detroit.mi.us (j chapman flack) (05/18/91)
In article <599@eskimo.celestial.com> nanook@eskimo.celestial.com (Robert Dinse) writes: >In article <9105060921.aa11316@art-sy.detroit.mi.us>, chap@art-sy.detroit.mi.us (j chapman flack) writes: ># ># mantissa = comp_t & 0x1FFF ># exponent = comp_t & 0xE000 Yow! Did I actually write that? I meant exponent = ( comp_t & 0xE0000 ) >> 13, of course. ># ># double ticks = ldexp( (double)mantissa, 3*exponent) ># ># The extra factor of 3 in the exponent bothers me, ... > >Specifically they stated that the exponent was base 8. Now, ldexp takes Well, that confirms it, I guess. It must have bothered me because I didn't think about it long enough. When I'm thinking about a problem, I sometimes try to simplify it by thinking about smaller quantities and then generalizing. This can get silly when the topic is floating point. I should know by now. What bothered me was the idea that as soon as you use up your 13 bits of significand the first time, you have to jump from counting by 1 to counting by 8. You'd lose less resolution if you just jumped to counting by 2 at that point. My intuition stopped there; the actual useful fact about that phenomenon is that you can define a measure called "wobble" which is the amount by which the relative error of a floating-point representation can vary for a fixed error of x "units in the last place." For example, a comp_t can count up to 8191 ticks without missing a tick. From 8K to 64K-1 ticks, you count by 8. So if a process actually used 8193 ticks, the closest comp_t would be 8192, which is off by one-eighth of an ulp, and differs from the real value by 0.0122%. If a process used 65529 ticks, the closest comp_t would be 65528, which is still off by 1/8 ulp, but only 0.00153%. The relative error corresponding to a certain error in ulps can vary by a factor of 8! In general, if a floating-point representation uses base b, the relative error corresponding to a fixed error in ulps can wobble by a factor of b. So a floating-point representation with a binary exponent minimizes wobble, which is why it intuitively appealed to me, though I didn't work it all out. I just found the information above in David Goldberg, "What Every Computer Scientist Should Know About Floating-Point Arithmetic" in the March 1991 _ACM Computing Surveys_. Lots of other good stuff in there too. Of course, the AT&T folks just traded off wobble for storage size and dynamic range. They wanted to stay in 16 bits. With a binary exponent, they could only measure about 2.9 hours on a 100Hz machine. Using base 8, a comp_t can measure about 5.4 years (with resolution of about 6 hours toward the end). If they had chosen base 4, the range would be about 15 days, which would still result in some overflows for anybody who doesn't remember to panic the system every two weeks. ;-) Now if they put all of that thought into the DESIGN, why couldn't they have put some of it into the COMMENTS ?? > > I am curious how you arrived at that formula, but now all things >considered it makes sense. Thanks for following up on my post! I assumed the exponent would be either the high 3 bits or the low 3 bits, not somewhere in the middle. I ran sleep(1) a few times for periods that varied by a few powers of two (in ticks). Look at the values and see which bits change when. Make theories. Compare to what acctcom says. Repeat.... -- Chap Flack Their tanks will rust. Our songs will last. chap@art-sy.detroit.mi.us -MIKHS 0EODWPAKHS Nothing I say represents Appropriate Roles for Technology unless I say it does.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/21/91)
In article <9105180923.aa03879@art-sy.detroit.mi.us> chap@art-sy.detroit.mi.us (j chapman flack) writes: [ on the use of a base-8 radix ] > I just found the information above in David Goldberg, "What Every Computer > Scientist Should Know About Floating-Point Arithmetic" in the March 1991 > _ACM Computing Surveys_. Lots of other good stuff in there too. Naturally, you can find the same information in Knuth, exercise 4.2.4-6. Lots of other good stuff in there too. ---Dan
torek@elf.ee.lbl.gov (Chris Torek) (05/25/91)
In article <9105180923.aa03879@art-sy.detroit.mi.us> chap@art-sy.detroit.mi.us (j chapman flack) writes: >Of course, the AT&T folks just traded off wobble for storage size and >dynamic range. ... Now if they put all of that thought into the DESIGN, >why couldn't they have put some of it into the COMMENTS ?? The comp_t stuff appears in 32V Unix (the original VAX port, swapping- only) and hence must date back to pre-V7 times. (32V apparently split off just slightly before the V7 release.) What this means is that the `AT&T folks' referred to above were really the original Bell Labs folks, and they were not known for verbosity. The comment in 32V reads: /* "floating pt": 3 bits base 8 exp, 13 bits fraction */ which is sufficient to tip off whoever might work on the file that there was something more to it; whoever was doing said work would then be expected to figure this out for himself, or ask.... -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
clewis@ferret.ocunix.on.ca (Chris Lewis) (05/26/91)
In article <13576@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >In article <9105180923.aa03879@art-sy.detroit.mi.us> >chap@art-sy.detroit.mi.us (j chapman flack) writes: >>Of course, the AT&T folks just traded off wobble for storage size and >>dynamic range. ... Now if they put all of that thought into the DESIGN, >>why couldn't they have put some of it into the COMMENTS ?? > >The comp_t stuff appears in 32V Unix (the original VAX port, swapping- >only) and hence must date back to pre-V7 times. (32V apparently split >off just slightly before the V7 release.) It was certainly in V7 - it was mostly used, I believe, in the "sa" (shell accounting, aka "process accounting" - not the same as current SV) stuff. The process accounting tended to generate big files, so I think they used this compressed form to save space, and to avoid having to do full floating point as part of the kernel's duties (of course, tho, the kernel often had to emulate floats and doubles for user programs if there was no hardware floating point). Can't remember whether it was in V6 or not. -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
McGuire@solbourne.com (Jim McGuire) (05/28/91)
In article <13576@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >In article <9105180923.aa03879@art-sy.detroit.mi.us> >chap@art-sy.detroit.mi.us (j chapman flack) writes: >>Of course, the AT&T folks just traded off wobble for storage size and >>dynamic range. ... Now if they put all of that thought into the DESIGN, >>why couldn't they have put some of it into the COMMENTS ?? > >The comp_t stuff appears in 32V Unix (the original VAX port, swapping- >only) and hence must date back to pre-V7 times. (32V apparently split >off just slightly before the V7 release.) >The comment in 32V reads: > /* "floating pt": 3 bits base 8 exp, 13 bits fraction */ Well, I'm pretty certain it was in the V5 & V6 kernels, as well. In fact, I don't remember ever seeing a kernel that didn't have the acct stuff, and I started working with the kernel stuff in Holmdel in '74. No doubt someone can correct me if my memory has dropped too many bits.... Of course, soon as I saw the "floating pt" comment, I didn't bother to study it any further! I mean, what does a kernel need with floating point? :) -- Jim McGuire, Solbourne Computer Speaking for mcguire@solbourne.com myself only!