41

Flat Earth Theory / Re: Questions about Air Travel

« on: May 02, 2020, 09:13:42 AM »

I am under the belief that many of the flights are based more on practicality rather than ideal paths.

Why would you set up a flight route across the potentially dangerous barren Arctic when it makes more sense to stay near more of the habitable zone containing airports, islands with airstrips, and also make money picking up and dropping off passengers on the way?

Here's a scenario for you. You're in a twin engined jet at cruise altitude, you get a sudden depressurisation, so the masks drop and the plane descends to 10,000 feet or less and you're over mountains with zero visibility outside. Then you get a catastrophic engine failure, a fire breaks out in the baggage hold, the GPS packs up and the satellite based radio stops working. The nearest airport is 5 1/2 hours flying time away. What's the likely outcome?

A perfectly safe landing.

Why? Because you're flying in an ETOPS-330 certified jet (330 minutes equals 5 1/2 hours flying time) over accurately mapped terrain, which means the fire suppression system in the hold will keep a fire at bay until you land, the plane flies just fine on one engine, it's equipped with an inertial navigation system, as backup for the GPS, so you know where you are and you have long range HF radios in case the satellite comms breaks down. All you need now is a semi-competent crew.

Why would cost sensitive airlines then get their aircraft to zig-zag around keeping close to nearby airports along their routes, when they can take a perfectly safe direct route. Your passengers are more likely to die on their way to the airport.

And as for stopping off to pick up passengers, aircraft are at their least cost efficient climbing and descending, taxiing along the ground, sitting at gates and loading and unloading passengers. Passengers nearly always seem to prefer faster direct flights. That's what's killing off the A380 and B747 with the old hub-and-spoke model. The modern economical twin jets allow economical point to point direct flights and when given the choice, passengers vote with their feet and wallets.

42

Flat Earth Theory / Re: Are plane tickets real?

« on: May 01, 2020, 04:59:04 PM »

Bingo. And not just the Bing API, but everything ever run on a computer has the same limitations. That's why computers typically deal differently with two types of number. The set of integers, in maths, referred to as ℤ are all the whole numbers, anything which can be written without a fractional part (e.g. -19, 0, 120). The set of real numbers, ℝ includes all the whole numbers (i.e. members of ℤ), plus all fractions, plus all the irrational numbers such as π. In maths, ℝ is a superset of ℤ. In a computer they are treated separately.

This is then yet even more evidence that the bing API is not based on the haversine formula! The real true haversine formula is not constrained by limited memory where the bing API one is.

Just run me through the logic here. If I say "here's a computer program which solves pythagoras's formula", then you're going tell me it doesn't, because it runs on a computer and the real pythagoras's formula is the perfect mathematical one. That seems to be the implication of what you're saying. And substitute for pythagoras literally every known mathematical formula.

I think you are missing the real point here. We have two implementations of something. I'm claiming the something I've implemented is called haversine. Microsoft wrote the other one and they claim theirs also implements something called haversine.

I've demonstrated that Microsoft's version rounds its numbers to the nearest 1cm, but actually found a way to stop their version from doing any rounding at all. Both versions are running on computers that will inevitably give imprecise results because they are dealing with real numbers. Both versions inevitably deal with pi because they calculate arc lengths on the surface of a sphere with a certain radius. The number pi is irrational and its true value is not precisely known, because it would contain an infinite number of digits. You could store a decimal digit of pi on every atom in the entire universe and you still don't have enough digits.

Given all that, when you compare 200 million results from their code with 200 million results from my code, the results match, 100%. The only way this could possibly happen is that the two implementations are virtually line for line the same, do exactly the same steps in exactly the same order, get exactly the same imprecise results from each of the internal calculations.

This is like getting two exam essays to mark from two different students. Not only do you find complete agreement on every point, but the same spelling and grammar mistakes are made throughout. It'd be pretty suspicious wouldn't it.

I don't have access to the Bing code, but the published versions of the haversine formula are almost certainly in my opinion where Microsoft looked when they were writing this stuff. It's simple enough code and there are a few minor variations and I tried a few of these, but in the end found one which, with a little extra experimentation, just matches exactly their results. You could just swap out their code and swap in my code and it would be impossible for anyone to find any difference.

43

Flat Earth Theory / Re: Are plane tickets real?

« on: April 30, 2020, 09:37:43 AM »

So the Bing API has limitations of modern computer science as you have described above in addition to the rounding and converting most likely in the API.

Bingo. And not just the Bing API, but everything ever run on a computer has the same limitations. That's why computers typically deal differently with two types of number. The set of integers, in maths, referred to as ℤ are all the whole numbers, anything which can be written without a fractional part (e.g. -19, 0, 120). The set of real numbers, ℝ includes all the whole numbers (i.e. members of ℤ), plus all fractions, plus all the irrational numbers such as π. In maths, ℝ is a superset of ℤ. In a computer they are treated separately.

Integers within a certain range can be stored exactly on computers. Operations which combine integers to form other integers, such as addition and multiplication are always exact, but the results may exceed the storage capacity and overflow. Integer division is allowed, but the fractional part of the result is ignored, so 8/3 = 2. That's just the way it is.

