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

#55486

<asetofsymbols@gmail.com> wrote:

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

I assume, by not-correct, you are thinking of numbers out of range.  Yes, 
there are methods to detect out of range integers.It is not clear to me the 
situation with regard to small floating point numbers.  By the nature of the 
beast, zero does not exist.  So the people in charge *define* zero.  You 
might dig around in the standard, IEEE 754, to see what you can find.  You 
want to focus on NaN, not a number.

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

But this still leaves you with the question: Is IEEE 754 actually in use in 
*your* environment. Numbers too small are called "underflow".  I would guess 
that the number of floating point schemes in use (hardware *and* software) 
is around 100. 

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

#55500

On Sat, 27 Dec 2014 08:25:51 -0600, "Osmium" <r124c4u102@comcast.net>
wrote:

>It is not clear to me the 
>situation with regard to small floating point numbers.  By the nature of the 
>beast, zero does not exist.  So the people in charge *define* zero.

Eh? Zero does exist. In IEEE754 it's all bits zero. But there is also
the possibility of -0.0 which is all bits zero except the sign bit and
I believe comparing 0.0 to -0.0 will result in them being equal.

I think you might be referring to the problem of comparing a very
small difference between two small doubles or floats to zero. This can
be problematic and the solution is to incorporate DBL_EPSILON or
FLT_EPSILON in the calculation to get "close enough" to zero as the
application requires.

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

#55503

"Geoff" wrote:

> On Sat, 27 Dec 2014 08:25:51 -0600, "Osmium" <r124c4u102@comcast.net>
> wrote:
>
>>It is not clear to me the
>>situation with regard to small floating point numbers.  By the nature of 
>>the
>>beast, zero does not exist.  So the people in charge *define* zero.
>
> Eh? Zero does exist. In IEEE754 it's all bits zero.

The following is from an IEE 754 reference.

<quote>

The number zero is represented specially:

  sign = 0 for positive zero, 1 for negative zero.
  biased exponent = 0.
  fraction = 0.
<endquote>

They are DEFINING it, as I said, with that wording.  The number can not be 
represented in the normal course of events.

But there is also
> the possibility of -0.0 which is all bits zero except the sign bit and
> I believe comparing 0.0 to -0.0 will result in them being equal.
>
> I think you might be referring to the problem of comparing a very
> small difference between two small doubles or floats to zero. This can
> be problematic and the solution is to incorporate DBL_EPSILON or
> FLT_EPSILON in the calculation to get "close enough" to zero as the
> application requires.

There are an infinitude of numbers between 0.0 and 1e-308.. If that doesn't 
bother you, so be it. 

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

#55511

On Sat, 27 Dec 2014 13:21:45 -0600, "Osmium" <r124c4u102@comcast.net>
wrote:

>"Geoff" wrote:
>
>> On Sat, 27 Dec 2014 08:25:51 -0600, "Osmium" <r124c4u102@comcast.net>
>> wrote:
>>
>>>It is not clear to me the
>>>situation with regard to small floating point numbers.  By the nature of 
>>>the
>>>beast, zero does not exist.  So the people in charge *define* zero.
>>
>> Eh? Zero does exist. In IEEE754 it's all bits zero.
>
>The following is from an IEE 754 reference.
>
><quote>
>
>The number zero is represented specially:
>
>  sign = 0 for positive zero, 1 for negative zero.
>  biased exponent = 0.
>  fraction = 0.
><endquote>
>
>They are DEFINING it, as I said, with that wording.  The number can not be 
>represented in the normal course of events.
>

They are not defining zero specially. They are defining two zeros and
the fact they must compare equal, which rules out a bit-wise compare.

>But there is also
>> the possibility of -0.0 which is all bits zero except the sign bit and
>> I believe comparing 0.0 to -0.0 will result in them being equal.
>>
>> I think you might be referring to the problem of comparing a very
>> small difference between two small doubles or floats to zero. This can
>> be problematic and the solution is to incorporate DBL_EPSILON or
>> FLT_EPSILON in the calculation to get "close enough" to zero as the
>> application requires.
>
>There are an infinitude of numbers between 0.0 and 1e-308.. If that doesn't 
>bother you, so be it. 
>

Considering the smallest unit of measure in the universe is the Planck
length, and that number is about 1.6e-35 meters, I'd say that a number
273 orders of magnitude smaller is doing pretty well for "as close to
zero as the application requires". 

