An integer divided by another integer is not an integer?

[Tom]

int v = 35;
int w = v / 35; //Error since v / 35 is a double

From the JavaScript code it generates, It looks like Dart uses double
to represent all numbers (like JS does). It is reasonable if the
performance is the only thing we concern. However, unlike JS, Dart
introduced the type called int, and it makes the code counter-
intuitive -- at least, unlike any language I know, dividing an integer
with another integer results as a double! It is error prone for people
new to Dart.

Is it a bug? Or, I missed something?

[Peter Ahé]

We are aware of the problem that we represent all numbers as double in
JavaScript. It would be ideal if we didn't have to do that. This is
something we'll keep iterating on.

When it comes to numbers, you should generally use the type "num"
unless you have strong reasons to pick a more specific type. For
example, if you're doing a for-loop, it makes sense to use "int". In
most other cases, you should use "num".

If you want to do truncating division, you should use the ~/ operator instead.

On Mon, Jan 9, 2012 at 10:57, Tom <tom....@gmail.com> wrote:
> int v = 35;
> int w = v / 35; //Error since v / 35 is a double

Actually, this is not an error. It is a type warning.

Cheers,
Peter

[Tom]

Sorry, please forget this thread. I got the answer: ~/, though it is
too subtle to me. Maybe it is because I never use a language like
this.

[Tom]

Peter, Thanks. Here is my test case. It might help you to know if the
design of / and ~/ is proper.

String encode(int v) {
for (; v > 0; v /= 37)
;//encode v % 37
}

Yes, it is a warning, but if we really run it, a dead loop actually.
It bet it must be painful to learn there is ~/ (as I did).

On Jan 9, 6:13 pm, Peter Ahé <a...@google.com> wrote:
> We are aware of the problem that we represent all numbers as double in
> JavaScript. It would be ideal if we didn't have to do that. This is
> something we'll keep iterating on.
>
> When it comes to numbers, you should generally use the type "num"
> unless you have strong reasons to pick a more specific type. For
> example, if you're doing a for-loop, it makes sense to use "int". In
> most other cases, you should use "num".
>
> If you want to do truncating division, you should use the ~/ operator instead.
>

[William Hesse]

Another thing this example helps illustrate is that types of variables
and parameters have no effect on the program.
Think of them just as type annotations, that can give you compilation
warnings if you want, but that don't affect the script at all
otherwise. So having an int variable is no different than having a
var variable. I don't think this message is getting out to people who
haven't watched Gilad's videos, enough.

--
William Hesse
Software Engineer
whe...@google.com

Google Denmark ApS
Frederiksborggade 20B, 1 sal
1360 København K
Denmark
CVR nr. 28 86 69 84

If you received this communication by mistake, please don't forward it
to anyone else (it may contain confidential or privileged
information), please erase all copies of it, including all
attachments, and please let the sender know it went to the wrong
person. Thanks.

[Tom]

I understand what you mean by "type annotation", but it leads to a
question why "int" was introduced at the first place? If all numbers
are double, won't it be less confusing if there is only one type for
numbers? Then, the developer knows how to handle it (like they did for
years in JS), rather than assume it is int and turn out to be a
double.

Allow me to suggest if you'd like to introduce int, please make it a
real integer (at least behaves like one). It is not only the int-to-
double issue but also precision and other well-recognized assumptions
when a programmer saw int. Otherwise, let developers know this
limitation by having only one number type.

Of course, any argument like this is very subjective. It is only my
two cents.

Regards,
Tom

[Tom]

Another issue: For example,

int v = 10;
v is int; //true
v is double; //true!!!

so int == double!? IMO, it is counter-intuitive.

[financeCoding]

You could also wrap it up and call toInt(). (v / 35).toInt(); ~/ probably a "best practice" as of now. 

[Peter Ahé]

Dart is a new programming language. If you want to see it as we intended it to work, use the Dart VM.

On the Dart VM, int and double are different.

Right now you're using a technology preview *and* compiling to JavaScript. JavaScript has a few key design flaws that are hard to work around without losing performance.

We have some promising preliminary work to improve how we generate JavaScript code. However, it is very possible that the best we can do is keep the current behavior. This is unfortunate, but we will not let flaws in JS dictate every aspect of Dart language design.

If you run your encode function on the Dart VM in checked mode, it'll throw an exception when you try to assign a double to an int. Once you change the program to work correctly on the VM, it'll also work correctly when compiled to JS.

Cheers,
Peter

[Tom]

Great to know that. Thanks.

[Bob Nystrom]

On Mon, Jan 9, 2012 at 6:07 PM, Tom <tom....@gmail.com> wrote:

I understand what you mean by "type annotation", but it leads to a
question why "int" was introduced at the first place?

