Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #55201 > unrolled thread

complex number in struct form in C

Back to article view | Back to comp.lang.c

Contents

  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 1 of 4  [1] 2 3 4  Next page →

#55201 — complex number in struct form in C

Hi there, I am thinking how to make one structure with complex number. Complex number has a form (a+b*i) and i is an imaginary number i = sqrt(-1).

struct ComplexNumber {
 
   int a;
   int b;

} CNumber;

Do you have an idea how to do it properly ?

[toc] | [next] | [standalone]

#55204

On 12/21/2014 10:20 AM, Dexterr wrote:
> Hi there, I am thinking how to make one structure with complex number. Complex number has a form (a+b*i) and i is an imaginary number i = sqrt(-1).
> 
> struct ComplexNumber {
>  
>    int a;
>    int b;
> 
> } CNumber;
> 
> Do you have an idea how to do it properly ?

If you need to have ints, you could do something like that, but
situations where using integers for that purpose would be useful are
extremely rare. If you think it's a good idea, you're probably (but not
necessarily) badly mistaken.

It you take that route, you'll have to write routines to perform all of
the normal complex math operations on ComplexNumber objects. Complex
division is going to be especially difficult if you insist on using
integers.

It's far more conventional to represent the components of a complex
number using floating point, which is why support for complex numbers
with floating point components was add in C99. Therefore, if you're
willing to adopt the more convenient, it's much simpler to use:

	_Complex double CNumber;

and let the compiler worry about such things for me. Also, <cmath.h>
contains complexified versions of the routines in <math.h>.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#55205

On Sunday, December 21, 2014 5:30:32 PM UTC+1, James Kuyper wrote:
> On 12/21/2014 10:20 AM, Dexterr wrote:
> > Hi there, I am thinking how to make one structure with complex number. Complex number has a form (a+b*i) and i is an imaginary number i = sqrt(-1).
> > 
> > struct ComplexNumber {
> >  
> >    int a;
> >    int b;
> > 
> > } CNumber;
> > 
> > Do you have an idea how to do it properly ?
> 
> If you need to have ints, you could do something like that, but
> situations where using integers for that purpose would be useful are
> extremely rare. If you think it's a good idea, you're probably (but not
> necessarily) badly mistaken.
> 
> It you take that route, you'll have to write routines to perform all of
> the normal complex math operations on ComplexNumber objects. Complex
> division is going to be especially difficult if you insist on using
> integers.
> 
> It's far more conventional to represent the components of a complex
> number using floating point, which is why support for complex numbers
> with floating point components was add in C99. Therefore, if you're
> willing to adopt the more convenient, it's much simpler to use:
> 
> 	_Complex double CNumber;
> 
> and let the compiler worry about such things for me. Also, <cmath.h>
> contains complexified versions of the routines in <math.h>.
> -- 
> James Kuyper

Thx James, 

it should be something like this

typedef struct _ComplexNumber_ {
  float real_part;
  float imaginary_part;
} CNumber;

CNumber complex;

[toc] | [prev] | [next] | [standalone]

#55206

"Dexterr" wrote:

> On Sunday, December 21, 2014 5:30:32 PM UTC+1, James Kuyper wrote:
>> On 12/21/2014 10:20 AM, Dexterr wrote:
>> > Hi there, I am thinking how to make one structure with complex number. 
>> > Complex number has a form (a+b*i) and i is an imaginary number i = 
>> > sqrt(-1).
>> >
>> > struct ComplexNumber {
>> >
>> >    int a;
>> >    int b;
>> >
>> > } CNumber;
>> >
>> > Do you have an idea how to do it properly ?
>>
>> If you need to have ints, you could do something like that, but
>> situations where using integers for that purpose would be useful are
>> extremely rare. If you think it's a good idea, you're probably (but not
>> necessarily) badly mistaken.
>>
>> It you take that route, you'll have to write routines to perform all of
>> the normal complex math operations on ComplexNumber objects. Complex
>> division is going to be especially difficult if you insist on using
>> integers.
>>
>> It's far more conventional to represent the components of a complex
>> number using floating point, which is why support for complex numbers
>> with floating point components was add in C99. Therefore, if you're
>> willing to adopt the more convenient, it's much simpler to use:
>>
>> _Complex double CNumber;
>>
>> and let the compiler worry about such things for me. Also, <cmath.h>
>> contains complexified versions of the routines in <math.h>.
>> -- 
>> James Kuyper
>
> Thx James,
>
> it should be something like this
>
> typedef struct _ComplexNumber_ {
>  float real_part;
>  float imaginary_part;
> } CNumber;
>
> CNumber complex;