Real numbers can sometimes be stored exactly, e.g. 0.5, because as noted before, that's 1/2 and requires only 1 bit in a binary computer, but oftentimes, real numbers are only approximations in a computer because the exact representation exceeds the 53 bits that you have available. Again, just the way it is.

Computers typically have a dedicated processor (either on a separate chip or integrated into the CPU chip) just to deal with floating point numbers, usually called a floating point unit (FPU) or a maths co-processor. The integer stuff is dealt with by the separate arithmetic logic unit (ALU).

In a perfect mathematical world, we wouldn't need to go to all this effort, we'd just need a single processing unit to deal with all numbers and an infinite amount of memory to store these numbers in, but computers are part of the real world, so have to be engineered to work around these issues as well as possible.

But let's get back to Bing and put this in perspective. The real numbers we deal with here, due to the inherent limitations of our computers, probably have capacity of around 16 significant figures (decimal notation), so for a maximum distance possible in our measurements of 20,000km (1/2 way around the world), that means 11 decimal places are available e.g. 20,000.00000000001 (16 in all). The "1" here is 10 nanometres, so we're saying Bing's values are mathematically accurate to 10 nanometres in 20,000 km. To be fair, since we're combining several steps to get the final result and each step can have an inaccuracy, the result may be out by a bit more than 10 nanometres, but that's for an extreme distance. For much shorter distances, the calculated values will be much closer to the theoretical mathematical result.

Microsoft, as we've demonstrated, round their results to the nearest 1cm, meaning that on this scale, the inaccuracies introduced by the computer itself are utterly irrelevant.

44

Flat Earth Theory / Re: Are plane tickets real?

« on: April 28, 2020, 10:43:57 PM »

You also have to figure out the difference between pure math, and actually calculating it with physical hardware. In the real world you will have rounding inaccuraces no matter what base you use.

Again it depends on the base. In base 10 .1 is not an infinite number.  in base 10 .1 + .1 = .2. No rounding whatsoever. No inaccuracies whatsoever.  so .1 + .1 is different in base 10 than it is in binary.

Sure but in base 10, 1/3 (as a decimal) is a repeating decimal, but in base 3, it's 0.1. The issue is exactly the same, whatever base you pick you will find some simple fractions which require an infinite series of digits after the radix point (i.e. the dot). These problem numbers may well be different for each base you pick, but they exist nonetheless.

In the realm of mathematics, these are not a problem. You can write them down if you invent a special notation such as 0.3 with a bar or dot above the 3 to indicate infinite repetition. Computers don't have this concept so the best you can do on a computer is fill as many available bits as you can (53) to get get as close to 1/3 as you can. Let's say that 53 bits is approximately equivalent to 16 decimal digits, so the best you can do is say that 1/3 is 0.3333333333333333, but the problem here is you can't tell the difference between a genuine 1/3 and 0.3333333333333333 (16 digits) or 0.33333333333333333333 (20 digits), because you can only store 16 digits in total. You end up with (in this case) 3 different numbers, which are all indistinguishable because all you can ever see is the first 16 digits. It's ambiguous.

Do you think base-10 has some magic properties, or that it is what real numbers are, and binary is somehow fake?

No just that match in base 10, as has been demonstrated in previous posts, is different than math in bindary.

The maths is the same, the nature of the problem is the same, the actual set of problem numbers varies depending on the base.

There is nothing special about base-10. We just picked it. Any other base works equally well.

binary sure seems to have some issues with adding .1 and .1

In much the same way as you'd have problems dealing with 1/3 in base 10.

There is no such thing as a "binary version' of a formula.  I am not sure how else to explain it. X+X has nothing to do with any bases.

lets test this formula x + x = 2x with the number .1

in base 10:
.1 + .1 = .2


Now try this: https://jsfiddle.net/jbcq3x95/.  0.1 + 0.1. You get:

0.1 + 0.1 = 0.2000000000000000111022302462515654042363

in binary
x + x <> 2x

This is nothing to do with binary, the same problems exist in every base whenever you have a limited number of digits you can store. If I tell you you can only store one digit, then in base 10, 1/3 + 1/3 = 3/5 because 0.3 + 0.3 = 0.6. You can improve things by using more digits, but you're just pushing the problem down the road. At some point you run out of digits and if the numbers you are dealing with require more digits than are available, you don't get entirely accurate results.

There is no such thing as a "binary version' of a formula.  I am not sure how else to explain it. X+X has nothing to do with any bases.

the example above suggest otherwise

 In maths you can write c = 2πr and that's an exact statement, but if you want to make an actual calculation using that equation, you need to assign a value to π and you just have to accept that value can't be exact, because however you

We're not talking about an infinite irrational number like pi. We are talking about .1 and mathematically those two numbers are very different.

But in the world of computers, the problem is exactly the same, you can't store the exact value of pi and you can't store the exact value of 1/3 either.

45

Flat Earth Theory / Re: Are plane tickets real?

« on: April 28, 2020, 05:00:37 PM »

That statement makes no sense, and shows you don't understand some basic math concepts.

A formula works no matter what base you use.  Binary, decimal, hexadecimal, those are ways of representing numbers. A formula or equation doesn't care which you pick. There is no 'Decimal Haversine ' or 'Binary Haversine' formulas.

