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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-11 23:42 +0100 |
| Message-ID | <o2kkmj$fbj$1@dont-email.me> |
| In reply to | #98872 |
On 11/12/16 20:55, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> By now you must have realised that it is /impossible/ for C to have a
>> standard method of detecting integer overflows (and buffer overruns,
>> though these are new to the thread here). Please do not continue
>> arguing for them - it cannot and will not happen, and I believe you
>> already know this and understand some of the reasons for that (even if
>> you don't agree with all of the reasons).
>
> I don't know how you reached that conclusion.
>
> Standard C of course does not specify overflow checking. But leaving
> aside the question of whether it's a good idea, either a future C
> standard or a C implementation with extensions certainly could.
>
> As proof of concept, I present Ada. Ada has exceptions as a language
> feature, very similar to C++ exceptions. It also requires arithmetic
> operations to be checked, raising an exception if the result is out of
> range. (Ada also has modular types, similar to C unsigned types, with
> wraparound semantics.)
>
> For example, you might have:
>
> declare
> N: Integer := Integer'Last;
> begin
> N := N + 1;
> Put_Line("Overflow not detected");
> exception
> when Constraint_Error =>
> Put_Line("Overflow detected");
> end;
>
> and the program *must* print "Overflow detected" in a conforming
> implementation.
>
> Why do you think something similar (perhaps using signals rather than
> exceptions?) would be impossible in C?
>
See my answer to Ben on the same question. Basically, I think it is so
highly unrealistic that it would be put in the C standards that I used
the word "impossible". But that was an exaggeration.
A key difference here is that C++ and Ada have exceptions - C does not,
and I do not expect it ever to have exceptions. When a language /has/
exceptions, then it has a very suitable mechanism in place for handling
overflows like this.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-11 14:53 -0800 |
| Message-ID | <9e80bbb3-a034-4f3a-8c7e-a58387e616a4@googlegroups.com> |
| In reply to | #98929 |
On Sunday, December 11, 2016 at 10:42:52 PM UTC, David Brown wrote: > > > See my answer to Ben on the same question. Basically, I think it is so > highly unrealistic that it would be put in the C standards that I used > the word "impossible". But that was an exaggeration. > > A key difference here is that C++ and Ada have exceptions - C does not, > and I do not expect it ever to have exceptions. When a language /has/ > exceptions, then it has a very suitable mechanism in place for handling > overflows like this. > During development, you usually want the program to crash and produce a stack trace, not to throw an exception that suppresses the cause of the overflow. During deployment, it just depends what the program is doing. Exceptions aren't a self-evidently bad solution, but they are hard to test and, in C++, cause some subtle problems. They're also a very heavy layer of machinery. My solution is to use doubles and 64 bit integers, then treat FLT_MAX as infinity and FLT_EPSILON as 0. That gets rid of most of the overflow problems.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-12 17:09 +1300 |
| Message-ID | <eb6m74Fm1p6U1@mid.individual.net> |
| In reply to | #98933 |
On 12/12/16 11:53 AM, Malcolm McLean wrote: > On Sunday, December 11, 2016 at 10:42:52 PM UTC, David Brown wrote: >> >> >> See my answer to Ben on the same question. Basically, I think it is so >> highly unrealistic that it would be put in the C standards that I used >> the word "impossible". But that was an exaggeration. >> >> A key difference here is that C++ and Ada have exceptions - C does not, >> and I do not expect it ever to have exceptions. When a language /has/ >> exceptions, then it has a very suitable mechanism in place for handling >> overflows like this. >> > During development, you usually want the program to crash and produce > a stack trace, not to throw an exception that suppresses the cause > of the overflow. There's no reason for an exception to suppresses the cause of the overflow. My own C++ exception base class includes a full stack trace in debug mode, so nothing is lost. > During deployment, it just depends what the program is doing. Exceptions > aren't a self-evidently bad solution, but they are hard to test > and, in C++, cause some subtle problems. They're also a very heavy > layer of machinery. Exceptions, at least in C++, aren't difficult to test. > My solution is to use doubles and 64 bit integers, then treat FLT_MAX > as infinity and FLT_EPSILON as 0. That gets rid of most of the overflow > problems. Not much use on most embedded systems. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-12 10:00 +0100 |
| Message-ID | <o2losm$ct1$1@dont-email.me> |
| In reply to | #98933 |
On 11/12/16 23:53, Malcolm McLean wrote: > On Sunday, December 11, 2016 at 10:42:52 PM UTC, David Brown wrote: >> >> >> See my answer to Ben on the same question. Basically, I think it is so >> highly unrealistic that it would be put in the C standards that I used >> the word "impossible". But that was an exaggeration. >> >> A key difference here is that C++ and Ada have exceptions - C does not, >> and I do not expect it ever to have exceptions. When a language /has/ >> exceptions, then it has a very suitable mechanism in place for handling >> overflows like this. >> > During development, you usually want the program to crash and produce > a stack trace, not to throw an exception that suppresses the cause > of the overflow. In most cases, at least during early development, you want the program to stop with a clear indication of the point of failure. You don't want the problem to be covered up in any way. (I also see Ian's point that you can make exceptions an integral part of development and testing. Exceptions could be a convenient way to print out trace information to a debug log, for example.) > During deployment, it just depends what the program is doing. Exceptions > aren't a self-evidently bad solution, but they are hard to test > and, in C++, cause some subtle problems. They're also a very heavy > layer of machinery. C++ exceptions can be a good thing, and a bad thing, depending on how they are used. And testing them can be challenging - especially being sure you test all cases in which they could be thrown. After all, exceptions are typically thrown only in unusual circumstances, which may be hard to provoke in testing. > > My solution is to use doubles and 64 bit integers, then treat FLT_MAX > as infinity and FLT_EPSILON as 0. That gets rid of most of the overflow > problems. > A better solution is simply to know what you are doing and make sure your arithmetic is correct. Don't "get rid of overflow problems" - avoid the possibility of the problems occurring by using appropriate types, scalings, tests, etc., /before/ problems could occur.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-12 22:20 +1300 |
| Message-ID | <eb78evF156qU1@mid.individual.net> |
| In reply to | #99011 |
On 12/12/16 10:00 PM, David Brown wrote: > On 11/12/16 23:53, Malcolm McLean wrote: >> On Sunday, December 11, 2016 at 10:42:52 PM UTC, David Brown wrote: >>> >>> >>> See my answer to Ben on the same question. Basically, I think it is so >>> highly unrealistic that it would be put in the C standards that I used >>> the word "impossible". But that was an exaggeration. >>> >>> A key difference here is that C++ and Ada have exceptions - C does not, >>> and I do not expect it ever to have exceptions. When a language /has/ >>> exceptions, then it has a very suitable mechanism in place for handling >>> overflows like this. >>> >> During development, you usually want the program to crash and produce >> a stack trace, not to throw an exception that suppresses the cause >> of the overflow. > > In most cases, at least during early development, you want the program > to stop with a clear indication of the point of failure. You don't want > the problem to be covered up in any way. > > (I also see Ian's point that you can make exceptions an integral part of > development and testing. Exceptions could be a convenient way to print > out trace information to a debug log, for example.) > >> During deployment, it just depends what the program is doing. Exceptions >> aren't a self-evidently bad solution, but they are hard to test >> and, in C++, cause some subtle problems. They're also a very heavy >> layer of machinery. > > C++ exceptions can be a good thing, and a bad thing, depending on how > they are used. And testing them can be challenging - especially being > sure you test all cases in which they could be thrown. After all, > exceptions are typically thrown only in unusual circumstances, which may > be hard to provoke in testing. That's one reason it is good practice to mock whatever your current "unit" calls in its tests. Once you do that, you can tell the mock to throw an exception (or return an error) as part of the test setup. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-12 01:28 -0800 |
| Message-ID | <0fdbff52-14ad-4566-8034-70432db815f3@googlegroups.com> |
| In reply to | #99019 |
On Monday, December 12, 2016 at 9:20:39 AM UTC, Ian Collins wrote: > On 12/12/16 10:00 PM, David Brown wrote: > > > C++ exceptions can be a good thing, and a bad thing, depending on how > > they are used. And testing them can be challenging - especially being > > sure you test all cases in which they could be thrown. After all, > > exceptions are typically thrown only in unusual circumstances, which may > > be hard to provoke in testing. > > That's one reason it is good practice to mock whatever your current > "unit" calls in its tests. Once you do that, you can tell the mock to > throw an exception (or return an error) as part of the test setup. > Yes, you need to call with values which will provoke overflow, to check that the exception is actually thrown. Then you need to call again in context to check that the exception handler actually handles the exception correctly. So realistically you need some sort of automated test harness.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-12 22:38 +1300 |
| Message-ID | <eb79ggF156qU2@mid.individual.net> |
| In reply to | #99020 |
On 12/12/16 10:28 PM, Malcolm McLean wrote: > On Monday, December 12, 2016 at 9:20:39 AM UTC, Ian Collins wrote: >> On 12/12/16 10:00 PM, David Brown wrote: >> >>> C++ exceptions can be a good thing, and a bad thing, depending on how >>> they are used. And testing them can be challenging - especially being >>> sure you test all cases in which they could be thrown. After all, >>> exceptions are typically thrown only in unusual circumstances, which may >>> be hard to provoke in testing. >> >> That's one reason it is good practice to mock whatever your current >> "unit" calls in its tests. Once you do that, you can tell the mock to >> throw an exception (or return an error) as part of the test setup. >> > Yes, you need to call with values which will provoke overflow, to > check that the exception is actually thrown. Then you need to call > again in context to check that the exception handler actually > handles the exception correctly. > > So realistically you need some sort of automated test harness. Unit tests should always be written using a a test framework. My current project uses Google test, which is widely used. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-12 02:43 -0800 |
| Message-ID | <65385380-f423-4276-9d27-0dcbe582af39@googlegroups.com> |
| In reply to | #99021 |
On Monday, December 12, 2016 at 9:38:31 AM UTC, Ian Collins wrote: > On 12/12/16 10:28 PM, Malcolm McLean wrote: > > > So realistically you need some sort of automated test harness. > > Unit tests should always be written using a a test framework. My > current project uses Google test, which is widely used. > Unfortunately it then becomes another thing to find, download, configure, familiarise yourself with and go wrong. That's not to say don't use it. I'm querying the "always". We use cpputest. But I don't find it all that useful. The main problem is that results of graphics algorithms are often easy to verify visually, hard to verify automatically, without effectively writing the code a second time to test the results. It's not useless however. e.g. I can check if two curves intersect by substituting the reported intersection point and ensuring that x1,y1 = x2,y2. But I can't as easily check a false negative. However in fact I've got two independent intersection routines, so I check them against each other. However near tangents can cause both to fail, so even that isn't perfect. Then an issue is how to generate the test set. Obviously lots of random curves are easy to set up. But that only rarely throws up a real challenge. Artists, however, are always drawing curves which intersect at exactly t = 0.5 and other difficult cases.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-13 08:20 +1300 |
| Message-ID | <eb8bj5F18c4U1@mid.individual.net> |
| In reply to | #99027 |
On 12/12/16 11:43 PM, Malcolm McLean wrote: > On Monday, December 12, 2016 at 9:38:31 AM UTC, Ian Collins wrote: >> On 12/12/16 10:28 PM, Malcolm McLean wrote: >> >>> So realistically you need some sort of automated test harness. >> >> Unit tests should always be written using a a test framework. My >> current project uses Google test, which is widely used. >> > Unfortunately it then becomes another thing to find, download, > configure, familiarise yourself with and go wrong. That's not to > say don't use it. I'm querying the "always". The alternative is to roll your own, which you then have to maintain. A good test framework isn't a trivial piece of code, especially if it has comprehensive mocking support. > We use cpputest. But I don't find it all that useful. The > main problem is that results of graphics algorithms are often > easy to verify visually, hard to verify automatically, without > effectively writing the code a second time to test the results. > It's not useless however. e.g. I can check if two curves > intersect by substituting the reported intersection point and > ensuring that x1,y1 = x2,y2. But I can't as easily check a > false negative. However in fact I've got two independent > intersection routines, so I check them against each other. > However near tangents can cause both to fail, so even that > isn't perfect. > > Then an issue is how to generate the test set. Obviously > lots of random curves are easy to set up. But that only rarely > throws up a real challenge. Artists, however, are always > drawing curves which intersect at exactly t = 0.5 and other > difficult cases. It's all so much easier if you write the code test fist. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-12 12:57 -0800 |
| Message-ID | <13b758b6-d938-4ffd-9659-c76a0007ba62@googlegroups.com> |
| In reply to | #99115 |
On Monday, December 12, 2016 at 7:20:12 PM UTC, Ian Collins wrote:
> On 12/12/16 11:43 PM, Malcolm McLean wrote:
> > On Monday, December 12, 2016 at 9:38:31 AM UTC, Ian Collins wrote:
> >> On 12/12/16 10:28 PM, Malcolm McLean wrote:
> >>
> >>> So realistically you need some sort of automated test harness.
> >>
> >> Unit tests should always be written using a a test framework. My
> >> current project uses Google test, which is widely used.
> >>
> > Unfortunately it then becomes another thing to find, download,
> > configure, familiarise yourself with and go wrong. That's not to
> > say don't use it. I'm querying the "always".
>
> The alternative is to roll your own, which you then have to maintain. A
> good test framework isn't a trivial piece of code, especially if it has
> comprehensive mocking support.
>
There's no simple relationship between test and code complexity.
E.g. if your text to speech says "Hello world" when you feed it
the one line program
texttospeech("Hello world");
then that's a very powerful test and, assuming no sabotage, a
strong indication that the subroutine works.
On the other hand, we've got an edit box that allows the user
to enter a length in units (metres, feet, etc), then change
the units globally, whist also setting a precision, and to
cap it all, it allows formulae like 2+2.
It's a silly thing and not really doing anything inherently
difficult. But you can imagine the number of test cases
something like that has to pass before you have confidence
in it.
> > Then an issue is how to generate the test set. Obviously
> > lots of random curves are easy to set up. But that only rarely
> > throws up a real challenge. Artists, however, are always
> > drawing curves which intersect at exactly t = 0.5 and other
> > difficult cases.
>
> It's all so much easier if you write the code test fist.
>
That works for problems where the right way to approach the
solution is well known. It doesn't scale to harder problems.
For example, curve to curve intersection where the intersection
point is exactly at 50% is a special case for a recursive
algorithm that cuts the curves in half. But not for one which
solves the equations numerically. Unless you know where the
special cases are likely to be, how can you write the tests,
given that there are an infinite number of pairs of curves?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-13 14:14 +1300 |
| Message-ID | <eb90bsF18c4U2@mid.individual.net> |
| In reply to | #99130 |
On 12/13/16 09:57 AM, Malcolm McLean wrote:
> On Monday, December 12, 2016 at 7:20:12 PM UTC, Ian Collins wrote:
>> On 12/12/16 11:43 PM, Malcolm McLean wrote:
>>> On Monday, December 12, 2016 at 9:38:31 AM UTC, Ian Collins wrote:
>>>> On 12/12/16 10:28 PM, Malcolm McLean wrote:
>>>>
>>>>> So realistically you need some sort of automated test harness.
>>>>
>>>> Unit tests should always be written using a a test framework. My
>>>> current project uses Google test, which is widely used.
>>>>
>>> Unfortunately it then becomes another thing to find, download,
>>> configure, familiarise yourself with and go wrong. That's not to
>>> say don't use it. I'm querying the "always".
>>
>> The alternative is to roll your own, which you then have to maintain. A
>> good test framework isn't a trivial piece of code, especially if it has
>> comprehensive mocking support.
>>
> There's no simple relationship between test and code complexity.
I never said the re was...
> E.g. if your text to speech says "Hello world" when you feed it
> the one line program
>
> texttospeech("Hello world");
>
> then that's a very powerful test and, assuming no sabotage, a
> strong indication that the subroutine works.
>
> On the other hand, we've got an edit box that allows the user
> to enter a length in units (metres, feet, etc), then change
> the units globally, whist also setting a precision, and to
> cap it all, it allows formulae like 2+2.
> It's a silly thing and not really doing anything inherently
> difficult. But you can imagine the number of test cases
> something like that has to pass before you have confidence
> in it.
In my case, as many as were required to write it.
>>> Then an issue is how to generate the test set. Obviously
>>> lots of random curves are easy to set up. But that only rarely
>>> throws up a real challenge. Artists, however, are always
>>> drawing curves which intersect at exactly t = 0.5 and other
>>> difficult cases.
>>
>> It's all so much easier if you write the code test fist.
>>
> That works for problems where the right way to approach the
> solution is well known. It doesn't scale to harder problems.
It does if you break down the harder problems into simpler ones:
something programmers tend to be good at!
> For example, curve to curve intersection where the intersection
> point is exactly at 50% is a special case for a recursive
> algorithm that cuts the curves in half. But not for one which
> solves the equations numerically. Unless you know where the
> special cases are likely to be, how can you write the tests,
> given that there are an infinite number of pairs of curves?
How can you write the code and know it works without the tests?
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-13 01:19 -0800 |
| Message-ID | <bd14a6ca-b4e9-4685-abcd-22765b96acd8@googlegroups.com> |
| In reply to | #99167 |
On Tuesday, December 13, 2016 at 1:14:44 AM UTC, Ian Collins wrote: > > >> It's all so much easier if you write the code test fist. > >> > > That works for problems where the right way to approach the > > solution is well known. It doesn't scale to harder problems. > > It does if you break down the harder problems into simpler ones: > something programmers tend to be good at! > 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)? Then the root finder method might not work at all. There are other approaches to the problem. > > For example, curve to curve intersection where the intersection > > point is exactly at 50% is a special case for a recursive > > algorithm that cuts the curves in half. But not for one which > > solves the equations numerically. Unless you know where the > > special cases are likely to be, how can you write the tests, > > given that there are an infinite number of pairs of curves? > > How can you write the code and know it works without the tests? > You produce a test bed. So the component goes straight into the prototype program, which acts as the test environment for it. That isn't always a good answer, but it's often more realistic than trying to do test-driven development. Two common cases are that one of the parameters to the function under test is "the world" and the other is, like curve intersection, that you need to write an intersection algorithm to write the tests.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-13 22:56 +1300 |
| Message-ID | <eb9uufFiu11U1@mid.individual.net> |
| In reply to | #99175 |
On 12/13/16 10:19 PM, Malcolm McLean wrote: > On Tuesday, December 13, 2016 at 1:14:44 AM UTC, Ian Collins wrote: >> >>>> It's all so much easier if you write the code test fist. >>>> >>> That works for problems where the right way to approach the >>> solution is well known. It doesn't scale to harder problems. >> >> It does if you break down the harder problems into simpler ones: >> something programmers tend to be good at! >> > 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)? > > Then the root finder method might not work at all. There are > other approaches to the problem. Polynomial curve fitting is something I use as a worked example when teaching TDD. I use tests and code I wrote long ago to match the discharge characteristics of the batteries in a power system (very close to a 5th order polynomial). For this data set, the match was "good enough" to meet the requirements. Good enough and no better: which was important because it didn't have to be perfect and expending more time and money on a better solution would have been a waste. >>> For example, curve to curve intersection where the intersection >>> point is exactly at 50% is a special case for a recursive >>> algorithm that cuts the curves in half. But not for one which >>> solves the equations numerically. Unless you know where the >>> special cases are likely to be, how can you write the tests, >>> given that there are an infinite number of pairs of curves? >> >> How can you write the code and know it works without the tests? >> > You produce a test bed. So the component goes straight into the > prototype program, which acts as the test environment for it. So you effectively roll your own test framework. This violates my first rule of unit testing. > That isn't always a good answer, but it's often more realistic > than trying to do test-driven development. It isn't a good answer. TDD is always a realistic option if you want fully tested, working, code. > Two common cases > are that one of the parameters to the function under test is > "the world" and the other is, like curve intersection, that > you need to write an intersection algorithm to write the tests. Or you generate the data for the curve you want to fit. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-13 05:16 -0800 |
| Message-ID | <1b677d66-06c5-4360-87af-cd39e7fa82e7@googlegroups.com> |
| In reply to | #99178 |
On Tuesday, December 13, 2016 at 9:56:41 AM UTC, Ian Collins wrote: > On 12/13/16 10:19 PM, Malcolm McLean wrote: > > On Tuesday, December 13, 2016 at 1:14:44 AM UTC, Ian Collins wrote: > >> > >>>> It's all so much easier if you write the code test fist. > >>>> > >>> That works for problems where the right way to approach the > >>> solution is well known. It doesn't scale to harder problems. > >> > >> It does if you break down the harder problems into simpler ones: > >> something programmers tend to be good at! > >> > > 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)? > > > > Then the root finder method might not work at all. There are > > other approaches to the problem. > > Polynomial curve fitting is something I use as a worked example when > teaching TDD. I use tests and code I wrote long ago to match the > discharge characteristics of the batteries in a power system (very close > to a 5th order polynomial). For this data set, the match was "good > enough" to meet the requirements. Good enough and no better: which was > important because it didn't have to be perfect and expending more time > and money on a better solution would have been a waste. > So TDD can work. However see my comment on machine learning. > >>> For example, curve to curve intersection where the intersection > >>> point is exactly at 50% is a special case for a recursive > >>> algorithm that cuts the curves in half. But not for one which > >>> solves the equations numerically. Unless you know where the > >>> special cases are likely to be, how can you write the tests, > >>> given that there are an infinite number of pairs of curves? > >> > >> How can you write the code and know it works without the tests? > >> > > You produce a test bed. So the component goes straight into the > > prototype program, which acts as the test environment for it. > > So you effectively roll your own test framework. This violates my first > rule of unit testing. > The prototype is the partly-finished version of what will become the released program, and also the test framework for the components which are gradually added. We build it like a house. But its not unit-tested, no. Unit testing is good, as long as the components are units that can be isolated from each other. But some things take "the world" as a parameter. Other things only make sense in a threaded environment where some of the threads are running short on time - very hard to mock that for a unit test though of course you can give threads dummy busy-idling to do. Normally it's easier and better just to work the existing system to the point it starts to break down. > > > That isn't always a good answer, but it's often more realistic > > than trying to do test-driven development. > > It isn't a good answer. TDD is always a realistic option if you want > fully tested, working, code. > People who promote methodologies usually make this mistake. The system works in many cases, therefore it must always be used. In fact TDD is of limited use for hard problems. It's fine for easy problems where the way to find the answer is well understood and you know which cases are likely to be edge cases. A very common failing is that people use TDD for hard problems which involve machine learning, and then they find that the program doesn't generalise beyond the test set. So in fact it's something of an anti-pattern for that class of problem. > > Two common cases > > are that one of the parameters to the function under test is > > "the world" and the other is, like curve intersection, that > > you need to write an intersection algorithm to write the tests. > > Or you generate the data for the curve you want to fit. > The problem is finding the points at which the curves intersect. Visually, its usually easy to verify (except for near-tangents). Programatically, it's quite hard to generate coefficients that will be a good test set and then calculate the points of intersection, unless you already have a working function. That's quite common for graphics programs. With curve fitting, you can usually easily verify that no point is more than x units away from the curve, but it's harder to verify that the curve is nice, that it doesn't over-fit. My own curve fitting has mainly visual criteria - it's used for artwork so the curves have to look right, which isn't always easy to capture in a formula. (I tried quintics, BTW, but they are very hard to handle and liable to wildly over-fit in an artistic context, not saying that's also true in battery discharge modelling context).
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-14 18:05 +1300 |
| Message-ID | <ebc296Fiu13U1@mid.individual.net> |
| In reply to | #99187 |
On 12/14/16 02:16 AM, Malcolm McLean wrote: > On Tuesday, December 13, 2016 at 9:56:41 AM UTC, Ian Collins wrote: >> On 12/13/16 10:19 PM, Malcolm McLean wrote: >>> On Tuesday, December 13, 2016 at 1:14:44 AM UTC, Ian Collins wrote: >>>> >>>>>> It's all so much easier if you write the code test fist. >>>>>> >>>>> That works for problems where the right way to approach the >>>>> solution is well known. It doesn't scale to harder problems. >>>> >>>> It does if you break down the harder problems into simpler ones: >>>> something programmers tend to be good at! >>>> >>> 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)? >>> >>> Then the root finder method might not work at all. There are >>> other approaches to the problem. >> >> Polynomial curve fitting is something I use as a worked example when >> teaching TDD. I use tests and code I wrote long ago to match the >> discharge characteristics of the batteries in a power system (very close >> to a 5th order polynomial). For this data set, the match was "good >> enough" to meet the requirements. Good enough and no better: which was >> important because it didn't have to be perfect and expending more time >> and money on a better solution would have been a waste. >> > So TDD can work. However see my comment on machine learning. > >>>>> For example, curve to curve intersection where the intersection >>>>> point is exactly at 50% is a special case for a recursive >>>>> algorithm that cuts the curves in half. But not for one which >>>>> solves the equations numerically. Unless you know where the >>>>> special cases are likely to be, how can you write the tests, >>>>> given that there are an infinite number of pairs of curves? >>>> >>>> How can you write the code and know it works without the tests? >>>> >>> You produce a test bed. So the component goes straight into the >>> prototype program, which acts as the test environment for it. >> >> So you effectively roll your own test framework. This violates my first >> rule of unit testing. >> > The prototype is the partly-finished version of what will become > the released program, and also the test framework for the components > which are gradually added. We build it like a house. > > But its not unit-tested, no. Unit testing is good, as long as the > components are units that can be isolated from each other. But > some things take "the world" as a parameter. Just about any problem can be broken down into units that can be isolated from each other. Do you write your application as one monolithic application? No, you decompose the problem into a set of individual functions (or objects) with defined functionality. > Other things only > make sense in a threaded environment where some of the threads > are running short on time - very hard to mock that for a unit > test though of course you can give threads dummy busy-idling to > do. Normally it's easier and better just to work the existing > system to the point it starts to break down. That is a truly horrible option. >>> That isn't always a good answer, but it's often more realistic >>> than trying to do test-driven development. >> >> It isn't a good answer. TDD is always a realistic option if you want >> fully tested, working, code. >> > People who promote methodologies usually make this mistake. > The system works in many cases, therefore it must always be used. > In fact TDD is of limited use for hard problems. Oh it's good to know that all of the work I do is simple... > It's fine for > easy problems where the way to find the answer is well > understood and you know which cases are likely to be edge > cases. It's fine as a development (don't forget it isn't intended as a testing methodology) methodology for any class of problem. Unit tests should never be viewed as the be all and end all of testing. They are simply the first layer, a tripwire to tell the developer that they have broken something before the testers get hold of the application. Being able to write the initial unit tests is also a good indicator that the problem is adequately specified. On several occasions we (developers) have produced code that passed all of our tests, but failed acceptance testing. In nearly every case, the problem was a bug in the specification. > A very common failing is that people use TDD for hard problems > which involve machine learning, and then they find that the > program doesn't generalise beyond the test set. So in fact > it's something of an anti-pattern for that class of problem. Maybe, I don't have any experience in that area so I can't really offer a rebuttal. But I would be surprised if the components of a machine learning can't be developed with TDD. >>> Two common cases >>> are that one of the parameters to the function under test is >>> "the world" and the other is, like curve intersection, that >>> you need to write an intersection algorithm to write the tests. >> >> Or you generate the data for the curve you want to fit. >> > The problem is finding the points at which the curves intersect. > Visually, its usually easy to verify (except for near-tangents). > Programatically, it's quite hard to generate coefficients that > will be a good test set and then calculate the points of > intersection, unless you already have a working function. > > That's quite common for graphics programs. With curve fitting, > you can usually easily verify that no point is more than > x units away from the curve, but it's harder to verify that > the curve is nice, that it doesn't over-fit. My own curve fitting > has mainly visual criteria - it's used for artwork so the curves > have to look right, which isn't always easy to capture in a > formula. (I tried quintics, BTW, but they are very hard to handle > and liable to wildly over-fit in an artistic context, not > saying that's also true in battery discharge modelling context). As I said yesterday, the solution was good enough and no better. I'm sure you could apply the same logic to your domain. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-13 08:19 -0800 |
| Message-ID | <lnr35bpzs6.fsf@kst-u.example.com> |
| In reply to | #99175 |
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?
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-13 17:01 +0000 |
| Message-ID | <87lgvjahls.fsf@bsb.me.uk> |
| In reply to | #99215 |
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. 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). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-13 10:48 -0800 |
| Message-ID | <2173746b-ac76-4474-8fe1-58d1deafb8d3@googlegroups.com> |
| In reply to | #99218 |
On Tuesday, December 13, 2016 at 5:01:27 PM UTC, 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. > > 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). > Ben has it right. Curve fitting can be 2 dimensional or one dimensional, depending on whether the x axis represents something like time, which is monotononic and even, or something like longitude vs latitude of a river, where the x term can go back on itself as you fit the equation.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2016-12-13 11:56 -0800 |
| Message-ID | <1fk05c5i9laqtm9e7tb4naottc8dpndteb@4ax.com> |
| In reply to | #99227 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-13 13:37 -0800 |
| Message-ID | <928e1c2d-c5f1-409a-a6e7-2897216767c8@googlegroups.com> |
| In reply to | #99246 |
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.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web