A lot of discussion about the "right" way to calculate a result, without discussing why.
My guess is something along the lines of an assumption that income is roughly equal to spending so you want "the" place on earth thats ideally suited to building your food processing plant or refrigerated warehouse to minimize total air shipping costs assuming everything will ship by air.
I'm not really sure what meaning this "center" has beyond that unless strange assumptions are made, like income is perfectly proportional to capital market size, or income is perfectly proportional to military power or something.
There is very fast alternative discrete rather than continuous method to calculate "a center" that scales very poorly as resolution increases (which doesn't matter because the input data is junk wrt sig figs and truth) which is just to make a giant mesh network of clusters of a discrete billion bucks at a certain lat/lon or whatever, then add an imaginary center that can move that optimizes itself to a minimum distance from all other existing points. You'll get into huge arguments about high enough res and metastability and rounding errors and local maxima/minima but you can ignore all that, given that as an engineering estimate the input data is junk, you just figure the total distance for each points at all whole degree intersections (88 W 43 N aka Chicago-ish, next 89 W 43 N, then 90 W 43 N ... ) so you figure 360*180 (actually more like 178 than 180, and a +2 for polar reasons) and then sort the 64000 or so results and pick the lowest.
Using the discrete method, if you figure there's 64K (16 bits) degree intersections on the globe and maybe 1024 (10 bits) or so clusters of a billion bucks, that is maybe 26 bits worth of distance calcs and additions, figure 3 bits per decimal digit for "less than 10 digits of operation" and we have multicore processors that run about that many ops per second (if you have the memory and IO bandwidth LOL, which you won't), that followed by a very modest sort, so this is quite tractable and has a resolution probably higher than the sig figs in the input data you're feeding it. No, it doesn't scale well to a higher resolution, and thats OK because the input data doesn't warrant it.
The whole topic smells of a really bad dotcom "brain twister" interview question for a CRUD app designer or CSS jockey. Back when that was how it was decided who was a good or bad one based on solving riddles and stuff.
Comments
A lot of discussion about the "right" way to calculate a result, without discussing why.
My guess is something along the lines of an assumption that income is roughly equal to spending so you want "the" place on earth thats ideally suited to building your food processing plant or refrigerated warehouse to minimize total air shipping costs assuming everything will ship by air.
I'm not really sure what meaning this "center" has beyond that unless strange assumptions are made, like income is perfectly proportional to capital market size, or income is perfectly proportional to military power or something.
There is very fast alternative discrete rather than continuous method to calculate "a center" that scales very poorly as resolution increases (which doesn't matter because the input data is junk wrt sig figs and truth) which is just to make a giant mesh network of clusters of a discrete billion bucks at a certain lat/lon or whatever, then add an imaginary center that can move that optimizes itself to a minimum distance from all other existing points. You'll get into huge arguments about high enough res and metastability and rounding errors and local maxima/minima but you can ignore all that, given that as an engineering estimate the input data is junk, you just figure the total distance for each points at all whole degree intersections (88 W 43 N aka Chicago-ish, next 89 W 43 N, then 90 W 43 N ... ) so you figure 360*180 (actually more like 178 than 180, and a +2 for polar reasons) and then sort the 64000 or so results and pick the lowest.
Using the discrete method, if you figure there's 64K (16 bits) degree intersections on the globe and maybe 1024 (10 bits) or so clusters of a billion bucks, that is maybe 26 bits worth of distance calcs and additions, figure 3 bits per decimal digit for "less than 10 digits of operation" and we have multicore processors that run about that many ops per second (if you have the memory and IO bandwidth LOL, which you won't), that followed by a very modest sort, so this is quite tractable and has a resolution probably higher than the sig figs in the input data you're feeding it. No, it doesn't scale well to a higher resolution, and thats OK because the input data doesn't warrant it.
The whole topic smells of a really bad dotcom "brain twister" interview question for a CRUD app designer or CSS jockey. Back when that was how it was decided who was a good or bad one based on solving riddles and stuff.