Function missing for complex numbers
jacob navia
notation.
Since this notation is not used in any significant package (that I know
of), translating other languages codes is unavoidable.
What is missing (besides several other stuff) is a function that takes
two floating point numbers and returns a complex. C++ provides the
constructor, what would NICE to have in C99. Fortran has
CMPLX(real,imag).
long double _Complex Complexl(long double,long double);
double _Complex Complex(double,double);
float _Complex Complexf(float,float);
This would make easier to translate codes from C++ and Fortran into
C. As it is now, the function call must be replaced
C=complex(A,B) --> C = A + (I*(b)), what is quite different and
contributes to the difficulty of translating those codes.
Thanks for your attention
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Keith Thompson
> I am translating complex number codes from fortran and C++ into the C99
> notation.
>
> Since this notation is not used in any significant package (that I
> know of), translating other languages codes is unavoidable.
>
> What is missing (besides several other stuff) is a function that takes
> two floating point numbers and returns a complex. C++ provides the
> constructor, what would NICE to have in C99. Fortran has
> CMPLX(real,imag).
>
>
> long double _Complex Complexl(long double,long double);
> double _Complex Complex(double,double);
> float _Complex Complexf(float,float);
>
> This would make easier to translate codes from C++ and Fortran into
> C. As it is now, the function call must be replaced
> C=complex(A,B) --> C = A + (I*(b)), what is quite different and
> contributes to the difficulty of translating those codes.
What's so difficult about A + I * B?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacob navia
> jacob navia <ja...@nospam.org> writes:
>> I am translating complex number codes from fortran and C++ into the C99
>> notation.
>>
>> Since this notation is not used in any significant package (that I
>> know of), translating other languages codes is unavoidable.
>>
>> What is missing (besides several other stuff) is a function that takes
>> two floating point numbers and returns a complex. C++ provides the
>> constructor, what would NICE to have in C99. Fortran has
>> CMPLX(real,imag).
>>
>>
>> long double _Complex Complexl(long double,long double);
>> double _Complex Complex(double,double);
>> float _Complex Complexf(float,float);
>>
>> This would make easier to translate codes from C++ and Fortran into
>> C. As it is now, the function call must be replaced
>> C=complex(A,B) --> C = A + (I*(b)), what is quite different and
>> contributes to the difficulty of translating those codes.
>
> What's so difficult about A + I * B?
>
Translation is much more complicated
Lew Pitcher
> I am translating complex number codes from fortran and C++ into the C99
> notation.
>
> Since this notation is not used in any significant package (that I know
> of), translating other languages codes is unavoidable.
>
> What is missing (besides several other stuff) is a function that takes
> two floating point numbers and returns a complex.
Sounds like the usual state of application programming to me. When porting
code from one language to another, you often find language idioms that do
not have a direct translation. Part of the porting process is to write
application-level code that stands in for the source language idiom.
> C++ provides the
> constructor, what would NICE to have in C99. Fortran has
> CMPLX(real,imag).
>
> long double _Complex Complexl(long double,long double);
> double _Complex Complex(double,double);
> float _Complex Complexf(float,float);
I presume that this is your proposal: to add to the new C standard a set of
standard functions that build complex data from floatingpoint values? If
so, could you expand on the workings and external behaviour of each of
these functions? How do you see these functions working? What error
conditions will they handle (or not handle)? What do the results look like?
> This would make easier to translate codes from C++ and Fortran into
> C.
When compared against the writing of new code that would use these
functions, how often do you see these new functions being used for porting
code? In other words, is code porting the only (or greatest) utility of
these functions? How about new code? Given the amount of activity around
porting or writing new "complex" code, is it worth the effort to define and
standardize these functions?
> As it is now, the function call must be replaced
> C=complex(A,B) --> C = A + (I*(b)), what is quite different and
> contributes to the difficulty of translating those codes.
In a later post, when asked the question
>> What's so difficult about A + I * B?
you answer with
> Translation is much more complicated
When you say "translation", are you referring to the work of the compiler,
or your work as the compiler developer, or your work as an application
developer?
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
jacob navia
> On May 15, 2009 06:58, in comp.std.c, jacob navia (ja...@nospam.org) wrote:
>
>> I am translating complex number codes from fortran and C++ into the C99
>> notation.
>>
>> Since this notation is not used in any significant package (that I know
>> of), translating other languages codes is unavoidable.
>>
>> What is missing (besides several other stuff) is a function that takes
>> two floating point numbers and returns a complex.
>
> Sounds like the usual state of application programming to me. When porting
> code from one language to another, you often find language idioms that do
> not have a direct translation. Part of the porting process is to write
> application-level code that stands in for the source language idiom.
>
>> C++ provides the
>> constructor, what would NICE to have in C99. Fortran has
>> CMPLX(real,imag).
>>
>> long double _Complex Complexl(long double,long double);
>> double _Complex Complex(double,double);
>> float _Complex Complexf(float,float);
>
> I presume that this is your proposal: to add to the new C standard a set of
> standard functions that build complex data from floatingpoint values? If
> so, could you expand on the workings and external behaviour of each of
> these functions? How do you see these functions working? What error
> conditions will they handle (or not handle)? What do the results look like?
Well, sorry, I forgot to explain but there is
(1) All those return a complex number of the corresponding type
(float, double or long double _Complex)
(2) I do not see how those functions could fail. That is why
there wasn't any error handling discussion. How could they fail?
Can you provide an example?
>
>> This would make easier to translate codes from C++ and Fortran into
>> C.
>
> When compared against the writing of new code that would use these
> functions, how often do you see these new functions being used for porting
> code?
In C++ and Fortran they are used a lot, in all codes I translated.
> In other words, is code porting the only (or greatest) utility of
> these functions?
Yes.
> How about new code? Given the amount of activity around
> porting or writing new "complex" code, is it worth the effort to define and
> standardize these functions?
>
I can't tell if anyone is using C99 complex code. I have no data. I am
translating codes to test my implementation, and I suppose that other
people would need to translate complex number code from Fortran and C++,
the main languages where there is already a lot of code already
written.
>> As it is now, the function call must be replaced
>> C=complex(A,B) --> C = A + (I*(b)), what is quite different and
>> contributes to the difficulty of translating those codes.
>
> In a later post, when asked the question
>>> What's so difficult about A + I * B?
> you answer with
>> Translation is much more complicated
>
> When you say "translation", are you referring to the work of the compiler,
not really.
> or your work as the compiler developer, or your work as an application
> developer?
I am translating those codes to test my implementation. Each time I find
a new package I see that complex(a,b) is used a lot, or CMPLX(a,b)
The problem with A+I*B is to make sure you have the parentheses
in the right place to avoid changing the algorithm... It is much
easier to translate a function call with another function call.
Keith Thompson
> Keith Thompson wrote:
>> jacob navia <ja...@nospam.org> writes:
>>> I am translating complex number codes from fortran and C++ into the C99
>>> notation.
>>>
>>> Since this notation is not used in any significant package (that I
>>> know of), translating other languages codes is unavoidable.
>>>
>>> What is missing (besides several other stuff) is a function that takes
>>> two floating point numbers and returns a complex. C++ provides the
>>> constructor, what would NICE to have in C99. Fortran has
>>> CMPLX(real,imag).
>>>
>>>
>>> long double _Complex Complexl(long double,long double);
>>> double _Complex Complex(double,double);
>>> float _Complex Complexf(float,float);
>>>
>>> This would make easier to translate codes from C++ and Fortran into
>>> C. As it is now, the function call must be replaced
>>> C=complex(A,B) --> C = A + (I*(b)), what is quite different and
>>> contributes to the difficulty of translating those codes.
>>
>> What's so difficult about A + I * B?
>
> Translation is much more complicated
I honestly don't see how. If nothing else, you can always emit
definitions for these functions at the top of the translated output,
and generate calls to them. They're all trivial to implement in
standard C.
But even that seems like overkill. You can mechanically translate
CMPLX(A, B)
to
((A) + I * (B))
Where's the problem?
jacob navia
Well, there is NO problem of algorithm obviously. I think however
that those functions should be provided by the language instead of
being written in slightly different form by each application developer!
I know I can write a macro to do that. The purpose here is that the
language provides them so that they can be written portably.
Mark Dickinson
> Keith Thompson wrote:
> > jacob navia <ja...@nospam.org> writes:
> >> This would make easier to translate codes from C++ and Fortran into
> >> C. As it is now, the function call must be replaced
> >> C=complex(A,B) --> C = A + (I*(b)), what is quite different and
> >> contributes to the difficulty of translating those codes.
>
> > What's so difficult about A + I * B?
>
> Translation is much more complicated
There's another serious issue with using A+I*B: on implementations
that define I to be _Complex_I rather than _Imaginary_I, A+I*B
typically doesn't have the desired effect of putting A into the real
part and B into the imaginary part: complex numbers involving
infinities, nans, or negative zeros tend to get messed up. For
example,
try compiling and running the following code on your favourite system.
#include <stdio.h>
#include <complex.h>
int main(void) {
double x, y;
x = -0.0;
y = 3.14;
printf("x is: %.17g, ", x);
printf("but real part of x+I*y is: %.17g\n", creal(x+I*y));
x = 2.72;
y = 1./0.;
printf("x is: %.17g, ", x);
printf("but real part of x+I*y is: %.17g\n", creal(x+I*y));
return 0;
}
Under GCC 4.4, I get this:
x is: -0, but real part of x+I*y is: 0
x is: 2.7200000000000002, but real part of x+I*y is: nan
Mark
Golden California Girls
I can think of one possible situation that would need to be documented and that
is when passed a NaN or INF to store.
Lew Pitcher
1) You have given us the function prototypes for three functions, and
verbally explained that each function would take "two floating point
numbers and returns a complex".
a) The suggested function names deviate from similarity to other standard C
functions, in that they each begin with a capital letter. For what reason
do you suggest this deviation?
b) You have not provided the algorithm that each of these functions would
use in order to accomplish the given task. With your current suggestion,
double _Complex Complex(double a, double b)
{
double _Complex c;
return c;
}
may satisfy the requirements, but would not generate the "correct"
results. So, tell us what these three functions are supposed to do, and
how they are supposed to do it.
2) Each of the proposed functions accepts an argument list containing two
floatingpoint numbers (of varying precision). How will each of these
functions deal with an argument of NaN or INF?
>>
>>> This would make easier to translate codes from C++ and Fortran into
>>> C.
>>
>> When compared against the writing of new code that would use these
>> functions, how often do you see these new functions being used for
>> porting code?
>
> In C++ and Fortran they are used a lot, in all codes I translated.
>
>> In other words, is code porting the only (or greatest) utility of
>> these functions?
>
> Yes.
Why should the standard include new functionality that is now coded only
infrequently, and only (or primarily) for the purposes of porting code to
C? You are asking C compiler implementors to add new functionality that
will hardly ever be used. You, personally, know the cost in development and
maintenance time to add such functions to a compiler; are those costs worth
it?
Oh, so you ask that the standard include these (likely seldomly used)
functions so that you, as an application developer, do not have to code a
small macro or helper function, the few times it becomes necessary?
jacob navia
Yes, the first is the real part, the second the imaginary part.
In true C99 style we would have:
The Complex functions
---------------------
Synopsis:
#include <complex.h>
long double _Complex Complexl(long double,long double);
double _Complex Complex(double,double);
float _Complex Complexf(float,float);
Description:
The complex functions take two floating point numbers, the real part and
the imaginary part of a complex number that is returned as their result.
NAN and INF arguments are inserted as such. No conversions are performed.
Returns:
The Complex functions return a complex number result with the same
precision as their arguments.
> a) The suggested function names deviate from similarity to other standard C
> functions, in that they each begin with a capital letter. For what reason
> do you suggest this deviation?
>
The reason is obvious: the identifier "complex" is already used. Besides
the name of the type is _Complex and NOT _complex, contrary to all other
C types that are lower case. I think that it would be highly confusing
for the user that the identifier Complex was used in a mixture of lower
and upper case.
> b) You have not provided the algorithm that each of these functions would
> use in order to accomplish the given task. With your current suggestion,
> double _Complex Complex(double a, double b)
> {
> double _Complex c;
> return c;
> }
> may satisfy the requirements, but would not generate the "correct"
> results. So, tell us what these three functions are supposed to do, and
> how they are supposed to do it.
>
See above
>
> 2) Each of the proposed functions accepts an argument list containing two
> floatingpoint numbers (of varying precision). How will each of these
> functions deal with an argument of NaN or INF?
>
See above
>>>> This would make easier to translate codes from C++ and Fortran into
>>>> C.
>>> When compared against the writing of new code that would use these
>>> functions, how often do you see these new functions being used for
>>> porting code?
>> In C++ and Fortran they are used a lot, in all codes I translated.
>>
>>> In other words, is code porting the only (or greatest) utility of
>>> these functions?
>> Yes.
>
> Why should the standard include new functionality that is now coded only
> infrequently, and only (or primarily) for the purposes of porting code to
> C? You are asking C compiler implementors to add new functionality that
> will hardly ever be used. You, personally, know the cost in development and
> maintenance time to add such functions to a compiler; are those costs worth
> it?
>
The new C99 notation has no code base since the standard decided not to
follow existing practice either in the "i" suffix for complex number
constants, or with the "constructor" mechanism of C++ and FORTRAN.
To easy the porting from those languages those functions are useful.
Besides, they provide functionality that is difficult to achieve
using the + notation, for instance when we want to construct a complex
number with negative zeros, INF or NANs.
You are against anything I say or propose. It is your right obviously,
but thinking that I want to spare the coding of those utterly trivial
functions is just ridiculous. If I wanted just to code those in
lcc-win, I would have done it in less time than what I am spending
answering your questions.
My objective is to have a consistent language. I think those functions
are needed in a consistent implementation of complex numbers.
jacob navia
The Complex functions
---------------------
Synopsis:
#include <complex.h>
long double _Complex Complexl(long double,long double);
double _Complex Complex(double,double);
float _Complex Complexf(float,float);
Description:
The complex functions take two floating point numbers, the real part and
the imaginary part of a complex number that is returned as their result.
NAN and INF arguments are inserted as such. No conversions are performed.
Returns:
The Complex functions return a complex number result with the same
precision as their arguments.
--
Lew Pitcher
[snip]
> You are against anything I say or propose. It is your right obviously,
> but thinking that I want to spare the coding of those utterly trivial
> functions is just ridiculous. If I wanted just to code those in
> lcc-win, I would have done it in less time than what I am spending
> answering your questions.
>
> My objective is to have a consistent language. I think those functions
> are needed in a consistent implementation of complex numbers.
Actually, Jacob, I'm /not/ against anything that you say or propose.
However, standards are important to me. As a software developer for over 20
years (30+ years in the computer business), writing large business
applications for finance, I've learned that "program specifications" are
important to get right /before/ you start development.
Standards (such as the ISO C standard) are the "program specs" for
developers (both those who develop compilers, and those who develop
end-user applications written in the language defined by the standard). You
have to get them right, and they have to be *explicit*. They cannot leave
room for interpretation or variation.
So far, your proposals have been interesting. I don't object to much about
them. But, they are /incomplete/. Your proposals do not cover all the
aspects that a standard needs covered. So, I ask leading questions. I ask
you to justify your decisions. I expect you to show that you have performed
the requisite due diligence and present a well-thought-out proposal. Where
your proposal lacks details, I ask for them.
I'm not against you (but, then again, I'm not /for/ you either). I'm /for/
the C standard, and for standardizing C. Where I question, it is to clarify
how your proposal fits in, and if it is well-thought-out.
jacob navia
Ok, excuse me. I had that feeling that anything I say is
wrong for you. Thanks for clarifying that.
I have modified my proposal, and made implicit stuff explicit
(see the other message I posted here with a definition in
C99 style, with inputs, outputs, NAN/INF handling).
I hope I answered all your questions, and sorry again for
misunderstanding you.
Mark Dickinson
> Here is a more formal approach
>
> The Complex functions
> ---------------------
> Synopsis:
>
> #include <complex.h>
> long double _Complex Complexl(long double,long double);
> double _Complex Complex(double,double);
> float _Complex Complexf(float,float);
>
> Description:
> The complex functions take two floating point numbers, the real part and
> the imaginary part of a complex number that is returned as their result.
> NAN and INF arguments are inserted as such. No conversions are performed.
>
> Returns:
> The Complex functions return a complex number result with the same
> precision as their arguments.
I think there's a very real need for these functions, simply because
for many implementations there's no other straightforward way to take
two doubles x and y and create the double _Complex whose real part is
x and whose imaginary part is y.
On platforms that have IEEE 754 arithmetic but don't implement the
imaginary types described in Annex G, x+I*y does *not* have the same
semantics as the proposed Complex(x, y).
Suppose that I'm on an IEEE 754 system, and x is -0.0 while y is
-infinity. How am I supposed to create the complex number whose real
part is x and whose imaginary part is y?
Mark
Lew Pitcher
wrote:
Agreed. As you pointed out upthread, even the behaviour of the simplest
expression of the functionality here (A + I * B) may vary, depending on
factors not expressed in this suggestion.
I would like to see Jacob expand the suggestion to include an algorithm that
each function would use to derive the resutant complex from. The algorithm
should include
a) the base expression,
b) an algorithm to be used when I is defined as _Complex_I,
c) an algorithm to be used when I is defined as _Imaginary_I,
d) requirements for handling of NaN and INF values,
e) variations and alterations for the differences in the standard
floatingpoint formats
lawrenc...@siemens.com
>
> This would make easier to translate codes from C++ and Fortran into
> C. As it is now, the function call must be replaced
> C=complex(A,B) --> C = A + (I*(b)), what is quite different and
> contributes to the difficulty of translating those codes.
#define complex(A,B) ((A) + I*(B))
--
Larry Jones
It's like SOMEthing... I just can't think of it. -- Calvin
jacob navia
> jacob navia <ja...@nospam.org> wrote:
>> This would make easier to translate codes from C++ and Fortran into
>> C. As it is now, the function call must be replaced
>> C=complex(A,B) --> C = A + (I*(b)), what is quite different and
>> contributes to the difficulty of translating those codes.
>
> #define complex(A,B) ((A) + I*(B))
>
If B is a NAN/INF or A is -0.0 this doesn't work.
jacob navia
Thanks, This is an important point, that I did not realize immediately.
Keith Thompson
> Lew Pitcher wrote:
[...]
>> a) The suggested function names deviate from similarity to other standard C
>> functions, in that they each begin with a capital letter. For what reason
>> do you suggest this deviation?
>
> The reason is obvious: the identifier "complex" is already used. Besides
> the name of the type is _Complex and NOT _complex, contrary to all other
> C types that are lower case. I think that it would be highly confusing
> for the user that the identifier Complex was used in a mixture of lower
> and upper case.
_Bool and _Imaginary are also mixed case.
You're right, the identifier "complex" (which would be the obvious
name) isn't available. But I'm still uncomfortable with the
mixed-case name, unlike almost all other library functions (_Exit is
the only exception I can think of, and it follows the same style as
the _Complex, _Bool, and _Imaginary keywords.)
I suggest "cmplx" (and cmplxf and cmplxl). I think there's precedent
for that name in Fortran.
If it weren't for the issue of negative zero, NaNs, and infinities,
I'd say it's not worth the effort, but given those issues I think I
agree that something like this is necessary.
Tim Rentsch
(* (double _Complex *) (double[2]){ x, y })
Guaranteed to work by 6.2.5p13.
Mark Dickinson
> dick...@gmail.com (Mark Dickinson) writes:
>> Suppose that I'm on an IEEE 754 system, and x is -0.0 while y is
>> -infinity. How am I supposed to create the complex number whose real
>> part is x and whose imaginary part is y?
>
> (* (double _Complex *) (double[2]){ x, y })
>
> Guaranteed to work by 6.2.5p13.
Ah yes. That works. Thanks.
I guess the real and imaginary parts of an existing complex number
could be accessed in similar manner.
I wonder why the standard includes functions creal and cimag to turn a
complex number into two reals, but no corresponding function to turn a
pair of real numbers into a complex number.
Mark
jacob navia
>
> I wonder why the standard includes functions creal and cimag to turn a
> complex number into two reals, but no corresponding function to turn a
> pair of real numbers into a complex number.
>
> Mark
That's the point. That function is missing.
Tim Rentsch
> Mark Dickinson wrote:
> >
> > I wonder why the standard includes functions creal and cimag to turn a
> > complex number into two reals, but no corresponding function to turn a
> > pair of real numbers into a complex number.
> >
> > Mark
>
> That's the point. That function is missing.
The expression given in the earlier posting shows that the
"missing" function isn't necessary; if needed it can be
supplied by a simple one-line macro definition. For most
people, the ROI here isn't high enough to make it visible
on their priority lists. Probably it's worth putting on
the list, but that doesn't mean its priority is high
enough so it should get done anytime soon.
Richard Bos
> jacob navia <ja...@nospam.org> writes:
>
> > Mark Dickinson wrote:
> > >
> > > I wonder why the standard includes functions creal and cimag to turn a
> > > complex number into two reals, but no corresponding function to turn a
> > > pair of real numbers into a complex number.
> >
> > That's the point. That function is missing.
>
> The expression given in the earlier posting shows that the
> "missing" function isn't necessary; if needed it can be
> supplied by a simple one-line macro definition. For most
> people, the ROI here isn't high enough to make it visible
> on their priority lists. Probably it's worth putting on
> the list, but that doesn't mean its priority is high
> enough so it should get done anytime soon.
*Shrug* It won't make me lose any sleep either way, but it seems the
perfect candidate to put on the list for CXXX9. A lot better than those
horrendous _s functions, anyway.
Richard
Tim Rentsch
Didn't I say basically the same thing? Or do you
mean a different list than I did?
Richard Bos
Oh, I didn't mean to contradict you, only to add another opinion.
Richard