Example Equation: X+X=2X

WRONG this has been shown by the post below:

Now try this: https://jsfiddle.net/jbcq3x95/. Put in 0.75 for A and 0.75 for B and press the "Add" button. As expected the answer is exactly 1.5, but now try 0.1 + 0.1. You get:

0.1 + 0.1 = 0.2000000000000000111022302462515654042363

So what's going on here? Computers work in binary. The number 0.1 in binary is 0.0001100110011[0011 repeated forever]. It's a simple number to deal with in base 10, but not in base 2, because you need an infinite number of bits and you don't have that, you actually have 53 (in a typical modern computer). That's why, when you add 0.1 and 0.1 together on a computer, you don't get 0.2 unless you round the answer.

Reciprocal powers of 2 in combination will always be fine, so 1/2, 1/4, 1/8, 1/16 etc. That's why 0.75 + 0.75 is exact because it's (1/2 + 1/4) + (1/2 + 1/4) and these are all reciprocal powers of 2.

in binary x + x does not always equal 2x.

In the perfect realm of maths, x + x = 2x always. On a calculator or a computer that is not true. It's nothing to do with binary, it's simply a fact that both have limited storage capacity, so either a computer or a calculator has a biggest number it can handle in its internal storage, so if you add 1 to that number, it can't handle it. It doesn't matter what base is being used. In maths you can write c = 2πr and that's an exact statement, but if you want to make an actual calculation using that equation, you need to assign a value to π and you just have to accept that value can't be exact, because however you choose to store that number, calculator, computer, paper, you have a finite amount of room for it.

The mathematical formula for haversine is perfect. It has no units and there is no base, because there are no numbers involved. The minute you want to use it to answer a question, you need paper or a computer or a calculator and you have exactly the same issues of storage and accuracy.

Saying haversine doesn't use binary numbers is a non sequitur, you can equally say haversine doesn't use decimal numbers either.

Online is a binary version of the haversine formula. The formula that you discussed in your post uses the traditional base 10 number system.

No it isn't, the formula I discussed is not base anything any more than saying c = 2πr is in base whatever. You can calculate a value for c using c = 2πr in any base you like.

46

Flat Earth Theory / Re: Are plane tickets real?

« on: April 28, 2020, 09:35:50 AM »

This is a good logical argument which presents more evidence that the original haversine formula is different than the formula use by bing because the original haversine formula does not deal with binary numbers!

Let's just have a look at the underlying maths as this seems to be confusing you no end.

let r be the radius of a sphere
let A=(φ1, λ1) and B=(φ1, λ1) be two points on a sphere where φ1, φ2 are the latitudes and λ1, λ2 are the longitudes of the two points
let d  be the great circle distance between two points
Imagine a line from A to the centre and another line from B to the centre. The angle at the centre where these two lines meet is called the central angle
let Θ be the central angle between the two points A,B on the sphere

then

hav(Θ) = hav(φ2 - φ1) + cos(φ1) cos(φ2) hav(λ2 - λ1) [ this is core of the haversine formula ]

and

d = r archav(Θ)

So these two formulae when combined allow us to work out the central angle between A and B and from this, the great circle distance.

Note that there are no numbers used at all in either of these formulae, there is nothing to say what units you should use or whether you should use binary, octal, decimal, duodecimal, hex or any other base for your values.

So what is hav? hav is a trigonometrical function just like sine and cosine. The haversine formula is so called because it is based on the haversine (hav) trigonometrical function. hav is an obscure one, so for convenience we can use trigonometrical identities to reformulate using the more familiar sin cos and tan.

hav(θ) = sin²(θ / 2) = (1 - cos(θ)) / 2

And we end up with

