Warning messages when compiling 'lcalc'
Anne Driver
But looking at lcalc, the code seems particularly poor, with lots of unused variables & deprecated code. It does not exactly inspire confidence in Sage. I don't know how it possible to check code core correctness under such circumstances.
tmp_x is unused. I thought that would be defined in a C or C++ file, not a header file. Lfind_zeros.h It's actually normal practice to have code in C and C++ files, not header files.
Functions are declared to return values, but do not do so. 'missing_data' is unused. Is that since it's not needed, or because the author forget to use it, so the code is unstable?
There are reports of "deprecated or antiquated header which may be removed without further notice at a future date".
Unfortunately, lcalc was the part of Sage I intended using - now I think I will look at other software. Hopefully some high quality open-source software. Parts of the code are quite well commented, but other parts have few if any comments. This has rather put me off.
Anne
William Stein
> When building open-source software, it is not unusual to see a few compiler
> warnings - usually deprecated code. There's quite a lot of them in Sage.
>
> But looking at lcalc, the code seems particularly poor, with lots of unused
> variables & deprecated code. It does not exactly inspire confidence in Sage.
> I don't know how it possible to check code core correctness under such
> circumstances.
The person who wrote Lcalc is easily the world leader in algorithms
for numerical
computation of zeros of L-series of all types, and has done vastly
more along these
lines than anybody else. I would greatly prefer code with unused variables
from a person that understands the relevant mathematics, than the
other way around.
> tmp_x is unused. I thought that would be defined in a C or C++ file, not a
> header file. Lfind_zeros.h It's actually normal practice to have code in C
> and C++ files, not header files.
>
> Functions are declared to return values, but do not do so. 'missing_data' is
> unused. Is that since it's not needed, or because the author forget to use
> it, so the code is unstable?
Maybe you should ask the author...
> There are reports of "deprecated or antiquated header which may be removed
> without further notice at a future date".
>
> Unfortunately, lcalc was the part of Sage I intended using - now I think I
> will look at other software. Hopefully some high quality open-source
> software. Parts of the code are quite well commented, but other parts have
> few if any comments. This has rather put me off.
Good luck.
-- William
>
> Anne
>
> --
> To post to this group, send email to sage-s...@googlegroups.com
> To unsubscribe from this group, send email to
> sage-support...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-support
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Michael Rubinstein
The antiquated header files and unused variables have been removed in L-1.3,
which has not yet been released to the public. It should be released in the
next couple of weeks.
Best,
Mike
Dr. David Kirkby
>
> The antiquated header files and unused variables have been removed in
> L-1.3,
> which has not yet been released to the public. It should be released in the
> next couple of weeks.
>
> Best,
> Mike
It would be good if you could remove that option from your makefile that adds
-Wa,-W to CFLAGS and/or CXXFLAGS in an attempt to suppress warnings from the
assembler.
Passing -W directly to the assembler causes an error with Sun assembler and
probably most non-GNU assemblers.
kirkby@t2:[~] $ gcc test.c
kirkby@t2:[~] $ gcc -Wa,-W test.c
/usr/ccs/bin/as: error: unknown option 'W'
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF]
[-m32] [-m64]
[-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis,
sparcvis2,sparcfmaf,sparcima}]
[-xcode={pic13,pic32}] file.s...
As such, your source code would not build on Solaris when the Sun assembler is
used, which is the recommended way to configure gcc on SPARC processors.
I've got no idea if your code is computationally intensive or not, but if it is,
then it would be good if it could build with the Sun C compiler
(/opt/SUNWspro/bin/cc on t2) and/or C++ compiler (/opt/SUNWspro/bin/CC on 't2').
The Sun compilers are more fussy than gcc, so will reject code that has GNUisms.
Dave
Anne Driver
Any serious attempt to check source code would include in a thorough check of what variables are used, their types, what they are used for, how they are used, what (if any) values they are initialized to. That would be true whether you were looking at your own code or that written by someone else.
I can not possibly see how an author can check his/her code properly unless they have done that. Doing that, one would soon realize these problems.
Neither can I understand how mathematical software than needs to be compiled by an end-user can be taken seriously unless there is a test suite. Lcalc lacks one.
When someone can't be bothered to check their code, then why should I believe they have taken due care to implement the mathematics properly? They may be the best mathematician in the world, but I personally would not trust their ability to write high quality software.
Of course, any non-trivial program is likely to have bugs, but the frequency of bugs could be reduced by careful testing - something that has clearly not been done in lcalc.
I can see some of the source code from Mathematica in the form of .m files. The care that has been taken in writing them is clearly more than the care which was taken in writing lcalc.
In principle with open-source code, it is possible for a user to check the code themselves. In practice, that is not likely to be the case, for all except the smallest of sections, especially when the code is poorly commented.
I do not fully trust any program, but my confidence in Sage is decreasing as I look at code like lcalc and see some of the comments on public mailing lists.
It's a shame, as I like using Sage, but after looking at some of the source code, in particular that of lcalc, my enthusiasm has decreased markedly. lcalc just happened to be the part that interested me, which is why I have looked at that in greater depth.
Anne.