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 C70B97F6D8 for ; Mon, 19 Jan 2015 11:59:44 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of stedolan@stedolan.net) identity=pra; client-ip=209.85.215.48; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="stedolan@stedolan.net"; x-sender="stedolan@stedolan.net"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of stedolan@stedolan.net) identity=mailfrom; client-ip=209.85.215.48; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="stedolan@stedolan.net"; x-sender="stedolan@stedolan.net"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-la0-f48.google.com) identity=helo; client-ip=209.85.215.48; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="stedolan@stedolan.net"; x-sender="postmaster@mail-la0-f48.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAAPPivFTRVdcwlGdsb2JhbABbhDSDAso+B0MBAQEBAREBAQEBBwsLCRIwhA0BAQQSEVYQAQoLDQICJgICIhIBBQEcBhMiiAoEriM+MYsukBaEAwqBF5FHgUEBBJdwkGASI4EVgiMdgVBvgUV+AQEB X-IPAS-Result: AsAAAPPivFTRVdcwlGdsb2JhbABbhDSDAso+B0MBAQEBAREBAQEBBwsLCRIwhA0BAQQSEVYQAQoLDQICJgICIhIBBQEcBhMiiAoEriM+MYsukBaEAwqBF5FHgUEBBJdwkGASI4EVgiMdgVBvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.09,426,1418079600"; d="scan'208";a="117602400" Received: from mail-la0-f48.google.com ([209.85.215.48]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Jan 2015 11:59:44 +0100 Received: by mail-la0-f48.google.com with SMTP id gf13so28003295lab.7 for ; Mon, 19 Jan 2015 02:59:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pVvPLUE4areNh2g7tXZ9gWqlgfbcI8A+1aQ+wbz5kPw=; b=lq+ve+PG2PPMhsVPomItCWcuobNI+jNNKTFIriEbyjkmkZdOe4ob9Ngvl9s7e6UPx6 6whDyGYaJS4aQTXQNV/J2spq9q15juOL/h1a0eNer8MZ0bcqc/0YfReWZsM6XjdIEssQ prwtYj7D9wJGillzggqsnxGsD8C7GnLLQEwnoi1H0nE9mckl4m91GO5h83H/+tKzjReo /9csG2b7iuIzRDSsbDy+a5OUN5qaQIVJggu2zaImGg/p4sYMfsaOsehu4VyLMT/MwuU5 uva/UjW5FkIeTWJjDUDtQBIkE8SEyC/SxPJjAF9l9Xjoj2uQPfiIsDxHz6p90i8mUAGu 6I+Q== X-Gm-Message-State: ALoCoQkfuSh/GhRugB2t17esnVv1E/U4pqDdEDynxk0Sge8EyATJpJqoP7E3gI82OZhc7HuGEVwT MIME-Version: 1.0 X-Received: by 10.112.13.103 with SMTP id g7mr11990871lbc.29.1421665183290; Mon, 19 Jan 2015 02:59:43 -0800 (PST) Sender: stedolan@stedolan.net Received: by 10.112.243.11 with HTTP; Mon, 19 Jan 2015 02:59:43 -0800 (PST) X-Originating-IP: [94.116.42.168] In-Reply-To: <54BBFFF7.6030106@mehnert.org> References: <54BBFFF7.6030106@mehnert.org> Date: Mon, 19 Jan 2015 10:59:43 +0000 X-Google-Sender-Auth: 0zGPTrU1ALeURpbVPU171icJ3nY Message-ID: From: Stephen Dolan To: Hannes Mehnert Cc: caml-list Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] behaviour of mod On Sun, Jan 18, 2015 at 6:48 PM, Hannes Mehnert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA384 > > Hi, > > is the behaviour of modulo arithmetics intentional: > -5 mod 4 = -1 ? > > While this reflects the C behaviour, my expectation was to always have > a positive result: > -5 mod 4 = 3 > > Any hints? Given OCaml's integer division operator, this is the correct "mod". The important property is: (x / y) * y + (x mod y) = x In other words, (x mod y) gives the error by which (x / y) * y fails to equal x. There are two reasonable (/, mod) pairs which have this behaviour. The first, which C and OCaml use, is where (x / y) rounds towards zero and (x mod y) has the same sign as x, so -5 / 4 = -1 and -5 mod 4 = -1. The second is where (x / y) rounds down and (x mod y) has the same sign as y, so -5 / 4 = -2 and -5 mod 4 = 3. Subjectively, I think the first division operator (round-toward-zero, aka truncate) and the second modulo operator are the more natural. The second modulo operator actually implements modular arithmetic, since with it x mod n buckets the integers x into n equivalence classes differing by multiples of n. But using the first (/) and the second mod breaks the remainder property above. Incidentally, Haskell provides both: the first is called (quot, rem) while the second is (div, mod). Stephen