www.digitalmars.com         C & C++   DMDScript  

D - Integer division.

reply Ilya Minkov <midiclub 8ung.at> writes:
Walter, please add a new operator!

I think '\' could make an appropriate integer division operator. '/' 
should always return a result of floating-point division, even taken 2 
integers as input.

You have already added a new operator for concatentation. It surprised 
me at first, but i see that it makes sense.

Look, integer division always returns a result which is *not consistent* 
with floating-point division by definition, unlike addition, 
subtraction, and multiplication, which generally (that is theoretically) 
are. It *is* a source of bugs, even if not a major one. And '\' operator 
is not taken in D, since line splicing is not there anymore.

Adding it would allow to mix integer and FP operations more freely and 
in a natural manner, with no casts in the middle. And cast is always a 
couple of parenthsis, or even several, always a legibility hamper for 
expressions. Other languages (Wirth family) also have 3 division 
operators: '/', 'div' and 'mod', which would become '/', '\', '%' 
respectively.

It would make the programmer make a conscious decision, whether he wants 
to preserve the FP part but change the type, or to truncate the number 
and get an integer, by writing a cast or truncation around the 
expression. Once he has not thought about that, he gets a compiler error 
of type mismatch.

Please consider: it would in no case requiere more casts, and in most 
cases less.

It would only be another consequent step in making the language more 
robust. You have already decided to make keyworded casts, and got enough 
incompatibility with C that something would prevent you from addding it.

It would become of even more importance, if tuples and simplified 
imlicit types ever make it into the language. But then it might be too late.

Best Regards,
-i.
Jan 21 2003
next sibling parent "Carlos" <carlos8294 msn.com> writes:
Mainly because of my Basic past, I wholeheartly (sp?) support that... Ok,
maybe that's a bit too much... ;)

"Ilya Minkov" <midiclub 8ung.at> escribió en el mensaje
news:b0k85f$mo$1 digitaldaemon.com...
| Walter, please add a new operator!
|
| I think '\' could make an appropriate integer division operator. '/'
| should always return a result of floating-point division, even taken 2
| integers as input.
|
| You have already added a new operator for concatentation. It surprised
| me at first, but i see that it makes sense.
|
| Look, integer division always returns a result which is *not consistent*
| with floating-point division by definition, unlike addition,
| subtraction, and multiplication, which generally (that is theoretically)
| are. It *is* a source of bugs, even if not a major one. And '\' operator
| is not taken in D, since line splicing is not there anymore.
|
| Adding it would allow to mix integer and FP operations more freely and
| in a natural manner, with no casts in the middle. And cast is always a
| couple of parenthsis, or even several, always a legibility hamper for
| expressions. Other languages (Wirth family) also have 3 division
| operators: '/', 'div' and 'mod', which would become '/', '\', '%'
| respectively.
|
| It would make the programmer make a conscious decision, whether he wants
| to preserve the FP part but change the type, or to truncate the number
| and get an integer, by writing a cast or truncation around the
| expression. Once he has not thought about that, he gets a compiler error
| of type mismatch.
|
| Please consider: it would in no case requiere more casts, and in most
| cases less.
|
| It would only be another consequent step in making the language more
| robust. You have already decided to make keyworded casts, and got enough
| incompatibility with C that something would prevent you from addding it.
|
| It would become of even more importance, if tuples and simplified
| imlicit types ever make it into the language. But then it might be too
late.
|
| Best Regards,
| -i.
|

-------------------------
Carlos Santander
http://carlos3.netfirms.com/
Mainly because of my Basic past, I wholeheartly (sp?) support that... Ok,
maybe that's a bit too much... ;)

