Yes, I'm pretty pleased with the way it works now. The early sensor boats are expensive to quick-buy and they don't seem to have the same reach so they seem like a pretty good trade-off now. Later in the game, I still need a few around (usually one for each 'front') rather than just one to see the bulk of my territory.

It is not a missing tile count. It is an estimate of the number of inputs for which the circular approximation gives the wrong answer. Using a ceiling function, any number of tiles from 4219 to 4446 should give a sensor range of 38. The circular approximation assigns an incorrect sensor range to 36% of the tile counts in this range. Using the ceiling function, any number of tiles from 19 to 36 should give a sensor range of 3; the circular approximation gives an incorrect sensor range for 44% of these values. Using a ceiling function, any number of tiles from 37 to 60 should give a sensor range of 4; the circular approximation gives an incorrect sensor range for 42% of these values. Using a ceiling function, any number of tiles from 61 to 90 should give a sensor range of 5; the circular approximation gives an incorrect sensor range for 40% of these values. And so on.

I am not evaluating 'missing tile count.' I am evaluating how effective the circular approximation is at providing the right answer. For ~26% of the possible input values on the range [1, 720], the circular approximation gives the wrong sensor range. This is a bad estimate; the circular approximation provides the wrong answer for more than a quarter of the input tile areas.

Where did I blame the ceiling function? I said that when using a ceiling function to round the numbers, the circular approximation provides the wrong sensor range for ~26% of tile areas from 1 to 720 tiles. It's about the same error rate as with the floor function (which provides the wrong sensor range for ~24% of the tile areas in the same range) and standard rounding (which provides the wrong sensor range for ~25% of the tile areas in the same range).

I am criticizing the circular approximation, not blaming the error on the ceiling function. I used the same function to round the numbers using the R = -0.5 + sqrt(9 + 12A) formula when determining how many of the values produced by the circular approximation were wrong because a simple comparison of the resulting ranges is the easiest way to get a count of the number of incorrect ranges.

You want sensor components to give bonuses in terms of area so as to implement a form of diminishing returns, and you don't feel that players need to know about area, and you agree that area revealed is not a particularly helpful statistic for the player to know. You are proposing, therefore, that a sensor component's statistics should list its size, its maintenance cost, and its production cost, and perhaps a statistic which is not particularly helpful to the player or no statistics related to its bonus at all. How then should the player decide which sensor component to use? Trial and error? Trial and error is not a fun or interesting way to handle ship design optimization.

Well thanks for clarifying my misunderstanding. But let me now correct yours. You see, you are throwing around right and wrong as if they are absolutes. Many of the formulas used in his game are, to a large degree, chosen arbitrarily. Circular area of coverage can also be such and algorithm, even if it doesn't work perfectly with hex maps. So the number is wrong almost half the time. But when it's wrong it is off by one, so it's not a big deal.

Now to your math. I will assume it is correct because I have no interest in validating it. But it's also a misuse of statistics, attempting to tell a false story. You can say the circle formula produces the wrong result 40% of the time. But because the result is at most one off, I can say that on average error is about 3.5% for hexr ranges from 1 to 15 (It only gets better as you expand), which most people would declare is a close approximation.

First, I never said I want any of this. I'll assume you and I both understand that by now and move on.

The confusion of diminishing returns for users is universal. The old formula for population to production was the same issue. If I want my planet to have 200 production, what population do I need accounting for bonuses? But that's not how most players play. They just try to maximize their production and don't care about the forumla or the specific number at the end. I'd be willing to bet that you do this as well. There's no reason to believe most players won't do the same for sensor range. Just pack the ship with as much sensor range as you can while meeting your remaining ship stat goals. Or if you are building a sensor ship, yes have them add sensors until they meet the range goal they want, and they can pack in engines or whatever else they want. That is essentially how it works now, even without diminishing returns.

The approximation fails to be less computationally complex to any significant degree and moreover is for something which should not need to be computed with any significant frequency, meaning that what little you gain in reduced computational complexity through the use of the approximation is essentially meaningless. That it fails to produce the right answer a significant amount of the time is a significant strike against it when it offers little benefit over using the correct equation. It is for this reason, not for its inaccuracy, that the approximation is bad.

Agreed.

Agreed that it offers little benefit over the more precise equation ("correct" and "right" are not the vocabulary to use in this context). Disagreed that it's specific inaccuracy makes the approximation bad. Lots of computations are specifically incorrect, but generally close, and turn out to still be of value. I wouldn't close down my business if I was unable to calculate down to the penny how much money I'd gross next month.

What if the first 3 sensors (and the regular Survey module) had <OnePerShip>true</OnePerShip> (in the ShipComponentsDefs.xml)?

The super-long-range detectors are still possible to make once you get to the 4th tier sensor (age of war), but those sensors cost a little at least. Having plenty of Thulium will also allow ships with extreme sensor range.

There are some ships in ShipBlueprintDefs.xml that want to put 3 sensors on the ship, not sure how that will react to this.