From owner-freebsd-current@freebsd.org Mon Jan 15 18:41:59 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CC7CE6E332 for ; Mon, 15 Jan 2018 18:41:59 +0000 (UTC) (envelope-from yuripv@icloud.com) Received: from pv33p00im-asmtp002.me.com (pv33p00im-asmtp002.me.com [17.142.194.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F5B4685A1 for ; Mon, 15 Jan 2018 18:41:59 +0000 (UTC) (envelope-from yuripv@icloud.com) Received: from process-dkim-sign-daemon.pv33p00im-asmtp002.me.com by pv33p00im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P2L00400XXFYP00@pv33p00im-asmtp002.me.com> for freebsd-current@freebsd.org; Mon, 15 Jan 2018 17:41:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1516038078; bh=k/lkXm2hIGRg8r7Y8V9FHpxhcRiPLQ6zBe5JR1Fm19s=; h=Subject:To:From:Message-id:Date:MIME-version:Content-type; b=eIrMllrXNofNXgQIDztot8TZcfVDbsIFaPZo3SIvZL5ECNIB0XgKAG42mEI2wiaMX 50IwXDFvPAM3VmFm/8cnDdI8KWh5CZCoGR3OBFrvELNfinKmG0nb0VsTHTm5WWuhpH RNupZof7B+WxMYdQJeUe1m26nQDVrlX0AmmB3TWNDffQEQYWtQ3WI7Vpepa57CnMWp ENpqnAGEES05q+RTwgHIPZ329SGnCAb5BkVuHLcsmbVXHVOZGo4R4HWUqcSqko89ao oulb+waF5NTKGEvln31zS9uoYAPrwbFf2AA3RXskUR5QFaHb1Jsigd3iah8odTpBZy On3HK23wLFqQA== Received: from icloud.com ([127.0.0.1]) by pv33p00im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P2L003PNYGP5Q20@pv33p00im-asmtp002.me.com>; Mon, 15 Jan 2018 17:41:17 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-15_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1801150250 Subject: Re: inconsistent for() and while() behavior when using floating point To: Mehmet Erol Sanliturk Cc: freebsd-current References: <6c423dbf-cd85-3c93-41e4-3362c06dfbb7@icloud.com> From: Yuri Pankov Message-id: Date: Mon, 15 Jan 2018 20:41:13 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 18:41:59 -0000 On Mon, Jan 15, 2018 at 08:38:15PM +0300, Mehmet Erol Sanliturk: > > > On Mon, Jan 15, 2018 at 5:38 PM, Yuri Pankov > wrote: > > Hi, > > Looking at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217149 > , I > noticed that it isn't a seq(1) problem per se, rather for() and > while() loops behaving inconsistently while using floating point, i.e.: > >         double i; > >         for (i = 1; i <= 2.00; i += 0.1) >                 printf("%g\n", i); > > would produce: > >         1 >         ... >         1.9 > > but: > >         double i; > >         for (i = 1; i <= 2; i += 0.2) >                 printf("%g\n", i); > > would correctly end with 2: > >         1 >         ... >         2 > > $ cc -v > FreeBSD clang version 6.0.0 (branches/release_60 321788) (based on > LLVM 6.0.0) > Target: x86_64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > > though gcc 4.4.4 on illumos behaves the same. > > Is this a known problem with loops and floating point numbers? > _______________________________________________ > > > > > When you perform floating point computations , it may be useful to > remember that , the last bits of floating point numbers may be > considered to be "noise" . > For that reason , the same "for" or "while" loops may behave differently > in different times and places . > > To make floating point related loops more deterministic , the useful > steps may be to compute "step size" and "number of steps" , and use > integer variables for counting loop steps with multiplication of "loop > counter"  and "step size" during loop steps :  For floating point loop > counter T = "integer loop counter" * "step size" . Indeed, exactly as I did in a patch for that PR. > A statement  like  T = T + "step size" will/may produce wrong results if > number of steps is sufficiently large . > > > Computer arithmetic and theoretical arithmetic are not the same . > For example , addition is not associative in computer arithmetic : a + ( > b + c ) is not always equal to ( a + b ) + c . Thanks to all replies, I now clearly see the problem.