Casts float returns to double.

[a1270]

These are all i could find. Probably duplicates previous pulls. Also remove cast to double on INCOMMRANGE, don't know why i did that.

[erendrake]

+A1270 Do you mind if i merge in some of your pull requests into my for. I didnt want to without your permission

[a1270]

Not at all. As long as the license is followed no one needs my permission. I will be interested if any of them have conflicts, don't have the free time to do extensive testing. Maybe write up how you did it so others can follow?

[Dunbaratu]

Can the expression code be made more robust to better handle type promotions so this stops being so much of a huge problem? In low level C, for example, if you try to add an int to a double, it doesn't complain at all - it just promotes the int to a double for the purposes of evaluating the expression.

Having to go through every number KOS ever returns and making sure that each and every one of them is a double seems to be sort of attacking this problem from the wrong end, so to speak.

[Dunbaratu]

@BIZZKeryer, I'm well aware of that.

What I'm saying is that it makes far more sense to dig down to the root cause of the problem which is NOT that some things are floats and some are doubles and some are ints. The root cause is the fact that the expression system should be perfectly capable of dealing with any mixture of numerical types in the first place. This is especially true given that we don't have a manual type conversion in the language and can't manually cast things. Because that doesn't exist, the system needs to be able to handle type conversions itself without fail.

If I did the following in C, for example, it wouldn't barf and complain:

int a = 2;
float x = 3.0;
double y = 1.0;

double z = a + x * y;

Instead if would unravel that expression like so:

1. Because of order of operations, the "x * y" happens first. When compiling the code, the compiler notices that it's dealing with a binary operator in which one side of the operator is a double and the other side is a float. Therefore instead of copying the float x on the stack (or register), it will copy a lengthened version of it that's been turned into a double. Now the multiplication has a double on both sides so it functions just fine.
2. Now it's dealing with the plus sign, and it has this: a + (some double that came from x_y).
   Just like with the multiplication in step 1 it notices that it's dealing with a binary math operator in which the operands mismatch. One of them is an int and the other is the double that came from x_y. So since it's dealing with an int and a double, instead of putting an exact copy of the int as-is onto the stack, it puts a version that was converted into a double onto the stack, so it now has a double plus a double. The result is a double.

It's the fact that KOS isn't doing that sort of logic that's causing these problems. If it was doing that sort of thing then wouldn't need to ensure that all variables everywhere are doubles.

There are some things for which doubles really don't make sense, like when you use a number as a loop counter, or when you track the state of a program flag as a number. Or when the TIME structure returns the days, hours, and minutes as separate components.

If the only reason everything is being made into a double is to work around the fact that the language can't do math on a mix of number types, then "the language can't do math on a mix of number types" is really the problem to fix.