Richard Stallman is responsible for the shrinking economy

No, it's not much of a complaint. If you really want exact answers then you should be using an exact arithmetic: integers or rationals. If you're using floating point numbers then it's because you want to go fast and you understand what finite precision means. It's a pity that there aren't many languages that support rationals at the language level, I'll admit. There are some, though.

I don't think that I've ever met a numerical algorithm that used floating point as intended where the complaints levelled here (extra precision in registers breaking == and an lsb or so of precision loss due to multiplication by the reciprocal instead of division by a constant) would break anything at all. -ffast-math is a GOOD thing...

[Completely off topic, I know. Please just ignore this rant.]

Cheers,

--
Andrew

It certainly does not mean GCC. GCC is a very wide and divers set of compilers. Testing one variant has no effect on any other variant

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I didn't know that they were also releasing under the LGPL. I knew they were going to include GPL licensing for their Windows version from 4.5 onwards, but having the LGPL as well is excellent news. This, along with KDE libraries (which have always been LGPL) for Windows, makes QT a very flexible choice for cross-platform development.

This, of course, was my point - and it's definitely a bit odd and of dubious legal status. I can understand Trolltech's reasons for putting it in, but hopefully Nokia will remove the clause at some point.

In effect what you are saying is that bugs in the different variants of gcc are completely independent. I find it somewhat hard to believe given that AFAIK the variants share considerable amounts of code. Testing gcc variants would seem to be akin to product family testing.

--
Pertti

Then the same goes for commercial compilers. Except of course they are tested to a far higher level. Also they share large code.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I don't think this has been in dispute at all.

--
Pertti

What I think you missed is that most commercial compilers share the some code across vendors. I assume you all knew this. So GCC is not more tested than commercial compilers.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

To the contrary, gcc keeps the compiler and the code generator separate. One can be advanced without the other. Thus compiler advances apply equally to all versions (of the same release number).

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

Yes it is in dispute. You can watch (and comment on and influence) the development of the next version of gcc. Not so for most commercial compilers.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

I'll dispute the claim that commercial compilers are tested to a far higher level. They may have larger official test suites, but any test suite is miniscule compared to the amount of real-world code on which a compiler is used.

Test suites aren't particularly good indicators of compiler quality, for many of the same reasons that benchmarks aren't particularly good indicators of the overall quality of a CPU, graphics card, PC or whatever.

Most test suites test one thing at a time. If you look at the release notes for a new compiler to see which bugs have been fixed, most of them correspond to interactions between multiple language features.

A large sample of real-world code will be far more likely to discover such bugs than any test suite. And that's how gcc releases are normally beta-tested: by compiling vast archives (e.g. the gnu.org or Debian FTP archives) with a particular version, then running whatever test suites the individual packages provide. Terabytes of source code written by thousands of different authors with a diverse range of programming styles.

I would guess that Microsoft does the same thing for MSVC, i.e. compiling Windows, Office, et al with each release candidate. But the average commercial compiler vendor simply doesn't have that much code on hand to test against.

Floating-point numbers are rationals. They're only only a subset of the rationals, but so long as a result is within that subset, there's no reason for *any* inaccuracy. 3, 4 and 12 are all exactly representable as floating-point, so there's no reason for 12/3 to produce an inexact result.

There seems to be a pervasive myth that all FP calculations inherently introduce unpredictable errors, as if the bottom few bits are pulled out of /dev/random. In many cases, there shouldn't be any error, and even where there is, it should be entirely predictable.

I've encountered it quite regularly. Mostly where the same code is used for both integers and floats, and -ffast-math causes it to produce incorrect results for integers.

Actually it is very true for commercial compilers.

1 you can have a direct effect of the ISO language 2 you can have a direct input to the writing and support team.

There is no difference.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Here's an article that might be of interest regarding the use of open source software in safety-critical and security-critical software:

