From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10734 invoked by alias); 9 Feb 2018 21:09:56 -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: List-Unsubscribe: X-Seq: 42356 Received: (qmail 13240 invoked by uid 1010); 9 Feb 2018 21:09:56 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr0-f172.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.128.172):SA:0(-1.9/5.0):. Processed in 2.018339 secs); 09 Feb 2018 21:09:56 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: stephane.chazelas@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=a9DFhvjNvwYXkbV4fyI6jNwcNNA9zV5zWCSpdJcNs+I=; b=IDxnv7jkwWBANk4W98eXwOgIQbR+e7FuwFqWwPM0L9Tqr+FwDA6CvORd2q/3cU7oT0 Fr9Rk8bJ6KORYSlaIRFIRrerAjpxkztk3XWmM8F4/T3FBGVmMbK4MVrjfI3D1J+SP0v4 FCjHa6C7MhQWGzaKMOjCJZny05zZvHuWhDBD7KuAx89086eB9gIqT947YVAYe1LtBz3T F7ZenquxfleP2OUF37dLUoxIZW39bxHIbX01t0hZMf/9/5l3MYXb7E73XwZ9QHfTVEAN pUVFEWjNh+p0gCJM7mNRZLqrpimPNdNBIgHpdK0R9Y8ir0Nqpb0aQP8OznMcTAYLclcG d5Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=a9DFhvjNvwYXkbV4fyI6jNwcNNA9zV5zWCSpdJcNs+I=; b=EJ3vtwlHbG5eIJ8O3EIc/TurM4L5fCkNRcDAV52F36oARZx2u5+KpRgfI3oYvJtMLj LfWtWmW+lAA4wfsxRH0dQbmMMbCwNk95H+bYMpqUx243cZ2sTqGF23MF9o/kqfi7l0eQ OTw+i1X31izKP6WBdLBafRBtzXJ2saeoQffilZuzjb5SMCWKZWY+1dsz+ns+9e49TKrL UkFz4u1baU10ghRslJbCQ/0hVRev6J9PkQdvicPRYdE64bvRq89VCdT0YqLHjy/bDAxY hTQtvBRxA7C9vNzV/IUYSt+43UE3fBQHl99/NeBOmKvMaiJKgA/rqBqZXdzpoCCdUoSY 8edQ== X-Gm-Message-State: APf1xPCwcEcHSctr3+HtkWjGbA8DVSyltRB/uc3ULt248g9I+GkcbwbP +bxJgnNoQeWd5Q/RzC8SNR19Ag== X-Google-Smtp-Source: AH8x225OZBZkkIT7kZQaBXrKYMSInl57kEsA24PlqKlWGA3LAMgmNVaUEbRnjvi12TmDihpaEVdVrA== X-Received: by 10.223.193.141 with SMTP id x13mr3324026wre.263.1518210589914; Fri, 09 Feb 2018 13:09:49 -0800 (PST) Date: Fri, 9 Feb 2018 21:09:48 +0000 From: Stephane Chazelas To: Daniel Shahaf Cc: zsh-workers@zsh.org Subject: Re: inf and nan in arithmetic expansions Message-ID: <20180209210948.GA27566@chaz.gmail.com> Mail-Followup-To: Daniel Shahaf , zsh-workers@zsh.org References: <20180207223051.GA30393@chaz.gmail.com> <4253.1518045946@thecus.kiddle.eu> <1518093995.645366.1263935336.265ED7BF@webmail.messagingengine.com> <20180208142211.GA14888@chaz.gmail.com> <1518190272.2338601.1265377152.605E16CD@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1518190272.2338601.1265377152.605E16CD@webmail.messagingengine.com> User-Agent: Mutt/1.5.24 (2015-08-30) 2018-02-09 15:31:12 +0000, Daniel Shahaf: > Stephane Chazelas wrote on Thu, 08 Feb 2018 14:22 +0000: > > 2018-02-08 12:46:35 +0000, Daniel Shahaf: > > > And then we could add 'inf' and 'nan' as readonly variables initialised to > > > those respective values (as Oliver also suggests in the 19597 thread). There > > > are compatibility implications for scripts that use these variable names, but > > > there is no way around them if we want to allow explicitly doing (( x = inf )) > > > in user code... > > > > But what value would you use for those variables? > > 'inf' would be positive infinity. 'nan' would be a NaN (whichever flavour > thereof would be least surprising). > > > Or do you mean that the shell arithmetic parser would understand > > "inf"/"nan" as the infinity and not-a-number numbers and not as the > > variable (otherwise with inf=inf, that would do infinite recursion) > > Why would it be recursive? I mean as in: $ inf=inf zsh -c 'echo $((inf))' zsh:1: math recursion limit exceeded: inf a variable name in arithmetic expression is expanded and its value subject to arithmetic evaluation and so on. There's always the option of defining them as: $ nan='(-(1e9999/1e9999))' inf='(1e9999)' zsh -c 'echo $((nan)) $((inf))' nan. inf. (I don't know why I need the "-" there, it's the same in ksh93) > > > but just make inf/nan readonly so users not be tempted to use them as > > variables? > > That would be the simplest implementation, yes. It might suffice, or we might > prefer something more elaborate. I'm not sure I see the benefit of preventing users using from using variables called "inf" or "nan". It seems to me that ksh93's approach at just treating "inf" and "nan" as literral constants representing their value like in C would be enough (which would in effect prevent users from using variables by the same name inside but not outside arithmetic expression (though they'd still be able to do $(($inf)))). -- Stephane