From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30848 invoked from network); 17 Aug 2021 08:25:55 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 17 Aug 2021 08:25:55 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 1ess; Mon Aug 16 19:44:59 -0400 2021 Received: from abbatoir.myfiosgateway.com (pool-74-108-56-225.nycmny.fios.verizon.net [74.108.56.225]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 0bd33cbb (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Mon, 16 Aug 2021 16:38:06 -0700 (PDT) Message-ID: To: 9front@9front.org CC: nabijaczleweli@nabijaczleweli.xyz Date: Mon, 16 Aug 2021 19:38:05 -0400 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: leveraged core HTTP lifecycle component Subject: Re: [9front] Re: seq: fix infinite loop Reply-To: 9front@9front.org Precedence: bulk Quoth Anthony Martin : > But really, if you're playing games at the boundaries > of floating point precision, you're bound to lose. I > suggest we either a) do nothing and leave the loop > exactly as it is described in the manual but add a note > in the BUGS section, or b) go back to the v8 method > that calculates the number of steps in the loop before > executing it. Even with the latter method you can see > odd results due to precision limitations but at least > there will be no infinite loops. > > I vote for "a". > I agree -- *BUT* I like the consolidation of the two loops. I'd take that. I also wonder if: for(val = min; val <= max; val += incr){ if(val == prev) sysfatal("insufficient precision") ... prev = val } covers the infinite loop case sufficiently.