Re: can somebody verify this C program which calls dsaupd_ ? (longish)
- From: Madhusudan Singh <spammers-go-here@xxxxxxxxxxxx>
- Date: Sun, 03 Apr 2005 14:44:32 -0400
H. S. wrote:
>>
>> It could be true, but it certainly would not be the first thing to
>> suspect.
>
> I compiled two Fortran libs separately. One ARPACK and the other BLAS.
> Since there are some points to be taken care of (one that I am sure of
> is the "_" appended by some compilers to Fortran functions), I wasn't
The underscore would be present in the C / C++ wrapper, right ? Which makes
it OT in almost any NG other than comp.lang.c or comp.lang.c++.
> sure I had taken care of everything. Moreover, there have been instances
> where gcc has exhibited incorrect behavior when it's code is
> optimized(at least till a few years ago, IIRC). For all I know, similar
> things could be possible in g77. Are you willing to go over the
g77 is more like a program that provides the input to gcc which does all the
backend, including optimization. It is well-tested with ARPACK.
> makefiles of each of these libraries that I used and confirm I am on the
> right track?
Most definitely. You may email those to me at <my last name>.<my first name>
reverse(ta) g-m-a-i-l reverse(tod) c-o-m
(I apologize for the email address formatting above, but you know how it is
with spam.)
>> If you used the Makefile included in the library (with the correct
>> settings in ARmakes.inc - it would not even compile correctly if those
>> settings were wrong), that is the wrong place to start looking for bugs.
>
> See above.
As I said, you have to test your C code in some fashion first. You might be
passing the wrong data type to the fortran (see glen's post on this thread)
for all we know.
>> Test what you wrote first (or whatever is the "weakest" in terms of
>> testing). If that is sanity checked by some means, only then start
>> casting the net wider. As a scientist, I am sure you can understand what
>> logical elimination and sound experimental sequence means.
>
> I am not sure if you read my original post carefuly. The C/C++ code is
> not what I wrote. I obtained it from the URL I mentioned. The code, when
Either way, you indicated that it was written a long time ago and does not
seem to be maintained, and I am fairly certain that it is not as
well-tested as the core FORTRAN (its in f77) ARPACK library is.
> it was written, was running correctly. It's expected output is given in
> the comments at the top of one of the files (.c or .h). I only made a
> few minor changes, the changes were only in syntax to get it compiled
> with the new gcc compiler. (If you really want to find out the
> modifications, diff is your friend)
I am really not interested in how you changed the C/C++ code. You are the
expert on that side of things.
If you were trying to call C from Fortran, I could possibly help on the NG,
but that is not what you are doing.
>
> So, given this and the reasoning I gave at the top, either the gcc
> compiler is wrong or the g77 compiler is wrong or my syntax changes are
> wrong or the way I compiled Fortran libs is wrong.
>
> Now, if you are saying that there is *no* way I could have made a
> mistake while compiling Fortran libs, then I am sure the problem is in
> the C code. Of course, this is with the assumption that both compilers
> do not have any bugs.
When compilers have bugs with code as thoroughly tested as ARPACK (which I
have used a lot in the past), the fact tends to get noticed. I have never
come across any reports of g77 misbehaving with ARPACK.
Neither have I ever experienced any such thing myself (period of use
2000-2002).
>
>
>> Further, as you partially realized when you made the post (assuming you
>> tested your C code first), it would be better to first ask if someone was
>> willing to test the code and only then send it to them off group. Posting
>> a bunch of non-Fortran code and irritating people is not the most polite
>> or even conducive way to get them to help you.
>
> This is contradictory to you wrote in one of your earlier posts. So lets
> just not discuss this.
>
You did not read the first sentence of the above paragraph :
"assuming you tested your C code first"
You did not do an independent test of your C program first, did you ? (Like
checking data types, etc.)
>
>> To better understand what I wrote, let me cast the choice in C :
>>
>> If you were writing a piece of code using the GNU C library, and found
>> unexpected behaviour, would you test your program first (and say consult
>> someone on comp.lang.c) or start asking people if your glibc is compiled
>> correctly ? The GNU C library is a widely used and extremely well-tested
>> piece of code. Its the wrong thing to suspect first.
>
> I am not questioning the g77 compiler itself mind it. See above.
You certainly hint it. See above.
>
> Annnyy hoooowww .... originally I had assumed it wouldnt' be too hard
> for anyone who is familiar with programming
> 1. to copy the two files into a directory,
> 2. use the two commands I gave (with proper path to Fortran libs)
> 3. And type "dsaupd" on the command line
> 4. and report if it worked or not.
While such a request might not be out of place on a hypothetical (?)
newsgroup comp.compiling.help.wanted, or even comp.lang.c, it most
definitely is OT on comp.lang.fortran (in case you did not certify that
your C code is flawless and providing the correct inputs to ARPACK). We
could check if a Fortran wrapper was providing the expected inputs to a
glibc (for instance), but really not the reverse.
.
- Follow-Ups:
- References:
- Re: can somebody verify this C program which calls dsaupd_ ? (longish)
- From: Madhusudan Singh
- Re: can somebody verify this C program which calls dsaupd_ ? (longish)
- From: H. S.
- Re: can somebody verify this C program which calls dsaupd_ ? (longish)
- Prev by Date: Re: General complete elliptic integral
- Next by Date: Re: General complete elliptic integral
- Previous by thread: Re: can somebody verify this C program which calls dsaupd_ ? (longish)
- Next by thread: Re: can somebody verify this C program which calls dsaupd_ ? (longish)
- Index(es):
Relevant Pages
|
