[Top][All Lists]

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

Re: Is this an fwrite/fread bug or just a floating point quirk?

From: David Grohmann
Subject: Re: Is this an fwrite/fread bug or just a floating point quirk?
Date: Wed, 25 Apr 2007 17:32:47 -0500
User-agent: Thunderbird (Windows/20070221)

John W. Eaton wrote:
On 25-Apr-2007, David Grohmann wrote:

| hmmm so my next question is how can I clear the bottom 29 bits of the | fraction so I can have a fake single precision value.

Why do you want that?  What good does it do to throw away the extra
precision and range?  I always thought the only reason to use single
precision values was to save space, not because it was desirable to
limit the precision and range of the calculations.

Well I want to be able to compare values that have been written to disk with values that are in memory. The format asks for 32bit float values on disk, so I write them out as float32. But writing the test for whether everything worked correctly comes back false even though octave is producing exactly the right behavior. (the real world example isn't writing out just one float, or just floats for that matter but I gave the float test case originally to boil it down)

Another solution would be an almost_equal(a, b, tolerance) that acts like isequal(a,b) but returns true as long as a and b are within a certain tolerance of each other. And in this case the tolerance would be the double value where all bits are zero except the bottom 29 which are 1.

Another solution is I could write a mex function that just does a c cast for float and then puts the values back into the matlab variable. I was just hoping to not reinvent the wheel if someone else already did this..

So to recap I need memory to match disk for testing purposes, or a more lax isequal() function.

David Grohmann
Senior Student Associate
Applied Research Lab : UT Austin : ESL - S206
Office: 512-835-3237

reply via email to

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