Re: Math expression evaluation error?

[ZyX <kp-pav@xxxxxxxxx>]

14.01.2015, 17:48, "Vincent Lefevre" <vincent@xxxxxxxxxx>:
> On 2015-01-14 02:03:33 +0300, ZyX wrote:
>>  13.01.2015, 19:01, "Vincent Lefevre" <vincent@xxxxxxxxxx>:
>>>  In POSIX, it is always an integer division.
>>  What?!
>>
>>  1. How POSIX is related? Zsh is not a POSIX shell and it is not emulation mode that is being discussed here.
>
> Zsh is partly based on POSIX for compatibility. The big difference
> is the lack of word splitting (unless SH_WORD_SPLIT is set). Otherwise
> I think that one should expect similar behavior, unless there is a
> good reason.
>>  2. If this standard is correct: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tagtcjh_15 then it references ISO C standard.
>
> [...]
>>     Where do you see a requirement for `/` to be integer division?
>
> The context is an integer arithmetic. Thus / is necessarily an
> integer division, like in C with integer types.

No. The context explicitly says that signed long integers or doubles should be used. Context of the ISO C standard obviously does not say anything like this.

>>  3. POSIX (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04) says that “Only signed long integer arithmetic is required.” And the section referenced there talks about signed long or double. Signed long integer arithmetic is *required* to be in there, but signed long integer arithmetics is *not required* to be the *only* arithmetics present in POSIX shell.
>
> It says: "as long as it does not affect the results in cases where
> there is no overflow"
>
> If $((1/2)) gave 0.5 in some shells, I fear this would break various
> scripts.

This is as well against the standard because in C division of two integers yields integers and is performed according to integer division rules.

>
> So, if a real-floating type is used, then for "/", I suppose that
> the implementation should do a floor() after the division if the
> context has operands recognized as integers, which is here equivalent
> to the integer division despite the two roundings (proved in
> http://www.vinc17.net/research/papers/rr_intdiv).
>
> But POSIX doesn't specify the arithmetic evaluation on expressions
> other than signed long integer arithmetic. An implementation that
> decides that $((1.0/2)) gives 17 "as an extension" could still be
> conforming.

Nope, it cannot ever be conforming. POSIX does this by saying that semantic of operation is the same as in C, except that only signed long integers and doubles are allowed. In C 1.0/2 gives 0.5 because this is how conversion rules are defined.

If you want to say it does *show me where POSIX explicitly forbids doubles in definition of arithmetic expansion*. I only see it explicitly forbidding the internal shell type (which is allowed to be greater then long or even be floating-point) to affect the results of operation (unless there is an overflow which is in any case not defined for signed integers) which is the case if one tries to divide two integers (effectively requiring shell to keep track on types even if it wants to use double for everything) and also in case doubles are used, effectively meaning that if shell supports doubles it should yield doubles after division involving a double: “The evaluation of arithmetic expressions shall be equivalent to that described in Section 6.5, Expressions, of the ISO C standard.”.

>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)