Provost Zakharov

Cool, I see. Good job! I'm still a little confused though, doesn't the exact error depend on 1) how admin typed in the formula, and 2) what precision the calculations are done in? How could you know either of those things? I tried a couple variations and I wasn't able to replicate this non-zero distance between {-71,67} and itself. Can you show what formula you are using, and how you calculated the error?

OK smart guy, what did I miss? Please enlighten us.

No, not worth it.

Thanks guys, but we don't need more datapoints. We basically have it figured out now, and the conclusion is you can't do better than 99%.

I was hoping that the points are still distributed on a grid, just with smaller spacing (like 0.01) so that we might still be able to find it. But, now that I think about it, I realize it would never monetarily be worth all the tries it would require to find it at that resolution. So I guess we can call the problem solved at this point. I'm looking forward to using our method to solve for a far away point next month =)

Hi, I see the last thread was misunderstood, and got locked. So let's try again. We've done extensive research on the math behind finding the hotspot. We're now at the point where it is conclusive that the hotspot does not have integer coordinates like it did the first time. We would like to know the precision of the hotspot because it will allow us to make an important decision: Do we continue the search for the elusive 100% or do we cut our losses because 99% is the best achievable anyways. It may be feasible to find the 100% spot if it has just 1 or 2 decimal places. Of course, admin doesn't have to reveal this information. But if I were admin, I would not want to see my players wasting their cash going on a wild goose chase. We just want to know if there is any point going further, that's all.

That's why you aren't matching the further-out points, the constant 50 isn't quite correct. The formula I came up with (using line fitting) is: eff(p) = floor(100 - 125*d(p,h)/pi) where d(p,h) is calculated with r = 1. I think it's better to do it this way so we don't need to know the actual number admin used for the moon radius. I quoted this formula in one of my earlier posts btw. If I work that formula into the same form as yours, it comes out to something like 43.6556 instead of 50, using 1737km for the moon radius.

No problem with the 92% or any of the points. Yeah, I'm pretty sure the feasible region is correct. I actually just double checked it via another method: Instead of just defining one feasible region for the hotspot, we can define a feasible region with respect to any individual datapoint. The feasible region for a datapoint p is the set of points which, if they were the hotspot, would match p. This can be defined as an inequality: feasible(p) = {x : p.value <= eff(p,x) <= p.value+1} With this definition, the global feasible region is just the intersection of all the feasible region of each datapoint. The advantage of doing it this way, is we can use powerful existing tools for computing/graphing inequality equations. Here is a sequence of plots I produced using this method, zooming in closer and closer to the feasible region (in yellow). Each "band" is the feasible region of a single datapoint. Great idea posting @ the question center. I don't have any ideas for points right now. If the question gets answered and we find out some information about the number of decimal places, I might be able to do something more; until then I consider the problem solved as far as possible.

I bought it when I had nothing else to buy. Haven't used it so far. (Not that I expected to.)

Assuming my efficiency formula is correct, we can test if any particular spot "could be" the hotspot by checking if all the currently known datapoints match what the formula predicts. The feasible region is the set of all points that "could be" the hotspot, as defined above. To actually compute the feasible region "exactly" is impossible, so I just sampled the feasibility function (on a regular grid with spacing of 1/200th of a degree in each direction).