The convention in C, is for real numbers to be represented by double, not 
float.  Look at the types of parameters and such in <math.h>

If "real number" is new to you, look it up, Wikipedia is good. 

[toc] | [prev] | [next] | [standalone]

#55210

On 12/21/2014 11:54 AM, Osmium wrote:
...
> The convention in C, is for real numbers to be represented by double, not 
> float.  Look at the types of parameters and such in <math.h>

Just about every function in <math.h> or <cmath.h> that has a 'double'
argument or a 'double' return value has a corresponding function with
'f' at the end of the name that takes float arguments or returns float
values, and another corresponding function with 'l' at the end that
takes 'long double' arguments or returns a 'long double' value. I don't
think you can justify the conclusion you're reaching from that evidence.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#55213

"James Kuyper" wrote:

> On 12/21/2014 11:54 AM, Osmium wrote:
> ...
>> The convention in C, is for real numbers to be represented by double, not
>> float.  Look at the types of parameters and such in <math.h>
>
> Just about every function in <math.h> or <cmath.h> that has a 'double'
> argument or a 'double' return value has a corresponding function with
> 'f' at the end of the name that takes float arguments or returns float
> values, and another corresponding function with 'l' at the end that
> takes 'long double' arguments or returns a 'long double' value. I don't
> think you can justify the conclusion you're reaching from that evidence.

If you want to say my conclusion is wrong, why don't you just say so? You do 
realize that this newsgroup is not for discussing the subtleties of the 
English language or rhetoric don't you?

AFAIK an example never proves anything. 

[toc] | [prev] | [next] | [standalone]

#55221

On Sun, 21 Dec 2014 11:08:16 -0600, "Osmium" <r124c4u102@comcast.net>
wrote:

>"James Kuyper" wrote:
>
>> On 12/21/2014 11:54 AM, Osmium wrote:
>> ...
>>> The convention in C, is for real numbers to be represented by double, not
>>> float.  Look at the types of parameters and such in <math.h>
>>
>> Just about every function in <math.h> or <cmath.h> that has a 'double'
>> argument or a 'double' return value has a corresponding function with
>> 'f' at the end of the name that takes float arguments or returns float
>> values, and another corresponding function with 'l' at the end that
>> takes 'long double' arguments or returns a 'long double' value. I don't
>> think you can justify the conclusion you're reaching from that evidence.
>
>If you want to say my conclusion is wrong, why don't you just say so? 

OK.  How did you reach the conclusion that the convention in C is to
use double when the language and standard library provides comparable
facilities to use float, double, and long double?  What parameter
types in math.h support this?

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#55226

"Barry Schwarz" wrote:

> On Sun, 21 Dec 2014 11:08:16 -0600, "Osmium" <r124c4u102@comcast.net>
> wrote:
>
>>"James Kuyper" wrote:
>>
>>> On 12/21/2014 11:54 AM, Osmium wrote:
>>> ...
>>>> The convention in C, is for real numbers to be represented by double, 
>>>> not
>>>> float.  Look at the types of parameters and such in <math.h>
>>>
>>> Just about every function in <math.h> or <cmath.h> that has a 'double'
>>> argument or a 'double' return value has a corresponding function with
>>> 'f' at the end of the name that takes float arguments or returns float
>>> values, and another corresponding function with 'l' at the end that
>>> takes 'long double' arguments or returns a 'long double' value. I don't
>>> think you can justify the conclusion you're reaching from that evidence.
>>
>>If you want to say my conclusion is wrong, why don't you just say so?
>
> OK.  How did you reach the conclusion that the convention in C is to
> use double when the language and standard library provides comparable
> facilities to use float, double, and long double?  What parameter
> types in math.h support this?

The most respected text for C is Ansi C, by K&R.  The following is from the 
section on <math.h>

                "In the following table, x and y are of type double, n is an 
int and
                 all functions return double"

*That* version of C has been around far longer than the current flavors.  So 
a 50 year old programmer naturally has written more programs than a 30 year 
old programmer, same deal for a programming language.

