From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 8D96EBC6B for ; Sat, 10 Feb 2007 15:55:48 +0100 (CET) Received: from oden.vtab.com (dns.vtab.com [62.20.90.195]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l1AEtl9X006818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 10 Feb 2007 15:55:48 +0100 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 1BCD426EEFC; Sat, 10 Feb 2007 15:55:47 +0100 (CET) Received: from virtutech.se (alfredo.hq.vtech [10.0.0.52]) by oden.vtab.com (Postfix) with ESMTP id E568C26EEF0; Sat, 10 Feb 2007 15:55:46 +0100 (CET) Received: (from mattias@localhost) by virtutech.se (8.11.6/8.11.6) id l1AEtkx04882; Sat, 10 Feb 2007 15:55:46 +0100 Date: Sat, 10 Feb 2007 15:55:46 +0100 Message-Id: <200702101455.l1AEtkx04882@virtutech.se> From: "=?iso-8859-1?q?Mattias_Engdeg=E5rd?=" To: ls-ocaml-developer-2006@m-e-leypold.de Cc: caml-list@yquem.inria.fr In-reply-to: (ls-ocaml-developer-2006@m-e-leypold.de) Subject: Re: [Caml-list] Multiplication of matrix in C and OCaml Content-Type: text/plain; charset=iso-8859-1 References: <45CAF3E2.7020807@univ-paris12.fr> <200702092353.09173.jon@ffconsultancy.com> <121wkybxh5.fsf@hod.lan.m-e-leypold.de> <200702100224.32450.jon@ffconsultancy.com> X-Virus-Scanned: ClamAV using ClamSMTP X-j-chkmail-Score: MSGID : 45CDDCF3.001 on concorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at concorde with ID 45CDDCF3.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; mattias:01 mattias:01 ocaml:01 compiler:01 infinities:01 nans:01 partial:01 caml-list:01 finite:02 nan:06 examples:07 i'm:09 wrong:09 wrong:09 zero:10 >Just to be sure: Would the compiler be wrong to optimize > > c * q > c * k > >to just > > q > k With IEEE floating-point it would be wrong for several reasons. Example 1: q and k are finite but c*q and c*k both are infinite. Example 2: q and k are small, so that c*q and c*k both are +-0 Example 3: c is NaN but q and k are not. I'm sure there are other examples involving but not limited to partial or total loss of precision, positive/negative zero, infinities and NaNs.