Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Telgin]

Perhaps it was something like that.  The puzzling thing though is that it implies that the different system calls in Fortran (or at least PGI's Fortran implementation) use different internal behavior.  INQUIRE gave back the proper file size, while READ barfed and claimed there was nothing to read.  If INQUIRE accepted file handles instead of just asking for the file name perhaps it would have caught the error too, since it and OPEN obviously found different files.

[olemars]

It does. You can INQUIRE a unit to get the file connected to it (if any).

[Skyrunner]

Yeesh. Fortran sounds terrible.

[olemars]

The IO hasn't changed much since tape stores. It's great with heavy, iterative math though, especially anything involving multidimensional arrays.

[Skyrunner]

Why would I choose Fortran over something like C?
I'm curious-does fortran really do better than C for iterative math, even with all the optimizations C went over the part decade?

[Siquo]

Why would I choose Fortran over something like C?
I'm curious-does fortran really do better than C for iterative math, even with all the optimizations C went over the part decade?

Because you're a financial institution that still uses Fortran code written 30+ years ago and refuses to rebuild 30+ years of code because that would require about 10 years of work?

[olemars]

Why would I choose Fortran over something like C?
I'm curious-does fortran really do better than C for iterative math, even with all the optimizations C went over the part decade?

There isn't really any answers to those questions since it depends on so many things. I guess one way to put it is that C is closer to memory while Fortran is closer to the CPU, so it depends what you feel you need more control over. Plus Fortran is intrinsically built around operations on large datasets and parallell processing. You can probably get the same performance in C and Fortran on, say, a grid simulation, but it will be a lot more work in C and the code will be a lot uglier (with the caveat that a lot of Fortran programmers are scientists with little care for readability).

And once you're used to array operations in Fortran, you'll quickly miss them when trying to do something similar in C. In return Fortran compilers have even fewer safety nets than C, substituting it with a more "fuck it, we'll do it live" attitude.

[Telgin]

It does. You can INQUIRE a unit to get the file connected to it (if any).

Oh, that's interesting and not something I found in any documentation.  That might have helped debug this faster.

Why would I choose Fortran over something like C?
I'm curious-does fortran really do better than C for iterative math, even with all the optimizations C went over the part decade?

Siquo and olemars hit the big points: it's arguably easier to learn to use for just throwing calculations into a program, and there is a lot of hideous and old Fortran code still floating around that isn't worth rewriting in another language.

There are some theoretical advantages to Fortran over C though.  I'm not sure how relevant it is to modern compilers, but Fortran's simplicity compared to C can let the compiler optimize it better in some cases.  An example of this would be pointer aliasing, which Wikipedia can explain better than me: Pointer Aliasing.

Having said that, I'd be pretty skeptical if someone told me they chose to write a new program in Fortran over C strictly because of performance reasons...

[MorleyDev]

Quote in the university individual final year project project handbook "it should be obvious that if you set yourself the goal of learning a new programming language from scratch you will probably produce a hurried and amateurish end product" -__-

Yeeeah, no. I get that it's written for people relatively new to software development, but still that seems like they are completely underestimating the students ability to pick up new languages. With enough experience, new languages aren't as big an impediment to development. I've only used Scala for about 4 days now (using it to rapidly prototype my project) but could totally see myself using it later down the line. Might even decide to write the server component of the project in it instead of C# if I can find some good libraries for that (it's tough to beat WebAPI).

Also you're supposed to justify how you're project fits in with modules you've had at university. Well, I guess I can justify it with the mandatory ones but my project and my optional choices are somewhat far apart. My project is playing to my strengths as a developer, whilst my module choices I made to plug my weaknesses. Technical stuff I can do, so I went for the more artistic and creative-focused modules because those are areas I've had the least success in the past and I want to fill that gap.

[Telgin]

Ugh, more Fortran stuff that probably belongs in the rage thread.  I'm beginning to question what the point of language standards are if code has to be significantly altered to compile in a different compiler.

This 10K line Fortran program compiles and (presumably) works fine in Intel's ifort compiler.  To get it to compile in PGI's compiler I had to hand code some language extensions that weren't present (namely an isnan function).  After I got it to compile, it crashed because of scary stuff that Intel's compiler was okay with (assigning to unallocated arrays).  I fixed that.  Now I have to figure out why it gives wildly different output compared to ifort's resulting binary.  Like, several orders of magnitudes in output differences.