d = 2r arcsin(√(sin²((φ2 - φ1) / 2) + cos(φ1) cos(φ2) sin²(λ2 - λ1))

And we can use another trigonometrical identity to replace the arcsin with arctan

arcsin(θ) = arctan(θ / √(1 - θ²))

Giving us (assuming I've got the brackets right)

d = 2r arctan(√(sin²((φ2 - φ1) / 2) + cos(φ1) cos(φ2) sin²(λ2 - λ1)) / √(1 - sin²((φ2 - φ1) / 2) + cos(φ1) cos(φ2) sin²(λ2 - λ1)))

And this is the formulation we have chosen to implement in code.

Note that this formulation does include an actual number, the number 2, but this isn't decimal 2, it's just the number 2 in some base which could be 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 etc. etc.

We can trivially rewrite this final formulation by replacing every number 2, wherever it occurs, with (1+1) and then you can't even rule out binary as as base for haversine.

d = (1+1)r arctan(√(sin⁽¹⁺¹⁾((φ2 - φ1) / (1+1)) + cos(φ1) cos(φ2) sin⁽¹⁺¹⁾(λ2 - λ1)) / √(1 - sin⁽¹⁺¹⁾((φ2 - φ1) / (1+1)) + cos(φ1) cos(φ2) sin⁽¹⁺¹⁾(λ2 - λ1)))

Furthermore we can see that the original formulation is equally valid and that didn't include any numbers at all, so basically, the number base is utterly irrelevant to haversine.

Saying haversine doesn't use binary numbers is a non sequitur, you can equally say haversine doesn't use decimal numbers either.

47

Flat Earth Theory / Re: Are plane tickets real?

« on: April 24, 2020, 08:47:13 AM »

He's nitpicking over rounding distances to the nearest cm.

This is math. If I put two numbers onto a website which says that it adds two numbers and I put the number 1 in twice and the answer is 2.0000000005 then the code that's running on that website, VERY VERY clearly is not adding two numbers. If it was then the answer would have been 2.0000000000. So when it comes to mathematical functions like this the results of a formula like haversine can only have one answer.

If I took a math test and I put 1 + 1 = 1.9999999999999999999999999999995

the answer is WRONG. I get an F on my test. My math teacher is a troll! Nit picking over such a small variance!!!!! I guess every math teacher and match major, and engineer is a troll.

I know that my last post takes away the whole rounding issue in relation to Bing, but I want to come back to this exact answer nonsense because you keep saying things like this and you are wrong.

Suppose I say to you what's 1/3 + 2/3. The answer is obvious, right? But suppose I say write the two numbers down as decimals and then add them by hand...

0.3333333333.......
0.6666666666.......
----------------------
0.9999999999.......

No matter how many digits you pick, the answer is 0.999..... etc. The only way you can ever get the correct answer from this is if you round the answer up. If you insist on never rounding, you can never make this add up to 1.

Now try this: https://jsfiddle.net/jbcq3x95/. Put in 0.75 for A and 0.75 for B and press the "Add" button. As expected the answer is exactly 1.5, but now try 0.1 + 0.1. You get:

0.1 + 0.1 = 0.2000000000000000111022302462515654042363

So what's going on here? Computers work in binary. The number 0.1 in binary is 0.0001100110011[0011 repeated forever]. It's a simple number to deal with in base 10, but not in base 2, because you need an infinite number of bits and you don't have that, you actually have 53 (in a typical modern computer). That's why, when you add 0.1 and 0.1 together on a computer, you don't get 0.2 unless you round the answer.

Reciprocal powers of 2 in combination will always be fine, so 1/2, 1/4, 1/8, 1/16 etc. That's why 0.75 + 0.75 is exact because it's (1/2 + 1/4) + (1/2 + 1/4) and these are all reciprocal powers of 2.

48

Flat Earth Theory / Re: Are plane tickets real?

« on: April 23, 2020, 08:42:32 AM »

The fact is, after all of this, ALL of you should be fairly confident that the bing API is not 100% haversine. It's VERY clear that there is rounding and converting going on behind the scenes.

Microsoft probably is doing some rounding in addition to haversine, haversine being stated by them as to what they use. The fact of the matter is that their distances match globe earth calculations. If they clandestinely used some other calculation their distance output would be vastly different than, let's say, Google Maps - And it's not.

I'll hand it to iamcpc, he does get me thinking creatively.

The latest sticking point is rounding. That got me thinking. Could we bypass rounding altogether as an issue by preventing Bing from rounding any numbers? If I were writing their code, I'd use the Math.round function to round, so what if we could disable that function, get it to just return the unadulterated number instead of rounding it. Yep, that works a treat. Here is my hijack of the rounding function...

Code: [Select]

Math.round = function (v) { return v; };
I've included new code as an attachment as usual. As set up, our code does no actual rounding at all in our haversine distance calculation and we're not (yet) attempting to hijack the rounding function, so if you run it, expect to see something like this:

Comparison between 1000000 locations
Min variation 0.0000036mm
Max variation 5.0mm
Avg variation 2.5mm
Min variation(%) 4.3e-14
Max variation(%) 0.024
Avg variation(%) 2.5e-8
Min dist 0.01743km
Max dist 20037.494km
Avg dist 10014.35624km

As expected, because Bing is rounding and we aren't, we get a 5mm max variation. Note also that the min/max/avg distances are rounded to 5 decimal places for readability.

Now remove the // comments on line 2 of the code to engage the hijack of the rounding function and run again. This time, any attempt to round anywhere, either our code or Bing's won't do anything at all. Here's the result.

Comparison between 1000000 locations
Min variation 0.0mm
Max variation 0.0mm
Avg variation 0.0mm
Min variation(%) 0.0
Max variation(%) 0.0
Avg variation(%) 0.0
Min dist 0.07886966971510709km
Max dist 20037.506423042065km
Avg dist 10028.233812273153km

So now Bing's unrounded results are being compared with our unrounded results. There is no rounding going on at all and we still get a 100% match. Note also that the rounding of the min/max/avg distances to 5 decimal places isn't working either - as expected.

So there we go, all the argument about rounding is moot because there isn't any going on any more.

Note: Once you've hijacked the round function, it stays hijacked until the browser window is refreshed and the code re-pasted, so bear this in mind if you want to try turning this on and off.

49

Flat Earth Theory / Re: Are plane tickets real?

« on: April 22, 2020, 08:31:42 AM »

They were not the same until we did some creative rounding. I could make a distance formula and round it to the nearest light year. I could measure the length of my roof with a tape measure and round it down to 0 light years and it would match the haversine formula. Does that mean I used the haversine formula to measure my roof? No I used a tape measure.

This is probably one of the dumber arguments you've made and it's really showing that you simply don't want to believe you could be wrong.

He's nitpicking over rounding distances to the nearest cm. At this point, I think the most plausible explanation is that iamcpc was trolling all along. Someone who calls rounding distances on a map to the nearest cm "creative rounding" just cannot be serious.

I still haven't made up my mind. He (I'm just going to assume he to avoid horribly tortured sentences) is quite consistent in his views and the topics he tends to engage in and is quite willing to engage, so on balance, I'll give him the benefit of the doubt.

There is an understandable element of caution/cunning about some of his answers, always leaving a way out somewhere. For example he started off saying he trusted Bing's distances, but then later qualified that to mean driving and walking distances, leaving open the possibility of later on dismissing the "red pin" measurement tool which clearly does use the spherical haversine. I'm OK with that, I think it's all part of the game and doesn't necessarily mean he's trolling.

To be honest, I've enjoyed this discussion. It prompted me to research some quite interesting topics and I had fun developing the code I posted. When I started with the idea of testing Bing via code, I really didn't think it'd end up being 200 million values exactly matching with arbitrary distance limits and it would never have got anywhere near that without iamcpc's questioning and prodding. I do like a challenge.

I was pretty sure he would not (at least publicly) change his mind, but perhaps in private, we've introduced a little uncertainty, who knows.

50

Flat Earth Theory / Re: Are plane tickets real?

« on: April 21, 2020, 01:55:35 PM »

I'd say getting the exact results over two hundred million calculations is pretty solid evidence the methods are the same.

They were not the same until we did some creative rounding. I could make a distance formula and round it to the nearest light year. I could measure the length of my roof with a tape measure and round it down to 0 light years and it would match the haversine formula. Does that mean I used the haversine formula to measure my roof? No I used a tape measure.

If you'd like to go out and measure 200 million different roofs to the nearest 1cm and find some simple mathematical formula which would give identical results without needing to go anywhere or take any measurements at all, I reckon you'd make a few $1m from that.

And now we're back to silence, tumbleweed, nothing, nada, no response.

Dude you have gotten many many responses. It's hit an impasse. We're trying to guess at what the Bing API is doing without seeing the source code. The only thing that I have learned is that, if the bing API does use the haversine formula, it does some pretty creating rounding.

Yes I did and the topic was very active for a long while, but then you complained about not being able to work with small distances and complained about rounding, so I went away and within 24h produced an improved solution to deal with the distance limitations and (I thought) answered your question about rounding. Then it all went quiet for a week, so from my perspective, a very active discussion appeared to have died for no apparent reason. I'm glad that you have re-engaged, so thank you for that.

I don't understand what you mean by creative rounding. 200 million Bing results are being returned with answers given in km to 5 decimal places. That means a 1cm resolution. It doesn't make any sense at all to quote distances on this scale to nanometer accuracy so it's perfectly sensible for the developers to round these values and a 1cm resolution is a good choice. When you compare with a non-rounded haversine value, you end up with a max variation of 0.5cm. This is a dead giveaway that they are rounding to the nearest cm. It's not creative rounding at all, it's an entirely sensible way to do it and it's a very simple bit of basic detective work to figure out this is what they've done.

In other words, their getDistanceTo method isn't directly an implementation of Haversine

Hmmm welcome to what I've been weary of this entire time....

In much the same way as a pineapple in a paper bag isn't a pineapple, it's a pineapple in a paper bag. So what.

it is a method which uses an implementation of Haversine. It clearly does other things as well. For example you can ask it to return the distance in a number of different units: feet, kilometres, metres, miles, nautical miles or yards. It also rounds to the nearest cm. Just to be clear, haversine neither rounds nor converts, but the getDistanceTo function, which uses it, does both.

exactly why we need to see the source code to know for sure. These exercises have just shown that, without the source code, it's very difficult to know what exactly is happening.

There are only two possibilities left here. A) Microsoft are telling the truth and they are using haversine. The very extensive testing strongly supports that hypothesis. B) Microsoft have deliberately published misleading documentation which claims they are using haversine, when they are not.