If I'm writing a program to measure particle tracks for Large Hadron
Collider experiments I can't go too far astray using doubles and for
accepting a difference of 2*DBL_EPSILON as "near zero". I dare say for
a physically realizable system, it's many times more precise than is
needed.

I deal with CNC machines and I'm often called upon to explain to the
uninitiated the difference between a specified accuracy and a
specified precision and repeatability in the domain of numbers out to
0.001 micrometers (1e-9 meters). Thermal, gravitational and mechanical
effects far outweigh our ability to maintain a tolerance that small
over more than a few centimeters. In the domain of the small, metals
behave more like Jello than the rigid objects we perceive them to be.
Feedback systems are integer based anyway, being counts on an encoder
mechanically coupled to the platform and internally carried in integer
registers and translated to either fix-point for display purposes or
to "real" for computational purposes. Even then, only out to 8 or 9
decimal places are "significant".

When the size of the observable universe (13.8e9 light years or 5.4e61
Planck lengths) can be measured in terms of less than 70 orders of
magnitude of the Planck length, I'd say 616 orders of magnitude was
plenty for "real numbers". 

If the ability to compute quantities to 2e-308 with an uncertainty of
2e-16 bothers you, so be it.

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

#55513

"Geoff" wrote:

<heavily edited>

> If the ability to compute quantities to 2e-308 with an uncertainty of
> 2e-16 bothers you, so be it.

You are getting all bent out of shape for no reason.  We simply don't agree 
on what the word "zero" means.To me, the word means nothing, nada, zilch, 
You just don't happen to agree with that.  That's fine, that's what "so be 
it" means. The representation is perfectly usable. 

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

#55521

On Sat, 27 Dec 2014 15:36:59 -0600, "Osmium" <r124c4u102@comcast.net>
wrote:

>"Geoff" wrote:
>
><heavily edited>
>
>> If the ability to compute quantities to 2e-308 with an uncertainty of
>> 2e-16 bothers you, so be it.
>
>You are getting all bent out of shape for no reason.  We simply don't agree 
>on what the word "zero" means.To me, the word means nothing, nada, zilch, 
>You just don't happen to agree with that.  That's fine, that's what "so be 
>it" means. The representation is perfectly usable. 
>

I'm not getting bent out of shape at all. You're the one who thinks
the infinity of reals between 1e-308 and zero is important to a
computation of anything that can be measured or quantified as part of
a real process. My point was that zero, zilch, nada _is_ in fact
represented in IEEE754 since "all bits zero" is defined as zero in
that representation. Now, the "special" part of IEEE754 zero is that
there are two of them and they compare equal.

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

#55525

On Saturday, December 27, 2014 10:54:26 PM UTC, Geoff wrote:
> 
> I'm not getting bent out of shape at all. You're the one who thinks
> the infinity of reals between 1e-308 and zero is important to a
> computation of anything that can be measured or quantified as part of
> a real process. My point was that zero, zilch, nada _is_ in fact
> represented in IEEE754 since "all bits zero" is defined as zero in
> that representation. Now, the "special" part of IEEE754 zero is that
> there are two of them and they compare equal.
>
Actually IEEE 754 has denormalised numbers, so values very close to
zero can be represented more accurately than with a straight exponent
field indicates magnitude representation.
That's handy because there's often a big difference between 1/epsilon
and 1/0, between a number which has a magnitude and sign (and thus 
often goes to unity in the next step), and a number which has an indeterminate value.

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

#55514

On Saturday, December 27, 2014 9:11:43 PM UTC, Geoff wrote:
> 
> Considering the smallest unit of measure in the universe is the Planck
> length, and that number is about 1.6e-35 meters, I'd say that a number
> 273 orders of magnitude smaller is doing pretty well for "as close to
> zero as the application requires". 
> 
You can easily lose precision, for example when inverting a matrix
which has a determinant very close to zero. I found it was a problem
when calculating the point of maximum curvature for a Bezier curve,
the maths involves a horrible expression, which is the terms of a
quintic equation. Though the Bezier was within normal parameters of
1000 or so units, the intermediates got very high, to several
billion or more, and the quintic equation solver choked. 

However you take action by rescaling values to close to unity,
adding extra bits isn't really the way to go, because the maths
can always throw at you a case where more bits are needed.

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

