Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91879 > unrolled thread
| Started by | Real Troll <real.troll@trolls.com> |
|---|---|
| First post | 2016-08-07 17:59 -0400 |
| Last post | 2016-08-10 15:00 -0500 |
| Articles | 20 on this page of 123 — 23 participants |
Back to article view | Back to comp.lang.c
Float Vs Double Real Troll <real.troll@trolls.com> - 2016-08-07 17:59 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-07 23:38 +0100
Re: Float Vs Double Real Troll <real.troll@trolls.com> - 2016-08-07 18:55 -0400
Re: Float Vs Double jameskuyper@verizon.net - 2016-08-07 16:43 -0700
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 19:36 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 04:05 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 20:41 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 11:41 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 04:23 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 23:45 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-10 03:26 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 01:00 +0100
Re: Float Vs Double jameskuyper@verizon.net - 2016-08-08 08:52 -0700
Re: Float Vs Double James Kuyper <jameskuyper@verizon.net> - 2016-08-08 11:58 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 10:06 -0700
Re: Float Vs Double "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-08 19:46 -0400
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:29 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 14:04 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:00 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 18:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 14:34 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 12:00 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 16:42 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 14:04 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:48 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-10 03:22 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-21 18:31 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-08-22 08:39 -0700
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-22 19:29 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-22 19:24 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 01:01 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-22 21:58 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 09:38 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 08:15 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 15:07 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 09:40 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 15:14 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:38 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 17:18 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 15:47 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 16:39 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 11:45 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 21:42 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 15:52 -0400
Re: Float Vs Double Ian Collins <ian-news@hotmail.com> - 2016-08-24 08:36 +1200
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-24 09:39 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:31 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 10:48 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 08:17 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 06:01 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 09:44 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 07:19 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:39 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 08:18 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 14:47 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:40 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 01:31 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 20:53 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-08-23 23:20 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:32 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-24 09:46 +0200
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 14:53 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:35 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 08:57 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 17:36 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 12:50 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 17:26 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 12:51 -0400
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:33 -0400
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-08-28 02:33 -0500
Re: Float Vs Double antispam@math.uni.wroc.pl - 2016-08-31 22:36 +0000
Re: Float Vs Double supercat@casperkitty.com - 2016-08-31 15:51 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:42 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-01 08:32 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 15:00 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-01 13:45 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 20:50 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-02 08:11 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 12:25 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-09-02 20:42 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 16:25 -0400
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 08:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 10:48 -0400
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 19:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 18:16 -0400
Re: Float Vs Double asetofsymbols@gmail.com - 2016-09-08 11:18 -0700
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-09-07 19:59 -0500
Re: Float Vs Double supercat@casperkitty.com - 2016-09-08 08:13 -0700
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-09-08 19:34 -0500
Re: Float Vs Double supercat@casperkitty.com - 2016-09-09 07:50 -0700
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-02 23:40 -0700
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 09:06 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 10:52 -0400
Re: Float Vs Double Rosario19 <Ros@invalid.invalid> - 2016-08-24 08:57 +0200
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 01:04 -0700
Re: Float Vs Double Ike Naar <ike@iceland.freeshell.org> - 2016-08-08 06:44 +0000
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-08 00:16 -0700
Re: Float Vs Double Richard Damon <Richard@Damon-Family.org> - 2016-08-08 23:29 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 14:03 +0200
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-08 05:14 -0700
Re: Float Vs Double BGB <cr88192@hotmail.com> - 2016-08-09 19:53 -0500
Re: Float Vs Double "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-07 18:47 -0400
Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 17:04 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-08 05:49 -0700
Re: Float Vs Double Nobody <nobody@nowhere.invalid> - 2016-08-10 03:26 +0100
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-09 20:15 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 06:07 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 06:13 -0700
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-10 16:43 +0200
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 07:56 -0700
Re: Float Vs Double supercat@casperkitty.com - 2016-08-10 08:39 -0700
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 09:56 -0700
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 10:04 -0700
Re: Float Vs Double Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 07:08 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-11 07:15 -0700
Re: Float Vs Double Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-12 08:11 -0700
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-10 20:38 +0200
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 12:20 -0700
Re: Float Vs Double supercat@casperkitty.com - 2016-08-10 12:17 -0700
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-10 21:48 +0200
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 13:40 -0700
Re: Float Vs Double Ian Collins <ian-news@hotmail.com> - 2016-08-12 08:01 +1200
Re: Float Vs Double BGB <cr88192@hotmail.com> - 2016-08-10 15:00 -0500
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | Real Troll <real.troll@trolls.com> |
|---|---|
| Date | 2016-08-07 17:59 -0400 |
| Subject | Float Vs Double |
| Message-ID | <no8ad8$ah6$1@gioia.aioe.org> |
Any reasons why the default precision value is still 6 since the bad old
days? For example the result I get is this:
> 3.141592653589793238 ==> Actual value
> x=3.141593
> z=3.141593
> x=3.141592741012573242
> z=3.141592653589793116
>
>
>
> Storage size for float : 4
> Storage size for double : 8
> Minimum float value: 1.175494E-38
> Maximum float value: 3.402823E+38
> Precision value: 6
The program I used is this:
#include <stdio.h>
#include <stdlib.h>
#include <float.h>
int main(void)
{
float x = 3.141592653589793238;
double z = 3.141592653589793238;
printf("3.141592653589793238 ==> Actual value\n");
printf("x=%f\n", x);
printf("z=%f\n", z);
printf("x=%20.18f\n", x);
printf("z=%20.18f\n", z);
printf("\n"); printf("\n"); printf("\n");
printf("Storage size for float : %d \n", sizeof(float));
printf("Storage size for double : %d \n", sizeof(double));
printf("Minimum float value: %E\n", FLT_MIN );
printf("Maximum float value: %E\n", FLT_MAX );
printf("Precision value: %d\n", FLT_DIG );
return 0;
}
[toc] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-07 23:38 +0100 |
| Message-ID | <87a8gomcg9.fsf@bsb.me.uk> |
| In reply to | #91879 |
Real Troll <real.troll@trolls.com> writes: > Any reasons why the default precision value is still 6 since the bad old > days? Why change it? Whilst it's unlikely that much software relies on the default precision for %f output, there is so little benefit to changing it the balance must be against any change. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Real Troll <real.troll@trolls.com> |
|---|---|
| Date | 2016-08-07 18:55 -0400 |
| Message-ID | <no8dgp$equ$1@gioia.aioe.org> |
| In reply to | #91879 |
So how do you perform scientific calculations which have to be as precise as possible? what changes one has to make to get 22 or more decimal places (see the program I gave before). To give you a trivial example, PI can be written as infinite decimal places so how do you accommodate this? On 07/08/2016 23:26, Stefan Ram wrote: > Real Troll <real.troll@trolls.com> writes: >> Any reasons why the default precision value is still 6 since the bad old >> days? For example the result I get is this: > There is no »default precision value« in C. But FLT_DIG > indeed has to be at least 6. But since the type of a > floating constant, such as »1.0«, is »double« and not > »float«, the »default« is more something like »double« and > not »float«, and DBL_DIG has to be at least 10 (I believe > it usually is more some value near 15). > > For many continuous values humans use, six digits already > are enough. For example, a temperature measured can be > > 33.3 degrees > > , the speed of a car can be > > 20.2 m.p.h. > > , the lenght of a rod of copper can be > > 15.2 mm > > , but did you ever observe a temperature of > > 33.31321 degrees > > , or a speed of > > 20.2214081 m.p.h. > > , or a rod with a length or > > 15.211418 mm > > ? Or can you prepare a temperature, a speed or a length > with such a precision? > > So, for many cases, 6 digits already are sufficient and > 15 are more than enough. And some implementations have > a long double type with even more precision. > > When still more precision is needed, one can download a library, > in which case C++ with its operator overloading of course > would be nice. > >
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-07 16:43 -0700 |
| Message-ID | <661abef1-6e71-4a0a-81eb-bd4592a6e85a@googlegroups.com> |
| In reply to | #91886 |
On Sunday, August 7, 2016 at 6:42:43 PM UTC-4, Real Troll wrote: > So how do you perform scientific calculations which have to be as > precise as possible? ... What I was taught as an undergraduate is that the key point in science is not so much being as precise as possible (extremely high precision is always possible, but would often be wastefully expensive). The key thing is to clearly understand how precise your raw measurements and calculated values actually are. Every numerical value should be written in the form 12.356 +/- 0.025. A complicated process called "propagation of error" is used for estimating the accuracy of calculated values - if you're seriously interested in such issues, I recommend Googling it. I was too careless to make a good experimentalist, and insufficiently imaginative to make a good theoretician, so I ended up doing scientific computer programming instead. And I watched in horror as the scientists I worked with almost never bothered to calculate error bars for their measurements. I see error bars in almost every published scientific paper I've ever read, but they don't seem to be a part of the day-to-day routine of these particular scientists. I was once asked whether a particular change to our program had produced a significant improvement. I passed that question on to the relevant scientist. He gave me a long list of measurements of the differences between the results using the two versions. I asked him if the differences were statistically significant. He responded with an even longer and more detailed report, but one which lacked the information I would have needed to calculate any of the standard statistical significance measures. I eventually learned that he had no idea what I was talking about, and when I did explain it to him, he had no idea how to determine whether they were significant. I was forced to report back to the original questioner "we don't know". I was rather embarrassed by the whole incident. > ... what changes one has to make to get 22 or more > decimal places (see the program I gave before). Keep in mind that all that your program demonstrated was the default precision with which floating point values are printed, and how to override that default. That has little, if anything, to do with the actual accuracy of the underlying floating point values. You can print a float value that has only 7 digits of accuracy, with 22 digits, and printf() will fill in all of those extra digits - their values won't be meaningful - but neither will they be random; they'll be determined by the value you're printing and the algorithm used to convert a floating point value to a decimal digit string. Conversely, if you don't specify the precision, you can print a long double value with 22 digits after the decimal place, and all you'll see are 6 of them. The thing you need to pay attention to is called FLT_EPSILON for float, DBL_EPSILON for double, and LDBL_EPSILON for long double. The maximum permitted value for FLT_EPSILON is 1E-5, while the maximum permitted value for DBL_EPSILON and LDBL_EPSILON is 1e-9. You generally should use the fastest type that has sufficiently low values for *_EPSILON to carry out your algorithms with sufficient accuracy. And in order to determine whether the value is sufficiently low, you're going to have to master "propagation of error". However, as a practical matter, double is sufficient for most scientific and engineering applications. Float is only rarely sufficient. In my work, we use it only to store our final results, and only when propagation of error indicates that those results have sufficiently low accuracy to justify using float. Since our raw measurements are mostly 12-bit photon counts, this is often the case. We do all intermediate calculations in double. > ... To give you a trivial > example, PI can be written as infinite decimal places so how do you > accommodate this? The maximum permitted value for DBL_EPSILON*PI is 3e-9, so there's no way to guarantee better than 9 decimal places in portable code. For code that's non-portable, you should check the actually value of DBL_EPSILON. If __STDC_IEC_559__ is pre-#defined by the implementation, then double is required to meet the requirements for a double precision type specified by IEC 60559 (== ANSI/IEEE 754), so DBL_EPSILON would be 0X1P-52, or approximately 2.2204460492503131E-16, which still isn't sufficient to get you 22 decimal digits. Any program that shows you 22 or more significant digits is using something other than one of the C standard types to calculate those digits. A software-emulated high-precision type is one way to do it, though I gather that there are more sophisticated approaches that have to be used when you're trying, for instance, to calculate the millionth digit of pi.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-07 19:36 -0700 |
| Message-ID | <73f20603-bb84-4f3d-883a-476a923dea2b@googlegroups.com> |
| In reply to | #91896 |
On Monday, August 8, 2016 at 12:43:58 AM UTC+1, james...@verizon.net wrote: > On Sunday, August 7, 2016 at 6:42:43 PM UTC-4, Real Troll wrote: > > So how do you perform scientific calculations which have to be as > > precise as possible? ... > > What I was taught as an undergraduate is that the key point in > science is not so much being as precise as possible (extremely high > precision is always possible, but would often be wastefully expensive). > The key thing is to clearly understand how precise your raw measurements > and calculated values actually are. > That's important, but it tends to be obvious, because most instruments come with a "precision" attached. or it's implicit in you quantisation. The killer is systematic bias in measurements due to unknown or uncontrollable for causes. > I eventually learned that he had no idea what I was talking about, > and when I did explain it to him, he had no idea how to determine > whether they were significant. I was forced to report back to the > original questioner "we don't know". I was rather embarrassed by the > whole incident. > Statistical significance test are useful for telling you that the results aren't significant and you've found nothing of interest. But they can't prove a hypotheis, only reject the null hypothesis. That's what most non-statisticians don't understand. And if you need a statistical significance test to tell you that the null is rejected, the most likely alternative hypothesis is noise due to systemic bias in measurements from unknown, uncontrollable, but not scientifically interesting causes. > > And in order to determine whether the value is sufficiently low, > you're going to have to master "propagation of error". > Unfortunately you don't know whether your errors cancel or accumulate, so the procedure is very limited practical value. If we assume that they all accumulate, we very quickly get absurdly wide error margins, if we assume that they all cancel, we might as well simply not propagate at all, and if we know, then how does what we are doing constitute research?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-08 04:05 +0100 |
| Message-ID | <87fuqgklk1.fsf@bsb.me.uk> |
| In reply to | #91912 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, August 8, 2016 at 12:43:58 AM UTC+1, james...@verizon.net wrote: <snip> >> The key thing is to clearly understand how precise your raw measurements >> and calculated values actually are. <snip> >> And in order to determine whether the value is sufficiently low, >> you're going to have to master "propagation of error". >> > Unfortunately you don't know whether your errors cancel or accumulate, > so the procedure is very limited practical value. If we assume that > they all accumulate, we very quickly get absurdly wide error margins, > if we assume that they all cancel, we might as well simply not > propagate at all, and if we know, then how does what we are doing > constitute research? Your editing of the post (without any marking), and the content of your reply, both suggests that these errors are the same errors that James is talking about above, but the context you cut makes it clear that they are not. The latter errors seem to refer to algorithm errors and you may very well know if the algorithm errors cancel or accumulate, even when doing original research (either on the algorithms or on the source data). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-07 20:41 -0700 |
| Message-ID | <e7af6453-114c-4458-a95c-a1ad5c8f98e7@googlegroups.com> |
| In reply to | #91914 |
On Monday, August 8, 2016 at 4:05:12 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > Your editing of the post (without any marking), and the content of your > reply, both suggests that these errors are the same errors that James is > talking about above, but the context you cut makes it clear that they > are not. The latter errors seem to refer to algorithm errors and you > may very well know if the algorithm errors cancel or accumulate, even > when doing original research (either on the algorithms or on the source > data). > OK, so we've got a set of data, measurements of children's height versus weight. In fact the error is mainly due to the fact that girls tend to carry mobile phones, so some of them are measured with too much weight, whilst boys go in for skinhead and often lose a bit of height. But the researchers aren't aware of that. They do have a accuracy statistic of 100 grams standard deviation in the weight and 1 cm standard deviation in the height, which is true enough. Your data consists of two CSV files containing name of child, sex, age, weight, height, from two schools, St Scholastica, our control group, and Snobsfield, our intervention group which has had healthy eating lessons. Your task is to write a program to tell us whether the healthy eating program has had any effect. How are you going to go about that?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-08 11:41 +0100 |
| Message-ID | <871t1zlf09.fsf@bsb.me.uk> |
| In reply to | #91918 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, August 8, 2016 at 4:05:12 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> >> Your editing of the post (without any marking), and the content of your >> reply, both suggests that these errors are the same errors that James is >> talking about above, but the context you cut makes it clear that they >> are not. The latter errors seem to refer to algorithm errors and you >> may very well know if the algorithm errors cancel or accumulate, even >> when doing original research (either on the algorithms or on the source >> data). >> > OK, so we've got a set of data, measurements of children's height > versus weight. > In fact the error is mainly due to the fact that girls tend to > carry mobile phones, so some of them are measured with too much > weight, whilst boys go in for skinhead and often lose a bit of > height. But the researchers aren't aware of that. They do have > a accuracy statistic of 100 grams standard deviation in the weight > and 1 cm standard deviation in the height, which is true enough. > > Your data consists of two CSV files containing name of child, > sex, age, weight, height, from two schools, St Scholastica, our > control group, and Snobsfield, our intervention group which has > had healthy eating lessons. > > Your task is to write a program to tell us whether the healthy > eating program has had any effect. How are you going to go about > that? I understand your point but you don't appear to have understood mine. I am sure I could have been clearer (and I may have been wrong), but you could ask me about it rather than ignoring it and setting homework like some patronising headmaster. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-08 04:23 -0700 |
| Message-ID | <2e3beaa0-85c1-4cb4-b689-40da47b7136e@googlegroups.com> |
| In reply to | #91941 |
On Monday, August 8, 2016 at 11:41:18 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Monday, August 8, 2016 at 4:05:12 AM UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> > >> > >> Your editing of the post (without any marking), and the content of your > >> reply, both suggests that these errors are the same errors that James is > >> talking about above, but the context you cut makes it clear that they > >> are not. The latter errors seem to refer to algorithm errors and you > >> may very well know if the algorithm errors cancel or accumulate, even > >> when doing original research (either on the algorithms or on the source > >> data). > >> > > OK, so we've got a set of data, measurements of children's height > > versus weight. > > In fact the error is mainly due to the fact that girls tend to > > carry mobile phones, so some of them are measured with too much > > weight, whilst boys go in for skinhead and often lose a bit of > > height. But the researchers aren't aware of that. They do have > > a accuracy statistic of 100 grams standard deviation in the weight > > and 1 cm standard deviation in the height, which is true enough. > > > > Your data consists of two CSV files containing name of child, > > sex, age, weight, height, from two schools, St Scholastica, our > > control group, and Snobsfield, our intervention group which has > > had healthy eating lessons. > > > > Your task is to write a program to tell us whether the healthy > > eating program has had any effect. How are you going to go about > > that? > > I understand your point but you don't appear to have understood mine. I > am sure I could have been clearer (and I may have been wrong), but you > could ask me about it rather than ignoring it and setting homework like > some patronising headmaster. > > You said that the error propagation depends on the algorithms used to process the data rather than the characteristics of the data. So there's an example of a dataset with some errors in it. So now explain how to write the algorithms so that they propagate those errors correctly and give us a sensible result.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-08 23:45 +0100 |
| Message-ID | <871t1ykhhn.fsf@bsb.me.uk> |
| In reply to | #91947 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, August 8, 2016 at 11:41:18 AM UTC+1, Ben Bacarisse wrote: <snip> >> I understand your point but you don't appear to have understood mine. I >> am sure I could have been clearer (and I may have been wrong), but you >> could ask me about it rather than ignoring it and setting homework like >> some patronising headmaster. >> > You said that the error propagation depends on the algorithms used to > process the data rather than the characteristics of the data. No I didn't. Would you like me to try again? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-10 03:26 -0700 |
| Message-ID | <15f5e309-0457-45b2-b2ee-e5ae02026cf6@googlegroups.com> |
| In reply to | #91998 |
On Monday, August 8, 2016 at 11:45:18 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Monday, August 8, 2016 at 11:41:18 AM UTC+1, Ben Bacarisse wrote: > <snip> > >> I understand your point but you don't appear to have understood mine. I > >> am sure I could have been clearer (and I may have been wrong), but you > >> could ask me about it rather than ignoring it and setting homework like > >> some patronising headmaster. > >> > > You said that the error propagation depends on the algorithms used to > > process the data rather than the characteristics of the data. > > No I didn't. Would you like me to try again? > You can have a shot. You've declined to explain how to approach my hypothetical problem on the grounds that the question is patronising. But since I'm summarising your summary of what someone else said, there's plenty of room for misinterpretation.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-11 01:00 +0100 |
| Message-ID | <87eg5wfa32.fsf@bsb.me.uk> |
| In reply to | #92053 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, August 8, 2016 at 11:45:18 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > On Monday, August 8, 2016 at 11:41:18 AM UTC+1, Ben Bacarisse wrote: >> <snip> >> >> I understand your point but you don't appear to have understood mine. I >> >> am sure I could have been clearer (and I may have been wrong), but you >> >> could ask me about it rather than ignoring it and setting homework like >> >> some patronising headmaster. >> >> >> > You said that the error propagation depends on the algorithms used to >> > process the data rather than the characteristics of the data. >> >> No I didn't. Would you like me to try again? >> > You can have a shot. Then I'll pass. > You've declined to explain how to approach my hypothetical problem on the > grounds that the question is patronising. No, I called it patronising (because it was), but I declined to explain how to approach it because it had nothing to do with what I said. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-08 08:52 -0700 |
| Message-ID | <11759965-6269-4711-a885-2f65f4d12097@googlegroups.com> |
| In reply to | #91912 |
On Sunday, August 7, 2016 at 10:37:08 PM UTC-4, Malcolm McLean wrote: > On Monday, August 8, 2016 at 12:43:58 AM UTC+1, james...@verizon.net wrote: > > On Sunday, August 7, 2016 at 6:42:43 PM UTC-4, Real Troll wrote: > > > So how do you perform scientific calculations which have to be as > > > precise as possible? ... > > > > What I was taught as an undergraduate is that the key point in > > science is not so much being as precise as possible (extremely high > > precision is always possible, but would often be wastefully expensive). > > The key thing is to clearly understand how precise your raw measurements > > and calculated values actually are. > > > That's important, but it tends to be obvious, because most instruments > come with a "precision" attached. or it's implicit in you quantisation. I assume that "obvious" refers to measured values, not calculated ones. > The killer is systematic bias in measurements due to unknown or > uncontrollable for causes. Which is why a lot of effort is expended in proper scientific work to make sure that systematic biases are known and controlled. > > I eventually learned that he had no idea what I was talking about, > > and when I did explain it to him, he had no idea how to determine > > whether they were significant. I was forced to report back to the > > original questioner "we don't know". I was rather embarrassed by the > > whole incident. > > > Statistical significance test are useful for telling you that the > results aren't significant and you've found nothing of interest. > But they can't prove a hypotheis, only reject the null hypothesis. I was only asked whether the change in our program had produced a significant improvement in the accuracy; i.e. whether we were justified in rejecting the null hypothesis that the changes had had no net effect. Therefore, standard statistical significance tests would have been entirely relevant to answering that question, if the scientist involved had bothered collecting the information needed to apply those tests. ... > > And in order to determine whether the value is sufficiently low, > > you're going to have to master "propagation of error". > > > Unfortunately you don't know whether your errors cancel or accumulate, If you don't know, you'd better find out. If you don't have any specific reason for expecting the errors to be correlated, the closest thing to a neutral assumption is that the errors are neither positively correlated, nor negatively correlated, but simply uncorrelated. And if you're signficantly wrong about that assumption, making calculations based upon the assumption that they are uncorrelated, and finding a resulting discrepancy between theory and measurement, will be the necessary first step in a process that can lead to a determination of how they are actually correlated. > so the procedure is very limited practical value. If we assume that > they all accumulate, we very quickly get absurdly wide error margins, > if we assume that they all cancel, we might as well simply not > propagate at all, and if we know, then how does what we are doing > constitute research? Let's take a simple case of a two measured quantities a and b, and single calculated quantity c, with c = a + b. Assume that the errors in a and b can be approximated as having a gaussian distribution with a mean of 0 an a standard deviation of sigma_a and sigma_b, respectively. Then if the errors in a are perfectly correlated with the errors in b, sigma_c = sigma_a + sigma_b. If they are perfectly anti-correlated, sigma_c = fabs(sigma_a - sigma_b). If they are uncorrelated, sigma_c = hypot(sigma_a, sigma_b). If they have an intermediate degree of correlation, you can measure that correlation and use it to calculate sigma_c by a formula that I don't use often enough to have memorized, but which produces results intermediate between those values. If you don't know how they're correlated, and the difference is significant, find out. If you don't, your results will reflect your ignorance of that correlation, and can be used as part of the process of determining how they are correlated. If it's not significant, then you don't have to worry about it - that's what "significant" means in this context. If they are in fact perfectly correlated, the correspondingly large calculated error is indeed something you'll have to deal with. If you consider an accurate error estimate to be absurdly large, I recommend adjusting your way of determining what you consider absurd. If they're perfectly anti-correlated, then they still don't cancel unless sigma_a == sigma_c, so you still need to calculate the non-zero error estimate. And if they do cancel exactly (for instance: a = 5+x, b = 2-x, sigma_a == sigma_b == sigma_x, c = 3 with a standard deviation of exactly 0), that's something important you should know about.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-08 11:58 -0400 |
| Message-ID | <noaa7n$5t5$1@dont-email.me> |
| In reply to | #91965 |
On 08/08/2016 11:52 AM, jameskuyper@verizon.net wrote: > If they're perfectly anti-correlated, then they still don't cancel > unless sigma_a == sigma_c, so you still need to calculate the non-zero > error estimate. And if they do cancel exactly (for instance: a = 5+x, > b = 2-x, sigma_a == sigma_b == sigma_x, c = 3 with a standard deviation of > exactly 0), that's something important you should know about. Correction: c=7. I actually had it right in the first draft and then "corrected" it to 2. :-(
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-08 10:06 -0700 |
| Message-ID | <29a9a163-40df-43b3-bba6-39a1108f5697@googlegroups.com> |
| In reply to | #91965 |
On Monday, August 8, 2016 at 4:52:16 PM UTC+1, James Kuyper wrote: > On Sunday, August 7, 2016 at 10:37:08 PM UTC-4, Malcolm McLean wrote: > > > The killer is systematic bias in measurements due to unknown or > > uncontrollable for causes. > > Which is why a lot of effort is expended in proper scientific work to make sure > that systematic biases are known and controlled. > But you don't know what the systematic biases are, otherwise you'd simply remove them. Maybe in a few areas that's not true, but for the vast majority of science, errors in data are contributions to measurements that you do not understand, do not know about, and cannot control for. > > I was only asked whether the change in our program had produced a significant > improvement in the accuracy; i.e. whether we were justified in rejecting the > null hypothesis that the changes had had no net effect. Therefore, standard > statistical significance tests would have been entirely relevant to answering > that question, if the scientist involved had bothered collecting the information > needed to apply those tests. > Is the program running the instrument that takes the measurement of analysing the data? if the latter, thenI'm afraid you inherently and fundamentally misunderstand what statistics are and how to use them. The accuracy is in the measurement, not the analysis. You can have a more powerful test that rejects more null hypotheses, but not a more "accurate" one, unless the old test was unsound. > > > Unfortunately you don't know whether your errors cancel or accumulate, > > If you don't know, you'd better find out. If you don't have any specific reason > for expecting the errors to be correlated, the closest thing to a neutral > assumption is that the errors are neither positively correlated, nor negatively > correlated, but simply uncorrelated. And if you're signficantly wrong about > that assumption, making calculations based upon the assumption that they are > uncorrelated, and finding a resulting discrepancy between theory and > measurement, will be the necessary first step in a process that can lead to a > determination of how they are actually correlated. > You don't know because error is inherently something you don't understand. > Let's take a simple case of a two measured quantities a and b, and single calculated > quantity c, with c = a + b. Assume that the errors in a and b can be approximated as > having a gaussian distribution with a mean of 0 an a standard deviation of sigma_a > and sigma_b, respectively. Then if the errors in a are perfectly correlated with the errors > in b, sigma_c = sigma_a + sigma_b. If they are perfectly anti-correlated, sigma_c = > fabs(sigma_a - sigma_b). If they are uncorrelated, sigma_c = hypot(sigma_a, sigma_b). > If they have an intermediate degree of correlation, you can measure that correlation > and use it to calculate sigma_c by a formula that I don't use often enough to have > memorized, but which produces results intermediate between those values. > But since you can measure the errors, it's easier simply to subtract the error term from the measurements and use error-free data. If you can't measure the errors, you can't know if they are correlated or not, though you can sometimes make an educated guess based on fundamentals and an understanding of the measuring process.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-08 19:46 -0400 |
| Message-ID | <e9a39dc6-8176-71f5-5374-5e4a5381e40c@verizon.net> |
| In reply to | #91896 |
On 08/07/2016 07:43 PM, jameskuyper@verizon.net wrote: ... > I was once asked whether a particular change to our program had produced a > significant improvement. I passed that question on to the relevant scientist. > He gave me a long list of measurements of the differences between the results > using the two versions. I just realized that I left out a key point. We judge the accuracy of our geolocation by matching up our images with a thousand or so small high-resolution precisely geolocated LandSat images, called control points. The differences I was referring to above are differences in how well the positions calculated by those two algorithms matched the known locations of the corresponding control points. The differences in the geolocation itself would have been pretty meaningless, without some basis for deciding which one was more accurate. The numbers did show that the new algorithm produced a better match to the control points, but it was a sufficiently small improvement that the question about whether it was statistically significant was justified. > ... I asked him if the differences were statistically > significant. He responded with an even longer and more detailed report, but one > which lacked the information I would have needed to calculate any of the > standard statistical significance measures. I eventually learned that he had no > idea what I was talking about, and when I did explain it to him, he had no idea > how to determine whether they were significant. I was forced to report back to > the original questioner "we don't know". I was rather embarrassed by the whole > incident.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-07 21:29 -0400 |
| Message-ID | <no8n9c$mfv$1@jstuckle.eternal-september.org> |
| In reply to | #91886 |
On 8/7/2016 6:55 PM, Real Troll wrote: > So how do you perform scientific calculations which have to be as > precise as possible? what changes one has to make to get 22 or more > decimal places (see the program I gave before). To give you a trivial > example, PI can be written as infinite decimal places so how do you > accommodate this? > > <snip> You use a language better suited to higher precision. C is not the best language for everything. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-08 14:04 +0200 |
| Message-ID | <no9sg0$mcl$2@dont-email.me> |
| In reply to | #91902 |
Le 08/08/2016 à 03:29, Jerry Stuckle a écrit : > You use a language better suited to higher precision. C is not the best > language for everything. You are just not up to date. Use lcc-win! lcc-win offers 1) Real long double (80 bits) support with approx 19 decimal digits 2) 128 bit IEEE double precision with around 30 decimal digits 3) Qfloat numbers with approx 130 (!!!) digits precision
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-08 09:00 -0400 |
| Message-ID | <no9vpa$fn$1@jstuckle.eternal-september.org> |
| In reply to | #91949 |
On 8/8/2016 8:04 AM, jacobnavia wrote: > Le 08/08/2016 à 03:29, Jerry Stuckle a écrit : >> You use a language better suited to higher precision. C is not the best >> language for everything. > > You are just not up to date. > > Use lcc-win! > > lcc-win offers > > 1) Real long double (80 bits) support with approx 19 decimal digits > 2) 128 bit IEEE double precision with around 30 decimal digits > 3) Qfloat numbers with approx 130 (!!!) digits precision > > Oh, I'm up to date. But you're using a compiler for a single OS with non-standard extensions that can change at any time. Not something I recommend for long-term development. If you need higher precision, use a language that supports higher precision. Or build your own library to support it (which isn't that hard for basic arithmetic operations). -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-08 18:43 +0200 |
| Message-ID | <noacrt$gkn$1@dont-email.me> |
| In reply to | #91952 |
Le 08/08/2016 à 15:00, Jerry Stuckle a écrit : > On 8/8/2016 8:04 AM, jacobnavia wrote: >> Le 08/08/2016 à 03:29, Jerry Stuckle a écrit : >>> You use a language better suited to higher precision. C is not the best >>> language for everything. >> >> You are just not up to date. >> >> Use lcc-win! >> >> lcc-win offers >> >> 1) Real long double (80 bits) support with approx 19 decimal digits >> 2) 128 bit IEEE double precision with around 30 decimal digits >> 3) Qfloat numbers with approx 130 (!!!) digits precision >> >> > > Oh, I'm up to date. But you're using a compiler for a single OS with > non-standard extensions that can change at any time. Not something I > recommend for long-term development. > One of my customers is MATLAB, and that since I started this project, in 1995. I am still here, but COMPAQ disappeared, Borland disappeared, and many other "BIG" companies disappeared. Another customer, is using my JIT under Macintosh OS X and linux. You just speak your prejudices against my work. By the way my extensions are foreseen in the standard, since it explicitly says that implementation might provide numbers of greater precision.
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web