Another computer algebra system : smib
pbillet
This is a computer algebra system for linux based on eigenmath (of George Weigt).
It handles :
- arithmetic (factorization, combinatorial, arithmetic functions, Dirichlet product)
- algebra (matrices, tensors, polynomials)
- analysis (functions, derivation, integration, Fourier transform)
- numerical analysis (numerical integration, sample manipulation, discrete Fourier transform)
smib is available at sourceforge.net
The documentation is still in french ...
If you enjoy you can send me a mail, if you don't ...
Dave
I'm somewhat puzzled why there is a need for something which I assume is
less capable than other larger systems.
I guess if you want to put it on a mobile phone or similar, there is a
point to it. But otherwise, why would I use 'smib'.
LINAP (Large is not a problem) seems to me to be more appropriate now.
Disks are big, so there is not really much advantage in making a system
less capable than others.
--
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange' take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.
Chip Eastham
> pbillet wrote:
> > smib means "Small is beautiful" (size of sources is less than 500ko).
> > This is a computer algebra system for linux based on eigenmath (of George Weigt).
> > It handles :
> > - arithmetic (factorization, combinatorial, arithmetic functions, Dirichlet product)
> > - algebra (matrices, tensors, polynomials)
> > - analysis (functions, derivation, integration, Fourier transform)
> > - numerical analysis (numerical integration, sample manipulation, discrete Fourier transform)
>
> > smib is available at sourceforge.net
>
> > The documentation is still in french ...
>
> > If you enjoy you can send me a mail, if you don't ...
>
> I'm somewhat puzzled why there is a need for something which I assume is
> less capable than other larger systems.
>
> I guess if you want to put it on a mobile phone or similar, there is a
> point to it. But otherwise, why would I use 'smib'.
Not to speak for the OP, but...
My thought was the learning curve might not
be as great for something with more modest
goals, and it might be more attractive for
customization than a more feature-complete
platform. According to sourceforge.net the
author placed at least this early version
of the software in the public domain.
regards, chip
Dave
I note your web page says this is linux.
Have you ever thought of testing it on Solaris? I could give you access
to a personal Solaris box of mine, which has a slow connection. I
*might* even be able to get you access on a larger (16 core) T5240
Solaris machine.
Would that interest you, or are you happy with only working on linux?
Stick an email address here in some disguised manner if you want, and
I'll contact you by private email.
Dave
Dave
Certainly the learning curve on the big maths package is steep. But I
can't see the point of devoting time learning a package which is too
limited, so you then have to spend time learning another.
It is probably more useful as a teaching aid, as its easier to
understand a couple of thousand lines of code than it is a few million
lines of code.
Sage
is free and open-source and undoubtedly does a lot more. It's not small
like smib - the compressed source code for Sage is over 200 MB.
Chip Eastham
> Certainly the learning curve on the big maths
> package is steep. But I can't see the point of
> devoting time learning a package which is too
> limited, so you then have to spend time
> learning another.
I find learning to be pretty much endless
regardless of choice of package.
> It is probably more useful as a teaching aid,
> as its easier to understand a couple of
> thousand lines of code than it is a few
> million lines of code.
Easier to understand, easier to maintain.
> Sage
>
> http://www.sagemath.org/
>
> is free and open-source and undoubtedly
> does a lot more. It's not small like smib
> - the compressed source code for Sage is
> over 200 MB.
Sage is a synthesis of some 72 open source
packages (about half a dozen of which like
Maxima and Pari/GP are CAS-type packages),
using Python, an open source scripting
language, to tie things together.
http://www.sagemath.org/links-components.html
Perhaps Sage illustrates the benefit of
building larger systems from smaller,
more elucidated components.
regards, chip
Richard Fateman
>
>> It is probably more useful as a teaching aid,
>> as its easier to understand a couple of
>> thousand lines of code than it is a few
>> million lines of code.
>
> Easier to understand, easier to maintain.
A piper cub airplane is easier to understand and easier to maintain than
a Boeing 747. Which would you rather use? (for what purpose...)
If you want to look at a teaching aid, there are several books that
discuss the writing of computer algebraic manipulation programs,..
differentiation, simplification, integration, parsers,
displays, etc.
Reading the source code of a small system might be useful AFTER
looking at material that is explicitly tutorial in nature. But
that kind of assumes that smib is an exemplar of
good practice, and not just some hack job. I have no knowledge
of smib except the previous messages in this thread.
I have the same reservations about recommending the reading of source
code of Sage as a teaching aid. I have not read any Sage python source
code.
Raphael Jolly
raphael@debian:~/projects/smib-0.8/sources$ make
raphael@debian:~/projects/smib-0.8/sources$ ./smib
**********************************
* Welcome to SMall Is Beautiful *
**********************************
> print(2+2)
Illegal instruction
raphael@debian:~/projects/smib-0.8/sources$ uname -a
Linux debian 2.6.26 #1 SMP Wed Jul 29 13:26:03 CEST 2009 i686 GNU/Linux
Raphael
pbillet
Hello,
I'm sorry but on my computer :
**********************************
* Welcome to SMall Is Beautiful *
**********************************
> print(2+2)
4
>
I would help you, but you don't give me a lot of informations.
Regards.
Philippe
Jay Belanger
pbillet <philipp...@noos.fr> writes:
..
>> raphael@debian:~/projects/smib-0.8/sources$ make
>> raphael@debian:~/projects/smib-0.8/sources$ ./smib
>> **********************************
>> * Welcome to SMall Is Beautiful *
>> **********************************
>> > print(2+2)
>> Illegal instruction
..
> I'm sorry but on my computer :
> **********************************
> * Welcome to SMall Is Beautiful *
> **********************************
>> print(2+2)
> 4
On my computer, running Ubuntu 8.04, it also works.
**********************************
* Welcome to SMall Is Beautiful *
**********************************
> print(2+2)
4
Jay
Dave
>
>>
>>> It is probably more useful as a teaching aid,
>>> as its easier to understand a couple of
>>> thousand lines of code than it is a few
>>> million lines of code.
>>
>> Easier to understand, easier to maintain.
>
>
> A piper cub airplane is easier to understand and easier to maintain than
> a Boeing 747. Which would you rather use? (for what purpose...)
>
> If you want to look at a teaching aid, there are several books that
> discuss the writing of computer algebraic manipulation programs,..
> differentiation, simplification, integration, parsers,
> displays, etc.
>
> Reading the source code of a small system might be useful AFTER
> looking at material that is explicitly tutorial in nature. But
> that kind of assumes that smib is an exemplar of
> good practice, and not just some hack job. I have no knowledge
> of smib except the previous messages in this thread.
I do not know if you ever see it, but there was a very good book written
by Andrew Tanenbau about Unix, which contained the full source code of a
small unix operating system called Minix (mini Unix). I personally had
think Tanenbau's license been less restrictive, minix would have 'taken
off', and linux would not have existed.
I think a similar book about a CAS would be useful as a teaching aid.
(Not that personally I have much interest in the internal workings of a
CAS.)
> I have the same reservations about recommending the reading of source
> code of Sage as a teaching aid. I have not read any Sage python source
> code.
I don't agree. There are several examples of bad programming style,
which would probably be good stuff for a computer science course!
I don't have the technical expertese to say how useful Sage's source
code is for learning about computer algebra systems.
I would say to the original poster, the best way to make your code more
robust is to test it on other systems. Clearly someone has pointed out
it mis-behaves on his machine. I have offered you access to Sun hardware
running Solaris if you want to test on Solaris.
From my own personal experience, testing code on multiple platforms
shows up lots of bugs. Sage builds on Solaris with gcc, but not the Sun
compiler. In attempting to build Sage with Sun's compiler, I have
uncovered all sorts of problems, which do not show up with gcc. A
partial list is here.
http://sagetrac.org/sage_trac/ticket/7056
pbillet
Dave you offer me a connection to a Solaris machine to test smib, I haven't a lot a time to play with many OSes.
As you use it, you can tell me if it works or not.
Thank you for your answer.
Philippe.
pbillet
Hello Raphael,
As I already said, it works for me. I just test it on an EEEPC with EEEbuntu.
I use the following parameters :
philippe@eeepc:~/Documents/smib-0.8/sources$ uname -a
Linux eeepc 2.6.29-1-netbook #0array1 SMP Mon Feb 23 15:02:03 MST 2009 i686 GNU/Linux
philippe@eeepc:~/Documents/smib-0.8/sources$ gcc -v
Utilisation des specs internes.
Target: i486-linux-gnu
Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Modèle de thread: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
philippe@eeepc:~/Documents/smib-0.8/sources$ g++ -v
Utilisation des specs internes.
Target: i486-linux-gnu
Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Modèle de thread: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
Maybe you can modify Makefile :
tag this line :
CXXFLAGS = -Wall -Wuninitialized -O -DLINUX -g -mfpmath=sse -msse2 -funroll-loops
Untag this one :
#CXXFLAGS = -Wall -Wuninitialized -O -DLINUX -g
You can send me mail (my mail is in the documentation).
I hope it helps you.
Regards,
Philippe.
Richard Fateman
.
>
> I would say to the original poster, the best way to make your code more
> robust is to test it on other systems.
I think that this notion of "robust" is questionable. Making a program
run very very well on a common configuration of hardware and software
strikes me as far more valuable than trying to water it down so it runs
on many different hardware and software configurations.
The failures of code in one or more of the multiple Sage environments
merely illustrates how poorly the notion of "machine independence" is
supported by the C specification, current C compilers, and whatever else
you need. (Does Python break this way too?)
I suspect that most of the bugs you find in these porting efforts have
nothing to do with computer algebra system algorithms or the libraries
that other people have written; fixing the bugs is, I suspect, a
distraction from the building of a good system on one platform. And
certainly not much of a "learning experience" unless your idea is that
learning computer algebra has to do with fiddling with optimization
settings on C compilers.
RJF
D Herring
Not necessarily so. Older compilers often accept significant errors
that trigger errors on newer compilers. Switching from one CPU
architecture to another often exposes uninitialized memory, latent
race conditions, etc.
Just today, such a port (by me of another company's system) exposed a
few functions being called with the default C prototype (headers not
included) and a couple enumerated variables being filled with values
from a different enumeration.
There are times when porting causes me to groan (usually to an ancient
solaris box); but its generally not too hard, and the code often
benefits from the added attention.
- Daniel
Richard Fateman
> Richard Fateman wrote:
>> Dave wrote:
>> (RJF) And certainly not much of a "learning experience" unless
>> your idea is that learning computer algebra has to do with fiddling
>> with optimization settings on C compilers.
>
> Not necessarily so. Older compilers often accept significant errors
> that trigger errors on newer compilers. Switching from one CPU
> architecture to another often exposes uninitialized memory, latent race
> conditions, etc.
If a program runs very very well on a platform, then the uninitialized
memory is insignificant on that platform (maybe initialized by the OS?
or irrelevant to the algorithm). Identifying or debugging this, nice as
it might be, is not high on my list of computer algebra algorithms.
>
> Just today, such a port (by me of another company's system) exposed a
> few functions being called with the default C prototype (headers not
> included) and a couple enumerated variables being filled with values
> from a different enumeration.
Again, the vagaries of C compilers adhering(or not) to different
standards is not a computer algebra problem. It is a problem caused, in
part, by using a language poorly suited to writing reliable code. It can
be remedied in several ways, none of which have to do with computer
algebra. (e.g. not using C!)
>
> There are times when porting causes me to groan (usually to an ancient
> solaris box); but its generally not too hard, and the code often
> benefits from the added attention.
If you think that being an expert in C minutia is part and parcel of
writing computer algebra programs, then this all fits together. I think
that writing computer algebra programs directly in C is a mistake. Even
writing in "Objective C" or "C++" does not get you to a much better
place. I would rather have my students learn about computer algebra.
The computer algebra system Reduce benefited from being written in a
standard language (PSL, a simplified Lisp), and then Reduce ports became
easy. PSL was implemented on a large number of different platforms,
including a microcoded version. Another Lisp, Franz Lisp, was
implemented on VAX and many Motorola 68000-based systems, also IBM 370
etc. Ports of computer algebra algorithms (Macsyma) were relatively
easy in Franz -- because the diddling with C compilers (etc) were viewed
as separable (and separated) tasks.
While it may be "educational" in some hackish concept of "education is
knowing the difference between two C compilers, brand X version x.xx and
brand Y version y.yy on OS version Z on hardware W", I contend that the
task of porting of (parts of) Sage to new hardware or software offers
little of (educational) value in terms of computer algebra algorithms.
RJF
PS. I am not saying quality "help-desk jockeys" are unimportant. Just
that I would rather not confuse them with computer algebra experts.
pbillet
I never thought that smib produced so much effects.
I work with IBM computer on Z/OS, COBOL, DB2, etc.
smib is just a hobby, I do it just for pleasure (something like fishing without fish ...).
Mr. Fateman, I must confess that TILU is a great source of inspiration for me. George Weigt uses a similar concept in Eigenmath for integration, I use it to compute Fourier transform.
Best regards.
Philippe Billet.
P.S. : sorry for my awful english ...
David Kirkby
> Dave wrote:
>
> .
>
>
>
> > I would say to the original poster, the best way to make your code more
> > robust is to test it on other systems.
>
> I think that this notion of "robust" is questionable. Making a program
> run very very well on a common configuration of hardware and software
> strikes me as far more valuable than trying to water it down so it runs
> on many different hardware and software configurations.
I'm not suggesting 'watering anything down'
> The failures of code in one or more of the multiple Sage environments
> merely illustrates how poorly the notion of "machine independence" is
> supported by the C specification, current C compilers, and whatever else
> you need. (Does Python break this way too?)
You have a total mis-understanding of the issues.
Most of the problems are due to things like
* Not all compilers are called by the same name, like not all people
are called by the same name. But some people think that if thy want to
compile a program, they use 'gcc'. Not realising that not all
compilers are called 'gcc'.
* There is no standard for command line switches, like there are no
standard for the location of switches in your car. But some people
think that if they use a particular switch, it will work on every
compiler. They do not.
* GCC does not enforce the C standards well. It has tons of its own
extensions, so people do not look at the standard, but write what
their compiler accepts. Sun's compiler is a lot stricter than gcc, so
will often not accept code that gcc will. As such, testing on Sun's
compiler will cause people to write better C code.
* People write code, which their compiler generates warning messages.
They do not like them, so they direct them to /dev/null. On another
compiler, those problems are not warnings, but errors so the program
will not build.
* gcc versions greater than 4.2.1 caused a lot of test failures of
the maths library mpfr on Solaris on a Sun T5240. My initial guess was
this was a gcc bug. Testing on my own Sun though, and older machine,
found no such bug. Eventually the bug was traced to a library in
Solaris which only affected machines based on the T1, T2 or T2+
processors.
> I suspect that most of the bugs you find in these porting efforts have
> nothing to do with computer algebra system algorithms or the libraries
> that other people have written; fixing the bugs is, I suspect, a
> distraction from the building of a good system on one platform. And
> certainly not much of a "learning experience" unless your idea is that
> learning computer algebra has to do with fiddling with optimization
> settings on C compilers.
>
> RJF
I've never seen anyone claim to have written a bug-free non-triial
program. Hence any large system (Sage, Mathematica, etc etc) will have
bugs. Sometimes bugs which can show up on one platform, do not on
another, but can come back to haunt you.
I can give you a few specific examples.
* A colleage of mine wrote some finite element software on a dual
processor linux machine. I then got a quad processor Sun, and he found
it would mis-behave. When he found the bug, he realised it was a
genuine bugs, which had simply not shown up on his machine, but did on
mine.
* I wrote some multi-threded code, which worked fine on my SPARC, an
HP box running HP-UX but would periodically crash on AIX. I eventually
traced the problem, and the fact it was only seen on AIX was more luck
than judgement. It could well have been triggered on any opperating
system.
* Related to computer algebra systems, Wolfram Reserach shipped
Mathematica for Solaris and no doubt tested it on modern hardware. On
older hardware it pegged the CPU after computing as something as
simple as 1+1
http://www.g8wrb.org/mathematica/
IMHO, testing code on a variety of operating systems, on a variety of
hardware often shows up bugs.
Systems with multiple processors often show up bugs that single
processor systems do not. With time, more and more machines will have
multiple processors or cores.
I'm always concerned about code where there are a lot of compiler
warnings. It shows an attention to lack of detail. I suspect if they
are lax about compilers generating warnings, they are probably lax
about the algorithms.
The author of this program has declined my offer of testing on
Solaris, but suggests I can test it for him. I don't time to test it
thoroughly, he does not have time to try to build it on Solaris. If he
does not have time to test it on Solaris, then I suspect he does not
have time to test it mathematically very well. Of course, he could
have spent a years man-time testing the maths of it, but I personally
become suspicious in cases like this.
Dave
Richard Fateman
>
>> (RJF) The failures of code in one or more of the multiple Sage environments
>> merely illustrates how poorly the notion of "machine independence" is
>> supported by the C specification, current C compilers, and whatever else
>> you need. (Does Python break this way too?)
>
> You have a total mis-understanding of the issues.
>
> Most of the problems are due to things like
<snip>
... a list of problems caused by failures of compilers, or programmers
to abide by some consistent specification.
Seems like just what I said, and not a mis-understanding at all.
....
>
> I can give you a few specific examples.
>
> * A colleage of mine wrote some finite element software on a dual
> processor linux machine. I then got a quad processor Sun, and he found
> it would mis-behave. When he found the bug, he realised it was a
> genuine bugs, which had simply not shown up on his machine, but did on
> mine.
Certainly sometimes a bug is discovered only after a program is ported
to a new environment -- a bug that existed in the old environment too,
but just had not been exercised. Spending time porting a program is
worthwhile if you want the program to run on other machines. Is it the
way you should spend your time if you want to learn about computer
algebra programs, or if you want to debug them? I think there are better
ways of spending time.
>
>
> IMHO, testing code on a variety of operating systems, on a variety of
> hardware often shows up bugs.
Yes, principally bugs in compilers, operating systems, and (more often)
programmers' understanding of compilers, operating systems, parallelism,
etc.
>
> Systems with multiple processors often show up bugs that single
> processor systems do not. With time, more and more machines will have
> multiple processors or cores.
I think that using the now commercially common multiple processors is a
challenge for implementers of compilers, operating systems, and indeed
computer algebra systems. Getting a CAS working well on a particular
(one hopes, common) multiple-processor machine would be worthwhile.
Debugging it for each and every one? Unlikely to be as worthwhile.
In the mid 1980s there were a host of multiple-processor machines,
typically motorola 68020s with a shared memory bus, but also processors
from MIPS. And a history of multiple-processor systems from SUN, etc.
Some ran Lisp, Macsyma, Maple, etc. Also, there is a history of
research on parallel computer algebra (search on Google Scholar).
Such research does not consist of porting program X to many different
implementations of multi-core machine OS/compiler/etc by diddling with
compiler flags.
<snip>
... Your speculation about someone who doesn't share your view about the
value/importance of porting his program to Solaris ... is that such
a programmer must be guilty of various inadequacies. Like lax testing etc.
I don't know enough about the specifics, but disagree with your view,
and see no reason to believe this person's code is inadequately tested
if it runs really robustly on the machine for which it was programmed.
RJF
Raphael Jolly
> Raphael Jolly wrote:
>> raphael@debian:~/projects/smib-0.8/sources$ make
>> raphael@debian:~/projects/smib-0.8/sources$ ./smib
>> **********************************
>> * Welcome to SMall Is Beautiful *
>> **********************************
>> > print(2+2)
>> Illegal instruction
>> raphael@debian:~/projects/smib-0.8/sources$ uname -a
>> Linux debian 2.6.26 #1 SMP Wed Jul 29 13:26:03 CEST
>> 2009 i686 GNU/Linux
>>
>> Raphael
>
> Hello Raphael,
>
> As I already said, it works for me. I just test it on an EEEPC with EEEbuntu.
> Maybe you can modify Makefile :
> tag this line :
> CXXFLAGS = -Wall -Wuninitialized -O -DLINUX -g -mfpmath=sse -msse2 -funroll-loops
>
> Untag this one :
> #CXXFLAGS = -Wall -Wuninitialized -O -DLINUX -g
The problem was that my computer doesn't have the sse2 instruction set.
The "configure" scheme in unix is designed to deal with such issues, I
suggest you use it to create the Makefile.
Raphael
Dave
>> * A colleage of mine wrote some finite element software on a dual
>> processor linux machine. I then got a quad processor Sun, and he found
>> it would mis-behave. When he found the bug, he realised it was a
>> genuine bugs, which had simply not shown up on his machine, but did on
>> mine.
>
> Certainly sometimes a bug is discovered only after a program is ported
> to a new environment -- a bug that existed in the old environment too,
> but just had not been exercised. Spending time porting a program is
> worthwhile if you want the program to run on other machines. Is it the
> way you should spend your time if you want to learn about computer
> algebra programs, or if you want to debug them? I think there are better
> ways of spending time.
To be honest, if code has no GUI, and I get the feeling this program is
a command line tool, then it should need no porting really.
> I think that using the now commercially common multiple processors is a
> challenge for implementers of compilers, operating systems, and indeed
> computer algebra systems. Getting a CAS working well on a particular
> (one hopes, common) multiple-processor machine would be worthwhile.
> Debugging it for each and every one? Unlikely to be as worthwhile.
If the code is a command line drive program (like for example the
kernel), then there should be few differences between for platform A and
code for platform B. If one uses portable thread libraries, then if code
breaks on platform B, but not on A, I would certainly think it is worth
while spending time on platform B to find the problem, as it is highly
likely to be a logical error in the program.
If you are writing in assembly code, then that is a different issue.
Years ago it seemed the norm to write in assembler, but I don't see much
of it now. Machines have got much faster, so there is less need for it.
> In the mid 1980s there were a host of multiple-processor machines,
> typically motorola 68020s with a shared memory bus, but also processors
> from MIPS. And a history of multiple-processor systems from SUN, etc.
> Some ran Lisp, Macsyma, Maple, etc. Also, there is a history of
> research on parallel computer algebra (search on Google Scholar).
> Such research does not consist of porting program X to many different
> implementations of multi-core machine OS/compiler/etc by diddling with
> compiler flags.
> <snip>
> ... Your speculation about someone who doesn't share your view about the
> value/importance of porting his program to Solaris ... is that such
> a programmer must be guilty of various inadequacies. Like lax testing etc.
No, it was his view that he did not have time to test it.
> I don't know enough about the specifics, but disagree with your view,
> and see no reason to believe this person's code is inadequately tested
> if it runs really robustly on the machine for which it was programmed.
It's been my experience that people who pay attention to detail, tend to
write portable code.
Anyway, to take a look at the specifics of this package, I looked at the
Makefile and read:
# 2. Compile it. (For Power PC and other big endian machines,
# first add -DMAC to CFLAGS below.)
#
# $ cd smib
# $ make
Now my machine it big-endian, but I hit the problem there is no CFLAGS
in the Makefile, other than in the comment.
This is however CXXFLAGS, so lets add it to there.
drkirkby@swan:[~/smib/smib-0.8/sources] $ make
/usr/local/gcc-4.4.1-sun-linker/bin/g++ -Wall -Wuninitialized -O -DLINUX
-g -mfpmath=sse -msse2 -funroll-loops -DMAC -c -o madd.o madd.cpp
cc1plus: error: unrecognized command line option "-mfpmath=sse"
cc1plus: error: unrecognized command line option "-msse2"
make: *** [madd.o] Error 1
Lets go back to the makefile, and I see two lines. Lets take a guess and
and see if the one without -msse2 and -DLINUX works, since this machine
ie neither linux or has mme2 instructions.
CXXFLAGS = -Wall -Wuninitialized -O -DLINUX -g -mfpmath=sse -msse2
-funroll-loops -DMAC
#CXXFLAGS = -Wall -Wuninitialized -O -DLINUX -g
After 1615 warnings from the g++ 4.0.1 (GNU C++ compiler), it did build
and run on Solaris.
The fact this is new code, I would not release it with over 1600
warnings messages from the compiler.
With a couple of changes:
CXXFLAGS = -O -g -DMAC -m64
smib : $(objects)
$(CXX) -m64 -o smib $(objects) -lm
I manged to build a 64-bit version with Sun's compiler, but I could not
build a workable 64-bit version with the GNU compiler.
Dave
> After 1615 warnings from the g++ 4.0.1 (GNU C++ compiler), it did build
> and run on Solaris.
Correction,
This was g++ 4.4.1 which gave 1615 warnings, not g++ 4.0.1.
The Sun compiler C++ gave tons of warnings too.
Dave
pbillet
The origin of those warnings is new versions of g++, when I began this small project, compiler didn't produced warning, now I have 1615 warnings (thank you for counting). As warnings doesn't prevent from smib working ...
How many warnings during Windows or Solaris compilation ?
Sincerely yours,
Philippe.
Dave
It's not hard to count them - grep's -c option is your friend, or you
would use 'wc'
> How many warnings during Windows or Solaris compilation ?
Not tried on Windows, but well over 1000 on Sun's compiler too.
> Sincerely yours,
>
> Philippe.
pbillet
A new version of smib is born !
What is new :
- a batch mode : put an input-file, smib gives you an output-file, it is very practice for plotting with qgfe,
- cooking pi in ten lessons,
- new documentation (still in french),
- some bug corrections.
And always a lot of warnings during compilation.
*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*
Bonjour,
Une nouvelle version de smib vient d'apparaitre.
Les nouveautés :
- mode de traitement par lot (batch) : on met un fichier en entrée, on obtient un fichier en sortie : pratique pour produire des fichiers à injecter dans gnuplot (via qgfe),
- 10 recettes pour calculer pi,
- nouvelle documentation,
- corrections de bugs.
Et toujours autant de warnings de compilation.
Brzy na shledanou !