#55544

On 12/27/2014 02:21 PM, Osmium wrote:
...
> There are an infinitude of numbers between 0.0 and 1e-308.. If that doesn't 
> bother you, so be it. 

The same is true for any consecutive pair of representable floating
point values. This is an unavoidable consequence of using a
representation with a fixed maximum number of bits.
-- 
James Kuyper

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

#55546

On Sunday, December 28, 2014 11:50:51 AM UTC, James Kuyper wrote:
> On 12/27/2014 02:21 PM, Osmium wrote:
> ...
> > There are an infinitude of numbers between 0.0 and 1e-308.. If that doesn't 
> > bother you, so be it. 
> 
> The same is true for any consecutive pair of representable floating
> point values. This is an unavoidable consequence of using a
> representation with a fixed maximum number of bits.
>
However the numbers between, say, 1.1 and 1.1 + DBL_EPSILON  are all much of a muchness,
it hard to think of a case where substituting one for another would make much difference
to a result, unless you cheat by folding 1.1 itself into an equation and subtracting.

That's not the case for the numbers between 0 and 1e-308. There's a huge difference between
 DBL_MAX/1e-308 and DBL_MAX/1e-500.

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

#55542

On 12/27/2014 01:20 PM, Geoff wrote:
> On Sat, 27 Dec 2014 08:25:51 -0600, "Osmium" <r124c4u102@comcast.net>
> wrote:
> 
>> It is not clear to me the 
>> situation with regard to small floating point numbers.  By the nature of the 
>> beast, zero does not exist.  So the people in charge *define* zero.
> 
> Eh? Zero does exist. In IEEE754 it's all bits zero.

True - but the point is that all-bits-zero does not represent zero as
the natural result of applying the general rule for interpreting the
representation - that rule includes an implied leading bit of 1 in the
significand, so all-bits-zero would therefore represent a large negative
power of 2. It's only by defining a special exemption from the general
rule that all-bits-zero represents 0.
-- 
James Kuyper

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

#55548

On 12/28/14 6:44 AM, James Kuyper wrote:
> On 12/27/2014 01:20 PM, Geoff wrote:
>> On Sat, 27 Dec 2014 08:25:51 -0600, "Osmium" <r124c4u102@comcast.net>
>> wrote:
>>
>>> It is not clear to me the
>>> situation with regard to small floating point numbers.  By the nature of the
>>> beast, zero does not exist.  So the people in charge *define* zero.
>>
>> Eh? Zero does exist. In IEEE754 it's all bits zero.
>
> True - but the point is that all-bits-zero does not represent zero as
> the natural result of applying the general rule for interpreting the
> representation - that rule includes an implied leading bit of 1 in the
> significand, so all-bits-zero would therefore represent a large negative
> power of 2. It's only by defining a special exemption from the general
> rule that all-bits-zero represents 0.
>

Actually, all of biased exponent == 0 is an exception to the implied 
leading bit of 1, resulting in the "denormals". Thus 0 is just a natural 
case of this group, but called out as having special significance.

Denormals, in addition to providing a natural representation for 0, also 
extend the range that can be expressed by a couple of orders of 
magnitude over just making biased exponent == 0 act "normally", at the 
progressive loss of accuracy as you use the extra range.

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

#55492

On 12/27/2014 03:22 AM, asetofsymbols@gmail.com wrote:
> 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...

Could you explain that comment further? I see no inherent reason why
fixed point formats couldn't implement something similar to a floating
point NaN.
-- 
James Kuyper

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

#55538

James Kuyper <jameskuyper@verizon.net> wrote:
> On 12/27/2014 03:22 AM, asetofsymbols@gmail.com wrote:
>> 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...
 
> Could you explain that comment further? I see no inherent reason why
> fixed point formats couldn't implement something similar to a floating
> point NaN.

They could, but traditionally haven't done that.

If might be convenient to use the most negative twos complement
value as a NaN. That would remove the problem with negating it.
It might even be nice to have an exception for operations on that
value, similar to a signaling NaN.

But in the beginning of twos complement computing it wasn't done,
and people got used to hardware not doing it.

Well, partly many early systems used sign magnitude, and then a little
later, ones complement. In those cases, one might have used -0 as
a trap (NaN) representation, but most didn't. When building adders
out of vacuum tubes, anything that made it simpler made it faster
and cheaper.

