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=AWL autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 16F47BC0B for ; Sat, 9 Dec 2006 03:03:28 +0100 (CET) Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id kB923P60009680 for ; Sat, 9 Dec 2006 03:03:27 +0100 Received: from ppp14-213.lns2.syd7.internode.on.net (HELO rosella) ([59.167.14.213]) by ipmail02.adl2.internode.on.net with ESMTP; 09 Dec 2006 12:33:23 +1030 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOaneUU7pw7V/2dsb2JhbAA X-IronPort-AV: i="4.09,516,1157293800"; d="scan'208"; a="57627001:sNHT304544968" Subject: Re: [Caml-list] if (n:int) < 0 then (-n) > 0 is FALSE From: skaller To: Brian Hurt Cc: Mattias =?ISO-8859-1?Q?Engdeg=E5rd?= , caml-list@yquem.inria.fr In-Reply-To: <4579B0E0.9050304@janestcapital.com> References: <45785E27.8050804@naughtydog.com> <200612071943.kB7JhC522308@virtutech.se> <200612081748.03288.jon@ffconsultancy.com> <200612081820.kB8IKL023123@virtutech.se> <4579B0E0.9050304@janestcapital.com> Content-Type: text/plain; charset=utf-8 Date: Sat, 09 Dec 2006 13:03:19 +1100 Message-Id: <1165629799.10557.18.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 457A196D.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; mattias:01 bug:01 integers:01 semantics:01 flags:01 stone:98 sourceforge:01 wrote:01 wrote:01 caml-list:01 arithmetic:01 precisely:01 int:01 int:01 rarely:02 On Fri, 2006-12-08 at 13:37 -0500, Brian Hurt wrote: > Mattias Engdegård wrote: > > > I wouldn't call it a bug. It looks like modulo arithmetic to me. > > > > > > > Let's not make a virtue of necessity. The type "int" was likely designed > > with the intent to provide a type that could be used for actual integers > > in a variety of circumstances, while giving good performance. The modulo > > semantics is rarely useful (especially the 30-bit signed variety) but > > is the price paid for reasonable performance with a simple implementation. > > > Actually, the modulo behavior comes out of how the CPU designers made > the CPUs work decades ago. It was very easy for them to just drop all > those extra bits (or not even compute them). And, of course, now that > behavior is cast in stone... More precisely I think: CPU's have always preserved the information in flags. The culprit here, as usual, is the C programming language. -- John Skaller Felix, successor to C++: http://felix.sf.net