From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5047 invoked by alias); 12 Jan 2015 09:56:38 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 34251 Received: (qmail 8576 invoked from network); 12 Jan 2015 09:56:34 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f5-b7fc86d0000066b7-b4-54b39a50c44f Date: Mon, 12 Jan 2015 09:56:28 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Floating point modulus Message-id: <20150112095628.4c6a30d5@pwslap01u.europe.root.pri> In-reply-to: <150111184632.ZM3188@torch.brasslantern.com> References: <1420807419-9270-1-git-send-email-mikachu@gmail.com> <54B013C5.6090307@eastlink.ca> <54B04A7A.1010402@eastlink.ca> <20150109223028.6e003bff@ntlworld.com> <54B066C5.3010008@eastlink.ca> <54B0D893.4080202@eastlink.ca> <510FB8E2-EA0C-4582-BD31-527E9755F0FB@larryv.me> <54B1ACA3.1050001@eastlink.ca> <150110175849.ZM21774@torch.brasslantern.com> <54B20E23.8090900@eastlink.ca> <150110231017.ZM24021@torch.brasslantern.com> <150111113601.ZM29941@torch.brasslantern.com> <20150111200119.134bfe2d@ntlworld.com> <150111120423.ZM10129@torch.brasslantern.com> <20150111202538.4859dbe0@ntlworld.com> <150111184632.ZM3188@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsVy+t/xy7oBszaHGDxbLmhxsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4Mm5sTyj4xl3x68NJxgbGGRxdjJwcEgImEhe6HrBD2GISF+6t Z+ti5OIQEljKKHFm3x9mkISQwBImicknuSAS2xglNmzdwgSSYBFQlZh/9DeYzSZgKDF102xG EFtEQFzi7NrzLCC2sICyxPtfU1hBbF4Be4kLm46A2ZwClhLT781mgRi6mk2i++chsDP4BfQl rv79xARxkr3EzCtnGCGaBSV+TL4HNpRZQEti87YmVghbXmLzmrdQl6pL3Li7m30Co9AsJC2z kLTMQtKygJF5FaNoamlyQXFSeq6RXnFibnFpXrpecn7uJkZI0H7dwbj0mNUhRgEORiUeXkup zSFCrIllxZW5hxglOJiVRHhdy4BCvCmJlVWpRfnxRaU5qcWHGJk4OKUaGEVPezcb5iX92O1w fu3U+ZcuXQv/vWPfY6E0tnnxX84c3/ls8t2jfDUemQpxGy3WiXsqxKYJseeuvi6r++BZv2Fo +t+r/3eJPnNtfOD3TfP1GSveZdWBn89P3+e04VnkeoaQEw7zFV/ozVn5JVEz3/Ruwq4lF7cF 9WwzTOfYtvOi9NVAHQMFflslluKMREMt5qLiRABpcT3WOAIAAA== On Sun, 11 Jan 2015 18:46:32 -0800 Bart Schaefer wrote: > On Jan 11, 8:25pm, Peter Stephenson wrote: > } > } I'll leave that to you, but instead of an explicit rounding you could do > } basically the same calculation but assigned to a variable declared as an > } integer and output that. > > Hm. This seems like a bug: > > % integer rnd > % print -- $(( rnd = ((29.1 % 13.0 * 10) + 0.5) )) > 31.500000000000014 > > Shouldn't the result of the $(( ... )) be an integer because rnd has been > declared as an integer? The result above is how I always thought it worked, actually. The type of the result isn't necessarily the type of the variable assigned to; there's never been any code to propagate types back from assignments, unlike in C. Whether or not it should be is another question. Looking at the doc, with its references to C, you'd probably be entitled to expect assignment types propagated the way they do in C. In particular: % integer foo % (( foo )); print $? 1 # foo is zero, status is non-zero % (( foo = 3.5/5.5 )); print $? 0 # foo is zero but # status is also zero as # result is non zero % (( foo )); print $? 1 # different result You might think the status at least went with the assignment. > I had to do this instead: That's what I was expecting you to do. pws