For the sake of argument, let's assume the latter. Let's assume Microsoft have developed a distance method which is indistinguishable from a haversine formula distance, to the nearest 1cm over distances ranging from 0.1 to 20,000km. Why would they even bother doing this when they could just use the very simple haversine formula in the first place. What would be the point? Does it even matter if we can demonstrably swap out the Microsoft implementation for our own and literally nobody could tell the difference. Either Bing is based on a globe model or it isn't, but it might as well be because you literally can't tell the difference.

And having gone to all the trouble of developing a new method, so far unknown to mankind, which leads to results which are indistinguishable from haversine, they then decide to lie about it and claim it is haversine. They could self-evidently save themselves an awful lot of time, trouble and money by just doing what they say they do and use haversine.

You yourself have said on a number of occasions there is no such thing as proof, which means you investigate, gather evidence, weigh the evidence and decide on the balance of probability where the truth lies. The trouble is you are simultaneously ignoring overwhelming evidence, demanding absolute proof and yet claiming there is no such thing as absolute proof.

From time to time cases come before courts where one songwriter claims plagiarism because another is using their song or parts of it. A famous example is George Harrison's My Sweet Lord and the similarities with The Chiffon's He's So Fine. Imagine if the two pieces of music were literally identical in every way. Every note, every instrument, every word, melody, harmony, beat, everything identical and indistinguishable. Your argument is "well we're at an impasse Judge, we'll never know".