(I've started a new branch, because other branches are getting too deep to look nice, and too long to find an appropriate leaf to reply to.)

In message , David Brown writes

As they are a suppler of Open Source and their business is in the Ada market it does make them rather biased doesn't it?

Also I disagree with some of their conclusions.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

As is your view (biased) as a supplier of commercial compilers....

These threads are always very predictable - strong pro open source views and strong anti open source views. I rarely find extreme views to be without flaw in any walk of life.

....in particular: "Suppose Boeing were forced to disclose the software controlling its new 787 'Dreamliner'. Would this suddenly give Airbus a huge advantage? Most likely not" ahh, actually yes it would.

", as you can't just lift the 787 avionics and drop them into an Airbus

350." .... no but you can learn alot from the architecture, control algorithms, models, safety cases etc. etc. All the things that would have cost Boeing millions upon millions to develop an expertise in.

--
Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.

At the risk of sounding pedantic: all FP results are within that subset. Even with reciprocal multiplication. If your algorithm destabilizes when a result is off by one ulp, then your algorithm is flawed (or maladjusted, if you will).

Replacing the bottom bits with output _from_ /dev/random will actually reduce problems in many algorithms.

The problem isn't unpredictability, the problem is that many programmers don't bother to learn the slightest bit of theory behind it.

If you care about correctness, you'd better consider the implications of using -ffast-math.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

In message , FreeRTOS.org writes

So I am told repeatedly in this NG ... :-) That was my point. They are no more neutral than I am in this case because their whole business model and their products rest on it.

Quite so. But usually less extreme out of News Groups. For some reason NG's seem to amplify them.

I agree... and hell would freeze over before they did it for two reasons

1 It would give their competitors a hell of an advantage, for free, on IP they have spent [at least] tens of thousands GBP/Euro/USD developing. 2 It would show their competitors that despite having spent [at least] tens of thousands GTBP/Euro/USD developing new IP that it is not revolutionary despite the press releases and "leaks" that it is earth shattering.

We are talking BUSINESS in the real world not the mechanics of developing SW in utopia. Developing ANY software takes time and resources (which == MONEY). No one give IP or resources away to competitors without a good reason (i.e. an equal or better pay-back)

So why would they want to give this IP to Airbus?

The only reason why the article says all this is because in the cold light of day the more people buying into it the more business Adacore get for their tools and consultancy in the aerospace market.

I have no problem with them or the article but it is no less biased than anything I write.

PS: Richard, having has such a short chat at Nuremberg you me and bigbrownbeastiebigbrownface should meet for a coffee some time. I think all three of us have something to chat about.

BTW NO, Neither Richard or I are bigbrownbeastiebigbrownface but we both know him/her :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I know they are biased - I posted the link for interest, not because I necessarily agree with all of it.

As do I. There is a place for open source software, and a place for closed source software.

Something like the software for avionics would not benefit from being open source (though I think the tools used should be open source - on that point, we must agree to disagree). The developers of the avionics software have nothing to gain, but lots to lose, by making their source freely available. However, their software *should* be clearly and directly available to appropriate authorities and independent groups able to check the correctness of the software. (That might already be the case, I don't know that industry.)

Software for electronic voting machines should be available for inspection for anyone who wants it. It should not necessarily be under an open source license - there should be no requirement that I can download the software and re-use it in other projects, or for building a rival machine. But I should be able to download the source for any voting machine I use, and inspect that source. I should be able to compile it and test it myself, and look for backdoors and flaws. Groups purchasing such machines should be able to compile the source code and compare it to the binary in the machines themselves, to verify that the machines are running the same code (note that this is a different thing from being able to compile and install their own binaries - they should be able to verify the binary, but changing it should be a carefully controlled procedure).

This is a trick isn't it? :-))))

I was thinking more of the development and test procedures. Than simply FOSS or CCSS (Commercial Closed Source Software)

Of course :-)

Lives in some cases. I kid you not.

It is for ALL safety critical SW as some one else has to verify it.

I agree. That is to prove there are no back doors or cheating. Though in the case of the US elections they have more pressing problems on legitimacy.

I agree.

Yes. A good idea in this scenario.

An independent observer should. There are many who would love to be able to get hold of the SW amend it and load it to the machines in their area.

Hanging offence I think to tamper with voting equipment. (At least it should be. )

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/