Re: Very weird resolution issue. Bug ????? Seriously !!

"Sung Soo Kim" <sskimbox@xxxxxxx> writes:

They must be the same in your sense. Matlab does not use the 'best'
algorithm to minimize the error, but it may be using 'speed
optimizing' algorithm that can sacrifice the accuracy. (Hm... this
sounds very important... another issue?)

Sorting, then adding, is the most accurate order. But almost no one
does that. MATLAB does not, Numerical Recipes in C does not, ATLAS
LAPACK/BLAS do not. So in some ways, all of these packages/libraries
sacrifice accuracy for speed... or simplicity... or whatever. They
simply don't address the issue.

You can get different answers on some CPUs and compilers that use 80-bit
double precision inside the FPU, but 64-bit in memory. Current Intel
CPUs have a choice- use the FPU, or use SSE2 instructions for
double-precision computations. SSE2 doesn't use 80 bit extended.

Cool. That's a good example of gray area that IEEE standard cannot
step in. But floating point accuracy was not my issue. My issue was
about 'inconsistency' of the matrix manipulation algorithm. Anyway...

This is exactly about that. Even in C, you can't ensure perfect
consistency, because a different compiler, or a different compiler
RELEASE, or a different architecture, may generate code that still
follows the C standard, but produces slightly different results, because
of the above.

This does not make C programs useless for science. You just have to
understand the constraints and limitations when you draw your
conclusions, just like with any other scientific tool.

In your experience, computations come out the same way all the time.
Your mistake is in assuming that that is somehow part of a standard, or
that they are guaranteed to do so. Take the 32-bit to 64-bit
migration. Many programmers assumed that a pointer was the same size as
an integer. It always worked before, so why not? The problem was, no
standard said it must, so the change to the new architecture breaks a
lot of code.

Assumption of consistency on 'scientific' software was my mistake? I
don't think so. Consistency must be the heart of scientific software,
though my assumption might have gone too far.

Sorry, I think it was your mistake. I don't mean to offend. I don't
think consistency in your sense *is* the heart of scientific software.
You can use Monte-Carlo simulations to do some very good science. Even
if the runs come out differently *on every run*, the statistical results
are consistent from a scientific point of view. Part of science is
tracking the sources of error in measurement and accounting for them.
Least-significant bits in floating point math are sources of error, and
failing to account for them is a mistake. In my opinion, of course.
And one that I've made many times.

But you know my point. They quietly changed the way of matrix
manipulation, and it's not in the compatibility documents (See 'math'
sections in
http://www.mathworks.com/access/helpdesk/help/techdoc/rn/bqsrae0.html
after R14sp3 or is it documented elsewhere???). Then I think I can at
least raise an issue, though no one really seems to care about that
(and I won't). Your example of pointer (32bit to 64bit) is super-big
issue in technology and it is well documented. I don't have any issue
with such a big change that I can easily access information of.

But my point is, running the same code in the same version of MATLAB on
a different platform might also produce different results. There's no
"quiet changing" going on. If you'd like documentation on what not to
expect from floating point, well, read the papers that have been
suggested to you.

And again, as a huge 'scientific' software with 'millions' of users,
any change of 'technical behavior' should be documented. Don't you
think so? (It might have been documented and I just couldn't find
it... In that case... Well... Shame on me...)

What we're all trying to say is that there is no change of technical
behavior. Floating point computations still come with round-off error.
You still should not rely on exact answers from floating point values.
That's not a change.

The way you are arguing, it sounds like next year you will have the same
argument when some other MATLAB function produces subtly different
output. Well, it may, because that's how floating point works. If you
are still relying on exact equality from floating point expressions,
DON'T!

It's virtually impossible to write code that adheres perfectly to the
guarantees of the standards and documentation. Whatever. We do the
best we can given the constraints and needs of a given project. But
when such a situation is pointed out to you, and you understand the
mistaken assumption involved, you fix the code and move on. You don't
protest the advances in architecture, numerical methods, compilers, or
whatever.

-Peter

Hm... I got your point but you went too far. Nothing cannot be
protested. You can think of many examples on that. :) And I moved on
already. One thing I can say is that you're free to show tolerance but
raising an issue is one's freedom and that's the real engine of
advances in anything, though I don't think my issue is so big.

My apologies if that came across as a rebuke. My sentence above uses
"you" in the stupid colloquial English sense of "one". Of course you
are free to protest whatever you want, and post it here. I do not mean
that there are things one should keep quiet about.

Thanks for keeping this civil in spite of my blunt language. I'm sorry
for that and thanks for your opinions.

-Peter
.

Relevant Pages

  • Re: Best way to force a JComponent to repaint itself
    ... Since I haven't posted any attack posts, there's nothing for me to stop. ... unless of course you want to know how to use the Java API documentation. ... I hope you've learned from that mistake. ... I don't care what your opinion is regarding what I do or do not need to do. ...
    (comp.lang.java.programmer)
  • Re: Reviving REMARKS
    ... > fixed paragraph names encouraged the inclusion of significant ... The standard mavens, in their eternal and rather foolish quest ... "documentation prologs" out of programs and if not move them to ... Far more useful is a good source code management tool. ...
    (comp.lang.cobol)
  • Re: The Problems of TeX
    ... many TeX distributions did not come with it - OzTeX is one (in ... If your definition of "not exotic" is "everything that was standard x ... The MacTeX distribution is flawed in that it fails to provide the simple ... silly because it's purely down to a lack of decent documentation. ...
    (comp.text.tex)
  • VHDL Library Madness
    ... the documentation, but it's a tough thing to get changed. ... Appnote code is the hardest to fix. ... some coding standard. ... , go through all the example code which has "bad" libraries, ...
    (comp.lang.vhdl)
  • Re: CRT and Win32 SDK
    ... However, it might give a reader an impression that when doing embedded programming one typically has a full-fledged language at hand, where in effect the runtime library implements what the OS would provide on e.g. a PC. ... The C and C++ standards differentiate between hosted and free-standing implementation to deal with the special constraints of embedded programming, where free-standing doesn't need to provide all of the language's standard library, but even that distinction does in practice not go far enough: it might be that fundamental language features such as static variables and exceptions are not available on the embedded platform's language implementation. ... Both the user-mode Win32 API and the kernel ... The documentation remarks are very important parts of that documentation and form the main part of it. ...
    (microsoft.public.vc.language)