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=


 integers as input.

=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 than '\'? Maybe '$' or '#' or '=A7' or even ' ' :> 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

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.

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



 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


 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

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

 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" 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


 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


 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: \=A7$# : ',' 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

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.

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

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

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

 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=

 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