www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: integer division with float result

reply Stas Sergeev <stsp aknet.ru> writes:
Bill Baxter Wrote:

 Comparing with dynamically typed languages like Python isn't useful
 because in Python a/2 can return an integer for if a==4 a float if a==5.
   A statically typed language like D doesn't have that luxury.



just always return float, or is there?


 Anyway, that said, I think it'd be nice to have / do float division, and 
 introduce another operator (like python's //) for truncated integer 
 division.



You either write:
int c = a / b;
or:
float c = a / b;
Both seem to perfectly express the intention, so
what is the new operator may be good for?
Currently, the later expression simply makes no
sense. I don't even think it is present in some code.
So I don't think there will be any confusion or the
compatibility breakage even.
Nov 18 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Stas Sergeev wrote:

 Bill Baxter Wrote:

 Comparing with dynamically typed languages like Python isn't useful
 because in Python a/2 can return an integer for if a==4 a float if a==5.
   A statically typed language like D doesn't have that luxury.



 just always return float, or is there?
 

 Anyway, that said, I think it'd be nice to have / do float division, and 
 introduce another operator (like python's //) for truncated integer 
 division.



 You either write:
 int c = a / b;
 or:
 float c = a / b;
 Both seem to perfectly express the intention, so
 what is the new operator may be good for?



Which flavor of division is being used here?

void do_something(int x) { ... }
void do_something(float x) { ... }

do_something(a/b);

--bb
Nov 18 2007
prev sibling parent reply Lars Noschinski <lars-2006-1 usenet.noschinski.de> writes:
* Stas Sergeev <stsp aknet.ru> [07-11-19 06:46]:

Bill Baxter Wrote:

 Comparing with dynamically typed languages like Python isn't useful
 because in Python a/2 can return an integer for if a==4 a float if a==5.
   A statically typed language like D doesn't have that luxury.



just always return float, or is there?



Efficiency and accuracy. An integer division is faster than a float
division. Also, not all integer values can be represented exactly as
floats.
Nov 19 2007
next sibling parent reply Stas Sergeev <stsp aknet.ru> writes:
Lars Noschinski Wrote:

Of course, but there is no problem to make the / op to
just always return float, or is there?



 division.



to know the result type beforehand, is it not? It then
can decide whether it needs the float calculations or not.
And in a more complex cases, the one can hint the compiler
to not use float calculation by explicit casts to int, like this:
int a = (int)(b / c) * 500;
This expression can still be compiled without the fp math.
And the cast is not redundant here as it truncates the value,
and the programmer always knows when he needs to truncate
the value in his expression. He is unlikely to forget such a cast.
While currently the casts like this:
float a = (b / (float)c) * 500;
are used only to tell the compiler about the desired type, and
the programmer can easily forget to put one.
Nov 19 2007
parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Stas Sergeev wrote:

 But isn't it just an optimization issue? The compiler is supposed
 to know the result type beforehand, is it not?



No, exactly that is the problem: The compiler knows the result type
only in some cases, as has been said twice now already.


 And in a more complex cases, the one can hint the compiler
 to not use float calculation by explicit casts to int, like this:
 int a = (int)(b / c) * 500;
 This expression can still be compiled without the fp math.
 And the cast is not redundant here as it truncates the value,
 and the programmer always knows when he needs to truncate
 the value in his expression. He is unlikely to forget such a cast.
 While currently the casts like this:
 float a = (b / (float)c) * 500;
 are used only to tell the compiler about the desired type, and
 the programmer can easily forget to put one.



That tradeoff can be made. Some people might be more happy then.
Some will be less happy. A lot of work will have been caused for
little gain.
Also: We have all understood your point. Some think the same as you,
some different. As it's a matter of tastes, you won't achieve much
more if you keep pressing it. This is not like wooing a woman, where
you get extra points for perseverance.

Regards, frank
Nov 19 2007
parent reply Stas Sergeev <stsp aknet.ru> writes:
0ffh Wrote:

 Also: We have all understood your point. Some think the same as you,
 some different. As it's a matter of tastes, you won't achieve much
 more if you keep pressing it.



The guy said that the efficiency is the problem,
and I said that I don't think so (perhaps I was wrong,
but where is the pressure?).
As for not reading the entire thread - very probably.
For some reasons the thread got "split". The fragments
that  I've found quickly, I've looked through, the others
got slipped. :) (but search seems to help now)
Nov 19 2007
parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Stas Sergeev wrote:

 0ffh Wrote:

 Also: We have all understood your point. Some think the same as you,
 some different. As it's a matter of tastes, you won't achieve much
 more if you keep pressing it.






Maybe not, conceded.


 The guy said that the efficiency is the problem,
 and I said that I don't think so (perhaps I was wrong,
 but where is the pressure?).
 As for not reading the entire thread - very probably.
 For some reasons the thread got "split". The fragments
 that  I've found quickly, I've looked through, the others
 got slipped. :) (but search seems to help now)



It's just that I can't stand the long threads which are usually
caused when people try to argue about things which boil down to
a mere matter of preference. Those disagreements cannot, and so
will not, be resolved with technical (or any other) arguments.
Even if one of the possibilities were really objectively better
that doesn't help much unless it's by a rather wide margin.
The less difference it makes, the more unlikely it is that it's
convincing, the longer and more painful it all gets.
I just wanted to stop this short... =)

Now to something completely different: The efficiency thing.

If I make returning floats the default for integer division
then it will make actual integer division slow (three casts
and the float division) unless you have the compiler do type
inference. Type inference is not always possible. That means
we still need casts (only in different places now) plus extra
logic in the compiler to achieve nothing more than changing
to a different default behaviour, which is a matter of taste.
Q.E.D.

regards, frank
Nov 19 2007
parent 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
0ffh wrote:

 then it will make actual integer division slow (three casts
 and the float division) unless you have the compiler do type



Hrmm, probably int division and two casts would suffice, which
might be reduced by the optimiser to just the division. Still,
this works only for for some cases and does not invalidate the
overall argument (bit like some kind of type inference through
the back door, with the same weakness).

regards, frank
Nov 19 2007
prev sibling parent reply Matti Niemenmaa <see_signature for.real.address> writes:
Lars Noschinski wrote:

 An integer division is faster than a float division.



This actually isn't the case on Pentium 4, at least.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Nov 20 2007
parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Matti Niemenmaa wrote:

 Lars Noschinski wrote:

 An integer division is faster than a float division.



 This actually isn't the case on Pentium 4, at least.



Even if fdiv takes as many cycles as idiv, you'll still
have to add the time needed for the necessary casts.

regards, frank
Nov 20 2007
parent Matti Niemenmaa <see_signature for.real.address> writes:
0ffh wrote:

 Even if fdiv takes as many cycles as idiv, you'll still
 have to add the time needed for the necessary casts.



True, there's some setup involved. I didn't check the code generated to get the
exact values, but on the Pentium 4, for instance, the FDIV instruction actually
takes some 5-10 cycles _less_ than the DIV/IDIV instruction. (If anybody wants
to research, see http://www.agner.org/optimize/instruction_tables.pdf )

Just pointing something out. Lars's point about accuracy is more relevant than
efficiency, anyway.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Nov 20 2007