The almost obsessive interest in "improving" C and studying the arcane 
details of the standards expressed here by a few tens of people is not 
representative of the thousands of C programmers in the world.  They just 
crank out real programs for real people. 

[toc] | [prev] | [next] | [standalone]

#55261

"Osmium" <r124c4u102@comcast.net> writes:

> "Barry Schwarz" wrote:
>
>> On Sun, 21 Dec 2014 11:08:16 -0600, "Osmium" <r124c4u102@comcast.net>
>> wrote:
>>
>>>"James Kuyper" wrote:
>>>
>>>> On 12/21/2014 11:54 AM, Osmium wrote:
>>>> ...
>>>>> The convention in C, is for real numbers to be represented by double, 
>>>>> not
>>>>> float.  Look at the types of parameters and such in <math.h>
>>>>
>>>> Just about every function in <math.h> or <cmath.h> that has a 'double'
>>>> argument or a 'double' return value has a corresponding function with
>>>> 'f' at the end of the name that takes float arguments or returns float
>>>> values, and another corresponding function with 'l' at the end that
>>>> takes 'long double' arguments or returns a 'long double' value. I don't
>>>> think you can justify the conclusion you're reaching from that evidence.
>>>
>>>If you want to say my conclusion is wrong, why don't you just say so?
>>
>> OK.  How did you reach the conclusion that the convention in C is to
>> use double when the language and standard library provides comparable
>> facilities to use float, double, and long double?  What parameter
>> types in math.h support this?
>
> The most respected text for C is Ansi C, by K&R.  The following is from the 
> section on <math.h>
>
>                 "In the following table, x and y are of type double, n is an 
> int and
>                  all functions return double"
>
> *That* version of C has been around far longer than the current flavors.  So 
> a 50 year old programmer naturally has written more programs than a 30 year 
> old programmer, same deal for a programming language.

This might be an age/experience disagreement.  If you ever used K&R C
you will have to work hard to forget that float was very much a
second-class type.  In K&R C you can't write a float -- all floating
point constants are of type double, and floats promote to double in
expressions, so you can't, for example, add two floats.  Neither can you
pass a float to a function (in the usual sense of the term) so you can't
print one either.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#55460

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 

[toc] | [prev] | [next] | [standalone]

#55462

<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

The floating point types,as a group, are usually used because of their much
larger range. For example, the distance to the sun is a big integer, even
expressed in feet. There was a rough consensus, many years ago, that 36-bit
floating point numbers contain enough bits to be useful  for many so-called
"scientific" problems.  This produced many "36-bit computers".

In theory at least, the floating point types are rarely used in financial
work because of the cconcern you expressed

[toc] | [prev] | [next] | [standalone]

#55536

Osmium <r124c4u102@comcast.net> wrote:
> <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
 
> The floating point types,as a group, are usually used because of their much
> larger range. For example, the distance to the sun is a big integer, even
> expressed in feet. There was a rough consensus, many years ago, that 36-bit
> floating point numbers contain enough bits to be useful  for many so-called
> "scientific" problems.  This produced many "36-bit computers".

Well yes, but it is more important that the quantity under consideration
have a relative error (that scales with the size of the value) than
an absolute error. 

The distance from the earth to the sun, for most uses, has a fairly
large uncertainty. 

For example, people have been measuring Newton's gravitational 
constant for over 200 years, and now have it to about four decimal
places. 

http://en.wikipedia.org/wiki/Gravitational_constant

but also see:

http://www.livescience.com/46385-new-gravitational-constant-measurement.html

So, if you are trying to use the distance to the sun to consider the
gravitational effect, then floating point is probably fine.
(And single precision might do.)

One method for finding exoplanets (ones around stars other than our sun)
is to look for the doppler shift in light from the star. To measure
that, one has to consider that we are on a moving earth, and need to 
carefully consider the speed of our orbit around the sun, specifically
the component in the direction of the star of interest. That might need
more precision, but might still be fine in floating point.

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. 

Two things that it is generally believed should not be done in
floating point (besides cryptography) are finance and typesetting.
 
> In theory at least, the floating point types are rarely used in financial
> work because of the cconcern you expressed.

Yes.

-- glen

[toc] | [prev] | [next] | [standalone]

#55547

On 28/12/2014 07:04, glen herrmannsfeldt 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?

