Jump to page: 1 2
Thread overview
Integer division.
Jan 21, 2003
Ilya Minkov
Jan 21, 2003
Carlos
Jan 21, 2003
Russell Lewis
Jan 21, 2003
Ilya Minkov
Jan 22, 2003
Sean L. Palmer
Jan 23, 2003
Russell Lewis
Jan 21, 2003
Ilya Minkov
Jan 23, 2003
Russell Lewis
Jan 23, 2003
Evan McClanahan
Jan 23, 2003
Daniel Yokomiso
Exponentiation operator
Jan 24, 2003
Sean L. Palmer
Exponentiation operator
Jan 24, 2003
Sean L. Palmer
Exponentiation operator (was: Integer division.)
Jan 24, 2003
Sean L. Palmer
Jan 24, 2003
Evan McClanahan
Jan 24, 2003
Ilya Minkov
Jan 24, 2003
Sean L. Palmer
Jan 24, 2003
Ilya Minkov
Jan 27, 2003
Ilya Minkov
Jan 22, 2003
Antti Sykari
Jan 22, 2003
Ilya Minkov
January 21, 2003
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.

January 21, 2003
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/


January 21, 2003
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.

January 21, 2003
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.

BTW, can anyone think of a better operator token for integer division than '\'? Maybe '$' or '#' or '§' or even '@' :>
Or maybe a composite token like '/.'? No, too confusing, but maybe someone would come up with a better combination.

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

-i.

January 21, 2003
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.

January 22, 2003
"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


January 22, 2003
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
January 22, 2003
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

January 23, 2003
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...

January 23, 2003
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...

« First   ‹ Prev
1 2