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 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 0722DBC0C for ; Fri, 8 Dec 2006 19:20:23 +0100 (CET) Received: from oden.vtab.com (dns.vtab.com [62.20.90.195]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id kB8IKMQa015240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Dec 2006 19:20:22 +0100 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id C259B26EF30; Fri, 8 Dec 2006 19:20:21 +0100 (CET) Received: from virtutech.se (alfredo.hq.vtech [10.0.0.52]) by oden.vtab.com (Postfix) with ESMTP id A74AC26EF2F; Fri, 8 Dec 2006 19:20:21 +0100 (CET) Received: (from mattias@localhost) by virtutech.se (8.11.6/8.11.6) id kB8IKL023123; Fri, 8 Dec 2006 19:20:21 +0100 Date: Fri, 8 Dec 2006 19:20:21 +0100 Message-Id: <200612081820.kB8IKL023123@virtutech.se> From: "=?iso-8859-1?q?Mattias_Engdeg=E5rd?=" To: jon@ffconsultancy.com Cc: caml-list@yquem.inria.fr In-reply-to: <200612081748.03288.jon@ffconsultancy.com> (message from Jon Harrop on Fri, 8 Dec 2006 17:48:03 +0000) Subject: Re: [Caml-list] if (n:int) < 0 then (-n) > 0 is FALSE Content-Type: text/plain; charset=iso-8859-1 References: <45785E27.8050804@naughtydog.com> <200612071943.kB7JhC522308@virtutech.se> <200612081748.03288.jon@ffconsultancy.com> X-Virus-Scanned: ClamAV using ClamSMTP X-j-chkmail-Score: MSGID : 4579ACE6.000 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at discorde with ID 4579ACE6.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; mattias:01 mattias:01 bug:01 integers:01 semantics:01 unboxed:01 bignum:01 unboxed:01 bignum:01 compiler:01 overflows:01 slower:01 integer:01 caml-list:01 functions:01 >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. >> I would love to have a fast unboxed integer type that automatically >> overflows to bignum, but it would be a tad slower than the current "int". > >How can it be both unboxed and allow overflow to a bignum? Would you generate >int and bigint versions of all functions and then bail to the bigint version >if anything overflowed? This is just what Lisp implementations have done for decades. Yes, it means that code must be prepared to handle either version (unless the compiler can prove that this is not necessary). Generating two versions of all functions is neither necessary nor sufficient.