From: Walter Roberson <>
Organization: Canada Eat The Cookie Foundation
User-Agent: Thunderbird (Windows/20081209)
MIME-Version: 1.0
Newsgroups: comp.soft-sys.matlab
Subject: Re: Very weird resolution issue. Bug ????? Seriously !!
References: <goju5b$nv4$> <> <gonnuu$krq$> <TASrl.72499$uG1.3742@newsfe16.iad> <gopada$bj8$> <Ajisl.2485$eT1.312@newsfe20.iad> <gou61a$goe$> <gp3qf0$2pf$> <gp3tt1$kl7$> <gp45io$3av$>
In-Reply-To: <gp45io$3av$>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Lines: 69
Message-ID: <ZSxtl.14619$3S3.7390@newsfe22.iad>
X-Trace: newsfe22.iad 1236707897 (Tue, 10 Mar 2009 17:58:17 UTC)
NNTP-Posting-Date: Tue, 10 Mar 2009 17:58:17 UTC
Date: Tue, 10 Mar 2009 12:58:22 -0500
Xref: comp.soft-sys.matlab:523823

Sung Soo Kim wrote:
> I didn't know that 10byte FP is actually IEEE standard, which makes me happier. :)

Note that that it is optional within that standard: the standards says that if
you implement it at all (and want to claim conformance to the standard), do
it such and such a way, but it doesn't require that hardware implement it.

Another part of the IEEE 754 standard that was added in the second half of 2008
was decimal arithmetic. My understanding is that IBM has a working implementation,
though I do not recall which model line.

So... what is specified by a programming language standard might be considerably
more lax than is specified by a particular arithmetic standard. If you are lucky,
the programming language standard does not actively prohibit the arithmetic
standard from being used to its full extent, but general purpose programming
languages intended to be used on multiple architectures are usually deliberately
a bit vague on arithmetic details, not wanting to lock themselves out of
being implemented for a reasonable market, and not wanting to lock themselves
out of being implemented in some future technology where some constraints that
seem like good ideas now "for reproducibility" might later prove to be a
technical burden.

And then we have the side issue that there *is* no programming language
standard for Matlab. Matlab is defined by how it actually operates, rather
than by some written specification. If there is a difference between how 
Matlab actually operates and how it is -documented- to operate, 
sometimes the operation is changed to match the documentation and sometimes
the documentation is changed to match the operation. Which, in the longer
view is probably how it should be, in that studies (over several programming
languages) have shown that automatic generation of code from specifications 
does NOT produce bug-free code because it turns out that specifications
(having been written by humans) have bugs. (If you have a specification
notation that is sufficiently powerful to express large complex programs,
then the specification notation is -itself- a computer language.) But
it's still a pain for Matlab users, in that it is often not clear to
the outside how TMW decides which side to fix -- and they *have* been
known to entrench what to many of us would appear to be obvious bugs.

With no offense intended to The Mathworks: if *I* were building software
in which the uttermost practical correctness and reproducibility of the
calculations was important, then I would not use Matlab. For anyone
concerned about numeric analysis, the clue should be glaringly obvious:
NONE of Matlab's library routines (that I have seen) document the precision
to be expected from the operation (other than perhaps the Fixed Point toolbox.)
And more subtly but still obviously important: Matlab provides no basic utility
routines such as "sum vector, optimized for highest accuracy".

>> a = randn(1,10000);
>> sum(a)

ans =


>> sum(sort(a))

ans =

>> [b,c]=sort(a);
>> sum(fliplr(b(b<0))) + sum(b(b>0))

ans =


But no "sum_accurately" routine to do it right :(