|
The actual route is decided by the pilot taking into account guidance from their airline so as a passenger you don't get any say on that unless the airline publishes that guidance in which case you can decide whether to use them or not.
In this case airspace was closed to commercial flights below 32000 foot and this was flying at 33000 which was believed to safe from the use of portable anti airraft weapons. Long range SAMs were not considered likely probably naively.
I suspect following this airlines will avoid the area totally.
|
|
|
|
|
The anti-Kiev fighters had just bragged about capturing some Buk systems. And as far as I know they have no airforce so the govt forces don't need to use SAMs. They also bragged about downing a plane other than the Su-25 and hastily deleted the brag once news of civilian aircraft vanishing appeared 
|
|
|
|
|
The Buk system seems to a Soviet / Russian equivalent to the US Patriot...
|
|
|
|
|
glennPattonPUB wrote: The Buk system seems to a Soviet / Russian equivalent to the US Patriot...
A moot point to the passengers of the ill fated flight. 
Once you lose your pride the rest is easy.
I would agree with you but then we both would be wrong.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
I was thinking, that you have to know what you are doing to use one. It's not telescopic sight, push the button thing there is a bit more to it...if the users knew enough to get a good launch, track & hit with it, they had to know what they were firing at was a Su-25...
|
|
|
|
|
glennPattonPUB wrote: if the users knew enough to get a good launch, track & hit with it, they had to know what they were firing at was a Su-25
They knew what they were firing and what their target was.
Once you lose your pride the rest is easy.
I would agree with you but then we both would be wrong.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
greldak wrote: In this case airspace was closed to commercial flights below 32000 foot and this was flying at 33000 which was believed to safe from the use of portable anti airraft weapons. Long range SAMs were not considered likely probably naively.
I suspect following this airlines will avoid the area totally.
One can hope.
Once you lose your pride the rest is easy.
I would agree with you but then we both would be wrong.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
3D Homunculus Nebula [^]
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
Wow, I think looks kinda like a shelled peanut, maybe a day with less caffeine is needed to make sense!
|
|
|
|
|
Four web browsers(opera, safari, firefox, chrome) reports the answer to the following calculation *incorrectly*:
((54/31)+140)
Those 4 browsers return the value : 141.74193548387098
IE reports the value of : 141.74193548387097
Note:The two leading #s in the next example are just for alignment.
if you calculate 54/31 using javascript and browser you get:
##1.7419354838709677
The second one calcs the same equation and simply adds 140 ((54/31)+140) -- to change precision.
141.74193548387098
Notice the digit after the last 9 in the sequence. The rounded up value should be a 7 (round up from 6), but it is reported as an 8 in every browser except IE. You can also compare the value to Windows Calculator for 54/31.
Windows calculator gives : 1.7419354838709677419354838709677
Interesting?
Here's the HTML / JavaScript so you can copy / paste and try in all browsers:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
</head>
<body>
<div>Clicking the [Calc] button runs two calculations and shows the result on this page. First calc is: (54/31)</div>
<span style="color:red">Note:</span><span>The two leading #s are just for alignment.</span>
<p id="p1">
</p>
<p id="p2">
</p>
<div>The second one calcs the same equation and simply adds 140 ((54/31)+140) -- to change precision.</div>
<div id="extra" style="color:blue"></div>
<input type="button" value="Calc" onclick="DoCalc()"/>
<script type="text/javascript">
var p1 = document.getElementById("p1");
var p2 = document.getElementById("p2");
var extra = document.getElementById("extra");
function DoStart()
{
testdiv.textContent = "started";
}
function DoCalc()
{
p1.textContent = "";
p1.textContent += "##" + 54/31;//calcObject1.y / calcObject2.x;
var outval = ((54/31)+140);
p2.textContent = outval.toString();
extra.textContent = "Notice the digit after the last 9 in the sequence.";
extra.textContent += " The rounded up value should be a 7 (round up from 6), but it is reported as an 8 in every browser except IE.";
extra.textContent += " You can also compare the value to Windows Calculator for 54/31. Interesting?";
}
</script>
</body>
</html>
|
|
|
|
|
That's in the 17th SF so I think it's just hitting double precision. I get the same (apparently) wrong answer using double precision arithmetic in .Net too. If I use arbitrarily extended precision I get
141.74193548387096774193548387096774193548387096774193548387096774...
... which seems right as it's a repeating fraction.
I guess IE's JS engine uses some extended precision (128 bit?) floating point API behind the scenes.
|
|
|
|
|
That didn't really prove anything yet. I'll do the math though, will report back.
Ok then, the results are in. And guess what: it's IE that's wrong.
(54.0 / 31.0) + 140.0 evaluated with IEEE 754 doubles in Round to Nearest mode (as JavaScript demands, right?) gives exactly:
141.741935483870975076570175588130950927734375 (exact representation of the correct result)
141.74193548387097 (ie)
141.74193548387098 (correct conversion to 17 digits)
That 54/31 seems to give 1.7419354838709677 is really irrelevant, because
0) that's not what it gives. It gives 1.7419354838709677490982130620977841317653656005859375 (exactly).
1) a Number in JS is not a 17-digit decimal string that is manipulated like we learn in elementary school, it's a an IEEE 754 double.
modified 17-Jul-14 12:28pm.
|
|
|
|
|
That's very interesting. And as long as someone is wrong I'm happy.
Now, it just makes it all the better that IE is wrong. But that would /should mean that Windows Calculator is also wrong, because it gives same answer as IE.
|
|
|
|
|
Windows Calculator doesn't give the same answer as IE, it gives 141.74193548387096774193548387097. That would round to the string IE is displaying, but it doesn't round it so it's not the same.
Anyway, Windows Calculator doesn't make the same promise as JS. The help page says:
> In Scientific mode, Calculator is precise to 32 significant digits.
That's completely different from "IEEE doubles in Round to Nearest mode".
|
|
|
|
|
Oh, okay. You got good info. It's funny how it all seems right and the same til you start looking at this stuff up close.
Thanks for posting.
|
|
|
|
|
Since the precision significant digits for the equation has no decimals should the answer (rounded) not be 142?
At the most 141.7419 should be the answer.
[Edit]remembered correct phrase[/edit]
|
|
|
|
|
|
LOL!  I found this a long time ago and had no one to share it with. You are the lucky ones. 
|
|
|
|
|
That's the 14th decimal place? Close enough.
Are you trying to plot the position of a particle on the other side of the galaxy or something? 
|
|
|
|
|
using this code:
decimal value = (54M / 31M) + 140M; , you get this answer (every time): 141.74193548387096774193548387
---------------------------
using this code:
double value = (54d / 31d) + 140d; , you get this answer (most of the time): 141.74193548387098
---------------------------
using this code:
double value = (54 / 31) + 140; , you get this answer (every time): 141.0
---------------------------
What's your point? All of your examples are wrong because you're using floating point math.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Mr. Dale Carnegie's first rule of Winning Friends & Influencing People is "Never tell a person they are wrong."
Also, there is no Decimal type in JavaScript and my original runs in JavaScript. Nor is there any double type.
Well, not really.
Also, did you run the JavaScript sample in IE? Then you would've gotten the udder answer.
Also, I have not point. It was just math for fun.
thx.
|
|
|
|
|
I don't really care about what types are/are not available in Javascript. The simple fact of the matter is that it's using floating point math to do it, and you're never going to be absolutley sure about what you're gonna get back for the last digit because of that fact.
And what the hell is wrong with you? Math is NOT fun. I've been doing trig in code for the last week or so, and I kinda hate it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: And what the hell is wrong with you? Math is NOT fun.
Agree with you there. I bet the wizards come out and bash their math clubs upon our noggin's now.
|
|
|
|
|
John Simmons / outlaw programmer wrote: Math is NOT fun.
Those are fighting words.
[Picard voice] To each his own, #1.
|
|
|
|
|
The real head-spinner for me is that all of the browsers could (and hopefully should) have calculated exactly the same value.
The 'bug' could be in the converting to decimal for displaying.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
