_Complex and _Imaginary datatypes

_Complex and _Imaginary datatypes

[Justin Hibbits]

Hi, I'm not on the list, so CC all replies to me, (or some other way of letting
me get them).

Basically, I want to rally high-profile compiler developers to change the C99
standard.  I think that the _Complex and _Imaginary data types are completely
useless in the mainline language and should be moved back to the library, which
is where they usually are.

My biggest argument is that it increases the complexity of the compiler itself,
which is not necessary.

Flames, comments, etc are welcome.

Thanks,
Justin Hibbits

-- 
Registered Linux user 260206

Re: _Complex and _Imaginary datatypes

[Marcel Cox]

"Justin Hibbits" <jrh29@po.cwru.edu> wrote in message
news:20030223201818.GA29555@lothlorien.cwru.edu...
> Hi, I'm not on the list, so CC all replies to me, (or some other way of
letting
> me get them).

There are actually 2 convieniant ways to look at the messages if you are not
subscribed:

1) The mailing list archives at http://gcc.gnu.org/ml/gcc/

2) The gmane news server:
news://news.gmane.org/gmane.comp.gcc.devel

> Basically, I want to rally high-profile compiler developers to change the
C99
> standard.  I think that the _Complex and _Imaginary data types are
completely
> useless in the mainline language and should be moved back to the library,
which
> is where they usually are.

Forget it:
- once a feature in in the official standard of a language, it is almost
impossible to remove it. The idea is that new versions of the standard are
allowed to extend or clarify the language, but existing programs should
remain compatible with the new standard, or at least require a minimum
effort of adjustment. However if you would remove complex number support
again, all programs using this feature would stop working without any
suitable replacement.
As for the uselessness of these features, I'm sure that many people will
very strongly disagree with you. The lack of these data types was one of the
reasons why so much numerical code is still done in Fortran. The numerical
enhacements in C99 is directly targeted to making C a valid replacement for
Fortran for numerical code. All previous C standards were lacking too many
features (date types and numerical functions) Fortran programmes were used
to.

> My biggest argument is that it increases the complexity of the compiler
itself,
> which is not necessary.

Most popular C compilers already support the complex data types. So the work
is already done, and it's quite useless to complain about the compelxity
now. Besides, the support of complex number is small in complexity compred
to for example many features C++ compilers have to implement. As most of the
time, C and C++ compilers are kind of developed together, the support for
complex numbers is simply trivial to the overall compiler support.

Marcel

Re: _Complex and _Imaginary datatypes

[Erik Trulsson]

On Sun, Feb 23, 2003 at 03:18:18PM -0500, Justin Hibbits wrote:
> Hi, I'm not on the list, so CC all replies to me, (or some other way of letting
> me get them).
> 
> Basically, I want to rally high-profile compiler developers to change the C99
> standard.  I think that the _Complex and _Imaginary data types are completely
> useless in the mainline language and should be moved back to the library, which
> is where they usually are.

Changing the C99 standard itself won't happen.  The time to do that was
before it was published.  (Standards are not changed retroactively.)
What you might be able to do is to convince the standards people to
remove _Complex and _imaginary from the next revision of the C
standard.

I think that the schedule is that a review of the standard will be done
after 5 years (i.e. in 2004) but that is for minor modifications and
corrections only as I understand it and removing a non-trivial part of
the language (such as Imaginary/_Complex) will almost certainly not
happen.
The next major revision of the C standard is, I believe, scheduled for
2009 and work on that hasn't even begun yet.
By then I suspect that _Imaginary/_Complex will be a firmly entrenched
part of the C language and removal will be probably met with a lot of
resistance.

> 
> My biggest argument is that it increases the complexity of the compiler itself,
> which is not necessary.

Do you have any numbers on how large this increase in complexity is?
Without looking closely at the issue I suspect the increased complexity
from this is quite small, especially when compared to other language
additions in C99 like variable-length arrays.

> 
> Flames, comments, etc are welcome.

My opinion is: Forget it. You are very unlikely to convnice the
standards commitee to remove support for _Complex/_Imaginary from the C
standard and doing it will almost certainly not be worth the trouble
anyway.

(Besides, consider that the fact the reason this was added to C99 was
because at least some people *wanted* this in the language.  Those
people will probably not be happy if this support is removed.

Consider also the fact that while it is usually easy to add features to
a language/system, it is often very difficult to remove features once
people have started using them.)


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

Re: _Complex and _Imaginary datatypes

[Steven Bosscher]

Op ma 24-02-2003, om 06:17 schreef Andrew Pinski:
> I just want to voice my opinion now since no one has mentioned Fortran 
> yet.
> 
> I would say C is evolving past what C++ is and more into Fortran.

Let's hope, then, that C200x will include array assignments too!  :-)

Seriously, C99 tries to be a good scientific language, but really it is
not IMHO.  And "the people in the field" seem to agree.  Also, nobody
said it's a good think that C is evolving into Fortran.  Just another
attempt to be the "Language Of Everything".

I wonder how many people really use C99's numerical features including
complex data types.

Greetz
Steven

Re: _Complex and _Imaginary datatypes

[Andrew Pinski]

I just want to voice my opinion now since no one has mentioned Fortran 
yet.

I would say C is evolving past what C++ is and more into Fortran.
Fortran includes complex types so if people want to use C has a good 
scientific language,
you need complex types included in the language, having it in a library 
some times does
not help because certain concepts you would need to write out like add 
but since C does
have overloading functions (they have types based functions for math 
though, in C99) it
is very hard to do that.

For an example:
double a; ComplexDouble b;
ComplexDouble c;
ComplexDouble d;

Right now:
c = b+a;
d = c - _Imaginary * 2.0;

Your proposal (yes the parser is simpler):
ComplexDouble temp;

c = addComplexDoubleToDouble(b,a);
temp = makeComplexDouble(0, 2.0);
d = addComplexDoubleToComplexDouble(b,temp);

Thanks,
Andrew Pinski


On Sunday, Feb 23, 2003, at 19:04 US/Pacific, Justin Hibbits wrote:

> You know what?  Just forget what I suggested.  Apparently I'm the only 
> member
> of the minority who believes C shouldn't change to be C++, which it 
> seems to be
> doing.  So, from now on, I'll just keep my mouth shut.  Nobody cares 
> what I
> think, as apparently I'm just a fucking troll.
>
> -- 
> Registered Linux user 260206
>
>
>
>

Re: _Complex and _Imaginary datatypes

[Justin Hibbits]

You know what?  Just forget what I suggested.  Apparently I'm the only member
of the minority who believes C shouldn't change to be C++, which it seems to be
doing.  So, from now on, I'll just keep my mouth shut.  Nobody cares what I
think, as apparently I'm just a fucking troll.

-- 
Registered Linux user 260206

Re: _Complex and _Imaginary datatypes

[Robert Dewar]

> Do you have any numbers on how large this increase in complexity is?
> Without looking closely at the issue I suspect the increased complexity
> from this is quite small, especially when compared to other language
> additions in C99 like variable-length arrays.

I think it would actually make the compiler *more* complicated to have
type complex be in a library. You would still want the compiler to recognize
this type specially and generate efficient code knowing about the type, and
this might be more difficult, not less if the type is not integral to the
language. Yes, it might make a simple student-type compiler simpler, but
then such projects can omit complex in any case.