tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: [OT] Setting HTTP response headers caching for 1 year doesn't work
Date Wed, 19 Jan 2011 16:30:29 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter,

On 1/19/2011 6:09 AM, Peter Crowther wrote:
> On 19 January 2011 03:10, Christopher Schultz
> <chris@christopherschultz.net>wrote:
> 
>> Yup: float is the default decimal type. Double-precision takes longer,
>> so you have to ask for it.
>
> Chris, that's the only comment in your post I'd take issue with. To
> my knowledge, a constant with a fractional part is assumed to be
> double unless stated otherwise.

I think I assumed that float was standard, ran the program, saw that the
answers were different, and concluded that I was right. I didn't really
check the numbers.

I actually have my copy of Harbison/Steele's C: "A Reference Manual" in
front of me for a technical review I'm doing of an Objective-C for iOS
book (see how this all ties together?).

Section 5.2 ("Floating-Point Types") has this to say:

"The use of float, double, and long double is analogous to the use of
short, int, and long. Prior to ISO C, all implementations were required
to convert all values of type float to type double before any operations
were performed (see section 6.3.4), so using type float was not
necessarily more efficient than using type double. In ISO C, operations
*can now be performed using type float*" (emphasis mine).

Section 6.3.4 ("Usual binary conversions") has a table which shows what
type of conversion is done given a pair of operands and the environment.
For float and double, these are the rows:

Op A	Op B	ISO C	Traditional
double	any	double	double
float	any	float	double

So, it looks like ISO C changed the rules to actually make more sense
(to me, at least) in that "float" is the default floating-point
arithmetic strategy. (This makes sense to me because the compiler ought
to do the fastest thing possible by default, and the programmer should
have to specify double-precision if desired.)

> I'm actually interested to know your environment for your
> precision.c code, as a single-precision (32-bit) float is only good for 6-7
> significant figures and your answers agree to 11sf.  Is your compiler
> quietly using IEEE754 64-bit precision, even where you request float?

Not sure.

$ cc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
- --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
- --enable-shared --with-system-zlib --libexecdir=/usr/lib
- --without-included-gettext --enable-threads=posix --enable-nls
- --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
- --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
- --enable-mpfr --enable-targets=all --enable-cld
- --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
- --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)

$ uname -a
Linux dev.chadis.com 2.6.18-14-fza-686-bigmem #1 SMP Thu Jan 1 17:20:47
UTC 2009 i686 GNU/Linux


Fortunately, I'm not a theoretical physicist, so I'm not usually worried
about the difference between floating-point numbers at the e-10 level :)

- -chris

> I love Smalltalk as a prototyping language, for example; but I don't use it
> for the inner loops of genomics code that's optimised to squeeze every piece
> of speed of of a particular AMD processor in a cluster, and that takes the
> time to process some experimental results down from a year to a day.

Oddly enough, I remember back around 2002 when "bioinformatics" was
looking to be the Next Big Thing, lots of people were talking about how
Perl was going to take over the world because of how easy it was to do
certain operations (pattern matching, hashing, etc.) and our dev group
all laughed because, while we all love Perl (and Java), we knew that
failing to write those algorithms in a high-performance language was
going to literally set them back months or years in their research just
due to wasted CPU time. We even scoffed at the use of Java for such
things... but that was before JITs were really, really good.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk03EaUACgkQ9CaO5/Lv0PCvYQCfREBBEgnVyCtXJ9mjQuU8duqm
J54AniueuAXWK8NhbH5vs+x0kXJtfw1B
=4D5l
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message