With these coordinates added to my model, the hotspot location is extremely constrainted. It must be inside a small square centered around {-70.9225, 67.01}, with dimensions 0.16 x 0.21 (degrees, lat x lon). (the actual feasible region is not a square, it's some kind of discrete polygon.) There are no integer coordinates inside the feasible region. I think it's time we simply ask admin to clarify that it does not have integer coordinates, so that we can end the wild goose chase. 99% is the best result that can be achieved unless we can magically guess the coordinates to the full number of decimal places.

Afaik, this is exactly how it works. If it wasn't done this way, it might be possible to go into negative amounts which wouldn't make any sense. Sure, it's reduced a lot compared to if you simply added them all. But it doesn't matter. They are still worth it, and the game is balanced as is.

Awesome! That far-out point at 78 really helped. I was able to find a new efficiency function that is capable of matching the data perfectly: eff(hs,p) = 100 - 125*d(hs,p)/pi Unfortunately, if this is correct, I believe it implies that the hotspot does not have integer coordinates. My calculations say that -71,68 is the only integer point that can be at the center and still match everything. We already have it marked down as 99% Here's the new plot. Notice all points are in the correct band now:

Wait, you seem to have a bunch of new datapoints there, where are you getting these? Can you post a full listing of all the datapoints you have, including all the old ones? Thanks for trying it. Since that didn't work, I'm at a bit of a loss. I can't seem to make the numbers work. I wonder if my formula for calculating the efficiency is correct. Right now I'm using eff(pt, hs) = 100-100*d(pt,hs)/pi where pt is any point, hs is the hotspot and d is the great circle distance function with radius = 1. The algorithm is like this: for every point p with integer coordinates on the map -assume p is the hotspot -calculate the efficiency of all known datapoints and count how many match the points that match every datapoint are hotspot candidates. Except I can't get all the points to match. If the efficiency formula was correct, there should be several points (or at least one, the hotspot) which matches every other point. I've tried about a dozen other variations on the formula, including different rounding modes, having a constant multiple or exponent, etc. I also tried some other distance formulas but those weren't even close. Of course, the efficiency formula itself could be derived by curve fitting or something, but we don't have enough datapoints for that. We'd need a bunch of much further out points, in the 60s, 70s 80s etc.

I agree with (-71,65) being the most likely. I developed a new method based on assuming integer coordinates, and I think it is better than what I had before. The new method calculates (-71,65) as the hotspot. This is what the "efficiency regions" look like under my current model, assuming (-71,65) is the hotspot. Each band going out from the center represents 1% efficiency drop. The innermost region is 99%. 100% is not visible because it is not a region, just a single point. The only datapoint that doesn't match is the 94% point. My model predicts that spot should be 95%. I'm not sure what the problem is, I need more far-away datapoints to figure that out. and for fun, a view of the whole moon: (EDIT: this won't look the same as the in-game map, because google maps uses a different image map and a different projection method)

I just posted that datapoint, why would you move there? edit: somebody try -71, 69 that looks like the next best candidate at this point.

2 new datapoints: -79, 75: 94% -70, 69: 99% I calculated these points using a least-squares method. (I will give a full explanation of the method once I complete it.) The first point was off because I messed up one of the constants by a factor of 2. However, the extra datapoint helped a lot for the second try, especially because it was a bit further away than all the other points. Admin, if you're reading this, can I suggest not rounding off the efficiency % to an integer? It would be really helpful for the calculation. Here's a summary of all the datapoints so far: data = { {99, {-70, 69}}, {98, {-72, 72}}, {98, {-73.6, 69.17}}, {97, {-68, 72}}, {97, {-68.18, 76.49}}, {97, {-75, 65}}, {94, {-79, 75}}} edit: and a graphic of them.

Ok, it's explained earlier in this thread (here: http://forums.cybernations.net/index.php?s...&p=1806043) Anyways, I'd like to take a crack at figuring out a good method of calculating the hotspot. I looked through the thread and the data is all over the place and I'm not really sure which data is from this month or last, or before or after X and Y were switched, etc. If someone has a nice clean dataset I'd appreciate if you post it here. I promise I'll provide a detailed description of the method if I figure it out. I'm a 4th year in math so I believe I have a chance of getting it with a bit of effort B)

Is dragging the locator the only way to move the base? It doesn't seem to display what the new coordinates are, how do I know where I'm moving to?

Why would you intentionally pay twice the market rate for tech?

Did admin consider the fact that this information might affect which wonder we buy in the first place? It's pretty unfair to force us to learn by trial and error when buying billion dollar wonders.. you essentially only get one shot in this case.

I said it before and I'll say it again since I didn't get an answer: Why do the images suddenly need to be a "uniform size"? They weren't uniform size for the last 3 years and it worked just fine. Seriously ... that doesn't make any sense, at all.

As the head of a site like this, you might have figured that out through experience by now, and learned not to unnecessarily change the "simple details" which people are most emotional about? People are a lot more open to larger changes which actually do something new, and aren't just change for change's sake. For example, no one is requesting that the new moon/mars bases be removed (edit: saying you won't buy it doesn't count), but you do have a bunch of people (myself included) who are requesting the old images back.

The old images were not uniform size (you just stated that), and yet they worked fine for the past 3 years. Why would adding new ones mean they all suddenly need to be uniform size? This argument doesn't make any sense at all.

Great change, now I can do 20 day collection cycles instead of 15, without fear of deletion.