Types of the variables about kyoto HOT 11 CLOSED

Dude. Not cool.

Adam [email protected] wrote:

The types that we use for describing different parameters of countries are really inconsistent. E.g. available to spend (which at the beginning of the the game is a fraction of a GDP) is long while GDP is double.
As the unit of everything are quite arbitrary, I suggest to use long for each variable except those that express ratios, rates and percentages (none of the parameters is such). This way, we would avoid type conversion problems and division of doubles problem.

If you agree with me, I will implement the change and. the constructor is going to change! :D

Reply to this email directly or view it on GitHub:
#1

from kyoto.

But it will make everything actually easier to handle. I will change it and update the constructors in all the countries so the code still compiles.

from kyoto.

I think leave it as is for now, fix it later. Having doubles will avoid
stupid errors in rounding etc (as many of these values will be operated on
with double precision within a class) and this saves the author having to
round.

On 6 June 2012 19:47, Adam <
[email protected]

wrote:

The types that we use for describing different parameters of countries are
really inconsistent. E.g. available to spend (which at the beginning of the
the game is a fraction of a GDP) is long while GDP is double.
As the unit of everything are quite arbitrary, I suggest to use long for
each variable except those that express ratios, rates and percentages (none
of the parameters is such). This way, we would avoid type conversion
problems and division of doubles problem.

If you agree with me, I will implement the change and. the constructor is
going to change! :D

---

Reply to this email directly or view it on GitHub:
#1

from kyoto.

Is the issue eventually resolved?

from kyoto.

It hasnt been yet. Some of the values are still longs, which is causing issues when calculating carbonReduction etc. These can be fixed without changing the types in AbstractCountry however. I'm not sure on whats the best solution.

from kyoto.

We could use doubles for every variable, but it introduces different problems:
X / double 0.0 = Infinity. We will not get proper exceptions when attempting to divide by 0
A == B cannot be used. Two doubles are almost never equal, if anyone wants to compare them, he has to specify the error interval (A > 0.95_B && A < 1.05_B).
I think it's a smaller problem than using longs which would often loose information.

from kyoto.

Losing information doesnt quite convey the problem. For example, when calculating carbonReduction you need to perform carbonOutput/energyOutput. As two longs this returns 0, and invalidates the rest of the functions.

Careful implementation (casting?) and testing means changes don't need to be made

from kyoto.

Yes, there is a problem when calculating ratios like this.
The normal transition like:
double dirtyIndistry = (double) (carbonOutput / energyOutput)
Is going to return 0.0 as it does the conversion after the caluclation. The way around it is
double dirtyIdustry = ( (double) carbonOutput) / energyOutput

This is a little tricky though and we invite people to introduce bugs. If we used doubles for all the values, this problem wouldn't exist. Don't you think we should make implementations as easy as possible?

from kyoto.

Ok, we'll leave this open until Monday (?) morning for people to register reasons not to change to doubles. Otherwise, we'll turn this into a task and assign it.

Or are we in a particular rush to progress with this over the weekend?

from kyoto.

I think there is no rush generally, but I wanted to see as many issues issued (:D) and closed :D

from kyoto.

Tory and I agreed to change all longs to doubles, I'll leave this open till Friday then close to give people a chance to scout any remaining unneeded casting or now needed rounding (Math.round).

from kyoto.