51

Flat Earth Theory / Re: Are plane tickets real?

« on: April 21, 2020, 09:02:55 AM »

...because the haversine formula does not include any rounding.

I realise I didn't address this point.

Just to refresh the memory, here's what the Bing documentation has to say (my emphasis)...

Calculate the distance between two locations on the surface of the earth using the Haversine formula.

In other words, their getDistanceTo method isn't directly an implementation of Haversine, it is a method which uses an implementation of Haversine. It clearly does other things as well. For example you can ask it to return the distance in a number of different units: feet, kilometres, metres, miles, nautical miles or yards. It also rounds to the nearest cm. Just to be clear, haversine neither rounds nor converts, but the getDistanceTo function, which uses it, does both.

My code didn't reflect that crucial difference and actually violates a principle of software design - single responsibility. My distance calculation function was doing two distinct jobs, directly calculating a haversine distance and then post-processing this result to give a rounded value in km. This is not what the Bing documentation says should happen, I should have a separate function which uses a pure implementation of haversine to get a result and then post-process the result.

So I've changed the code. Now I have a pure implementation of haversine (onlyHaversine) which does no conversion or rounding - just as you say it should - and a separate distanceUsingHaversine function which is the analogue of Bings getDistanceTo. The distanceUsingHaversine function now uses haversine (onlyHaversine), it does not implement haversine.

Functionally the code is identical. All I've done is split my original function in two and moved the code across so both functions now have a single job to do (the single responsibility principle).

One last thing. If you switch off the rounding, the max variation you see is exactly 5mm. What does that tell you? Well if Bing does round to the nearest cm, then that means values such as 1.50 cm get rounded up to 2, which is a 5mm difference. You can never get more than a 5mm variation when rounding to the nearest cm and if you have enough random numbers, you are bound to see a 5mm variation. The presence of a 5mm max variation actually tells you what rounding strategy they are using. I didn't spot this myself at first, but when you do, it's obvious isn't it.

52

Flat Earth Theory / Re: Are plane tickets real?

« on: April 20, 2020, 04:52:41 PM »

Comparison between 200000000 locations
Min variation 0.0mm
Max variation 0.0mm
Avg variation 0.0mm
Min variation(%) 0.0
Max variation(%) 0.0
Avg variation(%) 0.0
Min dist 0.10001km
Max dist 0.39999km
Avg dist 0.25km

i.e. Bing maps API distance calculations correlate 100% with an independently developed Haversine formula having compared distances between 200 million random pairs of locations.

So the jury have come back in...

On the charge of Bing documentation having been accused of being accurate when they assert they use the spherical Haversine formula for distance calculations - guilty as charged due to overwhelming evidence. Bing uses Haversine for distances.

On the charge of Bing maps distances having been accused of being "based on measured distances in our 3d world" (i.e. incorporating elevation changes) - case dismissed as the prosecution failed to provide any evidence whatsoever.

And now we're back to silence, tumbleweed, nothing, nada, no response.

There is still this issue of rounding which is very unclear to me. Is the variance on these short distances 0 because they are rounded down to the nearest KM which is 0 KM? If so then this is overwhelming evidence that the Bing API is not based on the haversine formula because the haversine formula does not include any rounding.

The implementation of haversine I am using is internally working in metres. The values it calculates are first rounded to 2 decimal places, i.e. to the nearest cm. Then the value is converted to km and returned.

The reason for rounding at all is simply that when I looked at the values Bing was returning, they appeared to have been rounded. I experimented with different roundings of my own and when I tried to the nearest cm rounding, suddenly all my results matched with Bings.

If I had rounded to the nearest 10cm or the nearest 0.1cm then the results would not match.

It's a similar to me asking you what is 1/6 as a decimal. If you give me the answer 0.17 rather then 0.167 or 0.1667, then I'm going to guess that you're giving me the answer rounded up to the nearest 2 decimal places, so if I then ask what is 2/3, I'm guessing you will be consistent and tell me 0.67 rather than 0.667 or anything else.

53

Flat Earth Theory / Re: Are plane tickets real?

« on: April 20, 2020, 09:38:22 AM »

A while back in this thread I said:

I originally got involved in this thread talking about distances on Bing maps. After a lot of back and forth discussion, I finished with a post where I showed the line of code calling the Bing API to calculate a distance, showed the official Bing documentation for this code, where it tells you they use the globe based Haversine formula. In my view, that's beyond reasonable doubt - Bing maps under the hood is clearly based on a Globe model. Since then, silence, tubleweed, nothing, nada, no response.

I get that people have lives and it's unreasonable to expect responses all the time, but I've seen this before. Once the scales start to tip irretrievably in the direction of the RE in a discussion, it dies silently.

That prompted a revival of the thread which was then very active right up until I posted a modified version of a piece of code which addressed all of the criticisms of the earlier versions. Specifically, this new code:

Allows you to specify very small distances to measure.
Allows you to specify a very large number of tests to perform and completes in a reasonable time.
Gives precisely identical results to the Bing API.

