issue 7006 - std.math.pow (integral, integral) crashes on negative exponents
timon.gehr at gmx.ch
Tue Dec 17 14:26:42 UTC 2019
On 17.12.19 14:39, Dominikus Dittes Scherkl wrote:
> On Tuesday, 17 December 2019 at 12:31:15 UTC, Timon Gehr wrote:
>>> I still don't understand
>>> why anybody want a function with signature
>>> int pow(int, int)
>> You are apparently not aware that std.math.pow is the implementation
>> of the built-in `^^` operator. Removing it is not even on the table,
>> it should just work correctly.
> Did I suggest to remove it? NO.
> But I'm of the opinion that having each internal operator returning the
> same type as the given types is not always useful.
> ^^ should result in a real if the exponent is outside ubyte range.
> Is this wrong?
> Am I crazy?
Probably not, but note that I am wasting hours of my finite life on what
should be a trivial issue with a trivial fix, so I hope you do
understand my slight frustration. This is not efficient.
>>> there are only two interesting cases:
>>> int pow(int, ubyte)
>>> > and
>>> complex pow(complex, complex)
>> Those cases already work fine, and they are off-topic.
> No, they do not work fine,
pow(int,ubyte) works. pow(complex,complex) works.
> because an implausible input range for the
> exponent is defined.
There are reasonable outputs for the entire range of each individual
> I still think this should be fixed.
I will argue against this and we will both lose some more time, but feel
free to open an enhancement request on bugzilla if you think it is worth it.
>> As I am stating for the third time now, there are x such that
>> `pow(x,int.max)` and/or `pow(x,int.min)` neither overflow nor cause
>> any rounding.
> Yes, the cases with x == -1, 0 or 1. And only them.
> Maybe it should be fixed for these cases, for those who insist to use
> the operator instead of some very fast bit-muggling if they need a
> toggling function.
I don't insist on doing that. I only insist on the function producing
correct outputs _when_ it is used. There is no reason to expect it not
to work. Also, "very fast bit-muggling" often just does not matter in
practice (especially because the compiler developers also know it), it
is more typing and it is less readable especially if there is some
analogous domain-specific notation.
>>> To make this more prominent for the user, I would only allow 8bit
>>> exponents anyway.
>> I am the user in question and I am not a moron. Thanks a lot.
> I didn't say that. Don't lay words into my mouth.
I didn't do that. In the context of the thread it is however reasonable
to interpret your statement as suggesting that I need hand-holding. This
is further reinforced by your statement about bit-muggling. (There is a
certain kind of smugness that is somewhat common with mediocre
programmers, and your statements will resonate with the afflicted, even
if you didn't intend them that way.)
>> This is such a trivial issue. This shouldn't be this hard.
> It's not hard. But there are a lot of cases where giving a negative
> exponent is NOT intended, and maybe it is a better idea to throw to
> indicate misuse instead of rounding away all information by returning 0?
I'd highly prefer it to consistently return 0 rather than kill my
program without a stack trace. However, I agree that this case is
slightly less clear-cut.
> (except for the three special cases where I already agreed treating them
> correct would be a win).
(After I repeated my explanation for the third time.)
More information about the Digitalmars-d