
Zero to the Power of Zero - known
https://en.wikipedia.org/wiki/Zero_to_the_power_of_zero
======
_nalply
After reading this I think a mathematically sound approach is to leave 0^0
undefined.

Then because of practicality define 0^0 = 1 accepting some weirdness around
0^0 (limits to 0^0 not being 1).

With "practicality" I mean for mathematicians the convenience for some
definitions, perhaps like this: "While we know that 0^0 is undefined, we
proceed with the definition 0^0 = 1, because in our domain the disconuity
doesn't matter [...]". This could be a footnote.

For programmers just let the pow() function(s) return 1.

It's a pity (or in a more positive way: spicy) that nature doesn't hold the
principle of the least surprise. It's something we can't or shouldn't fix.

~~~
lidHanteyk
I think that you are overcomplicating the underlying reasoning. Consider: How
many functions are there from the empty set to the empty set? One, right?

------
kens
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.

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

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

~~~
nine_k
Why do they agree everywhere else then?

------
murkle
Good referenced reasoning about it here
[https://www.nctm.org/tmf/dr.math/faq/faq.0.to.0.power.html](https://www.nctm.org/tmf/dr.math/faq/faq.0.to.0.power.html)

------
Koshkin
From the programmer’s standpoint, the reasoning goes like this. In C++, the
initial value you pass to std::accumulate depends on the operator. For
addition, 0 is the “natural” choice. For multiplication, it is 1. So, if you
raise a number to some power using this function, you implicitly or explicitly
start with 1. Followed by accumulation of the _zero_ number of 0s this leaves
you with 1.

~~~
nine_k
This logic is broken.

If you take 1 as the initial value, and run the operation n ≥ 1 times, the
initial value is used at least once.

But if you run the operation _zero times_ , the initial value is _never_ used,
so the result is undefined.

~~~
Koshkin
[https://en.cppreference.com/w/cpp/algorithm/accumulate](https://en.cppreference.com/w/cpp/algorithm/accumulate)

------
badrabbit
How is nothing multiplied nothing times 1? I feel dumb asking this,but, why is
it not 0 or NaN.

2^4 == 2 _2_ 2 _2 == 16

0^0 == 0_0 _0_ 0 == 0

Why is it not that simple?

~~~
gizmo686
Why should the answer be 0?

We have an intuition that 0 is the identity element for addition, so it makes
sense to treat it as the starting point for many things.

However, when we look at multiplication, 0 looks very different. Instead of
preserving the other value, as it does with addition, multiplying by 0 changes
the other value in an information destroying way (e.g if you know that x * 0 =
0, you have no idea what x is). This property of 0 is so distinct from the
other numbers, that when we consider the integers (or reals, or complex
numbers) as a structure that only has multiplication, but not addition, we
typically exclude 0 from consideration.

Since (discrete) exponentiation is a multiplicative process, it makes sense to
consider it in terms of the integers under multiplication; and so excluding 0.
When we consider integers under multiplication, we notice that 1 has the same
properties that 0 had under addition. Namely, 1 * x = x for all x. Given this,
it makes sense to treat 1 as the "empty" element, the same way you want to do
with 0 in additive contexts.

~~~
badrabbit
Thank you for the explanation, the reasoning sort of makes sense but I still
can't wrap my head around how on the left side of the equation there is
nothing(0) on the right hand there is something. Something cannot come out of
nothing when considering natural phenomena in reality.

------
Tainnor
This is one of the things most mathematicians usually don't care much about.
Unlike programming (or automated theorem proving), mathematics can tolerate
slight ambiguities that end up not mattering for the argument at hand, because
it's ultimately read by people who understand the context.