Just a reminder, here are the results for 200 million tests between 0.1 and 0.4km:

Comparison between 200000000 locations
Min variation 0.0mm
Max variation 0.0mm
Avg variation 0.0mm
Min variation(%) 0.0
Max variation(%) 0.0
Avg variation(%) 0.0
Min dist 0.10001km
Max dist 0.39999km
Avg dist 0.25km

i.e. Bing maps API distance calculations correlate 100% with an independently developed Haversine formula having compared distances between 200 million random pairs of locations.

So the jury have come back in...

On the charge of Bing documentation having been accused of being accurate when they assert they use the spherical Haversine formula for distance calculations - guilty as charged due to overwhelming evidence. Bing uses Haversine for distances.

On the charge of Bing maps distances having been accused of being "based on measured distances in our 3d world" (i.e. incorporating elevation changes) - case dismissed as the prosecution failed to provide any evidence whatsoever.

And now we're back to silence, tumbleweed, nothing, nada, no response.

54

Flat Earth Theory / Re: Are plane tickets real?

« on: April 14, 2020, 03:54:28 PM »

I ran it for 100 pairs at 0 to 10 km. It took a really, really long time to run. But when it completed, the results are as predicted (Chrome 80, Mac 10.15.3):

the issue that I have here is that the only way you were able to make them match was by rounding the number. The issue with that is that there could be one distance which is 1.1 KM away from another distance. When you round to the nearest kilometer we are unable to see those kinds of differences as demonstrated before when the numbers were different and you were not rounding.

When I looked at the values I was getting back from Bing, it looked to me like they had been rounded to the nearest cm, which IMHO is a reasonable thing for them to do. If you accept just for the sake of argument that they are using Haversine, that means they are using a perfect sphere as an approximation for an imperfectly shaped earth, so calculating distances to tiny fractions of a millimetre is a bit pointless. If I'm right, then to match the code I'm using with the Bing code, I need to do the same as they do.

