About Python's Mixed Numeric Data Types converting results up to the most complicated operand...

Question

A little background: I'm in the process of learning Python through O'Reilly's, "Learning Python" book, I've had some experience in Java.

Anyway, upon reading Chapter 5 (I'm still in the middle of it, actually) I have come across a question with the way Python treats results of Mixed Numeric expressions. In the book, they use an example of mixing an integer and a floating-point number (40 + 3.14) and proceed to explain that the result of this expression would be a floating-point number because Python converts operands up to the type of the most complicated operand.

My question is this: Instead of programmers having to remember which Numeric operand is the highest and remember that the that the result will be "upped" to that format, wouldn't it be simpler to create a special Numeric Literal for result types?

My logic is this: If you have a decimal place in your expression, you know it's going to be a floating point number, if you have something like 3+4j, you know it's going to be a complex number. Why should you have to remember the hierarchy of Numeric Literals just to know what your result is going to be treated as? In my opinion, it seems like it would be a much simpler process to assign results to a single, uninformed Literal to know that regardless of whether or not the expression has Mixed Numerics, it will be treated as a specific Data Type.

Follow up question: Is there a language where this kind of thing is currently being preformed?

Again, my knowledge of Python is limited, so this may be a silly question, but I would like to know why programmers have to put themselves through this process. The only reason why I could imagine that there isn't a system of some kind in place already is that perhaps the specific Numeric Type of a result isn't as important as it is in some other languages (Java).

Answer 1

"If you have a decimal place in your expression, you know it's going to be a floating point number, if you have something like 3+4j, you know it's going to be a complex number."

That is the "hierarchy of Numeric Literals". I'm not really sure what more you want. Furthermore, the result will always be a subclass of numbers.Number, so you actually do have some guarantee about what type the resulting object will be.

Answer 2

Suppose you had a unified numeric type and you typed the following statements:

a = 42
b = 42.24
c = 4 + 2j

How would this be any different from what you get today?

This is already valid Python. The only difference is that type(a), type(b), type(c) return int, float and complex, and I guess you want them all to return something like number. But you never really deal with that unless you want/have to.

There are reasons for having something like a scheme-like numerical tower. You may take advantage of the hardware for integer calculations if you know you're only dealing with itnegers. Or you may derive from the int type when you know you want to restrict some kind of user input to an integer.

I'm sure you can find a language with a type system that has some kind of unified number. But I'm not sure I've understood your argument. Perhaps I've missed something in your question?

Answer 3

Don't think i really understood question:

1. Do you mean that operation result should be explictly specified? you can do it with explict cast

   float(1+0.5)

   int(1+0.5)

   complex(1+0.5)

2. Do you mean that operators should accept only same type operands?

   1+2

   1+0.5 -> raises exception

   1+int(0.5)

   float(1)+0.5

   while having sense, it would introduce too much verbosity and int->float casts are always successful and don't lead to precision loss (except really large numbers)

3. Separate operands for different return types:

   1 + 0.5 -> int

   1 \float_plus\ 2 -> float

   Duplicates explict cast functionality and is plain sick