"Ilya Minkov" <midiclub 8ung.at> escribió en el mensaje
news:b0k85f$mo$1 digitaldaemon.com...
| Walter, please add a new operator!
|
| I think '\' could make an appropriate integer division operator. '/'
| should always return a result of floating-point division, even taken 2
| integers as input.
|
| You have already added a new operator for concatentation. It surprised
| me at first, but i see that it makes sense.
|
| Look, integer division always returns a result which is *not consistent*
| with floating-point division by definition, unlike addition,
| subtraction, and multiplication, which generally (that is theoretically)
| are. It *is* a source of bugs, even if not a major one. And '\' operator
| is not taken in D, since line splicing is not there anymore.
|
| Adding it would allow to mix integer and FP operations more freely and
| in a natural manner, with no casts in the middle. And cast is always a
| couple of parenthsis, or even several, always a legibility hamper for
| expressions. Other languages (Wirth family) also have 3 division
| operators: '/', 'div' and 'mod', which would become '/', '\', '%'
| respectively.
|
| It would make the programmer make a conscious decision, whether he wants
| to preserve the FP part but change the type, or to truncate the number
| and get an integer, by writing a cast or truncation around the
| expression. Once he has not thought about that, he gets a compiler error
| of type mismatch.
|
| Please consider: it would in no case requiere more casts, and in most
| cases less.
|
| It would only be another consequent step in making the language more
| robust. You have already decided to make keyworded casts, and got enough
| incompatibility with C that something would prevent you from addding it.
|
| It would become of even more importance, if tuples and simplified
| imlicit types ever make it into the language. But then it might be too
late.
|
| Best Regards,
| -i.
|

-------------------------
Carlos Santander
http://carlos3.netfirms.com/
Jan 21 2003
prev sibling next sibling parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Ilya Minkov wrote:

 Walter, please add a new operator!
 
 I think '\' could make an appropriate integer division operator. '/' 
 should always return a result of floating-point division, even taken 2 
 integers as input.


It's a good idea, although I would say it should go the other way 
around.  Leave '/' for old-style C division; use '\' for auto-float 
division.

Of course, I know already that some people will argue about which 
floating point type the auto-cast should be to; I don't have an answer 
for that.
Jan 21 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Russell Lewis wrote:

 Ilya Minkov wrote:
=20

 Walter, please add a new operator!

 I think '\' could make an appropriate integer division operator. '/'=20
 should always return a result of floating-point division, even taken 2=




=20

 integers as input.


=20
=20
 It's a good idea, although I would say it should go the other way=20
 around.  Leave '/' for old-style C division; use '\' for auto-float=20
 division.


And how about "standard" float? In the sense of consistency, a division=20
returning FP has to be the same for either type. And I would prefer not=20
to break working FP code, where it makes no sense. Besides, inverting=20
the system breaks the whole fragile but beautiful idea of it. It=20
wouldn't prevent any bugs this way, but create new.

IMO, "integer division" is not an actual division. If you divide 2=20
apples by 4 parts, you don't get zeroes. You get halves. It also=20
corresponds to design of other languages.

BTW, can anyone think of a better operator token for integer division=20

Or maybe a composite token like '/.'? No, too confusing, but maybe=20
someone would come up with a better combination.


=20
 Of course, I know already that some people will argue about which=20
 floating point type the auto-cast should be to; I don't have an answer =



 for that.
=20


Extended, of course, because it's the format of FP machine registers. It =

  would get downcasted on the exit out of the function, or at assignment =

to a typed FP. I bet this would also be Walter's decision. All=20
well-known compilers follow this same convention.

-i.
Jan 21 2003
next sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b0kc41$3bl$1 digitaldaemon.com...

 Of course, I know already that some people will argue about which
 floating point type the auto-cast should be to; I don't have an answer
 for that.


Extended, of course, because it's the format of FP machine registers. It
  would get downcasted on the exit out of the function, or at assignment
to a typed FP. I bet this would also be Walter's decision. All
well-known compilers follow this same convention.


Don't be so quick to mandate extended.  Not all machines have extended (or
even double) precision.  The PS2's Vector Units, for example, only support
single precision.

It'd be nice if the compiler could look at the type of the result and use
that.  But implicit typing doesn't seem to have a strong following here.

Sean
Jan 22 2003
prev sibling parent Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Ilya Minkov wrote:

 Russell Lewis wrote:
 

 Ilya Minkov wrote:


 Walter, please add a new operator!

 I think '\' could make an appropriate integer division operator. '/' 
 should always return a result of floating-point division, even taken 
 2 integers as input.


 It's a good idea, although I would say it should go the other way 
 around.  Leave '/' for old-style C division; use '\' for auto-float 
 division.


 
 
 And how about "standard" float? In the sense of consistency, a division 
 returning FP has to be the same for either type. And I would prefer not 
 to break working FP code, where it makes no sense. Besides, inverting 
 the system breaks the whole fragile but beautiful idea of it. It 
 wouldn't prevent any bugs this way, but create new.
 
 IMO, "integer division" is not an actual division. If you divide 2 
 apples by 4 parts, you don't get zeroes. You get halves. It also 
 corresponds to design of other languages.