If Bing are either not rounding at all or rounding to something else, such as the nearest mm or nearest metre then if I round my results (not Bing's, I'm not touching Bing's results at all) when I shouldn't or get the rounding wrong, I'll see a mismatch. On the other hand if my to-the-nearest-cm results match exactly with the unadulterated results from Bing, then I'm doing it right.

55

Flat Earth Theory / Re: Are plane tickets real?

« on: April 14, 2020, 03:32:34 PM »

Well inevitably the code is a bit more complex, so I'll explain what I've done.

I have a new function to generate a dependent pair of random locations. The start location is entirely random as before, generated in the same way.

Then I generate a vector in the form of a pair of numbers, a bearing and a distance. The bearing is just a random angle between 0 and 360. The distance is a random number between the min and max settings. If the max is set too high, then I just use 1/2 way around the world, i.e. around 20,000km instead to prevent any nasty overflows.

Then I add the vector to the start location to give me a destination a suitable distance away. This means all my generated pairs of locations are sensibly separated and I'm not having to throw anything away.

To make things a bit more flexible, the settings object now allows you to choose to use the old or new method for pair generation and whether or not you want any rounding. Without rounding, expect to see variations of up to 5mm or so. To change features, just comment out the one you don't want (add a // to comment) and uncomment the one you do want. I think you'll understand what I mean if you look at the code. So for example, use dontRound to avoid rounding and round2dp to round to 2 decimal places.

Web site to use is as before, https://www.bing.com/api/maps/sdk/mapcontrol/isdk/layerevents#TS

The code for Haversine and the code to allow me to add the vector come from https://www.movable-type.co.uk/scripts/latlong.html

56

Flat Earth Theory / Re: Are plane tickets real?

« on: April 13, 2020, 09:50:13 PM »

Seems to be working fine for me.  Chrome on Windows 10.

It looks like it's because I made some changes to the minimum and maximum distances. I wanted to try a few distances that were between 8 and 10 KM or a few that were between .1 and .4 KM. It ran for 10 minutes trying to do one comparison with a min distance of .4 and a max distance of .4. Very strange that this thing is unable to do smaller distances.


I feel like, if we are going to compare distances, the smallest distance should be something less than 756 KM. Why is it that we are unable to do 100 samples of 0-1 KM and 100 samples of 2-10 KM etc.

Ah, OK that makes sense. The way it works is that it generates a completely random pair of locations, which could be any distance apart, then works out the distance between them. If this distance falls outside the min/max distance setting then it is discarded and it just generates another pair and tries again and again until it gets a good pair. This is simple to implement, but wasteful. If your distance range is set to 0 - 20,000km, then every pair will be within range so you'll generate (say) 1000 pairs and all 1000 are valid. Halve that range and you'll have to generate twice as many pairs to get 1000 useful ones etc. etc. The smaller the range, the worse it gets.

If you are trying to use a range of say 2 - 10km, then you're probably generating thousands or maybe even millions of out of range ones just to get one in range. I did wonder about making the pair generation a bit more intelligent, but wanted to keep the code simple and easy to understand.

I'll have a think about this and come up with an improved version.

57

Flat Earth Theory / Re: Are plane tickets real?

« on: April 13, 2020, 04:07:52 PM »

It occurred to me following my last post that the results given by the independent implementation of Haversine and Bing are so very close that perhaps there was an extra step I could take to eliminate the difference altogether. I had another look at the rounding idea and realised that I'd converted a result to km and then rounded it, so out of interest, I tried this the other way around, i.e. round first and then convert to km.


Code is included as an attachment to this post as before. Instructions to run as per my earlier post.

I'm not getting any results. I got the website, I put the code in, i hit the play button and nothing happens. I'm only trying to do 100 locations. It just says "Page Unresponsive". What browser are you using to do this?

Chrome on Windows 10.

Also just tried it in Edge and Internet Explorer 11. Works on all 3 for me.

Did you just change nlocations in settings (to 100) or anything else?

58

Flat Earth Theory / Re: Are plane tickets real?

« on: April 12, 2020, 03:13:29 PM »

It occurred to me following my last post that the results given by the independent implementation of Haversine and Bing are so very close that perhaps there was an extra step I could take to eliminate the difference altogether. I had another look at the rounding idea and realised that I'd converted a result to km and then rounded it, so out of interest, I tried this the other way around, i.e. round first and then convert to km.

Now the results look like this:

Comparison between 1000000 locations
Min variation 0.0mm
Max variation 0.0mm
Avg variation 0.0mm
Min variation(%) 0.0
Max variation(%) 0.0
Avg variation(%) 0.0
Min dist 4km
Max dist 20029km
Avg dist 10014km

So no further excuses, this version of Haversine correlates 100% with the results from Bing over a million random pairs of distances.

Code is included as an attachment to this post as before. Instructions to run as per my earlier post.

59

Flat Earth Theory / Re: Are plane tickets real?

« on: April 12, 2020, 07:53:08 AM »

Well lets use millimeters then. A=1,000,000mm, B=1,000,000mm, what is the exact value of C?

I'm not asking for the EXACT value of C i'm asking for the correct answer down to the millimeter. Which your information has CLEARLY demonstrated that the calculations are not the same providing VERY clear evidence that the claims made on the Bing website are not 100% accurate. Or they are vague intentionally.

Oh you are not asking for the exact value? You just need it to the nearest millimetre and then you'll be happy. 5mm is too much, but to the nearest 1mm is OK.

Well then it's your lucky day. It occurred to me that one possibility is that Bing is just simply reporting the answer with fewer decimal places than the independent version of Haversine, which would lead to a discrepancy between the answers. So I went back to the code and experimented, changing the number of decimal places to try and get closer to whatever Bing are using. And I hit paydirt!

Take the code I gave you (you do have it now don't you, I see someone has downloaded it successfully, hopefully it was you) and replace line 74 with:

Code: [Select]

updateStats(Math.round(d1 * 100000.0) / 100000.0, d2);  // Update stats for the two distances calculated
These are the results I get with that modification in place:

Comparison between 1000000 locations
Min variation 0.0mm
Max variation 0.0000036mm
Avg variation 4.0e-7mm
Min variation(%) 0.0
Max variation(%) 2.2e-14
Avg variation(%) 3.9e-15
Min dist 7km
Max dist 20026km
Avg dist 10021km

As you see, the max variation over a test of a million comparisons has gone down from 5mm to 0.0000036mm or 3.6 nanometers if you prefer.

Correct me if I'm wrong, but you said you wanted it down to the nearest 1mm, so you should be happy with 3.6 nanometers.

60

Flat Earth Theory / Re: Are plane tickets real?

« on: April 11, 2020, 09:04:48 PM »

And just to take your example of the hypotenuse calculator, what exactly is C going to be if A=1 and B=1? Actually I'll let you off if you give me the first 100 million digits of the answer. According to WikiPedia the current best answer to this question is from a guy called Ron Watkins who has worked it out to 10 trillion digits, so I'm really letting you off lightly you know.

 If the hypotenuse calculator used distances of over a billion millimeters  the answers would match down to the millimeter. In this situation they do not match when measuring distances of significantly less than a billion millimeters. How you are unable to understand that this is math and when putting variables into a formula there is only ONE possible correct answer. The answer is correct or incorrect.

If variables are plugged into formula A and the answer is 1 and then plugged into formula B and the answer is 1.000005 then they are NOT the same formula. Period. Case closed.

Well lets use millimeters then. A=1,000,000mm, B=1,000,000mm, what is the exact value of C?

Bear in mind that 1,000,000mm is exactly 1km, so this is exactly the same question as asking A=1km, B=1km, what is C?

I don't care what answer you write down for this, your answer is wrong. If you write down an answer to the nearest billionth of a nanometer, I can always add one extra decimal to that to make the answer more accurate. Give me 1 trillion decimal places and I can make the answer more accurate. So if you point me to any hypotenuse calculator in existence, whatever answer it gives, I can give you a more accurate one. That's the issue with this particular problem, the actual answer has an infinite number of decimal places, there is no such thing as ONE possible correct answer in your example. There is a theoretical answer and that's obviously in this case √2km, but since you can't ever write that down as a number, neither can you get a calculator or computer to compute it either.

And if you insist on using a billion millimeters, well I'll just invent a new unit, the kilo-kilometre (kkm) and then the problem is just A=1kkm, B=1kkm, what is C?