(Fortran originated on the 36 bit sign magnitude vacuum tube
based IBM 709. Actually, it stores 16 bit (15 plus sign) in 
the 36 bit words.)

-- glen

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

#55495

On 2014-12-27, asetofsymbols@gmail.com <asetofsymbols@gmail.com> wrote:
> 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...

Here is the thing. Both fixed and floating-point use rational numbers to
approximate real numbers. Except in certain cases, both representations
introduce error, due to their approximative nature. These errors can be
understood and quantified. That understanding and quantification is one of the
jobs of the numeric analyst.

A limitation shared by both fixed and floating-point numbers is that
although they represent rational numers, they in fact cannot represent
all rational numbers.

For example, a binary floating-point representation can perfectly
represent 1/2, 1/4, 1/8, ... but not 1/3, 1/5 or 1/10.
The same can be said of binary fixed-point representation.

A binary fixed point with three bits of fractional precision gives you
fractional parts which are combinations of 1/2, 1/4 and 1/8. That's it!
In other words, the fractions .000, .001, .010, .011, ..., .111.

So not only do these representations provide *only* an approximation of the
real numbers, they also only approximate many rational numbers, too.

This is okay; the approximations are good enough for real work: building
a bridge, landing a rover on Mars, and so on.

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

#55227

On 12/21/2014 12:08 PM, Osmium 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?

I don't want to say you're wrong, because I can't prove that you're
wrong - not because you aren't wrong (though I think you might be) but
because I don't have access to objective evidence sufficient to prove it.

What I do have sufficient objective evidence to prove is that the
evidence you provided in support of your belief doesn't actually support
it. In fact, it provides a whole lot more support to the claim that
there is no unique convention (though it doesn't prove that, either).
That is why I restricted my comments to pointing that out.

Would you really have preferred it if I had made a counter claim for
which I couldn't provide any better evidence than yours? I can see why
you might like that, but what benefit do I gain from saying something
that foolish in public? I've committed more than enough foolishness by
accident, I see no point in deliberately adding to the list.
-- 
James Kuyper

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

#55232

James Kuyper <jameskuyper@verizon.net> writes:
> 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.

The *f() and *l() functions were added in C99.  In C90 and earlier,
<math.h> only had functions that operate on double.  Even in C99 and
later, the functions with the most straightforward names operate on
double.  Unsuffixed floating-point literals are of type double.
Arguments of type float are promoted to double when passed to variadic
functions.

The convention is not stated explicitly in the standard, but in my
experience the common wisdom is that floating-point calculations should
*usually* be done using type double, with long double used when extra
range or precision is needed and float used to save space.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#55249

James Kuyper <jameskuyper@verizon.net> 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.

This is true now, but not in all versions of the C standard.

And even so, the one without the extra letter is (double).

Contrast that to Fortran before generics, where there was SQRT
(single precision) and DSQRT (double precision).  Also, Fortran
constants are single unless they have a D exponent, or, and later
versions of the standard, a kind value.

C constants without f or l are double.

-- glen

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

#55207

On 12/21/2014 11:35 AM, Dexterr wrote:
...
> it should be something like this
> 
> typedef struct _ComplexNumber_ {
>   float real_part;
>   float imaginary_part;
> } CNumber;
> 
> CNumber complex;
> 

_Complex float CNumber;

is something very much like your definition, except that _Complex float
is a scalar type, and not a struct, which means that extracting the real
and imaginary part is done differently: (float)complex will give you the
real part, and cimagf(complex) will give you the imaginary part.

If someone chooses to #include <complex.h>, then it will contain the
equivalent of

#define complex _Complex

It is therefore no longer a good idea to give a variable a name like
'complex', even if you yourself will not be #including <complex.h>.
-- 
James Kuyper

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

#55212

Il 21/12/2014 17:35, Dexterr ha scritto:
..
> it should be something like this
>
> typedef struct _ComplexNumber_ {
>    float real_part;
>    float imaginary_part;
> } CNumber;
>
> CNumber complex;
>

If you were here to actually learn something, you would at least
re-re-read what other people had to say about how to choose a proper
name for your identifiers. I refer to what Ben Bacarisse said upthread:

http://web.archive.org/web/20040209031039/http://oakroadsystems.com/tech/c-predef.htm#ReservedIdentifiers

-- 
Vincenzo Mercuri

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web