What "you get" varies based on perspective.  I think that most 4th 
graders would say that 2/4 gives you 0 remainder 2...
Jan 23 2003
prev sibling next sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Ilya Minkov wrote:

 Walter, please add a new operator!
 


One more. D doesn't seem to have a "power of" operator. Would '**' be OK?

BTW, OCaml defines a set of symbols, of which operator tokens can be 
constructed, to which belong /*-+<>| for example. What do you think, 
overloadable operators which consist of a free combination of a certain 
set of characters?

'//' would make a good integer division, if it just wasn't already a 
comment!

-i.
Jan 21 2003
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Ilya Minkov wrote:

 Ilya Minkov wrote:
 

 Walter, please add a new operator!


 
 One more. D doesn't seem to have a "power of" operator. Would '**' be OK?
 
 BTW, OCaml defines a set of symbols, of which operator tokens can be 
 constructed, to which belong /*-+<>| for example. What do you think, 
 overloadable operators which consist of a free combination of a certain 
 set of characters?
 
 '//' would make a good integer division, if it just wasn't already a 
 comment!
 
 -i.
 


A "power of" operator would be a very good idea, but we need to stay 
away from **, IMHO.  The expression:

	a ** b

would then have to be interpreted as "a to the power of b" even though 
people coming from C would say that b was a pointer being dereferenced...
Jan 23 2003
next sibling parent reply Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
Russell Lewis wrote:

 Ilya Minkov wrote:
 

 Ilya Minkov wrote:


 Walter, please add a new operator!


 One more. D doesn't seem to have a "power of" operator. Would '**' be OK?

 BTW, OCaml defines a set of symbols, of which operator tokens can be 
 constructed, to which belong /*-+<>| for example. What do you think, 
 overloadable operators which consist of a free combination of a 
 certain set of characters?

 '//' would make a good integer division, if it just wasn't already a 
 comment!

 -i.


 
 A "power of" operator would be a very good idea, but we need to stay 
 away from **, IMHO.  The expression:
 
     a ** b
 
 would then have to be interpreted as "a to the power of b" even though 
 people coming from C would say that b was a pointer being dereferenced...


I've always used ^ informally. ^ or ^^ would get my vote, but there 
doesn't seem to me to be all that much reason for it, unless the 
compiler can use intrinsics to speed it up a lot more than a library 
function.

Evan
Jan 23 2003
next sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Evan McClanahan" <evan dontSPAMaltarinteractive.com> escreveu na mensagem
news:b0p2ab$2p7f$1 digitaldaemon.com...

 Russell Lewis wrote:

 Ilya Minkov wrote:


 Ilya Minkov wrote:


 Walter, please add a new operator!


 One more. D doesn't seem to have a "power of" operator. Would '**' be






OK?

 BTW, OCaml defines a set of symbols, of which operator tokens can be
 constructed, to which belong /*-+<>| for example. What do you think,
 overloadable operators which consist of a free combination of a
 certain set of characters?

 '//' would make a good integer division, if it just wasn't already a
 comment!

 -i.


 A "power of" operator would be a very good idea, but we need to stay
 away from **, IMHO.  The expression:

     a ** b

 would then have to be interpreted as "a to the power of b" even though
 people coming from C would say that b was a pointer being




dereferenced...

 I've always used ^ informally. ^ or ^^ would get my vote, but there
 doesn't seem to me to be all that much reason for it, unless the
 compiler can use intrinsics to speed it up a lot more than a library
 function.

 Evan


Defining a "pow" operator would be good for writing templates. Also it would
be a operator available for overloading. A library function can't be
properly dispatched in templates without using type specialization tricks.
But IMO the "pow" operator should be defined for floats, so we can write "2
^ 2" and "16 ^ 0.5" without problems.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 10/1/2003
Jan 23 2003
parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
^ is already XOR.  You could accidentally write 2^2 thinking it'll be 4, but
it'll produce 0.

2^^2 is unambiguous.

We need to be able to overload this because complex and quaternion can be
raised to powers;  they have exp and ln defined for them.  Ok, so we could
just overload pow(quat,float) and pow(complex,float) instead.  But I
wouldn't mind having another operator or seven.  ;)  Need a few more with
higher precedence than multiply, but lower precedence than exponentiation,
so we can overload an operator for dot and cross product (aka inner and
outer product).

Sean

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b0purq$948$1 digitaldaemon.com...

 Defining a "pow" operator would be good for writing templates. Also it


would

 be a operator available for overloading. A library function can't be
 properly dispatched in templates without using type specialization tricks.
 But IMO the "pow" operator should be defined for floats, so we can write


"2

 ^ 2" and "16 ^ 0.5" without problems.
Jan 23 2003
prev sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
When applied to constants it could be computed at compile time.  It should
at very least be an intrinsic, if not an actual operator.

Sean

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
news:b0p2ab$2p7f$1 digitaldaemon.com...


 would then have to be interpreted as "a to the power of b" even though
 people coming from C would say that b was a pointer being




dereferenced...

 I've always used ^ informally. ^ or ^^ would get my vote, but there
 doesn't seem to me to be all that much reason for it, unless the
 compiler can use intrinsics to speed it up a lot more than a library
 function.

 Evan
Jan 23 2003
prev sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
^ is also already spoken for, but ^^ would work.  Unless someone wants to
introduce a logical XOR, which does in fact have a certain amount of
support.

a ^^ b;   // a raised to the b'th power

Maybe back quote?

a ` b;

nah, looks wierd.  Anyone?

Sean

"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3E30085D.7090002 deming-os.org...

 Ilya Minkov wrote:

 Ilya Minkov wrote:


 Walter, please add a new operator!


 One more. D doesn't seem to have a "power of" operator. Would '**' be




OK?

 BTW, OCaml defines a set of symbols, of which operator tokens can be
 constructed, to which belong /*-+<>| for example. What do you think,
 overloadable operators which consist of a free combination of a certain
 set of characters?

 '//' would make a good integer division, if it just wasn't already a
 comment!

 -i.


 A "power of" operator would be a very good idea, but we need to stay
 away from **, IMHO.  The expression:

 a ** b

 would then have to be interpreted as "a to the power of b" even though
 people coming from C would say that b was a pointer being dereferenced...
Jan 23 2003
next sibling parent Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
Sean L. Palmer wrote:

 ^ is also already spoken for, but ^^ would work.  Unless someone wants to
 introduce a logical XOR, which does in fact have a certain amount of
 support.
 
 a ^^ b;   // a raised to the b'th power
 
 Maybe back quote?
 
 a ` b;
 
 nah, looks wierd.  Anyone?


right!  forgot about xor...  Someone mentioned ^^ could be logical xor, 
but I think that exponentiantion would be used more often for most 
people than logical xor (which can be worked around with the standard 
notation in any case).  I would support ^^ more readily than any of the 
other notations that I can think of.

Evan
Jan 24 2003
prev sibling next sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Sean L. Palmer wrote:

 a ` b;
=20
 nah, looks wierd.  Anyone?


I'm not sure all keyboard layouts allow you to type it. Is it a part of=20
original "one step for a man, a leap for a mankind" ASCII?

Let's take a look a the keyboard. These seem to be untaken, if i=20
remember right:



',' and '?' are taken, but i question them.

-i.
Jan 24 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message


news:b0rkpc$1493$1 digitaldaemon.com...

Sean L. Palmer wrote:
 a ` b;

 nah, looks wierd.  Anyone?





I'm not sure all keyboard layouts allow you to type it. Is it a part of
original "one step for a man, a leap for a mankind" ASCII?


Yes, it is.  Right before lowercase 'a'.  It may not be on all keyboards
though.


Let's take a look a the keyboard. These seem to be untaken, if i
remember right:






That's a foreign keyboard.  In the US we don't have the '§' key.


 ',' and '?' are taken, but i question them.


Comma seems necessary.  The comma operator seems fraught with potential for
obscurity.  I never found a real legitimate use for it except during
operator overloading, you can use it to construct lists.  Which is opposite
of its natural use in the C language.  I'd rather ',' always form lists of
things, the way it does in a parameter list.

?:  is useful.  So useful in fact that one starts to wonder if we really
need that pesky longwinded 'if' keyword at all.  ;)

Sean
Jan 24 2003
parent Ilya Minkov <midiclub 8ung.at> writes:
Sean L. Palmer wrote:

 That's a foreign keyboard.  In the US we don't have the '=A7' key.


Urrr ignorrand ammerrrikanzzzz! :>
There are thousands of ways to identify me as not being american. My=20
broken language, the e-mail adress, and so on. I have never been=20
identified as not being an american by a keyboard though. One can also=20
identify me as being non-german and non-austrian and and non-finnish=20
non-noone-knows what. Although i doubt the last. But i'm pretty much=20
sure i'm european since else i'd probably love C and hate Pascal.

It's a german keyboard. All 3 of mine have mutated to german lately. A=20
look at the US keyboard has approved that it's not there. Well, who=20
wants no law, needs no paragraph sign. :>


',' and '?' are taken, but i question them.


=20
 Comma seems necessary.  The comma operator seems fraught with potential=


 for

 obscurity.  I never found a real legitimate use for it except during
 operator overloading, you can use it to construct lists.  Which is oppo=


site

 of its natural use in the C language.  I'd rather ',' always form lists=


 of

 things, the way it does in a parameter list.


Right, parameter lists. I couldn't understand before, why the function=20
parameters are separated with ',', and struct members with ';'? Why are=20
these enclosed () and these in {}?

Why do the uses of "()" vs.  "{}" and ',' vs. ';' have to be so subtly=20
different? Here this, there that. Cook the soup after the most stupid=20
recipy.

But what is the (expession1, expression2, expression3) comma operator=20
for? I think it primarily has a value in conjunction with a=20
preprocessor, which is now gone. For reason.

The result of a comma extression is assigned to another expression, or=20
used in expressions. Why can't you write:

int param1 =3D { expression1; espression2; expression3}

This would make expressions-in-expression more legible, also allowing=20
some parenthesis to alternate:

(1+{({x+1}*2)+1}*3)

And why can't:

struct SomeStruct (
	Mem1: int,
	Mem2: float
)

??? puzzle!

I still catch myself at finding out that "for(,,){}" is not exactly corre=
ct.



 ?:  is useful.  So useful in fact that one starts to wonder if we reall=


y

 need that pesky longwinded 'if' keyword at all.  ;)


Right. But Pascal feels OK without it. It contacts code in rare cases,=20
doesn't make it more readable though. And it uses up that ':' too! Grr.
Jan 24 2003
prev sibling parent Ilya Minkov <midiclub tiscali.de> writes:
Sean L. Palmer wrote:

 Maybe back quote?
 
 a ` b;
 
 nah, looks wierd.  Anyone?


I now start to think that a tick "`" should be on every keyboard. Some 
languages, notably Lisp and Tick C make use of it. But maybe it should 
be kept for the same purpose as in these languages: dynamic code generation.

-i.
Jan 27 2003
prev sibling parent reply Antti Sykari <jsykari gamma.hut.fi> writes:
Ilya Minkov <midiclub 8ung.at> writes:


 Walter, please add a new operator!


I'd gladly welcome "div" for integer division, and it already fits the
bill in Pascal.

In C99, "div" returns a div_t structure which contains the quotient
and the remainder.  Which will both be produced by most sane processor
architectures as a result of a single division anyway.  If multiple
return values were allowed, D could do the same more naturally.

-Antti
Jan 22 2003
parent Ilya Minkov <midiclub 8ung.at> writes:
Antti Sykari wrote:

 Ilya Minkov <midiclub 8ung.at> writes:
 
 

Walter, please add a new operator!


 
 
 I'd gladly welcome "div" for integer division, and it already fits the
 bill in Pascal.
 
 In C99, "div" returns a div_t structure which contains the quotient


infix ?????


 and the remainder.  Which will both be produced by most sane processor
 architectures as a result of a single division anyway.  If multiple
 return values were allowed, D could do the same more naturally.


Any sane syntax for multiple return values, which would allow 
selectivity middle in the expression without driving crazy?


 
 -Antti
Jan 22 2003