Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: complex number in struct form in C |
| Date | 2014-12-29 20:54 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <m7sf31$ojc$1@speranza.aioe.org> (permalink) |
| References | (7 earlier) <cg5tkrFdk2bU1@mid.individual.net> <m7oa2p$m7a$1@speranza.aioe.org> <onTnw.296096$812.264879@fx20.am4> <m7r9bb$lgf$1@speranza.aioe.org> <20141229112747.367@kylheku.com> |
Kaz Kylheku <kaz@kylheku.com> wrote: >> BartC <bc@freeuk.com> wrote: >> (snip, I wrote) >>>> Two things that it is generally believed should not be done in >>>> floating point (besides cryptography) are finance and typesetting. >>> The issues with the uses in finance ones we all know about (whether we >>> agree or not). >>> What problems are you going to get in typesetting? (then I wrote) >> Knuth wrote that when working on TeX. For that reason, TeX uses only >> fixed point math for typesetting computation, though some floating >> point is used for messages. Computations in TeX are done in 32 bits, >> with 16 bits after the binary point, giving the value in printers >> points. (72.27 pt/in.) > If you use floating-point arithmetic for typesetting, it will look > fine to the naked eye. However, the results will not be bit-exact. Well, TeX was designed before IEEE floating point, when you had a variety of different rounding (or truncation) methods. TeX itself just positions characters on a page, actual bit patterns are generated by other programs. Changes in rounding could change line breaks, which then could change page breaks. > This means it will be more difficult to develop a regression > test suite which works on every supported target machine. Yes, that is one reason. Running the same input files should generate the same DVI file on every machine. The log file, which does use floating point, might be different, and I believe that there are systems to verify that in regression testing. But even more than regression, it is confusing to users to get different results on different machines. That might be less of a problem now, as generating PDF from DVI might be common enough, and that will at least have the same line and page breaks. (Though it might look different.) > The test suite will have to have some tolerances built in. Say, it could > judge how closely the typeset output is to some ideal value, and give that > a score from 0 to 1, and then the regression test suite is looking for, > say, 0.98 as a passing mark. But if you change line and page breaks, the differences will be big. TeX has the character widths, heights, and depths, which should be the same for every machine. But different rounding could easily change formatting decisions with a large effect. > In the area of encoding voice for telephony, you can do this with PESQ > scores, for instance. A regression suite for a bunch of voice codecs > can pass stock audio samples through them and measure PESQ. If the scores > deviate from the previously established "golden values", then there is > a problem. (This is useful to do even if the codecs could be tested > for bit-exactness. Why? Because the test can be done end-to-end, involving > analog components also. A failure could indicate not only that the > work on some codec has a bug, but that the equipment has problems, like > noisy amplifiers, distortion, or externaly induced noise.) I don't know digital telephony so well, but I don't think it has the page and line break problem. The goal is to be sufficiently close in sound. Now, in real VoIP you could have packet loss and such, but I don't think you count that in regression testing of codecs. > On the other hand, suppose your floating-point numbers give you 15 > decimal digits of significance, and say the output is quantized > into around 16 bits. You can still get bit-exact results, even > if there are discrepancies in the last digit from one machine to > the next. It may require some cunning in some of the corner cases. TeX quantizes to 1/65536 printers points, as 32 bit fixed point. Also, unlike just about everyone else, he went through the program to make sure that the regression testing gets to every part of the code, except for fatal errors. The actual tests are pretty much unrelated to any actual typesetting. >> He has an example where they were typesetting on a machine that they >> were told was 5333 dpi, and the results looked bad. When they found >> that it was actually 5333 1/3 dpi, everything worked fine. Just a >> tiny difference in rounding makes a big visual difference. > If you have a 5333 1/3 DPI black device, and you try to render 5333 > stripes which alternate between black and white, there will be a nasty > moiré effect. > A 1/3 difference out of 5333 is quite large. Much, much larger than > the fractional difference that arises from incrementing the least > signficant decimal digit when there are fifteen. >> Also, at that time different computers used different floating point >> systems with different rounding. > Audio and video codecs use floating-point. You will not hear or see a > difference between different floating-point systems. I suspect that is a mistake, but agree that you probably won't hear or see the difference. If it could change frame boundaries, then some professional editors might notice. > If, say, the type double is used, and gives you about 15 significant > decimal figures, your senses are not going to discern a discrepancy > in the least significant figure. TeX uses 32 bit fixed point, so you are going to twice the bits to 64 bit floating point. > The quantization of the data to the amplitude resolution of the > video or audio DAC destroys more significant figures than any > machine-dependent truncation or rounding. Well, for good results you want to dither before (or during) the ADC. I was once testing the conversion of 24 bit audio to 16 bit for CD writing, and did on with truncation and another with dither. Then wrote successive tracks at lower and lower levels. (Shift one more bit before the conversion.) The quantization noise was definitely lower with dither, though in most cases you wouldn't hear it. -- glen
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
complex number in struct form in C Dexterr <dejangru@gmail.com> - 2014-12-21 07:20 -0800
Re: complex number in struct form in C James Kuyper <jameskuyper@verizon.net> - 2014-12-21 11:30 -0500
Re: complex number in struct form in C Dexterr <dejangru@gmail.com> - 2014-12-21 08:35 -0800
Re: complex number in struct form in C "Osmium" <r124c4u102@comcast.net> - 2014-12-21 10:54 -0600
Re: complex number in struct form in C James Kuyper <jameskuyper@verizon.net> - 2014-12-21 12:00 -0500
Re: complex number in struct form in C "Osmium" <r124c4u102@comcast.net> - 2014-12-21 11:08 -0600
Re: complex number in struct form in C Barry Schwarz <schwarzb@dqel.com> - 2014-12-21 10:12 -0800
Re: complex number in struct form in C "Osmium" <r124c4u102@comcast.net> - 2014-12-21 13:22 -0600
Re: complex number in struct form in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-21 22:21 +0000
Re: complex number in struct form in C asetofsymbols@gmail.com - 2014-12-26 11:34 -0800
Re: complex number in struct form in C "Osmium" <r124c4u102@comcast.net> - 2014-12-26 14:10 -0600
Re: complex number in struct form in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-28 07:04 +0000
Re: complex number in struct form in C BartC <bc@freeuk.com> - 2014-12-28 13:14 +0000
Re: complex number in struct form in C Robert Wessel <robertwessel2@yahoo.com> - 2014-12-28 10:45 -0600
Re: complex number in struct form in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-28 08:56 -0800
Re: complex number in struct form in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-29 10:10 +0000
Re: complex number in struct form in C Kaz Kylheku <kaz@kylheku.com> - 2014-12-29 19:40 +0000
Re: complex number in struct form in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-29 20:54 +0000
Re: complex number in struct form in C BartC <bc@freeuk.com> - 2014-12-29 21:55 +0000
Re: complex number in struct form in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-30 03:07 +0000
Re: complex number in struct form in C BartC <bc@freeuk.com> - 2014-12-30 10:51 +0000
Re: complex number in struct form in C Rosario193 <Rosario@invalid.invalid> - 2014-12-30 12:15 +0100
Re: complex number in struct form in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-30 03:31 -0800
Re: complex number in struct form in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-30 12:17 +0000
Re: complex number in struct form in C BartC <bc@freeuk.com> - 2014-12-30 13:18 +0000
Re: complex number in struct form in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-30 05:28 -0800
Re: complex number in struct form in C BartC <bc@freeuk.com> - 2014-12-30 13:53 +0000
Re: complex number in struct form in C "Osmium" <r124c4u102@comcast.net> - 2014-12-30 08:53 -0600
Re: complex number in struct form in C "Chris M. Thomasson" <no@spam.invalid> - 2014-12-30 20:05 -0800
Re: complex number in struct form in C Jeff Higgins <jeff@invalid.invalid> - 2014-12-30 17:40 -0500
Re: complex number in struct form in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 08:58 -0700
Re: complex number in struct form in C Les Cargill <lcargill99@comcast.com> - 2015-03-24 19:41 -0500
Re: complex number in struct form in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-30 14:59 +0000
Re: complex number in struct form in C David Thompson <dave.thompson2@verizon.net> - 2015-01-12 15:33 -0500
Re: complex number in struct form in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-12 22:51 +0000
Re: complex number in struct form in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-12 23:34 +0000
Re: complex number in struct form in C James Kuyper <jameskuyper@verizon.net> - 2014-12-26 15:25 -0500
Re: complex number in struct form in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-28 07:17 +0000
Re: complex number in struct form in C BartC <bc@freeuk.com> - 2014-12-26 20:49 +0000
Re: complex number in struct form in C asetofsymbols@gmail.com - 2014-12-27 00:22 -0800
Re: complex number in struct form in C "Osmium" <r124c4u102@comcast.net> - 2014-12-27 08:25 -0600
Re: complex number in struct form in C Geoff <geoff@invalid.invalid> - 2014-12-27 10:20 -0800
Re: complex number in struct form in C "Osmium" <r124c4u102@comcast.net> - 2014-12-27 13:21 -0600
Re: complex number in struct form in C Geoff <geoff@invalid.invalid> - 2014-12-27 13:11 -0800
Re: complex number in struct form in C "Osmium" <r124c4u102@comcast.net> - 2014-12-27 15:36 -0600
Re: complex number in struct form in C Geoff <geoff@invalid.invalid> - 2014-12-27 14:54 -0800
Re: complex number in struct form in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-27 15:45 -0800
Re: complex number in struct form in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-27 13:40 -0800
Re: complex number in struct form in C James Kuyper <jameskuyper@verizon.net> - 2014-12-28 06:50 -0500
Re: complex number in struct form in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-28 04:25 -0800
Re: complex number in struct form in C James Kuyper <jameskuyper@verizon.net> - 2014-12-28 06:44 -0500
Re: complex number in struct form in C Richard Damon <Richard@Damon-Family.org> - 2014-12-28 08:33 -0500
Re: complex number in struct form in C James Kuyper <jameskuyper@verizon.net> - 2014-12-27 11:46 -0500
Re: complex number in struct form in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-28 07:28 +0000
Re: complex number in struct form in C Kaz Kylheku <kaz@kylheku.com> - 2014-12-27 17:23 +0000
Re: complex number in struct form in C James Kuyper <jameskuyper@verizon.net> - 2014-12-21 14:37 -0500
Re: complex number in struct form in C Keith Thompson <kst-u@mib.org> - 2014-12-21 12:37 -0800
Re: complex number in struct form in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-22 00:54 +0000
Re: complex number in struct form in C James Kuyper <jameskuyper@verizon.net> - 2014-12-21 11:54 -0500
Re: complex number in struct form in C Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-21 18:07 +0100
Re: complex number in struct form in C Dexterr <dejangru@gmail.com> - 2014-12-21 10:37 -0800
Re: complex number in struct form in C "Chris M. Thomasson" <no@spam.invalid> - 2014-12-21 10:55 -0800
Re: complex number in struct form in C raltbos@xs4all.nl (Richard Bos) - 2014-12-22 12:15 +0000
Re: complex number in struct form in C Dexterr <dejangru@gmail.com> - 2014-12-22 05:51 -0800
Re: complex number in struct form in C BartC <bc@freeuk.com> - 2014-12-22 14:01 +0000
Re: complex number in struct form in C Keith Thompson <kst-u@mib.org> - 2014-12-22 08:02 -0800
Re: complex number in struct form in C Keith Thompson <kst-u@mib.org> - 2014-12-22 08:03 -0800
Re: complex number in struct form in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-21 22:27 +0000
Re: complex number in struct form in C "Chris M. Thomasson" <no@spam.invalid> - 2014-12-21 10:51 -0800
Re: complex number in struct form in C Dexterr <dejangru@gmail.com> - 2014-12-21 11:14 -0800
Re: complex number in struct form in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-21 17:17 -0800
csiph-web