With visual displays, you can use grey levels to indicate edges that are 
'in-between' two pixels (and such problems are no different to 
displaying any other transformed geometry). While photo-typesetters work 
to very high resolutions.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#55550

On Sun, 28 Dec 2014 13:14:54 +0000, BartC <bc@freeuk.com> wrote:

>On 28/12/2014 07:04, glen herrmannsfeldt 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?
>
>With visual displays, you can use grey levels to indicate edges that are 
>'in-between' two pixels (and such problems are no different to 
>displaying any other transformed geometry). While photo-typesetters work 
>to very high resolutions.


I'm far from an expert on the subject, but I understand Knuth's
position to be that using FP leads to difficult rounding issues,
leading to visible artifacts in documents.  Presumably more serious
for small fonts and lower resolutions, where we know the misplacement
of a single pixel can lead to visible glitches.

So basically the same problem as with currency.

[toc] | [prev] | [next] | [standalone]

#55551

On Sunday, December 28, 2014 4:45:46 PM UTC, robert...@yahoo.com wrote:
> On Sun, 28 Dec 2014 13:14:54 +0000, BartC <bc@freeuk.com> wrote:
> 
> >What problems are you going to get in typesetting?
> >
> >With visual displays, you can use grey levels to indicate edges that are 
> >'in-between' two pixels (and such problems are no different to 
> >displaying any other transformed geometry). While photo-typesetters work 
> >to very high resolutions.
> 
> I'm far from an expert on the subject, but I understand Knuth's
> position to be that using FP leads to difficult rounding issues,
> leading to visible artifacts in documents.  Presumably more serious
> for small fonts and lower resolutions, where we know the misplacement
> of a single pixel can lead to visible glitches.
> 
> So basically the same problem as with currency.
>
Fixed point won't eliminate rounding errors, it just gives you a new
set. Which might be easier to deal with.
Modern fonts are described by Bezier curves. If you keep a curve
in double precision and anti-alias, you're going to be safe. However
if you can't anti-alias and you place glyphs with sub-pixel precision,
it's extremely difficult to avoid some visible artifacts.

[toc] | [prev] | [next] | [standalone]

#55563

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?

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.)  

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.

Also, at that time different computers used different floating point
systems with different rounding. 
 
> With visual displays, you can use grey levels to indicate edges that are 
> 'in-between' two pixels (and such problems are no different to 
> displaying any other transformed geometry). 

Anti-aliasing. 

> While photo-typesetters work to very high resolutions.

Yes, but as noted above, high resolution in itself isn't enough.
You have to digitize and round appropriately.

-- glen

[toc] | [prev] | [next] | [standalone]

#55567

On 2014-12-29, glen herrmannsfeldt <gah@ugcs.caltech.edu> 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?
>
> 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.

This means it will be more difficult to develop a regression test suite which
works on every supported target machine.

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.

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.)

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.

> 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.

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.

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.

[toc] | [prev] | [next] | [standalone]

#55568

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

[toc] | [prev] | [next] | [standalone]

#55569

On 29/12/2014 20:54, glen herrmannsfeldt wrote:


> TeX uses 32 bit fixed point, so you are going to twice the bits
> to 64 bit floating point.

(Twice?)

Can 64-bit floating point with its 52 precision bits emulate anything 
you might do with 32-bit fixed point? If so then I can't see the problem 
that floating point introduces.

(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).

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.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#55570

BartC <bc@freeuk.com> wrote:
> On 29/12/2014 20:54, glen herrmannsfeldt wrote:
 
>> TeX uses 32 bit fixed point, so you are going to twice the bits
>> to 64 bit floating point.
 
> (Twice?)
 
> Can 64-bit floating point with its 52 precision bits emulate anything 
> you might do with 32-bit fixed point? If so then I can't see the problem 
> that floating point introduces.

If you know the rounding mode, you can get close.  Add and subtract
should be pretty easy. 

There is a TeX routine to multiply a value by a 32 bit integer, 
generating a 64 bit product, then divide by another 32 bit integer.
Easy to do in hardware on many systems, not so easy in Pascal. 
Knuth recommends that one rewrite that one in assembler for faster
run time.

If your floating point hardware rounds, it is somewhat more difficult
to generate the appropriate truncated (fixed point divide) values.

> (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.
 
> 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.

-- glen

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web