help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Differing results on right division


From: Damian Philipp
Subject: Differing results on right division
Date: Fri, 27 May 2011 14:09:38 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10

Hello Octave-Gurus,

Short Version:

I need to do right division of matrices in C++. I lifted some code from
Octave, but the resulting matrix in my C++-Code has entries that differ
from the octave implementation. Example: One matrix element of the
result is 1.912705055093411825e-03 in Octave and
1.912705055093413776e-03 in C++ (notice the difference in the last four
digits).
Since both implementations are using the same code and the same Fortran
Subprograms in the background, my guess is that this does have something
to do with handling rounding errors. Could this indeed be the case? Does
octave activate e.g. specific compiler switches or runtime handling to
get special handling of rounding errors?

Long Version:

I have implemented some mathematical model, first as a prototype in
Octave and now for more sophisticated use in C++ (using IT++, not
liboctave). Both run on the same machine (Intel Xeon, Debian Lenny). I
am using Octave 3.2.4 (anything newer won't build on Lenny) built from
source, linked against Lennys' libatlas 3.6.0. My C++-Impelmentation is
linked to the same libatlas.

My main problem is that I see different results for the right division
of matrices, which completely blow my model apart. As IT++ does not
offer right division of matrices, I dug into the source of octave and
lifted the appropriate code (xdiv(), Matrix::LSSolve()) to my
implementation. I created a small demo program (Octave and C++) using
the lifted code. You can download it at
https://rapidshare.com/files/2816498129/accuracy-demo.tar.gz

There are three matrices in this example: Kpm, invertedPart and subPart,
taken from my original C++ code. My goal is to compute subPart =
Kpm/invertedPart. The demo programs compute result = Kpm/invertedPart
and then display result .- subPart. The C++-Implementation displays a
zero matrix (to be expected, it's the same code). The Octave
implementation displays a matrix with loads of very small but non-zero
entries.

What could be the cause of this? How could I possibly fix this?

Many thanks in advane!

Regards,
Damian Philipp

-- 
 University of Stuttgart, IPVS    phone: +49 711 685-88339
 Distributed Systems Group        www.ipvs.uni-stuttgart.de
 Universitaetsstrasse 38          address@hidden
 D-70569 Stuttgart, Germany


reply via email to

[Prev in Thread] Current Thread [Next in Thread]