Re: Function missing for complex numbers

Lew Pitcher wrote:
On May 15, 2009 11:31, in comp.std.c, jacob navia (jacob@xxxxxxxxxx) wrote:

Lew Pitcher wrote:
On May 15, 2009 06:58, in comp.std.c, jacob navia (jacob@xxxxxxxxxx)
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?

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

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.


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.

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?


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
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
.

Relevant Pages

  • Re: Two Click disassembly/reassembly
    ... that time into hand translating all of his applications to the new CPU. ... which is one more reason the conversion to a different CPU is ... RosAsm, at this point). ... the first place -- the power of the native CPU's language. ...
    (alt.lang.asm)
  • Re: Step by step lesson book
    ... Most particularly _the internet_ is a huge advance in general, ... It starts by translating diatonic number formula ... into a language known to all, welcomed by all, accessible by all. ... The analogy was "ingredients and recipes", ...
    (alt.guitar.beginner)
  • Re: Native language versions
    ... It is a different language which can be translated ... into perl and can use Perl modules. ... away quite a bit from the OP's notion of just translating perl keywords ... There's probably not much use for a user-accessible programming language ...
    (comp.lang.perl.misc)
  • Re: Function missing for complex numbers
    ... translating other languages codes is unavoidable. ... porting code from one language to another, ... I presume that this is your proposal: to add to the new C standard a set ...
    (comp.std.c)
  • Re: Fundamental difference between English and German
    ... Once one knows the foreign language one begins ... oneself in the foreign language than in one's native tongue while one ... problem translating into French but I realise that I can't be as nuanced ...
    (uk.politics.misc)