help understanding education

[General_Jah]

Hey guys I'm a bit confused on how education works exactly in RaR.

For example I have a tier 1 school and it says it will take 30 turns to graduate for my citizen. Then I had some problems with health and it was at -25% education points, but the tooltip still says 30 turns.

Is it always 30 turns for a tier 1 school or is there some other way to determine how long it will take?

Thanks

 

[Commander Bello]

If you mouse over the student it will show the current "production" of education with all modifiers and the needed turns for finishing the education.

 

[General_Jah]

Well that is what has me confused. It says 30 turns regardless of the modifier. For example, I had -25% production at one time still said 30 turns, then I had +10% in another city and it still said 30 turns

 

[Commander Bello]

Most probably this is due to the use of integers.
A student in a school "produces" 3 items of the yield education. If you have a +10% production increase due to health, the student produces 3.3 items, but only 3.0 (the integer part of the 3.3) are added up.

These conversion problems can be found all over the code.

 

[Nightinggale]

Most probably this is due to the use of integers.

This is my guess too. The code uses integer more or less everywhere, which causes rounding issues like this. Switching to floating point would solve it. However floating point have different kind of rounding errors, which could accumulate and cause all sorts of different issues, possibly even network stability issues. We are better off using integer with the issues they bring.

The problem with education time is the same as with any other profession producing yields. With 3 yields/turn, it will become 3 unless the bonus is at least +34%. Likewise you lose 1/turn if the penalty is -1% or -33%.

As I mentioned in the M:C forum quite a while ago, the only thing to do about this is to use a modifier for the goal. For instance if you produce 3/turn and require 60 to reach the goal, +10% production provides nothing (3.3 is still 3), but -10% required would become 60-6=54 or 18 turns required instead of 20. This works because bigger numbers are less affected (in percentage) by integer rounding errors.

However the scale of the redesign for this to work is not a minor task and nobody ever started.

 

[westamastaflash]

This is my guess too. The code uses integer more or less everywhere, which causes rounding issues like this. Switching to floating point would solve it. However floating point have different kind of rounding errors, which could accumulate and cause all sorts of different issues, possibly even network stability issues. We are better off using integer with the issues they bring.

The problem with education time is the same as with any other profession producing yields. With 3 yields/turn, it will become 3 unless the bonus is at least +34%. Likewise you lose 1/turn if the penalty is -1% or -33%.

As I mentioned in the M:C forum quite a while ago, the only thing to do about this is to use a modifier for the goal. For instance if you produce 3/turn and require 60 to reach the goal, +10% production provides nothing (3.3 is still 3), but -10% required would become 60-6=54 or 18 turns required instead of 20. This works because bigger numbers are less affected (in percentage) by integer rounding errors.

However the scale of the redesign for this to work is not a minor task and nobody ever started.

One thing to do instead would be what one of the Fall from Heaven modmods did - multiply *all the numbers* by 100 (or 10000), so integer division errors & rounding errors are nowhere near as bad. They also updated the interface to do floating point division to show the actual amounts.

 

[Nightinggale]

I have actually started using higher numbers internally as I made a class to combine multiple modifiers. The ideal usage is a number where you multiply with input and then divide by 100. You do that multiple times with different inputs. Vanilla has a bunch of those. Since it multiplies everything first, then divides, it will actually provide a bonus even though +10% doesn't, yet +10%^6 will.

I have considered changing yields to be multiplied by 100 to handle fractions. However I actually considered using 128 or 1024 for performance reasons. To quote this site Whats-the-computational-cost-of-the-division-operation

For instance, on the 32bit Intel Core i7, it seems that ADD takes 1 processor cycle (from start to finish), MUL takes 3, and DIV takes a staggering 26.

Dividing with 2^n with a hardcoded value (as in an enum value, not runtime), then a division can be changed to bitshift, which is as fast as ADD. 128 = 2^7 and 1024 = 2^10 while 100 will use the slow division, even when hardcoded. In the example CPU, dividing once will take 26 cycles while bitshift will only take one. multiplying and dividing will take 29 while multiplying and bitshift will take 4. This mean the same math will be 7-26 times faster when selecting the correct number to divide with.

Does it matter? Actually yes. The Colonization AI code is surprisingly slow compared to the bts one (presumably due to professions and yields making the choices more complex). This mean efficient coding becomes even more important, particularly for something the AI uses all the time, like checking if there is enough yields to build a building or profession.

Does it matter enough to use less human readable numbers rather than 100? I have no idea as cache misses and other stuff can screw up predictions like that. I will likely end up coding it to be an enum value, allowing it to be changed easily to test both setups and looking for performance and rounding errors using multiple different multipliers. However it's not something I'm implementing right now due to other modding priorities.

 

[westamastaflash]

Does it matter enough to use less human readable numbers rather than 100? I have no idea as cache misses and other stuff can screw up predictions like that. I will likely end up coding it to be an enum value, allowing it to be changed easily to test both setups and looking for performance and rounding errors using multiple different multipliers. However it's not something I'm implementing right now due to other modding priorities.

Cool, just wanted to make sure you knew about the option. I'm loving the mod as-is too.

 

[Nightinggale]

Oh btw just to be sure everybody are aware of this: I make new stuff for M:C, not RaR. Sadly RaR sort of died. Looks like I'm the only one left and I can't continue to develop two mods. I had to make a choice and I picked M:C because there I wouldn't be alone. I still make bugfixes for RaRE though (when I get around to it).