Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #55201 > unrolled thread
| Started by | Dexterr <dejangru@gmail.com> |
|---|---|
| First post | 2014-12-21 07:20 -0800 |
| Last post | 2014-12-21 17:17 -0800 |
| Articles | 20 on this page of 71 — 22 participants |
Back to article view | Back to comp.lang.c
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
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-30 10:51 +0000 |
| Message-ID | <Isvow.940268$u67.647565@fx08.am4> |
| In reply to | #55570 |
On 30/12/2014 03:07, glen herrmannsfeldt wrote: > BartC <bc@freeuk.com> wrote: >> (I'm done some typesetting (of technical manuals with hundreds of pages) >> using a graphical program that exclusively used floating point. The >> output was sent to a Postscript printer for it to do the hard job of >> getting quality output. Postscript seems to use floating point as its >> primary data type (I don't know what it does internally). > > Did you ever try to do a 90 or 180 degree rotation in PostScript? > Systems I used to know wouldn't do it right. (That is, sin(180) > and cos(90) aren't zero. What's so magical about fixed point then in that it manages to get sin(180) and cos(90) exactly right? That is, sin(pi) and cos(pi/2) when using radians, since usually working with degrees involves conversion to radians internally. But if degrees /are/ being used, then it is trivial to first check for these exact quarter angles. Even if they are expressed as 90.0 and 180.0. (In fact, I have an old graphics program where if you rotate bitmap objects, it can only display them when rotated by exactly 0, 90, 180, 270 etc degrees, but not 89.9 degrees. All expressed as floating point numbers.) >> Maybe, on a different system, there might have been the odd paragraph >> where a line break occurs before or after a particular word. But >> repeatability was not an issue. This is just a counter-example to your >> claim that you should never use floating point for typesetting.) > > I was just recalling some of Knuth's examples. You can argue it > out with him if you would like. This is the chap who used a made-up assembly language called MIX in his books (based around 6-bit word lengths or something)? This is instead of using a made-up high-level language (ie. pseudo-code) that people could understand. Enough said... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-12-30 12:15 +0100 |
| Message-ID | <e125aa5oif0saglv5nceb618a60adfckpi@4ax.com> |
| In reply to | #55571 |
On Tue, 30 Dec 2014 10:51:12 +0000, BartC <bc@freeuk.com> wrote: >On 30/12/2014 03:07, glen herrmannsfeldt wrote: >> BartC <bc@freeuk.com> wrote: > >>> (I'm done some typesetting (of technical manuals with hundreds of pages) >>> using a graphical program that exclusively used floating point. The >>> output was sent to a Postscript printer for it to do the hard job of >>> getting quality output. Postscript seems to use floating point as its >>> primary data type (I don't know what it does internally). >> >> Did you ever try to do a 90 or 180 degree rotation in PostScript? >> Systems I used to know wouldn't do it right. (That is, sin(180) >> and cos(90) aren't zero. > >What's so magical about fixed point then in that it manages to get >sin(180) and cos(90) exactly right? That is, sin(pi) and cos(pi/2) when >using radians, since usually working with degrees involves conversion to >radians internally. > in the few seems to me to understand for sin cos etc double they are as fixed .64 bit the problem is exponet in float not fixed... where it is != from 0 i think it is difficult to find one way to estimate the error and if it would be possible would be > of error for fixed point numbers the same bit afther the .
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-30 03:31 -0800 |
| Message-ID | <0f1c580d-f483-42c2-b9cd-240bd5ce0b8a@googlegroups.com> |
| In reply to | #55571 |
On Tuesday, December 30, 2014 10:51:34 AM UTC, Bart wrote: > > What's so magical about fixed point then in that it manages to get > sin(180) and cos(90) exactly right? That is, sin(pi) and cos(pi/2) when > using radians, since usually working with degrees involves conversion to > radians internally. > Because cos(pi/2 +/- epsilon) = a tiny amount in double precision. In fixed, you get either 0 or last bit set, and you need a rather ropey cosine function to get last bit set. However if you clamp to pixel edges rather than pixel centres (thinking of a pixel as a tiny square), then 0 and -epsilon clamp to 0 and -1, so you're a pixel out.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-30 12:17 +0000 |
| Message-ID | <87fvbx5o3g.fsf@bsb.me.uk> |
| In reply to | #55571 |
BartC <bc@freeuk.com> writes: > On 30/12/2014 03:07, glen herrmannsfeldt wrote: <snip> >> I was just recalling some of Knuth's examples. You can argue it >> out with him if you would like. > > This is the chap who used a made-up assembly language called MIX in > his books (based around 6-bit word lengths or something)? This is > instead of using a made-up high-level language (ie. pseudo-code) that > people could understand. > > Enough said... Really? A few ill-informed remarks about a book you don't seem to have read is saying enough? Enough for what? To dismiss everything else the author has written? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-30 13:18 +0000 |
| Message-ID | <yCxow.376840$7A5.156358@fx17.am4> |
| In reply to | #55574 |
On 30/12/2014 12:17, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 30/12/2014 03:07, glen herrmannsfeldt wrote: > <snip> >>> I was just recalling some of Knuth's examples. You can argue it >>> out with him if you would like. >> >> This is the chap who used a made-up assembly language called MIX in >> his books (based around 6-bit word lengths or something)? This is >> instead of using a made-up high-level language (ie. pseudo-code) that >> people could understand. >> >> Enough said... > > Really? A few ill-informed remarks about a book you don't seem to have > read is saying enough? Enough for what? To dismiss everything else the > author has written? It shows he does sometimes make quirky choices that some are not going to agree with. It doesn't mean dismiss everything as nonsense but you might want to make your own mind up about some things which might just be opinions rather than absolute truths. (I course I haven't read the 5-volumes about typesetting as you have. But have managed to produce several presentable manuals with fonts, diagrams and images, without their benefit and without any fixed point that I remember.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-30 05:28 -0800 |
| Message-ID | <25653401-8f8b-4800-85a8-fae25e6d3263@googlegroups.com> |
| In reply to | #55575 |
On Tuesday, December 30, 2014 1:18:32 PM UTC, Bart wrote: > On 30/12/2014 12:17, Ben Bacarisse wrote: > > BartC <bc@freeuk.com> writes: > > > >> On 30/12/2014 03:07, glen herrmannsfeldt wrote: > > <snip> > >>> I was just recalling some of Knuth's examples. You can argue it > >>> out with him if you would like. > >> > >> This is the chap who used a made-up assembly language called MIX in > >> his books (based around 6-bit word lengths or something)? This is > >> instead of using a made-up high-level language (ie. pseudo-code) that > >> people could understand. > >> > >> Enough said... > > > > Really? A few ill-informed remarks about a book you don't seem to have > > read is saying enough? Enough for what? To dismiss everything else the > > author has written? > > It shows he does sometimes make quirky choices that some are not going > to agree with. It doesn't mean dismiss everything as nonsense but you > might want to make your own mind up about some things which might just > be opinions rather than absolute truths. > > (I course I haven't read the 5-volumes about typesetting as you have. > But have managed to produce several presentable manuals with fonts, > diagrams and images, without their benefit and without any fixed point > that I remember.) > Donald Knuth was one of the world's leading experts on computer programming, author of what is accepted as the canonical standard textbook on the subject. With hindsight, he should have gone with C. But he had no way of knowing at the time how stable C would prove.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-30 13:53 +0000 |
| Message-ID | <Z7yow.306258$6H3.258217@fx35.am4> |
| In reply to | #55577 |
On 30/12/2014 13:28, Malcolm McLean wrote: > On Tuesday, December 30, 2014 1:18:32 PM UTC, Bart wrote: >> On 30/12/2014 12:17, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>>> This is the chap who used a made-up assembly language called MIX in >>>> his books (based around 6-bit word lengths or something)? This is >>>> instead of using a made-up high-level language (ie. pseudo-code) that >>>> people could understand. >>> Really? A few ill-informed remarks about a book you don't seem to have >>> read is saying enough? Enough for what? To dismiss everything else the >>> author has written? >> (I course I haven't read the 5-volumes about typesetting as you have. > Donald Knuth was one of the world's leading experts on computer > programming, author of what is accepted as the canonical standard > textbook on the subject. I'm aware of who he is. I may even have read one or two of his books while at college. But I also enjoy doing my own thing and working things out on my own rather than literally following the book. > With hindsight, he should have gone with C. But he had no way of knowing > at the time how stable C would prove. I think he might have been involved in some way with Algol 60, a far better choice and often used at the time to express algorithms in published works. C at the time would have been too crude (it still is rather), and too full of irrelevant details and limitations. Although still a long way ahead of using 'MIXAL', a very ugly language and a distraction from the algorithms presented in the books. (But didn't Knuth adopt C at some later stage? He seemed quite keen on it anyway.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2014-12-30 08:53 -0600 |
| Message-ID | <cgfsj1FtuqkU1@mid.individual.net> |
| In reply to | #55577 |
"Malcolm McLean" wrote: > Donald Knuth was one of the world's leading experts on computer > programming, author of what is accepted as the canonical standard > textbook on the subject. Donald Knuth is still alive.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <no@spam.invalid> |
|---|---|
| Date | 2014-12-30 20:05 -0800 |
| Message-ID | <m7vson$q42$1@speranza.aioe.org> |
| In reply to | #55582 |
> "Osmium" wrote in message news:cgfsj1FtuqkU1@mid.individual.net... > "Malcolm McLean" wrote: > > Donald Knuth was one of the world's leading experts on computer > > programming, author of what is accepted as the canonical standard > > textbook on the subject. > Donald Knuth is still alive. Damn right: http://www-cs-faculty.stanford.edu/~uno :^D FWIW, I personally wish I could probe his excellent mind from time, to time... What a wealth of sheer information! :^)
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2014-12-30 17:40 -0500 |
| Message-ID | <m7v9ot$mrs$1@dont-email.me> |
| In reply to | #55577 |
On 12/30/2014 08:28 AM, Malcolm McLean wrote: > With hindsight, he should have gone with C. But he had no way of knowing > at the time how stable C would prove. > MMIX 2009 a RISC computer for the third millennium <http://www-cs-faculty.stanford.edu/~uno/mmix.html> "If you're interested in joining this happy group of programmers, take a peek at ..."
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-24 08:58 -0700 |
| Message-ID | <kfnmw32idzg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #55577 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Tuesday, December 30, 2014 1:18:32 PM UTC, Bart wrote: >> On 30/12/2014 12:17, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>> >>>> On 30/12/2014 03:07, glen herrmannsfeldt wrote: >>> >>> <snip> >>> >>>>> I was just recalling some of Knuth's examples. You can argue it >>>>> out with him if you would like. >>>> >>>> This is the chap who used a made-up assembly language called MIX in >>>> his books (based around 6-bit word lengths or something)? This is >>>> instead of using a made-up high-level language (ie. pseudo-code) that >>>> people could understand. >>>> >>>> Enough said... >>> >>> Really? A few ill-informed remarks about a book you don't seem to have >>> read is saying enough? Enough for what? To dismiss everything else the >>> author has written? >> >> It shows he does sometimes make quirky choices that some are not going >> to agree with. It doesn't mean dismiss everything as nonsense but you >> might want to make your own mind up about some things which might just >> be opinions rather than absolute truths. >> >> (I course I haven't read the 5-volumes about typesetting as you have. >> But have managed to produce several presentable manuals with fonts, >> diagrams and images, without their benefit and without any fixed point >> that I remember.) > > Donald Knuth was one of the world's leading experts on computer > programming, author of what is accepted as the canonical standard > textbook on the subject. > > With hindsight, he should have gone with C. But he had no way of > knowing at the time how stable C would prove. Quite an understatement, since at the time the material on MIX was written C did not yet exist.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-24 19:41 -0500 |
| Message-ID | <mesvtn$i0g$2@dont-email.me> |
| In reply to | #55577 |
Malcolm McLean wrote: > On Tuesday, December 30, 2014 1:18:32 PM UTC, Bart wrote: >> On 30/12/2014 12:17, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>> >>>> On 30/12/2014 03:07, glen herrmannsfeldt wrote: >>> <snip> >>>>> I was just recalling some of Knuth's examples. You can argue it >>>>> out with him if you would like. >>>> >>>> This is the chap who used a made-up assembly language called MIX in >>>> his books (based around 6-bit word lengths or something)? This is >>>> instead of using a made-up high-level language (ie. pseudo-code) that >>>> people could understand. >>>> >>>> Enough said... >>> >>> Really? A few ill-informed remarks about a book you don't seem to have >>> read is saying enough? Enough for what? To dismiss everything else the >>> author has written? >> >> It shows he does sometimes make quirky choices that some are not going >> to agree with. It doesn't mean dismiss everything as nonsense but you >> might want to make your own mind up about some things which might just >> be opinions rather than absolute truths. >> >> (I course I haven't read the 5-volumes about typesetting as you have. >> But have managed to produce several presentable manuals with fonts, >> diagrams and images, without their benefit and without any fixed point >> that I remember.) >> > Donald Knuth was one of the world's leading experts on computer > programming, author of what is accepted as the canonical standard > textbook on the subject. > > With hindsight, he should have gone with C. But he had no way of knowing > at the time how stable C would prove. > Knuth did what he did for very good pedagogical, technical and no doubt personal reasons. Oberon or Modula probably should have taken over for 'C'. But it's easy to forget what the world looked like then: https://archive.org/stream/byte-magazine-1983-08/1983_08_BYTE_08-08_The_C_Language#page/n47/mode/2up -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-30 14:59 +0000 |
| Message-ID | <87wq59420c.fsf@bsb.me.uk> |
| In reply to | #55575 |
BartC <bc@freeuk.com> writes: > On 30/12/2014 12:17, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 30/12/2014 03:07, glen herrmannsfeldt wrote: >> <snip> >>>> I was just recalling some of Knuth's examples. You can argue it >>>> out with him if you would like. >>> >>> This is the chap who used a made-up assembly language called MIX in >>> his books (based around 6-bit word lengths or something)? This is >>> instead of using a made-up high-level language (ie. pseudo-code) that >>> people could understand. >>> >>> Enough said... >> >> Really? A few ill-informed remarks about a book you don't seem to have >> read is saying enough? Enough for what? To dismiss everything else the >> author has written? > > It shows he does sometimes make quirky choices that some are not going > to agree with. It doesn't mean dismiss everything as nonsense but you > might want to make your own mind up about some things which might just > be opinions rather than absolute truths. But you are just repeating myths. Most of the algorithms in TAOCP are presented abstractly, and sound reasons are given for using an invented machine code for some kinds of analysis. I am not saying there is no room for disagreement, but you just threw out an oft-quoted myth and "enough said". > (I course I haven't read the 5-volumes about typesetting as you > have. What do these have to do with it? I've only read two on typesetting and neither uses MIX. I am pretty sure that other three volumes (the annotated source code) don't either. In fact, The METAFONT Book uses a very neat application-specific language with I am sure you'd like very much. I think you are just recycling an old trope. > But have managed to produce several presentable manuals with > fonts, diagrams and images, without their benefit and without any > fixed point that I remember.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-01-12 15:33 -0500 |
| Message-ID | <gsb8badn9gs1s1nk3sbek6kic5e4i3i1ht@4ax.com> |
| In reply to | #55536 |
On Sun, 28 Dec 2014 07:04:57 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: <snip: floating point for large range but relative error> > Now, consider the computation of large prime numbers for encryption. > If you want a 1024 bit prime number, though the magnitude is large, > you probably don't want to compute it in floating point. You want to > know exactly, not just approximately, that a number is prime. > Not quite. *Computations* for (most) public-key cryptography (more than just encryption) must be exact. Today for RSA two 1024-bit primes are sufficient; for DSA and DH you need one 2048-bit. However we don't need to and usually don't know "exactly" -- to a mathematical standard -- that the claimed primes are truly prime. Specifically we generally use a process which randomly chooses an integer in the correct range and then applies "probable prime" tests that wrongly accept a composite with nonzero but extremely small probability like maybe 1e-50 -- something like the probability of being hit by an asteroid while you are doing the computation. There is actually a "provable prime" test (AKS) test that is never wrong, but it is too costly for practical use. There are algorithms that *construct* rather than randomly guess a provable prime, which are moderately more costly and sometimes used.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-01-12 22:51 +0000 |
| Message-ID | <m91j4t$6vr$1@speranza.aioe.org> |
| In reply to | #56177 |
David Thompson <dave.thompson2@verizon.net> wrote: > <snip: floating point for large range but relative error> (snip, I wrote) >> Now, consider the computation of large prime numbers for encryption. >> If you want a 1024 bit prime number, though the magnitude is large, >> you probably don't want to compute it in floating point. You want to >> know exactly, not just approximately, that a number is prime. > Not quite. *Computations* for (most) public-key cryptography (more > than just encryption) must be exact. Today for RSA two 1024-bit primes > are sufficient; for DSA and DH you need one 2048-bit. > However we don't need to and usually don't know "exactly" -- to a > mathematical standard -- that the claimed primes are truly prime. Yes. But the claim had to do with range, and I was indicating that relative error was more important. In the case of primes, knowing that you are within 10 or 1000 or 1e100 of a prime number doesn't help much at all. > Specifically we generally use a process which randomly chooses an > integer in the correct range and then applies "probable prime" tests > that wrongly accept a composite with nonzero but extremely small > probability like maybe 1e-50 -- something like the probability of > being hit by an asteroid while you are doing the computation. > There is actually a "provable prime" test (AKS) test that is never > wrong, but it is too costly for practical use. There are algorithms > that *construct* rather than randomly guess a provable prime, which > are moderately more costly and sometimes used. You want floating point when the range of numbers is large AND they need a specific relative error. Most physical measurements work that way. Measure the distance to the sun, or the atomic lattice spacing in a crystal, in both cases you might want a 1e-6 or so relative error. In the case of primes, you want an absolute error of less than 1, independent of the size of the potential prime, and so fixed point. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-01-12 23:34 +0000 |
| Message-ID | <87a91ntvxh.fsf@bsb.me.uk> |
| In reply to | #56177 |
David Thompson <dave.thompson2@verizon.net> writes: <snip> > There is actually a "provable prime" test (AKS) test that is never > wrong, but it is too costly for practical use. There are algorithms > that *construct* rather than randomly guess a provable prime, which > are moderately more costly and sometimes used. I hope it is not news to anyone here that there is a provable prime test! The AKS test make headlines (literally!) because it proves that checking a prime is "efficient" in a formal, theoretical sense. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-12-26 15:25 -0500 |
| Message-ID | <549DC451.1070801@verizon.net> |
| In reply to | #55460 |
On 12/26/2014 02:34 PM, asetofsymbols@gmail.com wrote: > Why use float, double, long double? For me it is better fixed point float... I not understand how people use float not fixed point could be sure all ok in financials calculus I work primarily in scientific data processing. For most intermediate calculations, we use double, but when writing to a file, we'll often use float, if it has sufficient precision, which is often the case. The images we're working on have as resolution of 250 meters, a float has sufficient precision to store the latitude, longitude, solar zenith and azimuth angles, and unit vectors pointing at the moon and the sun. However, a large fraction of the data produced by the programs I'm responsible for is stored as scaled integers, usually 16 bits. The value represented is scale_factor*scaled_integer+offset, where scale factor and offset are chosen at run time to spread out the valid range of represented values as evenly as possible from the range scaled integer values from 0 to 65535 (or, for image data, 0 to 32767 - values over 32768 are reserved for special uses). Conceptually, this isn't horribly different from fixed point floats, which are conceptually equivalent to choosing an offset of 0 and a scale factor which is a power of 10 (or 2). However, the scale and offset approach allows more precise matching of the range of the data to the range of representable integers.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-12-28 07:17 +0000 |
| Message-ID | <m7oar1$no0$1@speranza.aioe.org> |
| In reply to | #55463 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 12/26/2014 02:34 PM, asetofsymbols@gmail.com wrote: >> Why use float, double, long double? For me it is better fixed >> point float... I not understand how people use float not fixed >> point could be sure all ok in financials calculus > I work primarily in scientific data processing. For most intermediate > calculations, we use double, but when writing to a file, we'll often use > float, if it has sufficient precision, which is often the case. The > images we're working on have as resolution of 250 meters, a float has > sufficient precision to store the latitude, longitude, solar zenith and > azimuth angles, and unit vectors pointing at the moon and the sun. For a large variety of scientific data processing, double precision should be used for intermediate calculation when single precision results are needed. It is very easy for precision to be lost when subtracting two values of similar magnitude in an intermediate value. For example, matrix multiplication involves a sum over products of matrix elements for each term in the product matrix. It isn't hard to find cases where most of the bits are lost in that calculation. One of the worst problems, though one that often enough comes up in high school math class, is matrix inversion. Only for very small matrices is double precision likely to generate even single precision results. > However, a large fraction of the data produced by the programs I'm > responsible for is stored as scaled integers, usually 16 bits. The value > represented is scale_factor*scaled_integer+offset, where scale factor > and offset are chosen at run time to spread out the valid range of > represented values as evenly as possible from the range scaled integer > values from 0 to 65535 (or, for image data, 0 to 32767 - values over > 32768 are reserved for special uses). Conceptually, this isn't horribly > different from fixed point floats, which are conceptually equivalent to > choosing an offset of 0 and a scale factor which is a power of 10 (or > 2). However, the scale and offset approach allows more precise matching > of the range of the data to the range of representable integers. Much of numerical analysis is knowing where algorithm can go wrong, and adjusting as appropriate. For example, LU decomposition can be used in many cases that would be more obvious done with matrix inversion. -- glen
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-26 20:49 +0000 |
| Message-ID | <YRjnw.322428$607.90723@fx21.am4> |
| In reply to | #55460 |
On 26/12/2014 19:34, asetofsymbols@gmail.com wrote: > Why use float, double, long double? For me it is better fixed point float... I not understand how people use float not fixed point could be sure all ok in financials calculus Because floating point numbers have a far bigger range, are supported by the language, are usually implemented in hardware, and have libraries of maths functions already available. You'd need about 2000 bits to have a similar range to double, when using fixed point. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2014-12-27 00:22 -0800 |
| Message-ID | <e7414fe4-cc6d-42f6-968d-76170f8d3172@googlegroups.com> |
| In reply to | #55464 |
If one has a fixed point number, if I understand right, one has too a way for check if result is correct... For float not fixed point one can not be sure... Than one can make errors with fixed point too...
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web