From: Vincenzo Mercuri on
glen herrmannsfeldt wrote:


>> 3 -- what about the Standard IEEE 754 (IEC 60559:1989) conformance?
>> is that intrinsecal to the language or the implementation?
>> which language can offer a full support to the IEEE Standard,
>> C or Fortran?
>
> IEEE 754 (why 1989 and not 2008?) is not intrinsic to either,
> and likely neither offers full support. Fortran 2003 includes
> a module and many intrinsic functions, and those help write
> conforming code. Though not standard, many of the IEEE 754 features
> were available in C earlier than in Fortran.

Actually the reason not to mention the 2008 Standard is that it
is too recent. If I think about C99 compliance of even the most
widely used C compilers I think it will take long for IEEE 2008
to be supported.

>> 4 -- what about performance? would you bet on C or Fortran? :-)
>
> I wouldn't bet. If you are careful in writing the appropriate
> low-level code in C, it can often be faster than Fortran.
> If you are not so careful, a good optimizing Fortran compiler
> might generate faster code, or it might not.
[...]

I asked because it is such a temptation to keep using
the same programming language. But actually, the answer lies
in the reasons why and the contexts where the 2 languages were born.
Fortran for numeric computation and C for system programming
(and some more abstract programming paradigm).

Thank you.



--
Vincenzo Mercuri
From: Nick Maclaren on
In article <dc8cf9de-1ef4-445d-b9bf-14a214614eaa(a)i19g2000pro.googlegroups.com>,
steve <kargls(a)comcast.net> wrote:
>>
>> >Note, the only item marked broken for the compiler is
>> >near and dear to your heart.
>>
>> You have got that spectacularly wrong! =A0I thought that I had made
>> it clear that I regarded the IEEE 754 support as demented.
>
>I suppose I should have used a 'smiley' to denote sarcasm.
>Yes, I'm well aware of your views concerning ieee754.

Sorry - I shouldn't have posted when half asleep!

Regards,
Nick.
From: Nick Maclaren on
This is getting very off-group, so I shall stop here.


In article <slrni673rj.f7m.foo(a)vipunen.hut.fi>, JB <foo(a)bar.invalid> wrote:
>
>Well, gcc can be used with other C libraries than glibc. glibc is used
>only on Linux, AFAICT.

Just don't expect the combination to work! "glibc" should probably
read "a supported library, primarily gcc".

>That being said, you're right, and this split
>only on Linux, AFAICT. That being said, you're right, and this split
>has caused some problems in the past (an obvious one in the context of
>this discussion being that the level of C99 support is different on
>targets using different C libraries), and IMHO it would make sense if
>the C standard library would be part of gcc, and then glibc could be
>more like some "libposix" are whatever one might call it. But,
>anyways, that's not how things are done in reality, largely for
>historical reasons I suppose.

No, but it's NOT separated into the library, either. Fortran still
has a sharper distinction between the language and the intrinsics,
but Fortran 90 stopped regarding them as distinct, and I know of no
modern compiler/library combinations that can be split.

>> I will try to remember what the issue was where C99 was incompatible
>> with gcc, and there was a definite intent to maintain compatibility
>> at the expense of C99, and check what has happened to it. But it's
>> a long time ago now, and I may not be able to.
>
>The only thing I can recall right away is that there was an
>incompatibility with the C99 "inline" and the GCC extension
>"inline". IIRC something like the GCC "extern inline" meant the same
>thing as just "inline" in C99, and vice versa. But, this issue was
>fixed a few years ago, and GCC nowadays by default follows the C99
>semantics.

I remember something to do with the scope of variable length arrays,
but that MIGHT be something that could be swept under the carpet as
a quality of implementation issue.


Regards,
Nick Maclaren.
From: Vincenzo Mercuri on
teg ha scritto:
> Den Tue, 10 Aug 2010 18:26:35 +0200 skrev Vincenzo Mercuri:
>
>> 1 -- is there any reason not to learn Fortran (a new language for me)
>> and focus on C (and C numerical libraries) potentialities?
>
> Learn both and learn how to call Fortran from C and C from Fortran.


yes, that's the point indeed.


>> 2 -- is Fortran considered the best choice in this field only because
>> of its construct and syntax that makes easier to handle
>> mathematical entities?
>
> No, mostly because the code (and I mean Fortran77) is prettier :)


....in performing matrix calculations you are definitely right!
I still need the power of C in system programming though.


>> 4 -- what about performance? would you bet on C or Fortran? :-)
>>
>
> Same. For real performance critical applications you want handcoded
> assembly libraries.


true...but 'handcoding assembly libraries' sounds a little scary :-)

--
Vincenzo Mercuri
From: Vincenzo Mercuri on
Lynn McGuire ha scritto:

> I would use C++ instead C. I would also check on the potential
> platforms that you will be developing on or porting to and make
> sure that there is a good fortran vendor there. For instance,
> the iPhone only supports 4 compilers: Objective C, C++, C and
> Java. Any proprietary environments can be very limiting.

Thank you.
Well, actually I'd like to learn C++ too.
But for now, apart from numerical calculations,
I just need to do some system programming
and I find it easy, I'd say natural, to do it in C.
Maybe it would be as easy in C++, but I have (maybe wrongly)
a picture in mind of C++ as not so handy for small
functions (I'd say procedures in a Fortran context),
but more suitable for large projects.



--
Vincenzo Mercuri