From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17524 invoked by alias); 8 Feb 2018 14:22:22 -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: 42348 Received: (qmail 12041 invoked by uid 1010); 8 Feb 2018 14:22:22 -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 3.760831 secs); 08 Feb 2018 14:22:22 -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=r5avhjJAqLSZwthOblVhuqkD863RTAOsVSIVMObPdYs=; b=lPtAKD9JBdEauLELjXOLEvWoRN7u3X+yp2YPgJDmxm4tPxuLP89Zl3Bu2bL9DQ2len QeMh+a9Hha6omvRsfQdC0wP4A2/FeBO/qc3zoK9cSyPA/lVZGajAFlUstCHCsGXhuPzz qn3tp97mFbjnnxOKXEvhGftSsgHtyPNuDCjqWFfAE88CBy1B04a2ol2i+CbI8vf6tvy7 hUlDyIyl/guo3LkZ+6egNEcfqKeoPL0cyevFhWSMjGdIFiAG23ChMjVgelUnS3U4he8f mpy1orT++RqY2AikpBjm5j7BncPdGP+FU2+0a1qC8mFEUPz2Th7Omm9XchV/meb7Bhmd borA== 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=r5avhjJAqLSZwthOblVhuqkD863RTAOsVSIVMObPdYs=; b=j0Ksexz/BbgB/lIM8k6+gYVCyQaPPOiNR3kXa6JHog1CVXvj344Y2weEIXVOmDlKjs toLqbU5BI3lFMvywy8IyGEIvxAAVtYayAxN7iZg/C11qP8qKFdg6nSb8ooWX0hwQcS1Z uiER+e+nad3hMQ85bxDW2X00UJQ12T6MThZ/BA5rftcDJ5A2ITWDZrbn/gs+BSnHgJxN 2cvs/rNyKUM7rAXFF3cLO1MbQm09JIJYkYRCLFFt7OJsl4e35VLTDft6v8C5OoTthV5x OaGOdpD5Pk1WhdqPjE0RWNxwQ//Cjtjgv+KARYSTNYLMJuI0vIyZt+qhlX85GrFdAhaq tGHw== X-Gm-Message-State: APf1xPCaLRnGJxKXKJ7vslyWHT6xwAh2Kur3DTWpWT9i4B/DII+DNx8Z lyaTtf554NvDv6l+B2kbrvw= X-Google-Smtp-Source: AH8x226U1wQrdmYDrZ+I9ybGhBcDiyJFYZSPdggOAgOcWg9ys5io3CzR8tyc7bb/cEkW+z2qNCwi1g== X-Received: by 10.223.136.73 with SMTP id e9mr923823wre.98.1518099733844; Thu, 08 Feb 2018 06:22:13 -0800 (PST) Date: Thu, 8 Feb 2018 14:22:11 +0000 From: Stephane Chazelas To: Daniel Shahaf Cc: zsh-workers@zsh.org Subject: Re: inf and nan in arithmetic expansions Message-ID: <20180208142211.GA14888@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1518093995.645366.1263935336.265ED7BF@webmail.messagingengine.com> User-Agent: Mutt/1.5.24 (2015-08-30) 2018-02-08 12:46:35 +0000, Daniel Shahaf: [...] > Why do we generate "inf." with a period in the first place? I know of > no other tool that does this. Shouldn't we generate "inf" and "nan" > with no period? [...] The idea is that we add "." for floats that don't already have one and don't have a e/E to make sure they stay floats when used again in an arithmetic expression. That causes all sorts of problems with yash and ksh93 which don't do that. See https://unix.stackexchange.com/a/422123 for a few examples. It just looks like "inf" and "nan" were overlooked. Whether we output "inf", "Inf" or "inf.", we'd also want to make sure they're recognised on input. > 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? 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) but just make inf/nan readonly so users not be tempted to use them as variables? I'd also rather "inf" be used instead of "inf." (would also align with ksh93), but the change could potentially break some scripts. If we also make $inf/$nan read-only variables, that would also break scripts that use $inf/$nan variables but not in arithmetic contexts (like for inf in *.inf), so that doesn't sound like a good idea to me. -- Stephane