To help with that, I figured I'd try compiling it with the GNU Fortran compiler and see what its output is.  It staunchly refuses to compile the code at all, giving me lots of innocent looking warnings such as:

Code: [Select]

commonVar.f90:29.132:
    Included at tcsolver.f90:3:

5,sigw=2.0,gammastar=1.0
                                                                           1   
Warning: Line truncated at (1)

I don't really see a problem there, but I'm guessing lines like that have something to do with it complaining about some unbalanced parentheses later, which are most certainly balanced.  This is in a .f90 file so I don't think it's still expecting the column based format or anything odd...

I just really don't want to have to slog through hours of trying to figure out why gfortran won't compile this program just so I can check its output against ifort and pgfortran's binaries.  It'll probably give me an entirely different answer too, and where do I go from there?

I actually have no idea where to begin diagnosing why ifort and pgfortran produce binaries with different behaviors.  For giggles I tried running them through Valgrind's memcheck tool, which did indicate a few examples of branching depending on uninitialized values, but fixing those didn't make any difference.  Turning optimizations off didn't make any difference, which is both good and bad I suppose.  I guess I really have no choice but to try dumping values at various points and pray that the cause is limited to a small section of code.  Then I have to pray that I know what said code does, since it's just masses of equations using variables named things like ii or fspxxyzwa.

At least I'm getting paid by the hour.

[olemars]

If the program uses RNG's, compare the distribution for each compiler. Especially with hand crafted RNG's. Got burned there once.

[Telgin]

Interesting, I hadn't considered that possibility before.  I could definitely see that being the culprit behind some variation between compilers, and I'll have to file that away as something to check for in the future.

In this case, it was something embarrassingly simple: the two compilers implement the print and write functions slightly differently, causing the output to be formatted slightly differently.  For the first few lines of the output file they match up fine, but PGI's adds exponential notation in some places that Intel's doesn't, and that caused the line numbers to not match up after a while.  So by the time I got down to line 1,000, I was no longer comparing apples to apples... compensating for this by checking the exact offset into the file for each value showed they give the same answers.

Annoying, but at least I don't have to tear the whole program apart now.

[Skyrunner]

Well crap.

Link to my quandry.

If you can't tell what it is by the code, it's that even if you have a vector of BASE*, which all point to various inherited classes, their type is still BASE* even when dereferenced. That means an overloaded function can't tell what type the input is. I can't think of a clean way to make them identify properly.

The current output is

I am BASE. Identified as BASE
I am INHERITED 1. Identified as BASE
I am INHERITED 2. Identified as BASE
I am INHERITED 3. Identified as BASE
I am INHERITED 4. Identified as BASE
I am BASE. Identified as BASE
I am INHERITED 1. Identified as BASE

Ideal output is

I am BASE. Identified as BASE
I am INHERITED 1. Identified as INH1
I am INHERITED 2. Identified as INH2
I am INHERITED 3. Identified as INH3
I am INHERITED 4. Identified as INH4
I am BASE. Identified as BASE
I am INHERITED 1. Identified as INH1

What am I missing here? What I want to do is store multiple inherited classes in one vector, and then be able to tell what type they are via overloaded functions. I don't think an OOP language would miss this very obvious usage of OOP... would it? >_>

(This kinda sounds like reflection.)

edit: someone pointed me towards RTTI, which I kinda want. The wiki article seems to imply that it's a trial-and-error process and that there's nothing as clean as simply class in overloaded function out

[olemars]

When you store the INHx pointers in a vector<BASE *> they are implicitly cast to that type, so your overloads of idenitfy will definitely not do what you wish. But as you can see the correct reimplemented virtual function is called, so that's what you have to work with.

The cleanest is to make a virtual id() function (return an int or enum or whatever), reimplement for each inheriting class and test against that in identify(BASE id). The alternative is dynamic_cast and test for non-NULL, which tends to be discouraged (but is sometimes useful).

[Mego]

The fun thing is, I have been working on a project that adds some reflection to C++ classes. The ReflectBase class and Reflect.h header file are where most of the work is done. Note that this requires using GCC, as it uses the GNU C++ ABI functions. I'm not sure if MSVC has a compatible set of functions.