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.3 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 29A32BBC4 for ; Tue, 17 Mar 2009 16:13:09 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ9av0nVuiYS/2dsb2JhbADESpB8B4N1BocX X-IronPort-AV: E=Sophos;i="4.38,379,1233529200"; d="scan'208";a="36684593" Received: from solaria.dimino.org ([213.186.38.18]) by mail4-smtp-sop.national.inria.fr with ESMTP; 17 Mar 2009 16:13:08 +0100 Received: from aurora (localhost.localdomain [127.0.0.1]) by solaria.dimino.org (Postfix) with ESMTP id 4A41A8004C; Tue, 17 Mar 2009 16:13:08 +0100 (CET) Received: by aurora (Postfix, from userid 1000) id 5F74D4463C; Tue, 17 Mar 2009 16:13:08 +0100 (CET) Subject: Re: [Caml-list] Int64 comparison From: =?ISO-8859-1?Q?J=E9r=E9mie?= Dimino To: Elnatan Reisner Cc: Caml Mailing List In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Mar 2009 16:13:07 +0100 Message-Id: <1237302787.23290.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-Spam: no; 0.00; compiler:01 2009:98 polymorphic:01 polymorphic:01 caml-list:01 functions:01 functions:01 int:01 int:01 caml:02 represented:02 numerical:03 compiled:04 profiling:04 types:05 Le mardi 17 mars 2009 =C3=A0 08:51 -0400, Elnatan Reisner a =C3=A9crit : > Do the polymorphic ordering functions -- (<), (>), etc. -- correspond =20 > to the numerical ordering for Int64s and Int32s? I assume so, but I =20 > didn't see this specified anywhere. Yes, int64s and int32s are represented in memory by custom blocks [1], so there is a specific comparison functions for them. > If the answer is 'yes', is there a reason I should prefer > Int64.compare n1 n2 < 0 > to > n1 < n2 > ? They may be compiled differently if the compiler does not know that n1 and n2 are of type int32 or int64 in the second case, but the result will be the same. You can have look at [2], paragraph "Polymorphic types" for details. J=C3=A9r=C3=A9mie [1] http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html#toc136 [2] http://www.ocaml-tutorial.org/performance_and_profiling