precision errors. microblaze vs matlab single precision... huh?

Started by chriskoh September 12, 2007
Hi all embedded gurus out there,
    I am working on an embedded platform using microblaze. I am trying
to implement an algo, which does a inverse matrix function on the
microblaze (via C) and then port the results back to matlab.
   so this is the scenario.

1) matlab generates some numbers, passes them to microblaze via the
UART (ie. PC to UART)
2) microblaze will then generate the matrix, and then calculate its
inverse and do other stuff (dot product of matrices etc etc).
3) microblaze will then send the result back to PC via UART.

Ok..so here's the problem.
the result obtained differs from matlab's result (I coded the same
implementation also in matlab). the result obtained varies up to an
error of 1 decimal place!!!

How I tried to debug
1) step through the C code using the debugger for microblaze. (this is
very cool tool).
2) at each step of the way, look at how the variables change for each
operation in the C code running on microblaze...and also observe how
the variables change in matlab


this is what I noticed
thinking it was due to matlab processing it in double precision, i
type cast the whole matlab routine in single precision. then I tried
to verify it again in the same way. And I get the same problem :(

can anyone help? As a result of this precision errors, the whole algo
fails to work. I am really not sure which one to trust now.

Would appreciate if anyone can help me on the same. The current
microblaze platform is using hardware FPU.

Chris

Hi,

What rounding mode are you using for Matlab?
MicroBlaze only uses round-to-nearest rounding mode.

In order to get exactly the same every result operation in Matlab has to be 
done in single-precision.

G�ran

"chriskoh" <chrisdekoh@yahoo.com> wrote in message 
news:1189590703.769514.104310@57g2000hsv.googlegroups.com...
> Hi all embedded gurus out there, > I am working on an embedded platform using microblaze. I am trying > to implement an algo, which does a inverse matrix function on the > microblaze (via C) and then port the results back to matlab. > so this is the scenario. > > 1) matlab generates some numbers, passes them to microblaze via the > UART (ie. PC to UART) > 2) microblaze will then generate the matrix, and then calculate its > inverse and do other stuff (dot product of matrices etc etc). > 3) microblaze will then send the result back to PC via UART. > > Ok..so here's the problem. > the result obtained differs from matlab's result (I coded the same > implementation also in matlab). the result obtained varies up to an > error of 1 decimal place!!! > > How I tried to debug > 1) step through the C code using the debugger for microblaze. (this is > very cool tool). > 2) at each step of the way, look at how the variables change for each > operation in the C code running on microblaze...and also observe how > the variables change in matlab > > > this is what I noticed > thinking it was due to matlab processing it in double precision, i > type cast the whole matlab routine in single precision. then I tried > to verify it again in the same way. And I get the same problem :( > > can anyone help? As a result of this precision errors, the whole algo > fails to work. I am really not sure which one to trust now. > > Would appreciate if anyone can help me on the same. The current > microblaze platform is using hardware FPU. > > Chris >
Hi Goran,
    I am using type cast to single in matlab. Once you round the first
variable to single in matlab, it should round everything after that to
single already. Cos all resulting variables after that are already in
single precision. right?

by the way, you say " In order to get exactly the same every result
operation in Matlab has to be
done in single-precision."

but my question is, the difference in values of the result amount to
orders of  >0.5 occasionally! Isnt that a bit too much difference in
results?

Is the FPU inaccurate or am i seeing things...


Chris


On Sep 12, 4:54 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote:
> Hi, > > What rounding mode are you using for Matlab? > MicroBlaze only uses round-to-nearest rounding mode. > > In order to get exactly the same every result operation in Matlab has to =
be
> done in single-precision. > > G=F6ran > > "chriskoh" <chrisde...@yahoo.com> wrote in message > > news:1189590703.769514.104310@57g2000hsv.googlegroups.com... > > > > > Hi all embedded gurus out there, > > I am working on an embedded platform using microblaze. I am trying > > to implement an algo, which does a inverse matrix function on the > > microblaze (via C) and then port the results back to matlab. > > so this is the scenario. > > > 1) matlab generates some numbers, passes them to microblaze via the > > UART (ie. PC to UART) > > 2) microblaze will then generate the matrix, and then calculate its > > inverse and do other stuff (dot product of matrices etc etc). > > 3) microblaze will then send the result back to PC via UART. > > > Ok..so here's the problem. > > the result obtained differs from matlab's result (I coded the same > > implementation also in matlab). the result obtained varies up to an > > error of 1 decimal place!!! > > > How I tried to debug > > 1) step through the C code using the debugger for microblaze. (this is > > very cool tool). > > 2) at each step of the way, look at how the variables change for each > > operation in the C code running on microblaze...and also observe how > > the variables change in matlab > > > this is what I noticed > > thinking it was due to matlab processing it in double precision, i > > type cast the whole matlab routine in single precision. then I tried > > to verify it again in the same way. And I get the same problem :( > > > can anyone help? As a result of this precision errors, the whole algo > > fails to work. I am really not sure which one to trust now. > > > Would appreciate if anyone can help me on the same. The current > > microblaze platform is using hardware FPU. > > > Chris- Hide quoted text - > > - Show quoted text -
Hi,

May 2 cents : It seems to me that Desktop PC FPU use larger mantissa 
internally than what is strictly required by the IEEE SP standard, 
especially for some operations (such as /,sqrt). That *might* explain 
your results.

Also, did you check that the matrix inversion algorithm you used is 
robust enough in terms of numerical stability ?

Hope it can help.

Steven

chriskoh a &#2013265929;crit :
> Hi Goran, > I am using type cast to single in matlab. Once you round the first > variable to single in matlab, it should round everything after that to > single already. Cos all resulting variables after that are already in > single precision. right? > > by the way, you say " In order to get exactly the same every result > operation in Matlab has to be > done in single-precision." > > but my question is, the difference in values of the result amount to > orders of >0.5 occasionally! Isnt that a bit too much difference in > results? > > Is the FPU inaccurate or am i seeing things... > > > Chris > > > On Sep 12, 4:54 am, "G&#2013266166;ran Bilski" <goran.bil...@xilinx.com> wrote: > >>Hi, >> >>What rounding mode are you using for Matlab? >>MicroBlaze only uses round-to-nearest rounding mode. >> >>In order to get exactly the same every result operation in Matlab has to be >>done in single-precision. >> >>G&#2013266166;ran >> >>"chriskoh" <chrisde...@yahoo.com> wrote in message >> >>news:1189590703.769514.104310@57g2000hsv.googlegroups.com... >> >> >> >> >>>Hi all embedded gurus out there, >>> I am working on an embedded platform using microblaze. I am trying >>>to implement an algo, which does a inverse matrix function on the >>>microblaze (via C) and then port the results back to matlab. >>> so this is the scenario. >> >>>1) matlab generates some numbers, passes them to microblaze via the >>>UART (ie. PC to UART) >>>2) microblaze will then generate the matrix, and then calculate its >>>inverse and do other stuff (dot product of matrices etc etc). >>>3) microblaze will then send the result back to PC via UART. >> >>>Ok..so here's the problem. >>>the result obtained differs from matlab's result (I coded the same >>>implementation also in matlab). the result obtained varies up to an >>>error of 1 decimal place!!! >> >>>How I tried to debug >>>1) step through the C code using the debugger for microblaze. (this is >>>very cool tool). >>>2) at each step of the way, look at how the variables change for each >>>operation in the C code running on microblaze...and also observe how >>>the variables change in matlab >> >>>this is what I noticed >>>thinking it was due to matlab processing it in double precision, i >>>type cast the whole matlab routine in single precision. then I tried >>>to verify it again in the same way. And I get the same problem :( >> >>>can anyone help? As a result of this precision errors, the whole algo >>>fails to work. I am really not sure which one to trust now. >> >>>Would appreciate if anyone can help me on the same. The current >>>microblaze platform is using hardware FPU. >> >>>Chris- Hide quoted text - >> >>- Show quoted text - > > >
Hi Steven,
    so matlab results are more accurate?
    the matrix inversion algorithm method is rather robust actually in
terms of numerical stability. What I noticed however is that the
matrix formed already by my C code running on microblaze before the
inversion has already some numerical differences with matlab's
version. simple C code vs matlab single precision code.
but different results obtained. All discovered by stepping through the
C code running on microblaze.
    the matrix was formed simply by a dot product.

Chris

On Sep 12, 10:15 am, Steven Derrien <sderrienREM...@irisa.fr> wrote:
> Hi, > > May 2 cents : It seems to me that Desktop PC FPU use larger mantissa > internally than what is strictly required by the IEEE SP standard, > especially for some operations (such as /,sqrt). That *might* explain > your results. > > Also, did you check that the matrix inversion algorithm you used is > robust enough in terms of numerical stability ? > > Hope it can help. > > Steven > > chriskoh a =E9crit : > > > > > Hi Goran, > > I am using type cast to single in matlab. Once you round the first > > variable to single in matlab, it should round everything after that to > > single already. Cos all resulting variables after that are already in > > single precision. right? > > > by the way, you say " In order to get exactly the same every result > > operation in Matlab has to be > > done in single-precision." > > > but my question is, the difference in values of the result amount to > > orders of >0.5 occasionally! Isnt that a bit too much difference in > > results? > > > Is the FPU inaccurate or am i seeing things... > > > Chris > > > On Sep 12, 4:54 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote: > > >>Hi, > > >>What rounding mode are you using for Matlab? > >>MicroBlaze only uses round-to-nearest rounding mode. > > >>In order to get exactly the same every result operation in Matlab has t=
o be
> >>done in single-precision. > > >>G=F6ran > > >>"chriskoh" <chrisde...@yahoo.com> wrote in message > > >>news:1189590703.769514.104310@57g2000hsv.googlegroups.com... > > >>>Hi all embedded gurus out there, > >>> I am working on an embedded platform using microblaze. I am trying > >>>to implement an algo, which does a inverse matrix function on the > >>>microblaze (via C) and then port the results back to matlab. > >>> so this is the scenario. > > >>>1) matlab generates some numbers, passes them to microblaze via the > >>>UART (ie. PC to UART) > >>>2) microblaze will then generate the matrix, and then calculate its > >>>inverse and do other stuff (dot product of matrices etc etc). > >>>3) microblaze will then send the result back to PC via UART. > > >>>Ok..so here's the problem. > >>>the result obtained differs from matlab's result (I coded the same > >>>implementation also in matlab). the result obtained varies up to an > >>>error of 1 decimal place!!! > > >>>How I tried to debug > >>>1) step through the C code using the debugger for microblaze. (this is > >>>very cool tool). > >>>2) at each step of the way, look at how the variables change for each > >>>operation in the C code running on microblaze...and also observe how > >>>the variables change in matlab > > >>>this is what I noticed > >>>thinking it was due to matlab processing it in double precision, i > >>>type cast the whole matlab routine in single precision. then I tried > >>>to verify it again in the same way. And I get the same problem :( > > >>>can anyone help? As a result of this precision errors, the whole algo > >>>fails to work. I am really not sure which one to trust now. > > >>>Would appreciate if anyone can help me on the same. The current > >>>microblaze platform is using hardware FPU. > > >>>Chris- Hide quoted text - > > >>- Show quoted text -- Hide quoted text - > > - Show quoted text -
On Wed, 12 Sep 2007 09:13:48 -0700, chriskoh <chrisdekoh@yahoo.com>
wrote:

> >but my question is, the difference in values of the result amount to >orders of >0.5 occasionally! Isnt that a bit too much difference in >results?
That expectation might be realistic for expression containing only multiplications and divisions. However, as soon as the expression contains additions of a large and a small value or a subtraction between two more or less equal values, the result depends heavily on the floating point representation. What exactly is "single precision floating point" ? I can think about at least a dozen representations that are using that name, in which each representations might return a different result with problematic parameters. Paul
In article <1189590703.769514.104310@57g2000hsv.googlegroups.com>, 
chriskoh says...
> Hi all embedded gurus out there, > I am working on an embedded platform using microblaze. I am trying > to implement an algo, which does a inverse matrix function on the > microblaze (via C) and then port the results back to matlab. > so this is the scenario. > > 1) matlab generates some numbers, passes them to microblaze via the > UART (ie. PC to UART) > 2) microblaze will then generate the matrix, and then calculate its > inverse and do other stuff (dot product of matrices etc etc). > 3) microblaze will then send the result back to PC via UART. > > Ok..so here's the problem. > the result obtained differs from matlab's result (I coded the same > implementation also in matlab). the result obtained varies up to an > error of 1 decimal place!!! > > How I tried to debug > 1) step through the C code using the debugger for microblaze. (this is > very cool tool). > 2) at each step of the way, look at how the variables change for each > operation in the C code running on microblaze...and also observe how > the variables change in matlab > > > this is what I noticed > thinking it was due to matlab processing it in double precision, i > type cast the whole matlab routine in single precision. then I tried > to verify it again in the same way. And I get the same problem :( > > can anyone help? As a result of this precision errors, the whole algo > fails to work. I am really not sure which one to trust now. > > Would appreciate if anyone can help me on the same. The current > microblaze platform is using hardware FPU.
A couple a questions - Are your matrices anywhere near being singular? - Are the algorithms the same and implemented identically on the two systems? That will be most critical near singularity but even away from it there can be traps. - Is the data used the same? What do you lose transferring the data back and forth? - Finally, what happens when yo perform the obvious sanity check abd multiply the original matrix by its inverse? Robert -- Posted via a free Usenet account from http://www.teranews.com
Good day Paul,
    so which one is the correct one? PC's matlab of xilinx FPU? What
do I make out of the results?

Chris

On Sep 13, 1:48 am, Paul Keinanen <keina...@sci.fi> wrote:
> On Wed, 12 Sep 2007 09:13:48 -0700, chriskoh <chrisde...@yahoo.com> > wrote: > > > > >but my question is, the difference in values of the result amount to > >orders of >0.5 occasionally! Isnt that a bit too much difference in > >results? > > That expectation might be realistic for expression containing only > multiplications and divisions. However, as soon as the expression > contains additions of a large and a small value or a subtraction > between two more or less equal values, the result depends heavily on > the floating point representation. > > What exactly is "single precision floating point" ? > > I can think about at least a dozen representations that are using that > name, in which each representations might return a different result > with problematic parameters. > > Paul
In article <1189648753.153265.145740@d55g2000hsg.googlegroups.com>, 
chriskoh says...
> On Sep 13, 1:48 am, Paul Keinanen <keina...@sci.fi> wrote: > > On Wed, 12 Sep 2007 09:13:48 -0700, chriskoh <chrisde...@yahoo.com> > > wrote: > > > > > > > > >but my question is, the difference in values of the result amount to > > >orders of >0.5 occasionally! Isnt that a bit too much difference in > > >results? > > > > That expectation might be realistic for expression containing only > > multiplications and divisions. However, as soon as the expression > > contains additions of a large and a small value or a subtraction > > between two more or less equal values, the result depends heavily on > > the floating point representation. > > > > What exactly is "single precision floating point" ? > > > > I can think about at least a dozen representations that are using that > > name, in which each representations might return a different result > > with problematic parameters. > > > > Paul > > so which one is the correct one? PC's matlab of xilinx FPU? What > do I make out of the results?
Which one works? IE what hapens when you multiply the original matrix by its calculated inverse? Robert -- Posted via a free Usenet account from http://www.teranews.com