<br><br><div class="gmail_quote">On Thu, Nov 5, 2009 at 12:47 AM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Thu, Nov 5, 2009 at 12:09 AM, David Cournapeau <span dir="ltr"><<a href="mailto:david@ar.media.kyoto-u.ac.jp" target="_blank">david@ar.media.kyoto-u.ac.jp</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Charles R Harris wrote:<br>
><br>
><br>
> On Wed, Nov 4, 2009 at 11:39 PM, David Cournapeau<br>
</div><div><div></div><div>> <<a href="mailto:david@ar.media.kyoto-u.ac.jp" target="_blank">david@ar.media.kyoto-u.ac.jp</a> <mailto:<a href="mailto:david@ar.media.kyoto-u.ac.jp" target="_blank">david@ar.media.kyoto-u.ac.jp</a>>><br>
> wrote:<br>
><br>
> Charles R Harris wrote:<br>
> ><br>
> ><br>
> > On Wed, Nov 4, 2009 at 11:30 PM, David Cournapeau<br>
> > <<a href="mailto:david@ar.media.kyoto-u.ac.jp" target="_blank">david@ar.media.kyoto-u.ac.jp</a><br>
> <mailto:<a href="mailto:david@ar.media.kyoto-u.ac.jp" target="_blank">david@ar.media.kyoto-u.ac.jp</a>><br>
> <mailto:<a href="mailto:david@ar.media.kyoto-u.ac.jp" target="_blank">david@ar.media.kyoto-u.ac.jp</a><br>
> <mailto:<a href="mailto:david@ar.media.kyoto-u.ac.jp" target="_blank">david@ar.media.kyoto-u.ac.jp</a>>>><br>
> > wrote:<br>
> ><br>
> > Charles R Harris wrote:<br>
> ><br>
> > ><br>
> > > I don't think it's that bad. Leaving out the ppc and<br>
> sticking to<br>
> > ieee,<br>
> > > there is only double precision, extended precision and quad<br>
> > precision<br>
> > > versions of long double and they are easily determined at<br>
> run time.<br>
> ><br>
> > How would you determine this at runtime ?<br>
> ><br>
> ><br>
> > Excepting the PPC, just loop adding a number to one, dividing it by<br>
> > two at each iteration, and stop when the result is equal to one.<br>
><br>
> But that's not what I need. I need to know exactly the binary<br>
> representation: how many bits in the mantissa/exponent and where, the<br>
> exponent, where does subnormals start, the range of NAN<br>
> representations,<br>
> etc...<br>
><br>
><br>
> It tells you how many bits are in the mantissa, and given ieee the<br>
> rest follows. We only support ieee anyway.<br>
<br>
</div></div>But is this reliable ? It does not seem to work for long double in<br>
intel, for example (but seems to work for sparc64, at least using qemu).<br>
<div><div></div><div><br></div></div></blockquote></div></div><div><br>Works fine here:<br><br><span style="font-family: courier new,monospace;">#include <stdio.h></span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">int main(int argc, char **args)</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">{</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> long double tol;</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> int i;</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> for (i = 0, tol = 1; 1 + tol != 1; tol /=2, i++);</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> printf("count: %d\n", i - 1);</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> return 0;</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">}</span><br><br><br>$[charris@ubuntu ~]$ gcc precision.c<br>
$[charris@ubuntu ~]$ ./a.out<br>count: 63<br><br>That's 63+1 for the mantissa, which is what intel extended precision is.<br><br></div></div></blockquote><div><br>Googling around, it seems that the SUN quad precision is done in software, not hardware and is available but not used by the compilers in the current Intel based SUN systems, but will be in the next OS version. So it looks dependent on the compiler, meaning we probably need a run time check.<br>
<br>Chuck <br></div><br></div>