Provost Zakharov

Sorry for the delay, I've been a bit busy with newyears partying and such

I've been playing with it a bit and my conclusion is that perhaps one of the constants in the efficiency formula needs to be tweaked. The formula I determined experimentally for the moon is: eff(hs,p) = 100*(1 - k/pi*d(hs,p)) with k = 1.25. I chose k=1.25 based on curve fitting and because it's equivalent to 5/4 which is a nice number which I thought admin might type by hand. However, I went back and looked at it more closely, and it appears that the real constant isn't 1.25, but rather something which lies in the interval (1.2287, 1.2446). Any number from that interval works for both the old moon data and the new mars data.

Well, if efficiencies get rounded to the nearest integer instead of rounded down, then 99.51% would round to 100%, meaning the 100% region would be a circle (roughly speaking) instead of a point. We conclusively proved that is not the case, for the moon at least.

These are the three datapoints I used. And I am reusing the efficiency formula found for the moon. Assuming the hotspot is (37, 107), the efficiencies, respectively, are: 53.4936, 57.3661, 75.4756. Rounded down -> 53,57,75 Assuming the hotspot is (37, 108), the efficiencies, respectively, are: 52.9526, 56.8477, 75.3616. Rounded down -> 52,56,75 So it seems that 37,107 matches while 37,108 does not. Where is the calculation going wrong? Would Matt Miller or someone else explain? Thanks

Interesting, has anyone confirmed this? According to my formula and the data in this thread, it isn't possible.

It might be one of those spots which requires a weird decimal place correction. I've been going by Rich333's correction table (found here: http://forums.cybernations.net/index.php?s...&p=1930324) and it has worked until now, but we were never 100% sure if it was correct.

Been a couple days and I see no one has posted it yet, so as promised I will try to calculate it... lat, lon 37, 107 ? Someone see if that works.

I'm getting a lot of PMs asking for help finding the Mars hotspot. I think it would be cool if you guys could figure it out for yourselves, but I'll post the answer in a couple days if no one else has. Here are links to my posts in the Moon Hotspot thread which describe how to find it: http://forums.cybernations.net/index.php?s...t&p=1879412 http://forums.cybernations.net/index.php?s...t&p=1879493 http://forums.cybernations.net/index.php?s...t&p=1885515

Someone try this please.

Thanks for the data. Unfortunately, 50% measurements aren't helpful, and the other 2 are so close to eachother and the previous hotspot (which Rich333 posted) that they don't give any new information. If somebody wants to help out, please try the best guess point from my previous post (67,-1), or post a new >50% point which is at least a few degrees away from the existing ones.

My best guess at this point is: Lat 67 Lon -1

lol 35.00000001 not 35.00001

Cool, that settles it then. AirMe, add a note in the OP?

heh.. yeah. what worked for you? 35.0 or 35.0000001?

I was just giving you a heads up that the OP may not be accurate.

Your screenshot in the OP doesn't show the .00000001. Is 35.0, -68 also a 100% spot? Because according to Rich333's table, it shouldn't be.

Indeed it does, thank you! 35.00000001, -68 100%

That's two, so I just need one more now. If someone wants to try a spot, (34,-68) or (52,-33) are good candidates given the current information.

Assuming the formula hasn't changed since last month, I should be able to calculate a 99% region with just 3 datapoints.

I see. You get the two vectors and find the angle between them. But why do it that way? Most likely, admin just copied the great circle distance formula from wikipedia or some textbook, so if we are trying to find a formula that is "floating point equivalent" to admin's formula, that would seem to be a better starting point. This actually proves my point though, there are a bazillion ways to write this function, so I don't know what makes people so confident that they already found one equivalent to admin's.

Umm.. thanks but that doesn't really answer my question . I'm looking for someone to post some code which I can type in that produces the error. For example, if I use this (in C++): real surfaceDistance(real hs_lat, real hs_lon, real lat, real lon) { const real degree = (real)(M_PI/180); hs_lat*=degree; hs_lon*=degree; lat*=degree; lon*=degree; return acos(cos(hs_lat)*cos(lat)*cos(hs_lon-lon) + sin(hs_lat)*sin(lat)); } (where real is either float or double) then surfaceDistance(-71,67,-71,67) is exactly zero. obviously there are millions of possible variations on the above code which do the same thing, so I'm just asking which is the one you guys found that produces a nonzero error between (-71,67) and itself

So, what is the exact form of the distance formula that you are using to produce errors that match the data? As I said before, I tried several variations on it (32 bit, 64bit, etc) and for all of them, d({-71,67},{-71,67}) was exactly 0.

Nice work man. Looking forward to your result. I'm curious what fraction of the integer spots need error correction, and if there is a pattern if you plot those spots in 2D. It may be the case that there are too many spots to fit in a table, in that case it would be nice to have a function that computes the necessary correction.

Sigh. There is no looking at source code involved in setting your coordinates. Go read the link again.

See this post: http://forums.cybernations.net/index.php?s...t&p=1806043 Fail.