In-game manufacturing profitability view

[DeltaEpsilon]

But an alternative is to just do a recalculation based on smaller number of engineers.

Yeah, well, that's natural. If you perform const / X, result becomes less and less different from last as you increase X.

Let's consider 1 Workshop, 1 Living Quarters, and 50 Engineers. 46 Engineers could work on scanners at the same time. That gives you 33,120 Engineer hours per month. At 220 hours per scanner, this group would make 150 scanners every month. That costs $34,000 * 150 or $5,100,000 for supplies plus $1,250,000 for engineer salaries, plus $45,000 maintenance on the Workshop and Living Quarters, or $6,395,000. Dividing that by 150 means it costs you an average of $42,633 to make a Motion Scanner. This isn't a whole lot larger than the earlier calculation. There is, of course, some loss due to math issues, but less than when having 196 engineers working. (After the 5th hour, 230 engineer hours were used, and 10 of those were wasted.)

would make 150 scanners every month

Your calculations are not done properly. If you want to account for wasted hours, you are going to do this:
Product_made = max(floor(720 / (ceil(man_hours/engineers_assigned))), 1)
Floor - rounding to zero (5.4 ==> 5)
Ceil   - rounding to one  (5.1 ==> 6)
Max  - maximum, duh. (0.5, 1 ==> 1)
720  - amount of hours in an average month (24 * 30). It's 744 in case of 31 day month.

[Leprechaun]

Your calculations are not done properly. If you want to account for wasted hours, you are going to do this:
Product_made = max(floor(720 / (ceil(man_hours/engineers_assigned))), 1)
Floor - rounding to zero (5.4 ==> 5)
Ceil   - rounding to one  (5.1 ==> 6)
Max  - maximum, duh. (0.5, 1 ==> 1)
720  - amount of hours in an average month (24 * 30). It's 744 in case of 31 day month.

I'm not sure just how your calculations produce a significantly different result. Yes, I recognize the functions and the purpose is to simulate the odd math that XCom: EU is using. But I don't think the "max" function is valid, because it guarantees you will make at least 1 product, even if the number of hours assigned isn't sufficient to make one.

As far as number of days in a month, who wants to do 3 different calculations? February is 672 hours. If you want absolute accuracy, you calculate based on a 365 day year.

But the point of the calculations was not absolute accuracy, but to produce something reasonable as the basis for setting an initial sales price for a new items, which will then be reduced over time in simulation of normal economic forces.  It's grossly simplified, but I think the idea behind it remains valid.