On Oct 13, 2019, at 22:54, Chris Angelico <[email protected]> wrote:
>
> Mathematically, what's the difference between '1' and '1+0j' (or
> '1+0i')?
The details depend on what foundations you use, but let’s go with the most
common construction.
The natural number 1 is defined as 0 U {0}. Because 0 is defined as {}, that
means it’s {{}}.
The integer 1 is the equivalence class of all ordered pairs (where the ordered
pair `(x,y)` is defined as the set `{x, {x,y}}`) of natural numbers such that
the first one is the successor of the second.
The rational number 1/1 is the equivalence class of ordered pairs of integers
where the first one is equal to the second.
The real number 1.0 is (loosely) the equivalence class of (infinite) sets of
rational numbers less than 1/1.
The complex number 1.0+0.0j is the ordered pair of the real numbers 1.0 and
0.0. (There’s no need for an equivalence class here, but if you want to add
that, the class has one element, that ordered pair.)
None of these sets is the same as any of the others. You can expand the sets
all the way out, but you really don’t have to; it’s obvious that all complex
numbers are finite (an ordered pair can’t have more than two elements), and all
real numbers are infinite.
There are lots of other ways to construct numbers (technically an infinite
number of ways, but I mean ways that are practically interesting), but
generally, no real number is a complex number. The only foundation I know of
that sort of does what you want is based on category theory, and then the real
numbers and complex numbers aren’t sets, so the question technically doesn’t
even apply.
> Everything I've seen has said that a complex number with its
> imaginary part zero is equivalent to a real number,
But “equivalent to” doesn’t mean “same as”. It’s sort of like the difference
between `==` and `is` in Python: `1.0 == 1.0+0.0j` is true, but that doesn’t
mean `1.0 is 1.0+0.0j`, and therefore, the fact that `isinstance(1.0=0.0j,
complex)` doesn’t mean that `isinstance(1.0, complex)`. But don’t take that
analogy too seriously.
The right thing to say when you need to be strict is that there’s a morphism
that maps every real number to a unique complex number, and a morphism that
maps every complex number whose real part is 0 to a unique real number, and
that all the laws of real and complex algebra work as you’d expect with respect
to these morphisms (and you can even define things like real-complex
multiplication and then prove that you always get the same result as if you
mapped the real to its complex equivalent and did complex-complex
multiplication).
In most areas of math, and in most applications, you really don’t care which
definition you’re using, and you loosely just assume it’s any of the ones that
works, and that you’re using any of the morphisms that works, and so on. But in
those areas of math, you don’t deal with things like the set of reals, much
less the internal structure of a real; the fact that you don’t ask (e.g.)
whether some arbitrary object is an element of C is why you can be loose about
it.
> which would mean
> that '1' is as valid a way of representing that number as any other.
> It's the same as considering 42 to be rational, because it can be
> written as 42/1.
Well, any string is a valid way of representing any number under some system.
And when you’re doing complex analysis, it’s perfectly reasonable to say that
the string `1` represents the number `1+0i`. But then the string `1` isn’t
representing the real number `1`, so the mapping between reals and complex
numbers isn’t even relevant in the first place.
Again, think of Python, but don’t take the analogy too far. You can use `1`
almost anywhere you can use a float, and it will almost always mean the same
thing as `1.0` when you do. But that doesn’t mean when you use it in
`isinstance(1, float)` it’s the same as `1.0`. So, is `'1'` a valid way of
representing the float `1.0`? Yes if you’re doing arithmetic, no if you’re
doing type-switching.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/KWLUVZRGUZMFLSTQXYIA6YQGIU6Q5GMH/
Code of Conduct: http://python.org/psf/codeofconduct/