Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 48355 invoked from network); 19 Jan 2011 16:31:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 19 Jan 2011 16:31:08 -0000 Received: (qmail 20807 invoked by uid 500); 19 Jan 2011 16:31:05 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 20308 invoked by uid 500); 19 Jan 2011 16:31:00 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 20296 invoked by uid 99); 19 Jan 2011 16:30:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jan 2011 16:30:59 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [76.96.62.16] (HELO qmta01.westchester.pa.mail.comcast.net) (76.96.62.16) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jan 2011 16:30:51 +0000 Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta01.westchester.pa.mail.comcast.net with comcast id xUSR1f00A1wpRvQ51UWXSx; Wed, 19 Jan 2011 16:30:31 +0000 Received: from [192.168.1.201] ([69.143.109.145]) by omta18.westchester.pa.mail.comcast.net with comcast id xUWW1f01X38FjT13eUWXl2; Wed, 19 Jan 2011 16:30:31 +0000 Message-ID: <4D3711A5.5050808@christopherschultz.net> Date: Wed, 19 Jan 2011 11:30:29 -0500 From: Christopher Schultz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tomcat Users List Subject: Re: [OT] Setting HTTP response headers caching for 1 year doesn't work References: <4D32D59B.8020402@ice-sa.com> <4D32F58B.5050305@ice-sa.com> <4D35E60E.2010009@christopherschultz.net> <4D362C76.3000206@ice-sa.com> <4D365637.2090607@christopherschultz.net> In-Reply-To: X-Enigmail-Version: 1.2a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org -----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 > 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