issue 7006 - std.math.pow (integral, integral) crashes on negative exponents

[Timon Gehr]

On 15.12.19 20:52, berni44 wrote:
> On Sunday, 15 December 2019 at 18:31:14 UTC, Timon Gehr wrote:
>> You didn't provide an explanation for closing the issue, so I assumed 
>> it was an accident.
> 
> I wrote something about the floating result stuff, which was meant as an 
> explanation. Sorry, if that wasn't clear.
> 
>> -1^^-1 leading to "division by zero" instead of the correct answer of 
>> -1 makes no sense at all.
> 
> I agree, that "division by zero" is not the best here. I guess, that the 
> original programmer wanted to avoid throwing an exception.
> ...

What I wanted you to agree to is that computing the correct result is 
the correct thing to do. Division by zero and throwing an exception both 
make no sense here.

>>> a) Result type integral: There is no usecase,
>>
>> Nonsense, e.g., (-1)^^i.
> 
> Yeah, but what do you want to do with that?

Arithmetic. (I think it I was solving some combinatorics task involving 
(-1)^^i, but it has been a few years and I don't remember specifics.) I 
wrote a correct program and instead of getting the correct answer I got 
a floating point exception. I then filed a bug report.

Anyway, do I really have to argue that arithmetic is useful, or that D 
should compute the correct result for arithmetic expressions? The whole 
line of reasoning where I am somehow required to justify my point of 
view just makes no sense to me. E.g., what's the use of 37637663*3 
evaluating to 112912989 ? You can't think of a concrete use off the top 
of your head? Well, then maybe that expression should cause a divide by 
zero error because it is obviously indicative of a bug if such a thing 
occurred in your program?

> If the base is something 
> other than -1, 0 or 1 the result is a fraction, which cannot be 
> represented by an integral type. What should be the outcome of the 
> function in that case?
> ...

Ideally 0, but that's mostly about consistency with integer division. I 
hope we can all agree that there is really no justification for not 
computing the correct result if it actually fits into the return type.

>... I'm just not sure, if this is the best alternative...

What's in Phobos now is plain broken and that's why the bug report exists.

> 
> I'll file a PR with that and we'll see, what the reviewers will say.
> 

Thanks.