From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA17270 for caml-redistribution; Tue, 14 Dec 1999 08:52:55 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA01011 for ; Tue, 14 Dec 1999 05:17:24 +0100 (MET) Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id FAA06866; Tue, 14 Dec 1999 05:17:21 +0100 (MET) Received: from dylan (dialup05ip055.tus.azstarnet.com [169.197.32.55]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with SMTP id VAA13900; Mon, 13 Dec 1999 21:15:55 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <000e01bf45ea$5213db00$210148bf@dylan> From: "David McClain" To: "Xavier Leroy" , "Christophe Raffalli" Cc: Subject: Re: Plea for inline expansion of transcendentals. Date: Mon, 13 Dec 1999 21:17:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: weis I can appreciate the desire to keep the language pure and proper, but I must say that in nearly 30 years of experience I have never been tempted to take the sin of 2^64. I would suggest that an inline version of the basic transcendentals be made available along the same lines that unsafe_get and unsafe_set are made available for array access. They are inlined for speed, and provide little or no error checking. Their use is flagged by the prominent "unsafe" prefix in the source text, and the option is available to the end user as to when to use them.... - DM -----Original Message----- From: Xavier Leroy To: Christophe Raffalli Cc: caml-list@inria.fr Date: Monday, December 13, 1999 7:48 AM Subject: Re: Plea for inline expansion of transcendentals. >> It seems better to fail in this case, as the part of the number >> which is significant for these periodic functions is completely lost >> by the machine precision, so the renormalization is useless, isn't >> it ? > >Yes, the result of sin(2^64) is totally meaningless. However, >the Single Unix specification doesn't say that there is a range of >values for the argument of "sin" outside of which we can return an >error (however, it says "The sin() function may lose accuracy when its >argument is far from 0.0", which could be interpreted as "we can >return any wrong result"...) > >> The best would be to trap and raise an ML exception (Silly_Trigo :-). > >The trapping itself isn't trivial and requires a few instructions, >making the inlining of "sin" less interesting. > >> Actually ocaml2.04 toplevel (I have not try the compilers) does >> something very silly: >> >> # sin(10.0);; >> - : float = -0.544021110889 >> # sin(10e21);; >> - : float = 1e+22 >> >> Using Ocaml I can therefore prove -1 < 1e+22 < 1 .... Whooo :-) > >Nice example. You must be using RedHat Linux 6 on a PC :-) The >toplevel and bytecode compiler use whatever "sin" function is provided >by the C compiler and C library. If the latter is correct, you'll get >correct results. Your example works fine under Digital Unix, for instance. > >But it so happens that under RH 6.1, the "sin" function in the C >library does the right thing (perform the "fsin" instruction, check >for overflow, and normalize and try again if necessary), but "gcc -O" >generates directly an "fsin" instruction -- "gcc" without -O calls the >C library function. I view this as a gcc bug, though. > >- Xavier Leroy >