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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2016-12-13 19:11 -0800 |
| Message-ID | <5tc15c534a7db6biesl00v8er7icn95flj@4ax.com> |
| In reply to | #99267 |
On Tue, 13 Dec 2016 13:37:55 -0800 (PST), Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >On Tuesday, December 13, 2016 at 7:56:38 PM UTC, Geoff wrote: >> On Tue, 13 Dec 2016 10:48:48 -0800 (PST), Malcolm McLean >> <malcolm.mclean5@btinternet.com> wrote: >> >> [snip] >> >> >Curve fitting can be 2 dimensional or one dimensional. >> >> [snip] >> >> There is no curve without two dimensions. Period. >> >> It doesn't matter whether x axis represents a spatial coordinate or a >> temporal coordinate, it's still a coordinate that can be assigned a >> value. >> >We can't assign a value to a time co-ordinate. We can measure it, >but we can't assign it. At least as long as its in the past. >However I can move a chessman about in two or, with minor difficulty, >three dimensions of space. Your use of assigned in this context is foreign to me. Any quantity that can be measured can be assigned a value. By assignment I mean it can be a known quantity for use in any useful computation. I don't know what you mean when you are using it. A number is just a number but in order to have a "curve" you need at least two dimensions or you only have a collection of numbers. Without a second coordinate a collection of numbers cannot be a "curve". Whether that curve is X vs Y in on a graph or whether it's X,Y,Z and T as a trajectory in spacetime depends on the context. As for "assigning" a value to a time coordinate, I can designate a time T = 0 at some wall clock time and call it the present and I can assign a time T = 0 + 5 as five seconds in the future and T = 0 - 5 as five seconds in the past. I have assigned values for those time coordinates without regard to whether it's past or future. In your chessman example, you cannot describe the positions of the game without a time coordinate. A pawn must be at some initial position at some time coordinate in that game and it must be moved to a new position at some other time. Whether that time coordinate is wall clock time or some "number of moves of chess pieces later" is a choice of the description being used. There is no meaningful way to describe a chess game otherwise.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-13 20:13 +0100 |
| Message-ID | <o2ph6u$aec$1@dont-email.me> |
| In reply to | #99218 |
On 13/12/16 18:01, Ben Bacarisse wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> [...] >>> One way of solving the curve intersection problem is to build >>> a root finder which will solve equations with nine roots. >>> If the root finder works for all representable values of >>> coefficients, then great. But what if it doesn't? Is to going >>> to be good enough, (2 cubics can intersect nine times, but >>> almost always they intersect only once or twice on the interval >>> you are interested in)? >> >> Two cubics can intersect nine times? I don't think so. >> >> A cubic is an equation of the form ax^3 + bx^2 + cx + d = 0. >> It can have up to three roots (values of x for which it's true). >> The intersections of two cubics are the solutions of the difference >> between the two cubics -- which is itself a cubic, which have no >> more than three solutions. >> >> Is there a confusion about terminology? > > I think so. Malcolm is almost certainly talking about a cubic curve > rather than a cubic equation in one variable. A cubic curve is a > polynomial equation in /two/ variables p(x, y) = 0 where the maximum > degree of any term in x or y is 3. > I think you mean that the sum of the powers is at most 3, so that you have: a.x³ + b.x²y + c.xy² + d.y³ + e.x² + f.xy + g.y² + h.x + i.y + j 10 coefficients, so 9 roots (counting doubles as necessary, and including complex numbers). I don't think you you need a point at infinity. (Malcolm can say if this is more accurate or not.) > AFAIK, if you solve them in the right field (C extended with point at > infinity), two cubic cures always intersect in nine points but you must > count multiple coincident points as separate ones. > > The default meaning of cubic is certainly the one you assumed, but in > the context of graphics algorithms I think cubic curve is the more > natural meaning (though I'd try to keep saying "cubic curve" just to be > clear). >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-13 11:45 -0800 |
| Message-ID | <00bb3741-edd4-46d7-8586-ba1560e992c9@googlegroups.com> |
| In reply to | #99231 |
On Tuesday, December 13, 2016 at 1:14:00 PM UTC-6, David Brown wrote: > On 13/12/16 18:01, Ben Bacarisse wrote: > > I think so. Malcolm is almost certainly talking about a cubic curve > > rather than a cubic equation in one variable. A cubic curve is a > > polynomial equation in /two/ variables p(x, y) = 0 where the maximum > > degree of any term in x or y is 3. > > I think you mean that the sum of the powers is at most 3, so that you have: > > a.x³ + b.x²y + c.xy² + d.y³ + e.x² + f.xy + g.y² + h.x + i.y + j > > 10 coefficients, so 9 roots (counting doubles as necessary, and > including complex numbers). I don't think you you need a point at infinity. > > (Malcolm can say if this is more accurate or not.) A common way of representing Bézier curves is to use a pair of equations for x and y, both of which are cubic with respect to a parameter "t" which goes from 0 to 1. There are a total of eight parameters (four for x and four for y) which are commonly expressed using four points (the four x coordinates control the parameters for the x equation, and likewise for y). I'm not sure how many times two Bézier curves could intersect; since they are described as parametric equations and the intersections would often occur at places where the "t" values of the two curves didn't match. If one views the curves as the paths drawn by objects whose position at time t is defined by the equations, the objects may cross each others' paths without colliding.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-13 23:10 +0000 |
| Message-ID | <874m27a0ic.fsf@bsb.me.uk> |
| In reply to | #99231 |
David Brown <david.brown@hesbynett.no> writes: > On 13/12/16 18:01, Ben Bacarisse wrote: >> Keith Thompson <kst-u@mib.org> writes: >> >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> [...] >>>> One way of solving the curve intersection problem is to build >>>> a root finder which will solve equations with nine roots. >>>> If the root finder works for all representable values of >>>> coefficients, then great. But what if it doesn't? Is to going >>>> to be good enough, (2 cubics can intersect nine times, but >>>> almost always they intersect only once or twice on the interval >>>> you are interested in)? >>> >>> Two cubics can intersect nine times? I don't think so. >>> >>> A cubic is an equation of the form ax^3 + bx^2 + cx + d = 0. >>> It can have up to three roots (values of x for which it's true). >>> The intersections of two cubics are the solutions of the difference >>> between the two cubics -- which is itself a cubic, which have no >>> more than three solutions. >>> >>> Is there a confusion about terminology? >> >> I think so. Malcolm is almost certainly talking about a cubic curve >> rather than a cubic equation in one variable. A cubic curve is a >> polynomial equation in /two/ variables p(x, y) = 0 where the maximum >> degree of any term in x or y is 3. > > I think you mean that the sum of the powers is at most 3, Yes (the sum of the powers in any term is at most three). Actually I meant to say that the degree of any term is at most 3 which I think is right but maybe the degree of a term is not defined as I think it is. I don't know where my "degree of any term in x or y" came from! Anyway, your > a.x³ + b.x²y + c.xy² + d.y³ + e.x² + f.xy + g.y² + h.x + i.y + j makes it clear we are talking about the same equations. > 10 coefficients, so 9 roots (counting doubles as necessary, and > including complex numbers). I don't think you you need a point at > infinity. Well it was <mumble> decades ago but I think the key theorem here is Bézout’s Theorem. This is a theorem about curves in projective space rather than affine space (again from hazy memeory). But, as I say it's all rather dim so maybe I should back out now... <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-14 10:18 +0100 |
| Message-ID | <o2r2mj$n50$1@dont-email.me> |
| In reply to | #99293 |
On 14/12/16 00:10, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 13/12/16 18:01, Ben Bacarisse wrote: >>> Keith Thompson <kst-u@mib.org> writes: >>> >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> [...] >>>>> One way of solving the curve intersection problem is to build >>>>> a root finder which will solve equations with nine roots. >>>>> If the root finder works for all representable values of >>>>> coefficients, then great. But what if it doesn't? Is to going >>>>> to be good enough, (2 cubics can intersect nine times, but >>>>> almost always they intersect only once or twice on the interval >>>>> you are interested in)? >>>> >>>> Two cubics can intersect nine times? I don't think so. >>>> >>>> A cubic is an equation of the form ax^3 + bx^2 + cx + d = 0. >>>> It can have up to three roots (values of x for which it's true). >>>> The intersections of two cubics are the solutions of the difference >>>> between the two cubics -- which is itself a cubic, which have no >>>> more than three solutions. >>>> >>>> Is there a confusion about terminology? >>> >>> I think so. Malcolm is almost certainly talking about a cubic curve >>> rather than a cubic equation in one variable. A cubic curve is a >>> polynomial equation in /two/ variables p(x, y) = 0 where the maximum >>> degree of any term in x or y is 3. >> >> I think you mean that the sum of the powers is at most 3, > > Yes (the sum of the powers in any term is at most three). Actually I > meant to say that the degree of any term is at most 3 which I think is > right but maybe the degree of a term is not defined as I think it is. I > don't know where my "degree of any term in x or y" came from! Anyway, > your > >> a.x³ + b.x²y + c.xy² + d.y³ + e.x² + f.xy + g.y² + h.x + i.y + j > > makes it clear we are talking about the same equations. > >> 10 coefficients, so 9 roots (counting doubles as necessary, and >> including complex numbers). I don't think you you need a point at >> infinity. > > Well it was <mumble> decades ago but I think the key theorem here is > Bézout’s Theorem. This is a theorem about curves in projective space > rather than affine space (again from hazy memeory). But, as I say it's > all rather dim so maybe I should back out now... > > <snip> > If you are working in projective space, then your roots will be in the projective space too, I think. But I am not really going by any theory here - just "rules of thumb", hand-waving and more than a little of my own mumbling. When you have a polynomial, your roots are real or complex but not infinite - you need division somewhere to get infinite roots. And if your function has n degrees of freedom when choosing coefficients, it has (n-1) roots since you can always remove one of the degrees of freedom by dividing everything by one of the coefficients. That's my logic here, such as it is. To get any better, I'd have to think about it a lot, draw some graphs, read a bit, and generally refresh things I have happily forgotten about long ago. Or cross-post to sci.maths :-)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-14 12:37 +0000 |
| Message-ID | <87twa67klp.fsf@bsb.me.uk> |
| In reply to | #99319 |
David Brown <david.brown@hesbynett.no> writes: > On 14/12/16 00:10, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 13/12/16 18:01, Ben Bacarisse wrote: >>>> Keith Thompson <kst-u@mib.org> writes: >>>> >>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>>> [...] >>>>>> One way of solving the curve intersection problem is to build >>>>>> a root finder which will solve equations with nine roots. >>>>>> If the root finder works for all representable values of >>>>>> coefficients, then great. But what if it doesn't? Is to going >>>>>> to be good enough, (2 cubics can intersect nine times, but >>>>>> almost always they intersect only once or twice on the interval >>>>>> you are interested in)? >>>>> >>>>> Two cubics can intersect nine times? I don't think so. >>>>> >>>>> A cubic is an equation of the form ax^3 + bx^2 + cx + d = 0. >>>>> It can have up to three roots (values of x for which it's true). >>>>> The intersections of two cubics are the solutions of the difference >>>>> between the two cubics -- which is itself a cubic, which have no >>>>> more than three solutions. >>>>> >>>>> Is there a confusion about terminology? >>>> >>>> I think so. Malcolm is almost certainly talking about a cubic curve >>>> rather than a cubic equation in one variable. A cubic curve is a >>>> polynomial equation in /two/ variables p(x, y) = 0 where the maximum >>>> degree of any term in x or y is 3. >>> >>> I think you mean that the sum of the powers is at most 3, >> >> Yes (the sum of the powers in any term is at most three). Actually I >> meant to say that the degree of any term is at most 3 which I think is >> right but maybe the degree of a term is not defined as I think it is. I >> don't know where my "degree of any term in x or y" came from! Anyway, >> your >> >>> a.x³ + b.x²y + c.xy² + d.y³ + e.x² + f.xy + g.y² + h.x + i.y + j >> >> makes it clear we are talking about the same equations. >> >>> 10 coefficients, so 9 roots (counting doubles as necessary, and >>> including complex numbers). I don't think you you need a point at >>> infinity. >> >> Well it was <mumble> decades ago but I think the key theorem here is >> Bézout’s Theorem. This is a theorem about curves in projective space >> rather than affine space (again from hazy memeory). But, as I say it's >> all rather dim so maybe I should back out now... >> >> <snip> >> > > If you are working in projective space, then your roots will be in the > projective space too, I think. Yes. I think (but I am now way outside my comfort zone) to always get 9 roots you need to be in a projective space because in some cases the curves only "meet at infinity". In affine space, you get up to 9 roots rather than always 9 roots. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-14 21:31 -0800 |
| Message-ID | <kfnh965hi6h.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #99332 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 14/12/16 00:10, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 13/12/16 18:01, Ben Bacarisse wrote:
>>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>>
>>>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>>>> [...]
>>>>>>> One way of solving the curve intersection problem is to build
>>>>>>> a root finder which will solve equations with nine roots.
>>>>>>> If the root finder works for all representable values of
>>>>>>> coefficients, then great. But what if it doesn't? Is to going
>>>>>>> to be good enough, (2 cubics can intersect nine times, but
>>>>>>> almost always they intersect only once or twice on the interval
>>>>>>> you are interested in)?
>>>>>>
>>>>>> Two cubics can intersect nine times? I don't think so.
>>>>>>
>>>>>> A cubic is an equation of the form ax^3 + bx^2 + cx + d = 0.
>>>>>> It can have up to three roots (values of x for which it's true).
>>>>>> The intersections of two cubics are the solutions of the difference
>>>>>> between the two cubics -- which is itself a cubic, which have no
>>>>>> more than three solutions.
>>>>>>
>>>>>> Is there a confusion about terminology?
>>>>>
>>>>> I think so. Malcolm is almost certainly talking about a cubic curve
>>>>> rather than a cubic equation in one variable. A cubic curve is a
>>>>> polynomial equation in /two/ variables p(x, y) = 0 where the maximum
>>>>> degree of any term in x or y is 3.
>>>>
>>>> I think you mean that the sum of the powers is at most 3,
>>>
>>> Yes (the sum of the powers in any term is at most three). Actually I
>>> meant to say that the degree of any term is at most 3 which I think is
>>> right but maybe the degree of a term is not defined as I think it is. I
>>> don't know where my "degree of any term in x or y" came from! Anyway,
>>> your
>>>
>>>> a.x**3 + b.x**2y + c.xy**2 + d.y**3 + e.x**2
>>>> + f.xy + g.y**2 + h.x + i.y + j
>>>
>>> makes it clear we are talking about the same equations.
>>>
>>>> 10 coefficients, so 9 roots (counting doubles as necessary, and
>>>> including complex numbers). I don't think you you need a point at
>>>> infinity.
>>>
>>> Well it was <mumble> decades ago but I think the key theorem here is
>>> Bezout?s Theorem. This is a theorem about curves in projective space
>>> rather than affine space (again from hazy memeory). But, as I say it's
>>> all rather dim so maybe I should back out now...
>>>
>>> <snip>
>>
>> If you are working in projective space, then your roots will be in the
>> projective space too, I think.
>
> Yes. I think (but I am now way outside my comfort zone) to always get 9
> roots you need to be in a projective space because in some cases the
> curves only "meet at infinity". In affine space, you get up to 9
> roots rather than always 9 roots.
Yes, in general points at infinity are needed. It's easy to
see that they are by considering the two cubics
ax3 + bx2y + cxy2 + dy3 + ex2 + fxy + gy2 + hx + iy = 1
ax3 + bx2y + cxy2 + dy3 + ex2 + fxy + gy2 + hx + iy = 2
which obviously have no finite points in common. But they do
meet on one or more points on the line at infinity (perhaps
with a requirement that not all of a,b,c,d,e,f,g,h,i are
zero).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-15 13:26 +0100 |
| Message-ID | <o2u230$2ri$1@dont-email.me> |
| In reply to | #99443 |
On 15/12/16 06:31, Tim Rentsch wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 14/12/16 00:10, Ben Bacarisse wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>> >>>>> On 13/12/16 18:01, Ben Bacarisse wrote: >>>>>> Keith Thompson <kst-u@mib.org> writes: >>>>>> >>>>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>>>>> [...] >>>>>>>> One way of solving the curve intersection problem is to build >>>>>>>> a root finder which will solve equations with nine roots. >>>>>>>> If the root finder works for all representable values of >>>>>>>> coefficients, then great. But what if it doesn't? Is to going >>>>>>>> to be good enough, (2 cubics can intersect nine times, but >>>>>>>> almost always they intersect only once or twice on the interval >>>>>>>> you are interested in)? >>>>>>> >>>>>>> Two cubics can intersect nine times? I don't think so. >>>>>>> >>>>>>> A cubic is an equation of the form ax^3 + bx^2 + cx + d = 0. >>>>>>> It can have up to three roots (values of x for which it's true). >>>>>>> The intersections of two cubics are the solutions of the difference >>>>>>> between the two cubics -- which is itself a cubic, which have no >>>>>>> more than three solutions. >>>>>>> >>>>>>> Is there a confusion about terminology? >>>>>> >>>>>> I think so. Malcolm is almost certainly talking about a cubic curve >>>>>> rather than a cubic equation in one variable. A cubic curve is a >>>>>> polynomial equation in /two/ variables p(x, y) = 0 where the maximum >>>>>> degree of any term in x or y is 3. >>>>> >>>>> I think you mean that the sum of the powers is at most 3, >>>> >>>> Yes (the sum of the powers in any term is at most three). Actually I >>>> meant to say that the degree of any term is at most 3 which I think is >>>> right but maybe the degree of a term is not defined as I think it is. I >>>> don't know where my "degree of any term in x or y" came from! Anyway, >>>> your >>>> >>>>> a.x**3 + b.x**2y + c.xy**2 + d.y**3 + e.x**2 >>>>> + f.xy + g.y**2 + h.x + i.y + j >>>> >>>> makes it clear we are talking about the same equations. >>>> >>>>> 10 coefficients, so 9 roots (counting doubles as necessary, and >>>>> including complex numbers). I don't think you you need a point at >>>>> infinity. >>>> >>>> Well it was <mumble> decades ago but I think the key theorem here is >>>> Bezout?s Theorem. This is a theorem about curves in projective space >>>> rather than affine space (again from hazy memeory). But, as I say it's >>>> all rather dim so maybe I should back out now... >>>> >>>> <snip> >>> >>> If you are working in projective space, then your roots will be in the >>> projective space too, I think. >> >> Yes. I think (but I am now way outside my comfort zone) to always get 9 >> roots you need to be in a projective space because in some cases the >> curves only "meet at infinity". In affine space, you get up to 9 >> roots rather than always 9 roots. > > Yes, in general points at infinity are needed. It's easy to > see that they are by considering the two cubics > > ax3 + bx2y + cxy2 + dy3 + ex2 + fxy + gy2 + hx + iy = 1 > ax3 + bx2y + cxy2 + dy3 + ex2 + fxy + gy2 + hx + iy = 2 > > which obviously have no finite points in common. But they do > meet on one or more points on the line at infinity (perhaps > with a requirement that not all of a,b,c,d,e,f,g,h,i are > zero). > Good point. It is even easier with the examples: x = 1 and x = 2 They are parallel lines, and will meet at a point of infinity in a projective geometry, but not in a plain Euclidian geometry. To take this a step further, is it possible for pairs of equations like this to have some finite and some infinite meeting points? I suspect that you would have /either/ finite /or/ infinite meeting points, but not both (assuming the equations are not coincidental, of course). But this is not something I can figure out in my head.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-12 22:40 +1300 |
| Message-ID | <eb79jsF156qU3@mid.individual.net> |
| In reply to | #98784 |
On 12/12/16 01:22 AM, David Brown wrote: > > For full coverage testing, /every/ single instruction must be executed > during the test runs. When devising test sequences for a function, you > have to include values that will test each possible path in the > function. And if you now add extra branches based on overflow checking, > you also have to include test sequences that trigger the overflow checks > and branches. You need to do that for /every/ possible overflow check. > Code that was previously a series of arithmetic operations with no > branches is now a web of possibilities, and needs lots of different > inputs to test them all. And if the code is written correctly, so that > overflow does not happen, you /cannot/ find test cases that trigger > these branches - the code is completely untestable. If you had written the code test first, you would not end up with something that was untestable because the only reason to add a branch in the code would be to pass a test! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-12 13:22 +0100 |
| Message-ID | <o2m4n1$k4g$1@dont-email.me> |
| In reply to | #99022 |
On 12/12/16 10:40, Ian Collins wrote: > On 12/12/16 01:22 AM, David Brown wrote: >> >> For full coverage testing, /every/ single instruction must be executed >> during the test runs. When devising test sequences for a function, you >> have to include values that will test each possible path in the >> function. And if you now add extra branches based on overflow checking, >> you also have to include test sequences that trigger the overflow checks >> and branches. You need to do that for /every/ possible overflow check. >> Code that was previously a series of arithmetic operations with no >> branches is now a web of possibilities, and needs lots of different >> inputs to test them all. And if the code is written correctly, so that >> overflow does not happen, you /cannot/ find test cases that trigger >> these branches - the code is completely untestable. > > If you had written the code test first, you would not end up with > something that was untestable because the only reason to add a branch in > the code would be to pass a test! > That is only true when the checks for overflow are within the programmer's control. The suggestion here is for the overflow detection to be an integral part of the code generation. I.e., every "add" instruction should be generated as "add and trap if overflow". This is what I am arguing against - precisely because I don't want extra branches generated by the compiler. When the use of overflow detection is under the control of the programmer, then it becomes testable - whether you write the tests before the code, or after the code.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-12 08:35 -0800 |
| Message-ID | <3bbefb67-8eea-4026-a4f6-1fceb9810f6e@googlegroups.com> |
| In reply to | #99035 |
On Monday, December 12, 2016 at 6:22:19 AM UTC-6, David Brown wrote: > That is only true when the checks for overflow are within the > programmer's control. The suggestion here is for the overflow detection > to be an integral part of the code generation. I.e., every "add" > instruction should be generated as "add and trap if overflow". This is > what I am arguing against - precisely because I don't want extra > branches generated by the compiler. What I'd want to see is not a requirement that all compilers must always behave predictably in case of overflow, but rather that a means exist via which code can specify that it needs a compiler to uphold certain guarantees, whereupon quality compilers should uphold the guarantee when practical, but where compilers could refuse compilation instead while still being conforming. > When the use of overflow detection is under the control of the > programmer, then it becomes testable - whether you write the tests > before the code, or after the code. If a compiler sets a flag when integer math yields inaccurate results and code can test that flag at leisure, the overall set of paths through the program would not be adversely affected by the overflow checks; in cases where programs must either produce accurate results or report failure, such a design would allow more optimizations opportunities than would be possible if programmers checked overflow manually.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-09 08:43 -0800 |
| Message-ID | <16fbe25c-3621-45a1-8779-e0095f0b60b9@googlegroups.com> |
| In reply to | #98505 |
On Friday, December 9, 2016 at 8:22:50 AM UTC-6, Richard Heathfield wrote: > This is the big problem I see with Jacob's take on overflow. By the time > overflow happens, it's already too late. That's why it's fine for debug > mode and test mode, but you don't want to be relying on it in production. It may or may not be too late. If one has multiple ways of estimating some physical quantity and is prepared for one of them to report "unavailable", then an detected overflow which occurs while processing readings from a malfunctioning sensor need not be a problem. If there's no way that readings from a properly-functioning sensor would cause overflow, then code could use the occurrence of an overflow while processing the sensor data as an indication that the sensor was malfunctioning and the information that it would have produced should be considered "unavailable" (i.e. the system should use some other means of performing the necessary calculations).
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 09:47 -0500 |
| Message-ID | <o2eg34$bcr$1@jstuckle.eternal-september.org> |
| In reply to | #98498 |
On 12/9/2016 8:53 AM, David Brown wrote: > On 09/12/16 13:44, Richard Heathfield wrote: >> On 09/12/16 12:26, 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, >> >> Well, it should have been. The programmer should have predicted that >> overflow could happen, and chosen data types that made this impossible >> for the (highly predictable) numbers involved. If no native data types >> would do, a suitable data structure should have been devised. It's not >> difficult. > > That is not really accurate - the software should not have been prepared > for an overflow. The data should have been vetted so that there was no > overflow. > Yes. When dealing with sensors, you need to validate the incoming data. The more critical the sensor reading, the more important it is to validate the data. In this case the data was very critical. I worked on a system which included sensors on machinery - conveyor belt speeds, etc. The problem was this was a very electrically noisy environment, and occasionally the incoming data would become corrupted. Validating the data and throwing out the corrupted data solved several problems. > There are three correct ways to handle this sort of situation: > > 1. The code that reads the altimeter should have checked the values, and > made sure they were valid and in a suitable range before passing them on > to the code that uses those values. It would then be impossible for > that code to experience overflow. > Definitely. > 2. The code that used the altimeter values should have checked the > values it received, and either discarded them or "saturated" them to the > maximum valid value. It would then be impossible for that code to > experience overflow. > Another good possibility, but not as good as above. Passing on a known bad value can be as bad as overflow. > 3. The code that used the altimeter values should have used types with > sufficient range that there would be no overflow, regardless of the > value it received. It would then be impossible for that code to > experience overflow. > Which may or may not have been possible, depending on the processor being used and the data range. And with corrupted data, any size may not be big enough. > > Overflow checking is about figuring out what went wrong after something > /has/ gone wrong. Safe coding is about making sure things don't go > wrong in the first place. > > Now, there is nothing wrong with understanding that programmers make > mistakes, and adding additional checks or limitations to limit the > damage if there is a software bug - but the prime design point here is > that you do not let overflow happen. > Very definitely. > >> >>> and took that wrong data >>> at face value, what produced a NEGATIVE altitude. >> >> If that's what went wrong (and it's not entirely clear whether an >> overflow was responsible, but let's assume it was), then that is clear >> evidence of inadequate testing of the software. In such circumstances, >> an implementation that tests every operation for overflow would have >> been an invaluable testing tool. > > I agree about inadequate testing of the software. I don't agree that > testing all operations for overflow is helpful. That merely introduces > a vast number of code paths that cannot be taken, cannot be tested, and > cannot be verified. In a system that needs to be safe and reliable, you > do not put in extra code (explicitly by the programmer, or implicitly > via the tools) that you cannot test and do not need. (You do put in > extra checks at boundary points between modules, but you limit these and > check them independently.) > >> >>> 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. >> >> Right. Nobody is disputing that, are they? > > Not that I can see. Even though I am arguing against hidden > compiler-based overflow detection, except perhaps as a debugging tool > during development, I agree that overflows are dangerous. That is why I > say they should be avoided, not detected. > >> >>> 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. >> >> Nobody has claimed this, apart from you. >> > -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 16:11 +0100 |
| Message-ID | <o2ehgc$g0s$2@dont-email.me> |
| In reply to | #98509 |
On 09/12/16 15:47, Jerry Stuckle wrote: > On 12/9/2016 8:53 AM, David Brown wrote: >> On 09/12/16 13:44, Richard Heathfield wrote: >>> On 09/12/16 12:26, 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, >>> >>> Well, it should have been. The programmer should have predicted that >>> overflow could happen, and chosen data types that made this impossible >>> for the (highly predictable) numbers involved. If no native data types >>> would do, a suitable data structure should have been devised. It's not >>> difficult. >> >> That is not really accurate - the software should not have been prepared >> for an overflow. The data should have been vetted so that there was no >> overflow. >> > > Yes. When dealing with sensors, you need to validate the incoming data. > The more critical the sensor reading, the more important it is to > validate the data. In this case the data was very critical. > > I worked on a system which included sensors on machinery - conveyor belt > speeds, etc. The problem was this was a very electrically noisy > environment, and occasionally the incoming data would become corrupted. > Validating the data and throwing out the corrupted data solved several > problems. Yes. The trick is to avoid throwing out data that is actually valid, but that you just don't like! > >> There are three correct ways to handle this sort of situation: >> >> 1. The code that reads the altimeter should have checked the values, and >> made sure they were valid and in a suitable range before passing them on >> to the code that uses those values. It would then be impossible for >> that code to experience overflow. >> > > Definitely. > >> 2. The code that used the altimeter values should have checked the >> values it received, and either discarded them or "saturated" them to the >> maximum valid value. It would then be impossible for that code to >> experience overflow. >> > > Another good possibility, but not as good as above. Passing on a known > bad value can be as bad as overflow. Agreed. > >> 3. The code that used the altimeter values should have used types with >> sufficient range that there would be no overflow, regardless of the >> value it received. It would then be impossible for that code to >> experience overflow. >> > > Which may or may not have been possible, depending on the processor > being used and the data range. And with corrupted data, any size may > not be big enough. Agreed. > >> >> Overflow checking is about figuring out what went wrong after something >> /has/ gone wrong. Safe coding is about making sure things don't go >> wrong in the first place. >> >> Now, there is nothing wrong with understanding that programmers make >> mistakes, and adding additional checks or limitations to limit the >> damage if there is a software bug - but the prime design point here is >> that you do not let overflow happen. >> > > Very definitely. > I am not sure how it happened, but I am glad that we can sometimes be in full agreement!
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 10:49 -0500 |
| Message-ID | <o2ejn2$p7q$1@jstuckle.eternal-september.org> |
| In reply to | #98520 |
On 12/9/2016 10:11 AM, David Brown wrote: > On 09/12/16 15:47, Jerry Stuckle wrote: >> On 12/9/2016 8:53 AM, David Brown wrote: >>> On 09/12/16 13:44, Richard Heathfield wrote: >>>> On 09/12/16 12:26, 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, >>>> >>>> Well, it should have been. The programmer should have predicted that >>>> overflow could happen, and chosen data types that made this impossible >>>> for the (highly predictable) numbers involved. If no native data types >>>> would do, a suitable data structure should have been devised. It's not >>>> difficult. >>> >>> That is not really accurate - the software should not have been prepared >>> for an overflow. The data should have been vetted so that there was no >>> overflow. >>> >> >> Yes. When dealing with sensors, you need to validate the incoming data. >> The more critical the sensor reading, the more important it is to >> validate the data. In this case the data was very critical. >> >> I worked on a system which included sensors on machinery - conveyor belt >> speeds, etc. The problem was this was a very electrically noisy >> environment, and occasionally the incoming data would become corrupted. >> Validating the data and throwing out the corrupted data solved several >> problems. > > Yes. The trick is to avoid throwing out data that is actually valid, > but that you just don't like! > Not that hard. In the case of the conveyor belt, speed could only change so much between readings (unless the emergency stop button was pressed - but that is a different story). Comparing readings with previous ones showed if the reading was valid or not. Then pass an "invalid reading" value on to the program, which could decide what to do with it. Multiple invalid readings from the same sensor indicated a bad sensor or other problem and flagged the operator. Bad readings from multiple sensors indicated a major problem on the belt and initiated an emergency stop. Similar validation could be done on inertial sensors. >> >>> There are three correct ways to handle this sort of situation: >>> >>> 1. The code that reads the altimeter should have checked the values, and >>> made sure they were valid and in a suitable range before passing them on >>> to the code that uses those values. It would then be impossible for >>> that code to experience overflow. >>> >> >> Definitely. >> >>> 2. The code that used the altimeter values should have checked the >>> values it received, and either discarded them or "saturated" them to the >>> maximum valid value. It would then be impossible for that code to >>> experience overflow. >>> >> >> Another good possibility, but not as good as above. Passing on a known >> bad value can be as bad as overflow. > > Agreed. > >> >>> 3. The code that used the altimeter values should have used types with >>> sufficient range that there would be no overflow, regardless of the >>> value it received. It would then be impossible for that code to >>> experience overflow. >>> >> >> Which may or may not have been possible, depending on the processor >> being used and the data range. And with corrupted data, any size may >> not be big enough. > > Agreed. > >> >>> >>> Overflow checking is about figuring out what went wrong after something >>> /has/ gone wrong. Safe coding is about making sure things don't go >>> wrong in the first place. >>> >>> Now, there is nothing wrong with understanding that programmers make >>> mistakes, and adding additional checks or limitations to limit the >>> damage if there is a software bug - but the prime design point here is >>> that you do not let overflow happen. >>> >> >> Very definitely. >> > > I am not sure how it happened, but I am glad that we can sometimes be in > full agreement! > -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-12-09 05:53 -0800 |
| Message-ID | <61fb2523-214f-4eee-8a89-6f5ec3e1b9ef@googlegroups.com> |
| In reply to | #98489 |
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. Their equations produces negative altitude (I suppose, negative *estomation* of altitude, by Kalman filter or something similar) because that's what their equations would produces from incoming garbage even if calculations were made with infinite precision and range. Program logic was non-robust, bad readings of altimeter was not accounted for. Yes, that's called bugs. It has nothing to do with overflows or with anything that compiler can deal with automatically. It does not sound like programmer's fault at all. It sounds like mistake of algorithmist or of physicist that worked with algorithmist. Of course, good programmer can point to such sort of mistakes, but European Space Agency is of sort of organizations where feedback from below is least likely to reach upper levels of hierarchy. Once again, no programming language can help that. http://spacenews.com/esa-mars-lander-crash-caused-by-1-second-inertial-measurement-error/ Here they specifically mention "saturation reading" suggesting that even at the very lowest levels of software, before things converted from integer to FP, there was no overflow.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-12-09 06:04 -0800 |
| Message-ID | <03d70919-b8a2-4567-b60b-5dd99d47b778@googlegroups.com> |
| In reply to | #98499 |
So the calculus is done using " Float point"? Are not better big int and big fixed point float?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 15:09 +0100 |
| Message-ID | <o2eds0$3da$1@dont-email.me> |
| In reply to | #98502 |
On 09/12/16 15:04, asetofsymbols@gmail.com wrote: > So the calculus is done using " Float point"? Are not better big int and big fixed point float? > That will depend entirely on the circumstances, and the calculations needed. The most important factor is to choose a method that makes the source code clear and correct. With integer or scaled integer calculations, you often need to be much more careful about picking your types carefully, and ordering your calculations in order to avoid overflow. And your code can easily be filled with extra shifts and scalings, or hard-to-read code using function notation instead of arithmetic operators (unless you are using a language that support operator overloading).
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 10:06 -0500 |
| Message-ID | <o2eh6s$ffm$1@jstuckle.eternal-september.org> |
| In reply to | #98503 |
On 12/9/2016 9:09 AM, David Brown wrote: > On 09/12/16 15:04, asetofsymbols@gmail.com wrote: >> So the calculus is done using " Float point"? Are not better big int and big fixed point float? >> > > That will depend entirely on the circumstances, and the calculations > needed. The most important factor is to choose a method that makes the > source code clear and correct. With integer or scaled integer > calculations, you often need to be much more careful about picking your > types carefully, and ordering your calculations in order to avoid > overflow. And your code can easily be filled with extra shifts and > scalings, or hard-to-read code using function notation instead of > arithmetic operators (unless you are using a language that support > operator overloading). > > It's also highly dependent on the processor being used. Electronics are sensitive to damage by radiation, cosmic rays especially. The more complicated the processor, the denser and smaller the transistors and the more susceptible the chip is to radiation. The amount of lead required to shield the electronics would be prohibitively heavy. All electronic parts used in spacecraft (at least in the U.S.) are military grade - extended temperature range, etc. And I would bet even now they aren't 64 bit processors. 32 bit at the most, and in many cases 16 bit. And even then there are redundant computer systems in case of failure. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 16:32 +0100 |
| Message-ID | <o2eing$lb8$1@dont-email.me> |
| In reply to | #98516 |
On 09/12/16 16:06, Jerry Stuckle wrote: > On 12/9/2016 9:09 AM, David Brown wrote: >> On 09/12/16 15:04, asetofsymbols@gmail.com wrote: >>> So the calculus is done using " Float point"? Are not better big int and big fixed point float? >>> >> >> That will depend entirely on the circumstances, and the calculations >> needed. The most important factor is to choose a method that makes the >> source code clear and correct. With integer or scaled integer >> calculations, you often need to be much more careful about picking your >> types carefully, and ordering your calculations in order to avoid >> overflow. And your code can easily be filled with extra shifts and >> scalings, or hard-to-read code using function notation instead of >> arithmetic operators (unless you are using a language that support >> operator overloading). >> >> > > It's also highly dependent on the processor being used. Electronics are > sensitive to damage by radiation, cosmic rays especially. The more > complicated the processor, the denser and smaller the transistors and > the more susceptible the chip is to radiation. The amount of lead > required to shield the electronics would be prohibitively heavy. > > All electronic parts used in spacecraft (at least in the U.S.) are > military grade - extended temperature range, etc. And I would bet even > now they aren't 64 bit processors. 32 bit at the most, and in many > cases 16 bit. And even then there are redundant computer systems in > case of failure. > Yes, that is all true. There is also the issue that for spacecraft, design and planning stages take many years, so the microcontrollers used can be 5 or more years behind state-of-the-art by the time they are launched. So if your processor is not capable of doing the required calculations in floating point within the time available, then that necessarily limits your options. But within the options available, you choose the one that let you write the clearest code where you can be most confident that you get things right.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web