Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98489 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-12-09 13:26 +0100 |
| Last post | 2016-12-13 14:30 -0500 |
| Articles | 20 on this page of 121 — 28 participants |
Back to article view | Back to comp.lang.c
Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 13:26 +0100
Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 12:44 +0000
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 14:53 +0100
Re: Mars lander crash already5chosen@yahoo.com - 2016-12-09 05:58 -0800
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:11 +0100
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 16:56 +0100
Re: Mars lander crash supercat@casperkitty.com - 2016-12-09 08:51 -0800
Re: Mars lander crash already5chosen@yahoo.com - 2016-12-11 02:23 -0800
Re: Mars lander crash Gareth Owen <gwowen@gmail.com> - 2016-12-11 10:57 +0000
Re: Mars lander crash "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 12:34 -0500
Re: Mars lander crash Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 23:33 -0600
Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 14:22 +0000
Re: Mars lander crash asetofsymbols@gmail.com - 2016-12-09 06:30 -0800
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:48 +0100
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:46 +0100
Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 14:55 +0000
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:08 +0100
Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 15:52 +0000
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 17:35 +0100
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 18:35 +0100
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 19:10 +0100
Re: Mars lander crash "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 19:18 -0500
Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-09 16:49 -0800
Re: Mars lander crash "J. Clarke" <j.clarke.873638@gmail.com> - 2016-12-20 20:03 -0500
Re: Mars lander crash <william@wilbur.25thandClement.com> - 2016-12-09 22:04 -0800
Re: Mars lander crash supercat@casperkitty.com - 2016-12-10 10:59 -0800
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 13:22 +0100
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 14:18 +0100
Re: Mars lander crash already5chosen@yahoo.com - 2016-12-11 06:03 -0800
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 15:08 +0100
Re: Mars lander crash already5chosen@yahoo.com - 2016-12-11 06:20 -0800
Re: Mars lander crash luser droog <luser.droog@gmail.com> - 2016-12-11 07:08 -0800
Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 11:56 -0800
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 21:05 +0100
Re: Mars lander crash jameskuyper@verizon.net - 2016-12-11 12:57 -0800
Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 21:26 +0000
Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 09:23 -0800
Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 14:01 +0000
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 15:11 +0100
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 18:57 +0100
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 19:23 +0100
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 19:55 +0100
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 20:52 +0100
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 23:37 +0100
Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 16:10 -0800
Re: Mars lander crash BartC <bc@freeuk.com> - 2016-12-12 01:13 +0000
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 09:53 +0100
Re: Mars lander crash supercat@casperkitty.com - 2016-12-12 08:30 -0800
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 09:25 +0100
Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 10:36 -0800
Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 18:46 +0000
Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 09:12 -0800
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 18:53 +0100
Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 12:09 -0800
Re: Mars lander crash Jean-Marc Bourguet <jm@bourguet.org> - 2016-12-11 21:30 +0100
Re: Mars lander crash Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-11 15:50 -0500
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 23:02 +0100
Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 18:29 -0800
Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 12:03 -0800
Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 11:55 -0800
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 23:42 +0100
Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 14:53 -0800
Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 17:09 +1300
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 10:00 +0100
Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 22:20 +1300
Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 01:28 -0800
Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 22:38 +1300
Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 02:43 -0800
Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-13 08:20 +1300
Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 12:57 -0800
Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-13 14:14 +1300
Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 01:19 -0800
Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-13 22:56 +1300
Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:16 -0800
Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-14 18:05 +1300
Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-13 08:19 -0800
Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 17:01 +0000
Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 10:48 -0800
Re: Mars lander crash Geoff <geoff@invalid.invalid> - 2016-12-13 11:56 -0800
Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 13:37 -0800
Re: Mars lander crash Geoff <geoff@invalid.invalid> - 2016-12-13 19:11 -0800
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-13 20:13 +0100
Re: Mars lander crash supercat@casperkitty.com - 2016-12-13 11:45 -0800
Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 23:10 +0000
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-14 10:18 +0100
Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 12:37 +0000
Re: Mars lander crash Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:31 -0800
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-15 13:26 +0100
Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 22:40 +1300
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 13:22 +0100
Re: Mars lander crash supercat@casperkitty.com - 2016-12-12 08:35 -0800
Re: Mars lander crash supercat@casperkitty.com - 2016-12-09 08:43 -0800
Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 09:47 -0500
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:11 +0100
Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:49 -0500
Re: Mars lander crash already5chosen@yahoo.com - 2016-12-09 05:53 -0800
Re: Mars lander crash asetofsymbols@gmail.com - 2016-12-09 06:04 -0800
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:09 +0100
Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:06 -0500
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:32 +0100
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 17:30 +0100
Re: Mars lander crash BartC <bc@freeuk.com> - 2016-12-09 16:42 +0000
Re: Mars lander crash Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-09 11:43 -0500
Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-09 08:59 -0800
Re: Mars lander crash "J. Clarke" <j.clarke.873638@gmail.com> - 2016-12-20 19:36 -0500
Re: Mars lander crash "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-09 06:46 -0800
Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 14:57 +0000
Re: Mars lander crash Noob <root@127.0.0.1> - 2016-12-09 16:07 +0100
Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:03 +0100
Re: Mars lander crash "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 12:41 -0500
Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:52 -0500
Re: Mars lander crash jameskuyper@verizon.net - 2016-12-09 12:13 -0800
Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 21:56 +0100
Re: Mars lander crash jameskuyper@verizon.net - 2016-12-09 14:11 -0800
Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:46 -0500
Re: Mars lander crash <william@wilbur.25thandClement.com> - 2016-12-09 22:34 -0800
Re: Mars lander crash James Kuyper <jameskuyper@verizon.net> - 2016-12-10 18:38 -0500
Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 06:06 -0800
Re: Mars lander crash "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-10 01:17 +0800
Re: Mars lander crash Ken Brody <kenbrody@spamcop.net> - 2016-12-13 14:28 -0500
Re: Mars lander crash Ken Brody <kenbrody@spamcop.net> - 2016-12-13 14:30 -0500
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-09 17:30 +0100 |
| Message-ID | <o2em4j$43v$1@dont-email.me> |
| In reply to | #98499 |
Le 09/12/2016 à 14:53, already5chosen@yahoo.com a écrit : > On Friday, December 9, 2016 at 2:27:05 PM UTC+2, jacobnavia wrote: >> The european mars lander hitted the mars surface at 300Km/hr >> >> What happened? >> >> The altimeter when started working (after the heath shield separation) >> gave wrong data during one second. >> >> The software wasn't prepared for an overflow, and took that wrong data >> at face value, what produced a NEGATIVE altitude. >> >> The lander then, thinking it had already landed, stopped the rocket >> motors and started the sequence for after the landing, hitting the >> ground at more than 200 Km per hour. >> >> Overflows are dangerous stuff. >> >> But not everything went bad. The altitude was calculated much faster >> than what it would, if they would have tested for overflow at each >> operation. >> >> Speed is important for software. Not the results. > > According your own description, there was no overflow. > Sounds like floating point was used everywhere and all numerics worked out perfectly. How do you explain that the height was negative? Overflows make positive quantities become negative. I do not see how else this could be accounted for.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-09 16:42 +0000 |
| Message-ID | <o2emr6$74d$1@dont-email.me> |
| In reply to | #98554 |
On 09/12/2016 16:30, jacobnavia wrote: > Le 09/12/2016 à 14:53, already5chosen@yahoo.com a écrit : >> According your own description, there was no overflow. >> Sounds like floating point was used everywhere and all numerics worked >> out perfectly. > > How do you explain that the height was negative? > Overflows make positive quantities become negative. 3-5 is negative. But there is no overflow. But suppose it was an overflow; are you suggesting this check would have been during the landing? If so, what would the code have been able to do if such as overflow was triggered? Try the same (wrong) code again? Abort the landing (which sounds unlikely if there was no provision for getting back into orbit)? File a failure report before signing off? (I would have expected anyway that multiple cpus would be running the same control software but which were programmed by different teams, Space shuttle style, or possibly as already happens with avionics. With a majority vote taken.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2016-12-09 11:43 -0500 |
| Message-ID | <o2ems9$78o$1@dont-email.me> |
| In reply to | #98554 |
On Friday December 9 2016 11:30, in comp.lang.c, "jacobnavia" <jacob@jacob.remcomp.fr> wrote: > Le 09/12/2016 à 14:53, already5chosen@yahoo.com a écrit : >> On Friday, December 9, 2016 at 2:27:05 PM UTC+2, jacobnavia wrote: >>> The european mars lander hitted the mars surface at 300Km/hr >>> >>> What happened? >>> >>> The altimeter when started working (after the heath shield separation) >>> gave wrong data during one second. >>> >>> The software wasn't prepared for an overflow, and took that wrong data >>> at face value, what produced a NEGATIVE altitude. >>> >>> The lander then, thinking it had already landed, stopped the rocket >>> motors and started the sequence for after the landing, hitting the >>> ground at more than 200 Km per hour. >>> >>> Overflows are dangerous stuff. >>> >>> But not everything went bad. The altitude was calculated much faster >>> than what it would, if they would have tested for overflow at each >>> operation. >>> >>> Speed is important for software. Not the results. >> >> According your own description, there was no overflow. >> Sounds like floating point was used everywhere and all numerics worked out >> perfectly. > > How do you explain that the height was negative? I don't. I would leave /that/ up to the scientists, engineers and programmers who designed and built the spacecraft. > Overflows make positive quantities become negative. > > I do not see how else this could be accounted for. 1) Who says that the spacecraft ran code written in C? 2) Who says that the code didn't take the wrong root of a sqrt() value? Remember, there are two square roots of any positive number, one positive square root and one NEGATIVE square root 3) Who says that there wasn't some sort of data corruption / buffer overwrite involved? There /is/ a sign-bit in a floatingpoint number, after all, and that could be flipped from positive to negative by anything from stray cosmic rays to a buffer overwrite. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-09 08:59 -0800 |
| Message-ID | <lna8c5yr6c.fsf@kst-u.example.com> |
| In reply to | #98554 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 09/12/2016 à 14:53, already5chosen@yahoo.com a écrit :
[...]
>> According your own description, there was no overflow.
>> Sounds like floating point was used everywhere and all numerics
>> worked out perfectly.
>
> How do you explain that the height was negative?
> Overflows make positive quantities become negative.
>
> I do not see how else this could be accounted for.
Quoting the article that already5chosen@yahoo.com linked to
http://spacenews.com/esa-mars-lander-crash-caused-by-1-second-inertial-measurement-error/
The European Space Agency on Nov. 23 said its Schiaparelli
lander’s crash landing on Mars on Oct. 19 followed an
unexplained saturation of its inertial measurement unit, which
delivered bad data to the lander’s computer and forced a
premature release of its parachute.
Polluted by the IMU data, the lander’s computer apparently thought
it had either already landed or was just about to land. The
parachute system was released, the braking thrusters were fired only
briefly and the on-ground systems were activated.
[...]
“[T]he erroneous information generated an estimated
altitude that was negative,” ESA said. “That is, below
ground level. This in turn successively triggered a premature
release of the parachute and the back shell, a brief firing of
the braking thrusters and finally activation of the on-ground
systems as if Schiaparelli had already landed.
“In reality, the vehicle was still at an altitude of around
3.7 kilometers.”
So the root cause was a problem with the inertial measurement unit
(IMU), described as an "unexplained saturation". Note the word
"unexplained". Apparently the people investigating this still
don't know what caused the saturation.
Sure, it could have been an unhandled numeric overflow in software
running in the IMU -- but there isn't enough information in the
article to know that. For all we know, it could have been a
hardware problem.
(I'm curious to see how you'll manage to interpret this as a
personal insult.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-12-20 19:36 -0500 |
| Message-ID | <MPG.32c398887559e1c898a817@news.eternal-september.org> |
| In reply to | #98554 |
In article <o2em4j$43v$1@dont-email.me>, jacob@jacob.remcomp.fr says... > > Le 09/12/2016 à 14:53, already5chosen@yahoo.com a écrit : > > On Friday, December 9, 2016 at 2:27:05 PM UTC+2, jacobnavia wrote: > >> The european mars lander hitted the mars surface at 300Km/hr > >> > >> What happened? > >> > >> The altimeter when started working (after the heath shield separation) > >> gave wrong data during one second. > >> > >> The software wasn't prepared for an overflow, and took that wrong data > >> at face value, what produced a NEGATIVE altitude. > >> > >> The lander then, thinking it had already landed, stopped the rocket > >> motors and started the sequence for after the landing, hitting the > >> ground at more than 200 Km per hour. > >> > >> Overflows are dangerous stuff. > >> > >> But not everything went bad. The altitude was calculated much faster > >> than what it would, if they would have tested for overflow at each > >> operation. > >> > >> Speed is important for software. Not the results. > > > > According your own description, there was no overflow. > > Sounds like floating point was used everywhere and all numerics worked out perfectly. > > How do you explain that the height was negative? > Overflows make positive quantities become negative. > > I do not see how else this could be accounted for. You're at 3700 meters altitude and descending. Your inertial sensor glitches and says that you're going 9999 meters/sec for one second. So subtract 9999 from 3700 and what do you get? Where's the "overflow"?
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-09 06:46 -0800 |
| Message-ID | <11f217dd-d725-48c3-8dd2-829e67033675@googlegroups.com> |
| In reply to | #98489 |
On Friday, December 9, 2016 at 7:27:05 AM UTC-5, jacobnavia wrote:
> The european mars lander hitted the mars surface at 300Km/hr
>
> What happened?
>
> The altimeter when started working (after the heath shield separation)
> gave wrong data during one second.
>
> The software wasn't prepared for an overflow, and took that wrong data
> at face value, what produced a NEGATIVE altitude.
>
> The lander then, thinking it had already landed, stopped the rocket
> motors and started the sequence for after the landing, hitting the
> ground at more than 200 Km per hour.
I thought there was an error due to English units / Metric units
conversion. This was the 1999 crash. Is there a newer one?
http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/
"NASA lost a $125 million Mars orbiter because a Lockheed Martin
engineering team used English units of measurement while the
agency's team used the more conventional metric system for a key
spacecraft operation, according to a review finding released
Thursday."
> Overflows are dangerous stuff.
>
> But not everything went bad. The altitude was calculated much faster
> than what it would, if they would have tested for overflow at each
> operation.
>
> Speed is important for software. Not the results.
I disagree with this statement notably. Speed is important for
software, but only when it is simultaneously producing correct
results. The two must work hand-in-hand otherwise it is a flawed
and useless tool.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-09 14:57 +0000 |
| Message-ID | <o2eglv$d3o$2@dont-email.me> |
| In reply to | #98508 |
On 09/12/16 14:46, Rick C. Hodgin wrote: > On Friday, December 9, 2016 at 7:27:05 AM UTC-5, jacobnavia wrote: >> The european mars lander hitted the mars surface at 300Km/hr >> >> What happened? >> >> The altimeter when started working (after the heath shield separation) >> gave wrong data during one second. >> >> The software wasn't prepared for an overflow, and took that wrong data >> at face value, what produced a NEGATIVE altitude. >> >> The lander then, thinking it had already landed, stopped the rocket >> motors and started the sequence for after the landing, hitting the >> ground at more than 200 Km per hour. > > I thought there was an error due to English units / Metric units > conversion. This was the 1999 crash. Is there a newer one? Yes. Look up "ExoMars". 19 October 2016. <snip> >> Speed is important for software. Not the results. > > I disagree with this statement notably. So does Jacob. He's not good at sarcasm, at least not in English. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-12-09 16:07 +0100 |
| Message-ID | <o2eh9v$djf$1@dont-email.me> |
| In reply to | #98513 |
On 09/12/2016 15:57, Richard Heathfield wrote: > So does Jacob. He's not good at sarcasm, at least not in English. Jacob's posts are great for fine-tuning one's irony detector.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 16:03 +0100 |
| Message-ID | <o2eh1j$eun$1@dont-email.me> |
| In reply to | #98508 |
On 09/12/16 15:46, Rick C. Hodgin wrote: > On Friday, December 9, 2016 at 7:27:05 AM UTC-5, jacobnavia wrote: >> The european mars lander hitted the mars surface at 300Km/hr >> >> What happened? >> >> The altimeter when started working (after the heath shield separation) >> gave wrong data during one second. >> >> The software wasn't prepared for an overflow, and took that wrong data >> at face value, what produced a NEGATIVE altitude. >> >> The lander then, thinking it had already landed, stopped the rocket >> motors and started the sequence for after the landing, hitting the >> ground at more than 200 Km per hour. > > I thought there was an error due to English units / Metric units > conversion. This was the 1999 crash. Is there a newer one? > > http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/ > > "NASA lost a $125 million Mars orbiter because a Lockheed Martin > engineering team used English units of measurement while the > agency's team used the more conventional metric system for a key > spacecraft operation, according to a review finding released > Thursday." > I think that was a different crash. American rocket engineers manage to make some very impressive systems despite the ridiculous handicap of using Imperial units. Imagine where they would be now without having to deal with that nonsense. >> Overflows are dangerous stuff. >> >> But not everything went bad. The altitude was calculated much faster >> than what it would, if they would have tested for overflow at each >> operation. >> >> Speed is important for software. Not the results. > > I disagree with this statement notably. Speed is important for > software, but only when it is simultaneously producing correct > results. The two must work hand-in-hand otherwise it is a flawed > and useless tool. > I believe Jacob was being sarcastic. Sometimes it is hard to tell. You are correct, of course, that speed is subservient to correctness. Note that in many systems, especially control systems, correctness also includes timing aspects - if the results are not available on time, the system is not "correct". And even in systems that are not time-critical, usually speed is of at least /some/ relevance. It may be that Deep Thought would have given the correct question for the answer 42, but with a 7 million year run-time, it was not that helpful.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-09 12:41 -0500 |
| Message-ID | <e6676af1-12bc-e2ee-9989-f1579174e05c@verizon.net> |
| In reply to | #98514 |
On 12/09/2016 10:03 AM, David Brown wrote: > On 09/12/16 15:46, Rick C. Hodgin wrote: ... >> http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/ >> >> "NASA lost a $125 million Mars orbiter because a Lockheed Martin >> engineering team used English units of measurement while the >> agency's team used the more conventional metric system for a key >> spacecraft operation, according to a review finding released >> Thursday." >> > > I think that was a different crash. > > American rocket engineers manage to make some very impressive systems > despite the ridiculous handicap of using Imperial units. Imagine where > they would be now without having to deal with that nonsense. I've been working on one NASA project since 1996, and added a second one a few years ago. I can't remember ever seeing anything other than metric units used anywhere in connection with either project. Note that it was NASA which specified metric, and Lockheed Martin which failed to meet specifications.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 10:52 -0500 |
| Message-ID | <o2ejtl$p7q$2@jstuckle.eternal-september.org> |
| In reply to | #98508 |
On 12/9/2016 9:46 AM, Rick C. Hodgin wrote: > On Friday, December 9, 2016 at 7:27:05 AM UTC-5, jacobnavia wrote: >> The european mars lander hitted the mars surface at 300Km/hr >> >> What happened? >> >> The altimeter when started working (after the heath shield separation) >> gave wrong data during one second. >> >> The software wasn't prepared for an overflow, and took that wrong data >> at face value, what produced a NEGATIVE altitude. >> >> The lander then, thinking it had already landed, stopped the rocket >> motors and started the sequence for after the landing, hitting the >> ground at more than 200 Km per hour. > > I thought there was an error due to English units / Metric units > conversion. This was the 1999 crash. Is there a newer one? > > http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/ > > "NASA lost a $125 million Mars orbiter because a Lockheed Martin > engineering team used English units of measurement while the > agency's team used the more conventional metric system for a key > spacecraft operation, according to a review finding released > Thursday." > >> Overflows are dangerous stuff. >> >> But not everything went bad. The altitude was calculated much faster >> than what it would, if they would have tested for overflow at each >> operation. >> >> Speed is important for software. Not the results. > > I disagree with this statement notably. Speed is important for > software, but only when it is simultaneously producing correct > results. The two must work hand-in-hand otherwise it is a flawed > and useless tool. > > Best regards, > Rick C. Hodgin > Reminds me of a cartoon I saw back in the 70's. Two scientists standing in front of a two story high computer, looking at a piece of paper coming out of a slot in front. The caption was something like: "Amazing. It would take 473 mathematicians 328 years to make a mistake this big!". Bad results are worse than no results at all. Would you rather have your doctor give you a fast diagnosis - or a correct one? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-09 12:13 -0800 |
| Message-ID | <8cdb804e-14be-4735-a1cf-e3e1e1790233@googlegroups.com> |
| In reply to | #98537 |
On Friday, December 9, 2016 at 10:52:45 AM UTC-5, Jerry Stuckle wrote: ... > Bad results are worse than no results at all. Would you rather have > your doctor give you a fast diagnosis - or a correct one? Often, there's a deadline for making a decision about something (such as an incoming nuclear missile). A quick calculation might have a 20% chance of being wrong, but when it's right, it will save your life. A slower, more accurate calculation might have only a 0.5% chance of being wrong, but the result will never arrive until it's already too late do do anything about it. Which would you prefer?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-09 21:56 +0100 |
| Message-ID | <o2f5nt$4mr$1@dont-email.me> |
| In reply to | #98606 |
I do not see any point in sacrificing safety for speed. The problem with overflows is that they decay in a dramatic fashion. A huge quantity can become a small positive number, for instance. If you handle overflow you can "peg" the variable to its maximum value, instead of warping around. That would mean that INT_MAX+1 is INT_MAX, and the meaning of INT_MAX is just that it is equal or BIGGER than INT_MAX. That way, you do not change sign and comparisons for less or greater will still work. You are proposing ridiculous alternatives: If a missile is coming your way, you want an EXACT calculation and not a bogus one at ANY price. Then, you handle overflow and in case of any error, you can STILL have a correct chance that the software degrades gracefully, not with fatal consequences because you have forethought about the problem. If you have just to write a function that you pass to signal() and you can receive info about the place of the overflow, and you can choose either to restart, return a maximum value, whatever you think is best in the context of your application. And that, in a portable way, not relying on obscure compiler switches that will have to be changed at each compiler in a new environment. I do not think that an extension of the C standard to handle in a standard way standard signals would be too much effort. The signals DIV BY ZERO, OVERFLOW, (integer, floating) ARRAY OUT OF BOUNDS could be standardized and if the underlying system supports them, they would have a standard meaning.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-09 14:11 -0800 |
| Message-ID | <72d8abd1-46b0-44f4-b250-4387858ff197@googlegroups.com> |
| In reply to | #98609 |
On Friday, December 9, 2016 at 3:56:53 PM UTC-5, jacobnavia wrote: > I do not see any point in sacrificing safety for speed. > > The problem with overflows is that they decay in a dramatic fashion. > A huge quantity can become a small positive number, for instance. > > If you handle overflow you can "peg" the variable to its maximum value, > instead of warping around. > > That would mean that INT_MAX+1 is INT_MAX, and the meaning of INT_MAX is > just that it is equal or BIGGER than INT_MAX. That way, you do not > change sign and comparisons for less or greater will still work. > > You are proposing ridiculous alternatives: If a missile is coming your > way, you want an EXACT calculation and not a bogus one at ANY price. There's intermediate states between exact and bogus. A completely bogus result is worthless, but a perfectly accurate result is not infinitely valuable. A result could have accuracy intermediate beween "none at all" and "perfect", and that intermediate level of accuracy might be valuable enough to justify not spending the extra time required to make it more accurate. I haven't had to deal with missles. I have, however, had to deal with Gamma Ray Bursts (GRBs), with the objective of getting at least one conventional telescope (out of dozens that were participating in the project) pointed at the estimated location of the GRB as soon as possible after the burst, in the hopes of detecting radiation at visible wavelenths caused by the same phenomenon (which was unknown at that time) that caused the GRB. Interestingly, one of the telescopes that was being used for this purpose had originally been designed to visually track incoming nuclear missiles. The more gamma ray photons we collected, the more accurate our estimate of the GRB location would have been. However, if we waited too long collecting those photons, the radiation in visible wavelengths that we were hoping to catch might have already ended. My boss decided to send out the best position we could calculate using only one second of GRB photons, and hope that was good enough. I'm not sure how he made that decision, and it might not have been a rational one; but some trade-off had to be made between accuracy and time.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 22:46 -0500 |
| Message-ID | <o2ftou$8gn$1@jstuckle.eternal-september.org> |
| In reply to | #98606 |
On 12/9/2016 3:13 PM, jameskuyper@verizon.net wrote: > On Friday, December 9, 2016 at 10:52:45 AM UTC-5, Jerry Stuckle wrote: > ... >> Bad results are worse than no results at all. Would you rather have >> your doctor give you a fast diagnosis - or a correct one? > > Often, there's a deadline for making a decision about something (such as an incoming nuclear missile). A quick calculation might have a 20% chance of being wrong, but when it's right, it will save your life. A slower, more accurate calculation might have only a 0.5% chance of being wrong, but the result will never arrive until it's already too late do do anything about it. Which would you prefer? > So you're willing to start WW III based on a calculation that is only 80% accurate? I'm glad you aren't working on our national defense! -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2016-12-09 22:34 -0800 |
| Message-ID | <q7kshd-t4d.ln1@wilbur.25thandClement.com> |
| In reply to | #98645 |
Jerry Stuckle <jstucklex@attglobal.net> wrote: > On 12/9/2016 3:13 PM, jameskuyper@verizon.net wrote: >> On Friday, December 9, 2016 at 10:52:45 AM UTC-5, Jerry Stuckle wrote: >> ... >>> Bad results are worse than no results at all. Would you rather have >>> your doctor give you a fast diagnosis - or a correct one? >> >> Often, there's a deadline for making a decision about something (such as >> an incoming nuclear missile). A quick calculation might have a 20% chance >> of being wrong, but when it's right, it will save your life. A slower, >> more accurate calculation might have only a 0.5% chance of being wrong, >> but the result will never arrive until it's already too late do do >> anything about it. Which would you prefer? >> > > So you're willing to start WW III based on a calculation that is only > 80% accurate? > > I'm glad you aren't working on our national defense! > I think his point was that context matters, and that one's approach depends on the consequences of failing, details of the implemention, and other factors. Bad results vs no results is meaningless without more context. At the end up the day, _anything_ you do will produce some kind of result. A trap that halts a program entirely might be the worse possible choice. Even the simplest piece of code will be part of a more complex system.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-10 18:38 -0500 |
| Message-ID | <o2i3jl$4jq$1@dont-email.me> |
| In reply to | #98645 |
Jerry Stuckle <jstucklex@attglobal.net> wrote: > On 12/9/2016 3:13 PM, jameskuyper@verizon.net wrote: >> On Friday, December 9, 2016 at 10:52:45 AM UTC-5, Jerry Stuckle wrote: >> ... >>> Bad results are worse than no results at all. Would you rather have >>> your doctor give you a fast diagnosis - or a correct one? >> >> Often, there's a deadline for making a decision about something (such as >> an incoming nuclear missile). A quick calculation might have a 20% chance >> of being wrong, but when it's right, it will save your life. A slower, >> more accurate calculation might have only a 0.5% chance of being wrong, >> but the result will never arrive until it's already too late do do >> anything about it. Which would you prefer? >> > > So you're willing to start WW III ... I postulated an incoming nuclear missile - I'd presume the war has already started. > ... based on a calculation that is only > 80% accurate? I think a calculation that completes in one minute, and gives me an 80% chance of stopping the missile, is much better than a calculation that completes in five minutes and gives me a 99.5% chance of stopping the missile - if the anti-missile weaponry has to fire within the next three minutes to be effective. > I'm glad you aren't working on our national defense! You would prefer using the calculation that guarantees that the (incoming!) missile hits it's target, because the calculation doesn't complete fast enough for its results to be used? I wouldn't mind if you were defended in that fashion, but I'd rather seriously object to anyone planning to defend me that way.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-11 06:06 -0800 |
| Message-ID | <0135e568-d453-4cf0-a57a-f5ba5efb5a00@googlegroups.com> |
| In reply to | #98537 |
On Friday, December 9, 2016 at 3:52:45 PM UTC, Jerry Stuckle wrote: > > Bad results are worse than no results at all. Would you rather have > your doctor give you a fast diagnosis - or a correct one? > Just depends. There are several ways a diagnosis can be incorrect. For example a trivial, self-limiting infection can be mistaken for a more serious one. Or a serious infection like meningitis can be mistaken for a harmless headache caused by stress. Mistake one wastes some antibiotics, mistake two can be fatal. Then unless your budgets are unlimited, you've got to accept some degree of error. We can't all have the most experienced consultant, the latest in screening technology, a gleaming path lab full of dedicated staff with PhDs.
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2016-12-10 01:17 +0800 |
| Message-ID | <o2eos7$fck$1@dont-email.me> |
| In reply to | #98489 |
On 9/12/2016 8:26 PM, jacobnavia wrote: > The european mars lander hitted the mars surface at 300Km/hr > What happened? Could someone show us the C source codes first? ;)
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2016-12-13 14:28 -0500 |
| Message-ID | <o2pi1s$adq$4@dont-email.me> |
| In reply to | #98489 |
On 12/9/2016 7:26 AM, jacobnavia wrote: [...] > The software wasn't prepared for an overflow, and took that wrong data at > face value, what produced a NEGATIVE altitude. [...] Reminds me of that old Lunar Lander game back in the 1970's. I "tweaked" it to accept negative thrust values, just to see what I could do with it. -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web