In the cast of the boost-interval library, the link I posted has a very clear warning about that; so I don't understand why that quote is relevant here. This warning shows that "floating point is hard" and that is MORE reason to be careful with your intervals!

Warning! Guaranteed interval arithmetic for native floating-point format is not supported on every combination of processor, operating system, and compiler. This is a list of systems known to work correctly when using interval and interval with basic arithmetic operators.

x86-like hardware is supported by the library with GCC, Visual C++ 7.1, Intel compiler ( 8 on Windows), CodeWarrior ( 9), as long as the traditional x87 floating-point unit is used for floating-point computations (no -mfpmath=sse2 support).
Sparc hardware is supported with GCC and Sun compiler.
PowerPC hardware is supported with GCC and CodeWarrior, when floating-point computations are not done with the Altivec unit.
Alpha hardware is supported with GCC, except maybe for the square root. The options -mfp-rounding-mode=d -mieee have to be used.
The previous list is not exhaustive. And even if a system does not provide guaranteed computations for hardware floating-point types, the interval library is still usable with user-defined types and for doing box arithmetic.

Good points - in fact in this case one can say that ALL of the calculations done by the different computer architectures are in fact wrong. to varying degrees When doing floating point math without rounding analysis being done then all bets are off. Measurements always have accuracies, and floating point math also adds it's own inaccuracies.

The Boost library can help: http://www.boost.org/doc/libs/1_54_0/libs/numeric/interval/doc/interval.htm

Of course all this extra interval management costs in terms of development and performance. But what is the cost of having supercomputers coming up with answers with unknown accuracy?

Please see http://www.eetimes.com/document.asp?doc_id=1280095 for more information on interesting developments with regards to automotive usages of Audio Video Bridging in Infotainment and control - http://avb.statusbar.com/faq.html - typically using Linux.

Pardon my ignorance but.... Isn't there a law against Snowden exercising his free speech rights to disclose what he learned about the NSA?

:-(

Yes, you are right.

Until RFC3514 is updated for IPv6, we can't expect IPv6 to gain full acceptance simply because of the lack of the E bit.

What is the problem here? Why couldn't the web browser just make sure that the cookies are passed via RFC3514 ( http://www.ietf.org/rfc/rfc3514.txt ) compliant packets (with the E bit field set to FALSE) if the advertiser is trustable?

I have a 20 meg MFM hard drive that is not readable by any computer anymore... just because of the interface.

He either outright knowingly lied before, or is incompetent. Not much intelligence there....

Wow! Thank you for that fix!

That event could have been a whole lot worse!

They haven't said which image bank they used. It doesn't matter how they got ahold of stolen material, right? The photographers need to sue the infringing party. The infringing party can then sue the image bank or the employee or whoever was responsible.

Why are people assuming that the BATF's concern is safety, or criminals?

Perhaps their primary concern is the market for firearms.

Currently, 3D printed firearms will not impact the sales of real firearms.

Also, the Xilinx FPGA design tools are only officially supported on RHEL. While I run Xilinx tools (and Impact JTAG programmer) with patched drivers, if I ever run into a problem they would look at the log file and refuse to help if they see that I am not running the supported RHEL.

No, really, it is Steve Job's fault - personally - that since the devices are loved so much by users, the re-sale black market price is high allowing big profits for people who steal them. If ONLY Steve Job made the products lousy, no one would pay for them! and no one would steal them!

Uh.... I wonder if the criminals DON'T steal the Android phones?

Criminal: "Give me your iPhone!"

Geek: "I have an Android phone!"

Criminal: "Darn, ok you can keep your Android."

???

For me, with GCC 4.7.2, the -ftree-vectorize fails miserably compared to GCC 4.3 for code that is already prepared for SSE or NEON vectorization.

Good points. So the issue is really with the GPL license enforceability....

I wonder if the same issues are at hand with GCCXML : http://www.gccxml.org/HTML/Index.html

One could make a library that just spawns a sub-process running GCCXML, then grab the result and pass the appropriate parts of the parse tree to the caller.

No linking involved, no GPL violations either.