Hacker News Reader

Comment by kens | Hacker News Reader

I consider the debate over 0^0 to be easily solved with type signatures. If you consider the function pow(float, float), 0^0 should be undefined. If you consider the function pow(float, int), then 0^0 should be 1. The problem is that people view these two different power functions as a single function.

View on HN

Speaking as a mathamatician, and replacing "float" with "real number":

We really like like to pretend that the integers are a subset of the real numbers. As such, we really like to pretend that the function pow : real X int -> real is a restriction of the function pow : real X real -> real.

Speaking as a programmer, I really expect the effect of casting between numeric types is only precision.

If pow(0f,0) != pow (0f, 0f), then you break both of these assumptions.

Shouldn't the int version be enbedded in the float version? Shouldn't they agree for equal values?

That's the point. They are two independent functions so they don't need to agree.

Why do they agree everywhere else then?

I wouldn't say it's the type of numbers, rather whether they're constant.

(Const 0)^(var 0) is 0.

(Var 0)^(const 0) is 1.

(Const 0)^(const 0) is undefined.

(Var 0)^(var 0) is defined based on the functions that define those variables.

But isn’t the following expected to be true?

  pow(0.0f, 0.0f) == (float)pow(0, 0)

If one is defined then so should the other. (At least, for developers’ benefit.)

Which languages are you thinking of? I just checked Haskell and Python, and they both give 1 for both integer and floating-point exponentiation.

Reply on news.ycombinator.com