On Nov 2, 7:24=A0pm, Walter Roberson <rober...@hushmail.com> wrote:
> Seth wrote:
> > I am having this problem on two separate machines, both with R2007a ins=
talled:
> >>> X =3D 0:.1:1
> >>> .3 =3D=3D X
> > ans =3D
> > 0 0 0 0 0 0 0 0 0 0 0
> > Clearly the ans should be
> > 0 0 0 1 0 0 0 0 0 0 0
> > What could I be doing wrong?
>
> The =3D=3D operator is giving the correct answer. You just aren't asking =
the question
> you think you are.
>
> The =3D=3D operator tests for *exact* equality, down to the last bit.
> You have made an error in believing that the colon operator will generate
> bitforbit identical multiples of the increment when compare to the
> algebraic number.
>
> There is no exact binary floating point representation of 0.1,
> and when you type in 0.3, you aren't getting exactly 3/10 either. Try
>
> format long g;
> (0:.1:1)  0.3
>
> and see whether you get an exact 0 value out at any element.
> And then try
>
> sprintf('0.75g', 0.3)
>
> and see whether the value stored internally is exactly 3/10 .
>
> It isn't a bug in Matlab. It's a fundamental limitation in the
> representation of numbers in *any* finite representation scheme.
> No matter what representation scheme you come up with, if it
> must store numbers in a finite amount of space, there will be
> some numbers that will not be exactly representable. Any finite
> discrete storage mechanism will be able to store at most a portion
> of the countable infinity, but the number of real numbers
> is (see Cantor's Diagonalization Argument) the uncountable infinity.
> There are an uncountable infinity of real numbers between any two
> numbers representable in any finite numeric representation system.
>
> Boiling this down into simpler terms:
>
> =A0 Never Do An Exact Comparison Of Floating Point Numbers
>
> If you want to know if two floating point numbers are equal and
> they were produced through even the slightest difference in
> methods (and that can include hidden compiler optimizations),
> then you must assume that even if the two expressions that
> produced the numbers were algebraically identical, that the
> bitforbit representation might differ slightly. So don't compare
> for equality: instead, check to see if the difference between
> the two numbers is sufficiently small to be negligible.
>
> 
> .signature note: I am now avoiding replying to unclear or ambiguous posti=
ngs.
> Please review questions before posting them. Be specific. Use examples of=
what you mean,
> of what you don't mean. Specify boundary conditions, and data classes and=
value
> relationships  what if we scrambled your data or used Inf, NaN, or com=
plex(rand,rand)?
Excellent answer, Walter, but you're feeding strawberries to swine.
