From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2470 invoked by alias); 12 Jan 2015 02:23:46 -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: 34246 Received: (qmail 9575 invoked from network); 12 Jan 2015 02:23:33 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Ko/6AtSI c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=YNv0rlydsVwA:10 a=Absri4RMmjatbx13aPIA:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <150111182323.ZM10282@torch.brasslantern.com> Date: Sun, 11 Jan 2015 18:23:23 -0800 In-reply-to: <54B30F05.1090207@eastlink.ca> Comments: In reply to Ray Andrews "Re: Floating point modulus" (Jan 11, 4:02pm) 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> <54B30F05.1090207@eastlink.ca> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Subject: Re: Floating point modulus MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 11, 4:02pm, Ray Andrews wrote: } Subject: Re: Floating point modulus } } On 01/11/2015 12:25 PM, 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.xs pws remainder=$1 } } Ignore this question if it can't be explained simply, since } I don't have the knowledge probably to even understand the } answer, but why is it more complicated You're conflating two only loosely related things. Above, Peter is talking about the regression test shell code; you seem to be asking about the C code change, which already works fine -- except that on different hardware/OS platforms, different implementations of double- precision arithmetic may cause the same floating-point operation to return results that differ in the less-significant decimal places. Since the tests rely on being able to (textually) compare an actual result to an expected result, you can't test just any floating point expression, you have to choose a floating point expression that will be the same everywhere to however many decimal places. } And: } } /* 25 */ BOOL|OP_A2IO, LR|OP_A2IO, RL|OP_OP, RL|OP_OP, RL|OP_E2, } -/* 30 */ RL|OP_E2, RL|OP_E2, RL|OP_E2, RL|OP_E2, RL|OP_E2IO, } } ... are those 'metas'? IOW, is that the internal representation of } some command syntax? Metafied? Tokenized? ... There are two tables in math.c, one with symbolic names of all the operators, and one with symbolic (represented as bitfield) binding and precedence of those same operators. The tables line up positionally. Yes, this should probably have been done with structs instead of with two parallel arrays, but this code was written by a college sophomore in 1993 or so and barely changed since. LR and RL are binding, OP_A2 and OP_E2 are assignment or expression and the number of operands, and a suffix of IO means the operator is "integer only". This information is used by the math parser. So my patch removed the "integer only" bit from the map for % and %= and changed the actual implemention to call fmod() for non-integers. The change is very small compared to the diff context produced. -- Barton E. Schaefer