Write differentce of reduction functions

[unnonouno]

I wrote difference of reduction functions in the document.

[niboshi]

You are using the term scalar value in two different meanings.
The first use is NumPy's scalar, e.g. numpy.int64, whereas the others mean Python's scalar values e.g. int, right?

Essentially we could implement cupy.int64 which is the GPU counterpart of numpy.int64 (not an alias of numpy.int64 as currently is). The problem is that we don't have it. So, maybe you'd better explain why we don't?

[unnonouno]

Ah, We can make cupy.int64 as a scalar value allocated on GPU. Do we need to make such a type?

[niboshi]

Ah, We can make cupy.int64 as a scalar value allocated on GPU. Do we need to make such a type?

@okuta Do you have any idea?

[okuta]

Sometimes, NumPy scalar type cause miracle problem.
We can use cupy.array(1, numpy.int32). Is it not enough?

[unnonouno]

You mean, NumPy scalar behaves inconsistently, and it is not reasonable to make CuPy scalar type which behaves like Numpy Scalar, right?

[unnonouno]

I updated it. How about this?

[okuta]

Yes, I agree your opinion.

And, document of this PR is good. Can I merge this?

[niboshi]

Content looks good, but i feel it could be grammatically improved.
How about this?

NumPy reduction functions (e.g. :func:numpy.sum) return scalar values (e.g. :class:numpy.float32).
However, CuPy counterparts return zero-dimensional :class:cupy.ndarrays. That's because CuPy scalar values (e.g. :class:cupy.float32) are allocated in CPU memory. If these types were returned, it would be required to synchronize between GPU and CPU.
If you want scalar values, cast the returned arrays explicitly.

[okuta]

Now, cupy.float32 is completely same numpy.float32. Using numpy.float32 is better.
I think it is possible to make better CuPy scalar in the future.

[okuta]

LGTM!

[niboshi]

This PR is causing doc-test failure in jenkins.
Could you make a quick fix or revert?