In addition to what Peter said, I think having an int type is handy. There are often cases where an API only expects an integer value. One obvious case is list indexers: foo[123] is fine but foo[123.45] is not. Given that, I think it's helpful if the type system can express that intent.

- bob

[Tom]

After trying a couple days and showing the code to my colleagues, I
still think it is not a good idea. Using ~/ is handy, but it is really
counter-intuitive. I strongly suggest:

1) An integer divided by an integer shall be an integer.
2) (v is int) && (v is double) shall always be false in any machine,
including running as JS.

The implementation is straightforward (GWT already does a good job,
doesn't it?). Of course, there is some performance penalty, but the
implementation is something can be enhanced over the time, especially
when Dart VM is available in different browsers. However, the language
spec stays forever.

Nowadays, programmers have to deal with different languages almost in
a daily basis. Image what will happen if one of your less-experience
members has to work at both server and client side? If he has to watch
someone's video and remind himself when switching task for such a
basic feature, there must be something wrong in the spec.

Sorry for strong wording. But, after programming in Java and JS for
years, I believe Dart has a good chance. Most of differences are more
or less like or dislike, but I'm afraid the integer issue will turn
off a lot of people.

Tom


On Jan 11, 2:18 am, Bob Nystrom <rnyst...@google.com> wrote:

[Peter Ahé]

Hi Tom,

On Thursday, January 12, 2012, Tom <tom....@gmail.com> wrote:
> After trying a couple days and showing the code to my colleagues, I
> still think it is not a good idea. Using ~/ is handy, but it is really
> counter-intuitive. I strongly suggest:
>
> 1) An integer divided by an integer shall be an integer.
> 2) (v is int) && (v is double) shall always be false in any machine,
> including running as JS.
>
> The implementation is straightforward (GWT already does a good job,
> doesn't it?). Of course, there is some performance penalty, but the
> implementation is something can be enhanced over the time, especially
> when Dart VM is available in different browsers. However, the language
> spec stays forever.
>

GWT is trying to implement Java. Java is a statically typed language
and relies on static types to determine what to do. For example, if I
write the following in Java:

double x = 5;
double y = 2;
double z = x / y;

The compiler will first generate code that converts the integer 5 to a
double (did you know this can silently cause loss of precision?). Then
it generates a convertion of the integer 2 to a double (another
potential loss of precision). Then based on the static types, the
compiler will generate a double division and when you run the program,
z will end up having the double value 2.5.

Had I written:

double z = 5 / 2;

The value in z will be the double value 2.0. This is because the
left-hand-side of the assignment is a pure integer division, and the
compiler generates a truncating integer division followed by
conversion from integer to double (silent loss of precision again).

In Dart, all these versions behave the same:

double x = 5;
double y = 2;
double z = x / y;

int x = 5;
int y = 2;
double z = x / y;

num x = 5;
num y = 2;
num z = x / y;

var x = 5;
var y = 2;
var z = x / y;

double z = 5 / 2;

In each case, the value of z will be the double 2.5.

> Nowadays, programmers have to deal with different languages almost in
> a daily basis. Image what will happen if one of your less-experience
> members has to work at both server and client side? If he has to watch
> someone's video and remind himself when switching task for such a
> basic feature, there must be something wrong in the spec.

I think you assume that inexperienced programmers will find C
semantics intuitive. I don't agree with this assumption. I don't think
that C semantics are intuitive: all the way through the school system,
you have learned that 5 / 2 = 2.5. C and Java does not agree with what
you learned in grade school, and that is not intuitive.

> Sorry for strong wording. But, after programming in Java and JS for
> years, I believe Dart has a good chance. Most of differences are more
> or less like or dislike, but I'm afraid the integer issue will turn
> off a lot of people.

I think you raise a good point here: programmers with experience in C,
C++, Java, or C#, may find the Dart number semantics difficult to
understand.

On the other hand, I think that JavaScript programmers will have no
problems at all with the number semantics.

I assume that we will to do usability studies of these kinds of things.

Cheers,
Peter

[Charles Forsyth]

Computer languages often differ on this: for example Pascal, following the Algol languages, has / producing a real result, and special operators for the integer operations ("div" and "mod" in Pascal).

(Algol 60 had ÷ instead of "div": "a ÷ b = sign(a/b) entier(abs(a/b))" for the variant producing an integer.)

BCPL and thus B were languages with only a word data type (integer or pointer) so / as integer division made sense.

C inherited that because it was an incremental extension of B (more or less), and float/double were thus added in.

Also integer operations are far more common in C, so I suppose it made sense that way too.

B and BCPL did later acquire real arithmetic, but using special operators (#/ and #* in BCPL).

I thought Python had / as giving a real result, but I haven't checked that; but that's just to emphasise that I can't take it for granted either way.