4 ms·
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 conside
by kens 6y ago
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.
- lidHanteyk 6y agoWhich languages are you thinking of? I just checked Haskell and Python, and they both give 1 for both integer and floating-point exponentiation.
- karpierz 6y agoI 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.
- kadoban 6y agoShouldn't the int version be enbedded in the float version? Shouldn't they agree for equal values?
- Koshkin 6y agoBut 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.)
- gizmo686 6y agoSpeaking 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.