From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 74B0D7F0EF for ; Wed, 27 Jan 2016 11:18:04 +0100 (CET) IronPort-PHdr: 9a23:uyu30haaAxY6C709QfT6B6L/LSx+4OfEezUN459isYplN5qZpcu7bnLW6fgltlLVR4KTs6sC0LqJ9fi6EjRQqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7/0o8eYO1UArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIYTGZn9Krw1TLsQWCwrMmdz7srxqRnOSQ+CznQZW2QS1BFPBl6BpBrzW5O0tirhqsJ83jObNIv4V+MaQzOnupdiVh7lkm8jOiQ+4SmDusVuja9B5jasvRtu64/SeoCccvRkKPCONegGTHZMC54CHxdKBZmxOtMC Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=xavier.leroy@gmail.com; spf=Pass smtp.mailfrom=xavier.leroy@gmail.com; spf=None smtp.helo=postmaster@mail-wm0-f46.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of xavier.leroy@gmail.com) identity=pra; client-ip=74.125.82.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="xavier.leroy@gmail.com"; x-sender="xavier.leroy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of xavier.leroy@gmail.com designates 74.125.82.46 as permitted sender) identity=mailfrom; client-ip=74.125.82.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="xavier.leroy@gmail.com"; x-sender="xavier.leroy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wm0-f46.google.com) identity=helo; client-ip=74.125.82.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="xavier.leroy@gmail.com"; x-sender="postmaster@mail-wm0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BRAQC2mKhWmy5SfUpehAxtiFe0MIc1PBABAQEBAQEBARABAQEBAQYLCwkhLoItghUBAQMBEhEEGQESJQIDAQsBBQUaAgUWCwICCQMCAQIBIgEFARwGAQwIAQEeh2QDCggOoESBMT4xizSEQIYnJw2EHCQBBQoEbYU3hGyHTIE6BZZ7hUeIEIIphnAOhVONBjCBDTdggzhpAYhDAQEB X-IPAS-Result: A0BRAQC2mKhWmy5SfUpehAxtiFe0MIc1PBABAQEBAQEBARABAQEBAQYLCwkhLoItghUBAQMBEhEEGQESJQIDAQsBBQUaAgUWCwICCQMCAQIBIgEFARwGAQwIAQEeh2QDCggOoESBMT4xizSEQIYnJw2EHCQBBQoEbYU3hGyHTIE6BZZ7hUeIEIIphnAOhVONBjCBDTdggzhpAYhDAQEB X-IronPort-AV: E=Sophos;i="5.22,354,1449529200"; d="scan'208";a="199661866" Received: from mail-wm0-f46.google.com ([74.125.82.46]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Jan 2016 11:18:03 +0100 Received: by mail-wm0-f46.google.com with SMTP id 123so144833972wmz.0 for ; Wed, 27 Jan 2016 02:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=QulGfXyusZoL3kQB3Ef56w5ZT72tj43dkhmwXRkxZ1Q=; b=v8ycRMhGBo/wdJCF9D1kcIur0mUviKhYw5bAaOnnt1ClbEFoTLTWTTGTZ+Nib8eqoB fOc89Q+llFxHuepbF4QOmtN+2EcuFrTfXMVYDVYzwW4o0H+yL+ClGKv9xpn8vOFIZfJE FZW5ZqwjcbKQ+F/3aM8NnSkzH6NhBqBADgcZ9UOARIdqElb3nhyKWLes0gcr7Yw0ExnJ u9DtTZ1oKBQbZwPw5rkri19HG3c7MXE/QtciQfXYVPtwnmRLZk0CplxfP/ohi5bDVs4l Ilj+PPcTZwOq4S4qWHzl5p7ma7NGy8V6YZP3B2RQumfdBotwv8XUum1IK0q/D/I8FLq+ DXVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=QulGfXyusZoL3kQB3Ef56w5ZT72tj43dkhmwXRkxZ1Q=; b=j3Blg7nktc/BkK1vYs6VpmNz0Va8nHadivgWX/dXSxPDqNaKp+YeIniANzvYUvEWzS pUsvSxgJYQUti1WkR6QkXeD9opg/uBDDd81WnVcqGG8hSzMgoDetQqzrnb/lHWU2K8ga c5CAU0OvgdKo3+neAZ2fPeWiVNE+0kDHgJE9AOaGQ5BqJlqr2gt+lxUGu69NNP8zMLM4 nbw4Q9tOMEotsESz9f6+XnS6sfw8xqGAWp1Y9KYhUXcyzv0q4IzUIcxM2z+PMZL5hTjH 2bp2SVsG7/KunF54ztq1QDlRkNnza62Z6sI/+b6UFQZM6kUlhPgXzCQo82dl/6fMErPx mZgQ== X-Gm-Message-State: AG10YOT3WwNhpn83PoD3pGLVSmq/HfFwZ/29/SMoGQCN9oiAT6a7iK4DI+ZqLKeq8MUzqw== X-Received: by 10.28.35.6 with SMTP id j6mr30933772wmj.80.1453889883894; Wed, 27 Jan 2016 02:18:03 -0800 (PST) Received: from [192.168.1.2] ([108.61.123.81]) by smtp.gmail.com with ESMTPSA id gg7sm5456058wjd.10.2016.01.27.02.18.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 02:18:02 -0800 (PST) Sender: Xavier Leroy To: peio , caml-list@inria.fr References: <1453854887.31205.2.camel@gmail.com> From: Xavier Leroy Message-ID: <56A8995A.3030304@inria.fr> Date: Wed, 27 Jan 2016 11:18:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1453854887.31205.2.camel@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] truncated division, remainder and arithmetics On 27/01/16 01:34, peio wrote: > while doing some modular arithmetic I discovered that OCaml uses the > 'truncated division' convention for the `/` (quotient) operator. > Actually this convention may seem innocent but it greatly affects the > `mod` (remainder) operator: the sign of the result is the same as > dividend. > > After some research I realized that lots of people (D.Knuth!) > criticized this convention in favor of floored division (sign of > remainder same as divisor) or euclidean division (remainder always > positive). I know such a key component of the language isn't likely to > be changed but I would like to get some of the rationals behind this > decision. All contemporary microprocessors that implement division in hardware implement what you call truncated division. The other forms of division and modulus (there are at least two others) can be implemented on top of that. See this excellent summary: Daan Leijen, Division and Modulus for Computer Scientists , July 2003. http://research.microsoft.com/apps/pubs/default.aspx?id=151917 > At last another thing that (slightly) bugs me: why don't `ceil` and > `floor` have the type `float -> int`? Because the inherent definitions > of these functions talks about integers, not floats Yes, but with the type you propose they would overflow easily for large enough FP arguments. In FP computations involving ceil and floor, it is often possible to do the computation entirely in floating-point, avoiding catastrophic overflow cases. > Maybe even more subtle is that `truncate` > has type `float -> int`. In my opinion the type `float -> float` would > be more appropriate here because the truncation operation is about > approximating a real number with a decimal (we already got > `int_of_float` for rough converting). "truncate" and "int_of_float" are (currently) the same function. - Xavier Leroy