Path: news.mathworks.com!newsfeed-00.mathworks.com!newsfeed2.dallas1.level3.net!news.level3.com!postnews.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!newsfe22.iad.POSTED!7564ea0f!not-for-mail From: Walter Roberson <roberson@hushmail.com> Organization: Canada Eat The Cookie Foundation User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 Newsgroups: comp.soft-sys.matlab Subject: Re: Very weird resolution issue. Bug ????? Seriously !! References: <goju5b$nv4$1@fred.mathworks.com> <muyocwgn8d7.fsf@G99-Boettcher.llan.ll.mit.edu> <gonnuu$krq$1@fred.mathworks.com> <TASrl.72499$uG1.3742@newsfe16.iad> <gopada$bj8$1@fred.mathworks.com> <Ajisl.2485$eT1.312@newsfe20.iad> <gou61a$goe$1@fred.mathworks.com> <gp3qf0$2pf$1@aioe.org> <gp3tt1$kl7$1@fred.mathworks.com> <gp45io$3av$1@fred.mathworks.com> In-Reply-To: <gp45io$3av$1@fred.mathworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lines: 69 Message-ID: <ZSxtl.14619$3S3.7390@newsfe22.iad> NNTP-Posting-Host: 24.79.146.116 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: newsfe22.iad 1236707897 24.79.146.116 (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: news.mathworks.com 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 = 10.574403301529 >> sum(sort(a)) ans = 10.57440330154 >> [b,c]=sort(a); >> sum(fliplr(b(b<0))) + sum(b(b>0)) ans = 10.5744033015403 But no "sum_accurately" routine to do it right :(