Re: Another computer algebra system : smib

David Kirkby wrote:


(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
.

Relevant Pages

  • Re: Article in Scientific American
    ... I.e., without an algorithm to ... proof-checker produces is not merely proof of the validity ... The point was only that using different operating systems or different ... compilers will tend to mitigate the possibility of compiler or operating ...
    (sci.math)
  • Re: Bug in latest IAR MSP430 compiler optimization???
    ... It has been assigned bug id EW20095, and it will be fixed in the ... of Plum-Hall or Perennial plus several sets of in house test suites for ... IAR use an industry standard test suite like this and FOUR other extensive test systems they do edit. ... Compared to many other compilers IAR are very good at testing compilers and fixing any bugs. ...
    (comp.arch.embedded)
  • Re: Global Variables : Where are they stored ?
    ... computers work, how operating systems typically work, and the ... So experiences with endianess and alignment are also ... We don't want fancy language features so that we can ... I am not sure if any of the compilers we use are ...
    (comp.lang.c)
  • Re: Warning to newbies
    ... You don't understand that the worst bug is the one you don't know ... several compilers to hand, and without testing the code on each, is ... being in the same comparison as you, and I don't suppose Seebs is either. ... the start of the partial match. ...
    (comp.lang.c)
  • Re: Opinions on PGI vs. Lahey Fortran
    ... >> it hit a segmentation violation or other similarly fatal error. ... > that kind of problem is common with many compilers. ... > ideal behavior, but not a bug. ... > such as changing the value of i inside of the loop). ...
    (comp.lang.fortran)