#integer nn=4 typeset -F nn=4 typeset -F aa= (( aa = ((2 * nn) - 1) / (nn**2) )) echo $aa If 'nn' is declared as an integer the above echos zero but if as a float the answer is correct. But nn will never actually be other than an integer so I don't like to declare it as a float. Am I not expecting successful arithmetic even with the integer? I know you can force the issue with: (( aa = ((2 * nn) - 1) / (nn**2.0) )) ... but I wonder why that's needed. Why are answers dumbed down like that? It's clearly a design decision but it seems to me unnatural. If 'aa' was an integer too I understand the result would have to be rounded down to zero, but since aa is a float, shouldn't all arithmetic automatically produce floating point results?

```
On Wed, Mar 24, 2021 at 10:20 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Why are answers dumbed down like that?
Every subexpression is considered independently, so float conversion
doesn't take place until the assignment is evaluated. The type of the
lvalue does not propagate across every rvalue.
```

```
On 2021-03-24 10:56 a.m., Bart Schaefer wrote:
> On Wed, Mar 24, 2021 at 10:20 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> Why are answers dumbed down like that?
> Every subexpression is considered independently, so float conversion
> doesn't take place until the assignment is evaluated. The type of the
> lvalue does not propagate across every rvalue.
>
So it's procedural rather than deliberate/designed. It's not hard to
cope with
still I'd vote to correct it -- one of those things where a look ahead
could
sorta say that if the lvalue is float, then all subsequent arithmetic
will be
float. Or not worth the trouble, it's easy enough to work around.
```

[-- Attachment #1: Type: text/plain, Size: 948 bytes --] On Wed, Mar 24, 2021 at 10:51 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > On 2021-03-24 10:56 a.m., Bart Schaefer wrote: > > On Wed, Mar 24, 2021 at 10:20 AM Ray Andrews <rayandrews@eastlink.ca> > wrote: > >> Why are answers dumbed down like that? > > Every subexpression is considered independently, so float conversion > > doesn't take place until the assignment is evaluated. The type of the > > lvalue does not propagate across every rvalue. > > > So it's procedural rather than deliberate/designed. It's not hard to > cope with > still I'd vote to correct it -- one of those things where a look ahead > could > sorta say that if the lvalue is float, then all subsequent arithmetic > will be > float. Or not worth the trouble, it's easy enough to work around. > The behavior of zsh in this regard is consistent with C and all languages inspired by it (C++, Java, C# and many, many others). This is really working as intended. Roman. [-- Attachment #2: Type: text/html, Size: 1408 bytes --]

```
On Wed, Mar 24, 2021 at 2:54 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> The behavior of zsh in this regard is consistent with C and all languages inspired by it (C++, Java, C# and many, many others). This is really working as intended.
Proof:
#include <stdio.h>
void main() {
int x = 3, y = 7;
float z = (x/y);
printf("%g\n", z);
}
```

```
On 2021-03-24 2:59 p.m., Bart Schaefer wrote:
> On Wed, Mar 24, 2021 at 2:54 PM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
>> The behavior of zsh in this regard is consistent with C and all languages inspired by it (C++, Java, C# and many, many others). This is really working as intended.
> Proof:
>
> #include <stdio.h>
> void main() {
> int x = 3, y = 7;
> float z = (x/y);
> printf("%g\n", z);
> }
>
Long time since I did any floating point in C, so I'll take you guy's
word for it. Final shot would that since one can force the conversion
by, say, multiplying by 1.0, which is otherwise pointless, one could
imagine some option whereby the bother is simply not required.
(( aa = ((2 * nn) - 1) / (nn**2.0) ))
... in that case the denominator is not changed in any way, yet if flags
that the division should be passed as a float. Seems an awkward way of
getting the conversion. How is 2^2 different from 2^2.0 ? If 'aa' was
an integer then of course the result must be rounded, but it still seems
to me the float should receive the actual result. One of my little
whines, nothing of substance. Still one might dream of setopt AUTO_FLOAT.
```

Ray Andrews wrote on Wed, Mar 24, 2021 at 18:12:29 -0700: > On 2021-03-24 2:59 p.m., Bart Schaefer wrote: > > On Wed, Mar 24, 2021 at 2:54 PM Roman Perepelitsa > > <roman.perepelitsa@gmail.com> wrote: > > > The behavior of zsh in this regard is consistent with C and all languages inspired by it (C++, Java, C# and many, many others). This is really working as intended. > > Proof: > > > > #include <stdio.h> > > void main() { > > int x = 3, y = 7; > > float z = (x/y); > > printf("%g\n", z); > > } > > > Long time since I did any floating point in C, so I'll take you guy's word > for it. Final shot would that since one can force the conversion by, say, > multiplying by 1.0, which is otherwise pointless, one could imagine some > option whereby the bother is simply not required. > > (( aa = ((2 * nn) - 1) / (nn**2.0) )) > > ... in that case the denominator is not changed in any way, yet if flags > that the division should be passed as a float. Seems an awkward way of > getting the conversion. How is 2^2 different from 2^2.0 ? If 'aa' was an > integer then of course the result must be rounded, but it still seems to me > the float should receive the actual result. The «/» operator is defined to perform integer division (discarding the remainder) when both of its arguments are integers, and floating-point division otherwise. That _is_ inconsistent, in a way, since in C it's not possible to implement a two-argument function that has the same semantics as the «/» operator for both integral and floating-point types… but that's how it is. > One of my little whines, nothing of substance. Still one might dream > of setopt AUTO_FLOAT. Python 3's division operator always returns floats. Daniel

On 2021-03-24 6:36 p.m., Daniel Shahaf wrote: > The «/» operator is defined to perform integer division (discarding the > remainder) when both of its arguments are integers, and floating-point > division otherwise. Sounds pretty well written in stone. One of those things that goes back from before the flood. > > Python 3's division operator always returns floats. I'd think of it as polite. Just now I'm doing this: (( divided = sum * 1.0 / level )) ... and it really does seem belabored.

```
On Wed, Mar 24, 2021 at 6:45 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> I'd think of it as polite. Just now I'm doing this:
>
> (( divided = sum * 1.0 / level ))
>
> ... and it really does seem belabored.
Doc, Arithmetic Evaluation section:
Users should beware that, in common with many other programming
languages but not software designed for calculation, the evaluation of
an expression in zsh is taken a term at a time and promotion of integers
to floating point does not occur in terms only containing integers. A
typical result of this is that a division such as 6/8 is truncated, in
this being rounded towards 0. The FORCE_FLOAT shell option can be used
in scripts or functions where floating point evaluation is required
throughout.
```

```
On 2021-03-24 7:37 p.m., Bart Schaefer wrote:
> The FORCE_FLOAT shell option can be used
> in scripts or functions where floating point evaluation is required
> throughout.
>
Ha!
```