Zsh Mailing List Archive
Messages sorted by:
Re: inf and nan in arithmetic expansions
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))'
(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)))).
Messages sorted by: