On Sunday, 14 April 2019 at 13:19:22 UTC, lithium iodate wrote:
> I personally would expect bitwise operations to operate on the underlying bit pattern instead of its two's-complement equivalent representation.

Aren't those the same thing?

On Sunday, 14 April 2019 at 13:23:27 UTC, Adam D. Ruppe wrote:
> On Sunday, 14 April 2019 at 13:19:22 UTC, lithium iodate wrote:
>> I personally would expect bitwise operations to operate on the underlying bit pattern instead of its two's-complement equivalent representation.
>
> Aren't those the same thing?

For the inbuilt integral types? Sure. For custom integral types? Not necessarily.
When dealing with protocols and compression you might get into the situation of defining an integer with some special coding as internal representation.

On Sunday, 14 April 2019 at 13:28:13 UTC, lithium iodate wrote:
> On Sunday, 14 April 2019 at 13:23:27 UTC, Adam D. Ruppe wrote:
>> On Sunday, 14 April 2019 at 13:19:22 UTC, lithium iodate wrote:
>>> I personally would expect bitwise operations to operate on the underlying bit pattern instead of its two's-complement equivalent representation.
>>
>> Aren't those the same thing?
>
> For the inbuilt integral types? Sure. For custom integral types? Not necessarily.
> When dealing with protocols and compression you might get into the situation of defining an integer with some special coding as internal representation.

How would adding isOdd to phobos change this?

On Sunday, 14 April 2019 at 15:01:22 UTC, Julian wrote:
> On Sunday, 14 April 2019 at 13:28:13 UTC, lithium iodate wrote:
>> On Sunday, 14 April 2019 at 13:23:27 UTC, Adam D. Ruppe wrote:
>>> On Sunday, 14 April 2019 at 13:19:22 UTC, lithium iodate wrote:
>>>> I personally would expect bitwise operations to operate on the underlying bit pattern instead of its two's-complement equivalent representation.
>>>
>>> Aren't those the same thing?
>>
>> For the inbuilt integral types? Sure. For custom integral types? Not necessarily.
>> When dealing with protocols and compression you might get into the situation of defining an integer with some special coding as internal representation.
>
> How would adding isOdd to phobos change this?

By selecting suitable treatment for the given type:
   inbuilt integer -> &1 (or whatever)
   does it provide a isOdd function? -> call isOdd of that type
   perhaps it somehow declared that oddity can't be determined -> fail fast and loud
   else try %2 != 0
   else fail fast and loud
none of which include making possibly incorrect assumptions about its representation.

On 4/14/2019 5:58 AM, Timon Gehr wrote:
> It is not possible to require specific values as function arguments in template constraints.

I believe it is if you use the "template expression" technique popularized in C++. Even if not, or if you understandably don't care for expression templates (I don't, either), you can overload based on the right operand being an int, and then special case it with a runtime test for '1'.

That test won't add significantly to the runtime if you've represented the integer as a series of primes and exponents.

> It should return `false` for every input that is not an integer.

Of course, the compiler will give an error for (f & 1), so the user will have an opportunity to decide what to do about it and if his algorithm makes any sense with odd floating point values, which it likely wouldn't. He then can write his own isOdd() function as necessary. We don't need to do it for him, and are not likely providing a useful service even if we did.

On 4/14/2019 5:13 AM, Timon Gehr wrote:
>> BTW, did you know that Phobos used to contain secant() and cosecant() functions? I removed them :-)
> 
> That seems like a bad idea even assuming your criteria. `sec(x)` rounds once (if implemented correctly) while `1/cos(x)` rounds twice.

Of course, they were implemented simply as reciprocals.


> Phobos also contains `sin` and `cos` functions. Please don't remove either of them.

Not likely. Those functions are rather difficult to implement correctly, and so are perfect candidates for library functions. Even as recently as just 5 years ago, some C compilers got them wrong. (The D phobos test suite would fail on them.)

Phobos was pretty much forced to provide its own implementations of many math functions because of erratic behavior of many C compiler library versions. It turns out that being good at writing compilers has no relevance to competence at the intricacies of implementing math functions :-)

On 15.04.19 09:44, Walter Bright wrote:
> On 4/14/2019 5:13 AM, Timon Gehr wrote:
>>> BTW, did you know that Phobos used to contain secant() and cosecant() functions? I removed them :-)
>>
>> That seems like a bad idea even assuming your criteria. `sec(x)` rounds once (if implemented correctly) while `1/cos(x)` rounds twice.
> 
> Of course, they were implemented simply as reciprocals.
> ...

Then they were incorrect and removing them was reasonable. But of course, in this case this anecdote has no bearing on the current discussion: you removed them (instead of fixing them), because they were too hard to implement, not because they were too easy to implement. :)

On 15.04.19 09:36, Walter Bright wrote:
> On 4/14/2019 5:58 AM, Timon Gehr wrote:
>> It is not possible to require specific values as function arguments in template constraints.
> 
> I believe it is if you use the "template expression" technique popularized in C++. Even if not,

It's not possible.

> or if you understandably don't care for expression templates (I don't, either), you can overload based on the right operand being an int, and then special case it with a runtime test for '1'.
> 
> That test won't add significantly to the runtime if you've represented the integer as a series of primes and exponents.
> ..
It would be ridiculous though. What do you suggest happens if the runtime check fails?

>  > It should return `false` for every input that is not an integer.
> 
> Of course, the compiler will give an error for (f & 1), so the user will have an opportunity to decide what to do about it and if his algorithm makes any sense with odd floating point values, which it likely wouldn't. He then can write his own isOdd() function as necessary. We don't need to do it for him, and are not likely providing a useful service even if we did.

That's basically what I wrote earlier in the same post. I then proceeded to answer your question anyway, showing that the behaviour of isOdd(infinity) is actually clear. isOdd(infinity), if it compiles at all, should return false.

(There may be some miscommunication going on. I believe this has happened a few times in the past as well. Sometimes, I explicitly agree with your conclusion, but I don't agree with your argumentation. You then seem to wrongly assume that I disagree with the conclusion, from which you conclude that I am wrong and my arguments do not matter.)

On 4/15/2019 5:54 AM, Timon Gehr wrote:
> Then they were incorrect and removing them was reasonable. But of course, in this case this anecdote has no bearing on the current discussion: you removed them (instead of fixing them), because they were too hard to implement, not because they were too easy to implement. :)

I removed them because they were implemented as trivia, and hence offered no value. (Yes, that is not just a reformulation of the reason you gave.)

If they were implemented in such a way as to offer value that 1/sin did not, then I would have considered retaining them.

On Mon, Apr 15, 2019 at 01:15:07PM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/15/2019 5:54 AM, Timon Gehr wrote:
> > Then they were incorrect and removing them was reasonable. But of course, in this case this anecdote has no bearing on the current discussion: you removed them (instead of fixing them), because they were too hard to implement, not because they were too easy to implement. :)
> 
> I removed them because they were implemented as trivia, and hence offered no value. (Yes, that is not just a reformulation of the reason you gave.)
> 
> If they were implemented in such a way as to offer value that 1/sin did not, then I would have considered retaining them.

Didn't he just say that 1/sin gives different rounding behaviour from a correct, direct implementation of csc?


T

-- 
Don't throw out the baby with the bathwater. Use your hands...