MATLAB Central Newsreader - Trouble - floor() BUG? or.... merely my faults?

Trouble - floor() BUG? or.... merely my faults?

ken — Tue, 17 Jun 2008 09:07:03 -0400

Hi, guys...
I'm new face here.

Is anybody could answer why the condition
happened being so weird.

floor, a very simplex internal function which bothered me...

There are some marked lines below explain my problem.
I thought that if it's my problem, it'd be an "access
violation" when running my code and caused
such weird result.

Please take a look. (Trace the place I marked)
Thanks a lot.

function floor_bug

Line2Pixel([1 1], [-7 -7])

% Most of the time, this function works well, though,
% the following parameter set exactly causes problem.
% Please as well check the middle of the code where I
highlighted.
% Problem there.
Line2Pixel([108 62], [-7 32])

function real_pixels=Line2Pixel(v1, v2)
% input: a line represented by end-point v1 to v2
% output: a sequence of pixels, may not in the order from
v1 to v2, might
% be in reversed order.
% There would be redundant pixels if points of (x, y) lie
in the line
% where x and y are both integers, in which case we ignored
to do clipping.

% % used for end-point verification
% s1=v1; s2=v2;

real_pixels=[];

% The followings deal with conditions on vert/hori line.
tmp0=v2-v1; % a
real vector
if tmp0==0 % a
zero vector
    real_pixels=[floor(v1)];
    return;
elseif tmp0(1)==0 % a
vertical line
    tmp00=floor(v1(1));
    for i=v1(2): sign(tmp0(2)): v2(2)
        real_pixels=[real_pixels; [tmp00 floor(i)]];
    end
    return;
elseif tmp0(2)==0 % a
horizontal line
    tmp00=floor(v1(2));
    for i=v1(1): sign(tmp0(1)): v2(1)
        real_pixels=[real_pixels; [floor(i) tmp00]];
    end
    return;
end

m=(v2(2)-v1(2))/(v2(1)-v1(1)); %
the slope
param1x=v1(1)-v1(2)/m; % a
constant(a) for x=ny+a
param1y=v1(2)-m*v1(1); % a
constant(b) for y=mx+b

%CX=@(CY) CY/m+param1x; %
get x from y
%CY=@(CX) m*CX+param1y; %
get y from x

% Reorder v1 and v2 because we want to increasingly
traverse along x-axis.
% After reordering, only two conditions for y are
considered.
if v2(1)<v1(1); tmp0=v2; v2=v1; v1=tmp0; disorder=1; else
disorder=0; end;

% The following code segment is a line-drawing algorithm
which uses
% floating point calculation as to be inefficient.
pixels=floor([v1(1) v1(2)]);
x_prime=pixels(1);
x_end=floor(v2(1));

if v1(2)<v2(2)
    y_inc=1;
    while x_prime<=x_end
        y=m*(x_prime+1)+param1y; %CY(x_prime+1);
        y_prime=floor(y);










        x=(y_prime+1)/m+param1x; %CX(y_prime+1);







                  %BUG HERE%
        %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
        %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
        % CHECK THE NEXT LINE: x_prime=floor(x);
        % while iterating to x==16.0000,
        % some incredible problem occurs.
        % floor() was out of mind......
        % Anybody knows why?????????????????????
        % help me here.
        % Appreciate a lot.
        %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
        %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


        x_prime=floor(x);
        pixels(end+1, :)=[x_prime y_prime]
    end
else
    y_inc=0;
    while x_prime<=x_end
        y=m*(x_prime+1)+param1y; %CY(x_prime+1);
        y_prime=floor(y);
        x=(y_prime-1)/m+param1x; %CX(y_prime-1);
        x_prime=floor(x);
        pixels(end+1, :)=[x_prime y_prime];
    end
end

% Transfer collected information to real pixels.
real_pixels=pixels(1, :);
if y_inc
    for i=2: size(pixels, 1)
        j=real_pixels(end, 2);
        while j<pixels(i, 2)
            j=j+1;
            if j>v2(2); break; end;
            real_pixels(end+1, :)=[real_pixels(end, 1) j];
        end
        j=real_pixels(end, 1);
        while j<pixels(i, 1)
            j=j+1;
            if j>v2(1); break; end;
            real_pixels(end+1, :)=[j real_pixels(end, 2)];
        end
    end
else
    for i=2: size(pixels, 1)
        j=real_pixels(end, 2);
        while j>pixels(i, 2)
            j=j-1;
            if j<v2(2); break; end;
            real_pixels(end+1, :)=[real_pixels(end, 1) j];
        end
        j=real_pixels(end, 1);
        while j<pixels(i, 1)
            j=j+1;
            if j>v2(1); break; end;
            real_pixels(end+1, :)=[j real_pixels(end, 2)];
        end
    end
end
if disorder; real_pixels=flipud(real_pixels); end; % reorder
% if length(real_pixels)>2 % clipping
% tmp=abs(real_pixels(1: 2: end-2, :)-real_pixels(3: 2:
end, :));
% tmp=tmp<2;
% real_pixels(2*find(and(tmp(:, 1), tmp(:, 2))), :)=[];
% end

% % used for end-point verification, fault if answer ~= 0
% s=floor([s1; s2]);
% prod([ ...
% prod([sum(s(1, :)~=real_pixels(1, :)), sum(s(1, :)
~=real_pixels(end, :))]), ...
% prod([sum(s(2, :)~=real_pixels(1, :)), sum(s(2, :)
~=real_pixels(end, :))]) ...
% ])

Re: Trouble - floor() BUG? or.... merely my faults?

Jos — Tue, 17 Jun 2008 10:01:03 -0400

"ken " <ken4aver@yahoo.com.tw> wrote in message
<g37urn$4eh$1@fred.mathworks.com>...
>
> Hi, guys...
> I'm new face here.

welcome!

...

> % floor() was out of mind......
> % Anybody knows why?????????????????????
> % help me here.
> % Appreciate a lot.

...

So, tell us then: what is the error and what was the value
of x when the error occured?

"The most important step towards a solution is the accurate
description of the problem."

Jos

Re: Trouble - floor() BUG? or.... merely my faults?

David — Tue, 17 Jun 2008 10:24:01 -0400

"ken " <ken4aver@yahoo.com.tw> wrote in message
<g37urn$4eh$1@fred.mathworks.com>...
>
> Hi, guys...
> I'm new face here.
>
> Is anybody could answer why the condition
> happened being so weird.
>
with the set of parameters giving you the problem this is
where your error really is:
y=m*(x_prime+1)+param1y; %CY(x_prime+1);
y_prime=floor(y);

the calculation works out that y=3.799999999999999e+001
which floor converts to 37... so it never gets past that
point, eventually it probably runs out of memory as its
stuck in an infinite loop building the array. overall the
code looks way over complicated for drawing a line, and as
too many chances for things like this to throw it off.
just what are you trying to do anyway?

Re: Trouble - floor() BUG? or.... merely my faults?

ken — Tue, 17 Jun 2008 14:34:02 -0400

"David " <dave@bigcompany.com> wrote in message <g383c1
$92q$1@fred.mathworks.com>...

> with the set of parameters giving you the problem this is
> where your error really is:
> y=m*(x_prime+1)+param1y; %CY(x_prime+1);
> y_prime=floor(y);
>
> the calculation works out that y=3.799999999999999e+001
> which floor converts to 37... so it never gets past that
> point, eventually it probably runs out of memory as its
> stuck in an infinite loop building the array. overall
the
> code looks way over complicated for drawing a line, and
as
> too many chances for things like this to throw it off.
> just what are you trying to do anyway?
>

:P...I'd notice about that and more explicitly state
problems.

And thanks, David.
I have done a Computed Tomography simulation code few weeks
ago, and have encountered this problem....it rarely happens
and happened.

Any idea to rectify such embarrassment or anyone knows any
related function in MATLAB could do line-pixel mapping? Or
to look for Line-drawing algorithms?

Regards and thanks in advance.

Re: Trouble - floor() BUG? or.... merely my faults?

David — Tue, 17 Jun 2008 15:39:01 -0400

"ken " <ken4aver@yahoo.com.tw> wrote in message
<g38i0q$gk$1@fred.mathworks.com>...
> "David " <dave@bigcompany.com> wrote in message <g383c1
> $92q$1@fred.mathworks.com>...
>
> > with the set of parameters giving you the problem this
is
> > where your error really is:
> > y=m*(x_prime+1)+param1y; %CY(x_prime+1);
> > y_prime=floor(y);
> >
> > the calculation works out that
y=3.799999999999999e+001
> > which floor converts to 37... so it never gets past
that
> > point, eventually it probably runs out of memory as
its
> > stuck in an infinite loop building the array. overall
> the
> > code looks way over complicated for drawing a line,
and
> as
> > too many chances for things like this to throw it
off.
> > just what are you trying to do anyway?
> >
>
> :P...I'd notice about that and more explicitly state
> problems.
>
> And thanks, David.
> I have done a Computed Tomography simulation code few
weeks
> ago, and have encountered this problem....it rarely
happens
> and happened.
>
> Any idea to rectify such embarrassment or anyone knows
any
> related function in MATLAB could do line-pixel mapping?
Or
> to look for Line-drawing algorithms?
>
> Regards and thanks in advance.
>
>
>

the matlab file exchange is a good place to start. here
are a couple along those lines.
http://www.mathworks.com/matlabcentral/fileexchange/loadFil
e.do?objectId=17658&objectType=File
http://www.mathworks.com/matlabcentral/fileexchange/loadFil
e.do?objectId=13397&objectType=file

and there are probably more there... and google sometimes
will find good stuff also.

Re: Trouble - floor() BUG? or.... merely my faults?

ken — Wed, 18 Jun 2008 06:34:01 -0400

"Jos " <DELjos@jasenDEL.nl> wrote in message
<g3820v$slj$1@fred.mathworks.com>...
> "ken " <ken4aver@yahoo.com.tw> wrote in message
> <g37urn$4eh$1@fred.mathworks.com>...

Anyway however, I have an additional vague thinking as to
argue.

x=3.79999999e+001, such sorts of value would ever be
obtained from some kind of calculation. It certainly is a
bit of difference between 37.9999 and 38.0000 and hence
allowable in scientific arithmetic.

BUT it stored in 37.9999 double, revealed 38.0000 on some
situations(like printout, some arithmetic, ...) and ALSO
37.9999 on others(here - floor()).

It manifests that the occasions for which floating points
evaluations are INCONSISTENCY!?
At least here, it is the conclusion that results of
floating points arithmetic are not PROPER to be in
corresponding to floor evaluations, right?

Please trace the above code I posted beginning at
x==16.0000 and starting monitoring either at program showed-
out or at commandline evaluations, evidence there.

and I list the trace results

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
In prog:

x=(y_prime+1)/m+param1x;

they are internally
15.99999999999997=(37+1)/0.26086956521739+ -
1.296666666666667e+002

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
But in commandline:

38/0.26086956521739

ans =

1.456666666666674e+002

K>> ans-1.296666666666667e+002

ans =

16.00000000000068

So... floor dead... Any comments?

Re: Trouble - floor() BUG? or.... merely my faults?

David — Wed, 18 Jun 2008 10:01:03 -0400

"ken " <ken4aver@yahoo.com.tw> wrote in message <g3aa8p$9f4
$1@fred.mathworks.com>...
> "Jos " <DELjos@jasenDEL.nl> wrote in message
> <g3820v$slj$1@fred.mathworks.com>...
> > "ken " <ken4aver@yahoo.com.tw> wrote in message
> > <g37urn$4eh$1@fred.mathworks.com>...
>
>
>
>
> Anyway however, I have an additional vague thinking as
to
> argue.
>
> x=3.79999999e+001, such sorts of value would ever be
> obtained from some kind of calculation. It certainly is
a
> bit of difference between 37.9999 and 38.0000 and hence
> allowable in scientific arithmetic.
>
> BUT it stored in 37.9999 double, revealed 38.0000 on
some
> situations(like printout, some arithmetic, ...) and ALSO
> 37.9999 on others(here - floor()).
>
> It manifests that the occasions for which floating
points
> evaluations are INCONSISTENCY!?
> At least here, it is the conclusion that results of
> floating points arithmetic are not PROPER to be in
> corresponding to floor evaluations, right?
>
> Please trace the above code I posted beginning at
> x==16.0000 and starting monitoring either at program
showed-
> out or at commandline evaluations, evidence there.
>
>
> and I list the trace results
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> In prog:
>
> x=(y_prime+1)/m+param1x;
>
> they are internally
> 15.99999999999997=(37+1)/0.26086956521739+ -
> 1.296666666666667e+002
>
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> But in commandline:
>
>
>
> 38/0.26086956521739
>
> ans =
>
> 1.456666666666674e+002
>
> K>> ans-1.296666666666667e+002
>
> ans =
>
> 16.00000000000068
>
>
>
>
>
>
>
> So... floor dead... Any comments?
>
>
>
>
>
>
>

not dead, just being applied in an unsafe manner. go back
and read the hundred or so other threads on floating point
calculations over the last year or so. this is well known
and documented and any time you program with floating
point variables you are going to see this. this is why
you will commonly see things like int(x+.5) or floor(x+.5)
when converting from floats to ints just to be sure that
single bit differences are masked. as far as displaying
different values in different places, this is just a
display issue, the underlying value hasn't changed, its
just the way it gets printed changes. change your display
preferences to long e or g and see what you get, all those
little bit differences suddenly start to make your numbers
look not so precise... but that is the world of floating
point calculations.

Re: Trouble - floor() BUG? or.... merely my faults?

ken — Wed, 18 Jun 2008 13:00:05 -0400

"David " <dave@bigcompany.com> wrote in message <g3amcv$ap4
$1@fred.mathworks.com>...
> "ken " <ken4aver@yahoo.com.tw> wrote in message
<g3aa8p$9f4
> $1@fred.mathworks.com>...
> > "Jos " <DELjos@jasenDEL.nl> wrote in message
> > <g3820v$slj$1@fred.mathworks.com>...
> > > "ken " <ken4aver@yahoo.com.tw> wrote in message
> > > <g37urn$4eh$1@fred.mathworks.com>...
> >
> >
> >
> >
> > Anyway however, I have an additional vague thinking as
> to
> > argue.
> >
> > x=3.79999999e+001, such sorts of value would ever be
> > obtained from some kind of calculation. It certainly is
> a
> > bit of difference between 37.9999 and 38.0000 and hence
> > allowable in scientific arithmetic.
> >
> > BUT it stored in 37.9999 double, revealed 38.0000 on
> some
> > situations(like printout, some arithmetic, ...) and
ALSO
> > 37.9999 on others(here - floor()).
> >
> > It manifests that the occasions for which floating
> points
> > evaluations are INCONSISTENCY!?
> > At least here, it is the conclusion that results of
> > floating points arithmetic are not PROPER to be in
> > corresponding to floor evaluations, right?
> >
> > Please trace the above code I posted beginning at
> > x==16.0000 and starting monitoring either at program
> showed-
> > out or at commandline evaluations, evidence there.
> >
> >
> > and I list the trace results
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > In prog:
> >
> > x=(y_prime+1)/m+param1x;
> >
> > they are internally
> > 15.99999999999997=(37+1)/0.26086956521739+ -
> > 1.296666666666667e+002
> >
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > But in commandline:
> >
> >
> >
> > 38/0.26086956521739
> >
> > ans =
> >
> > 1.456666666666674e+002
> >
> > K>> ans-1.296666666666667e+002
> >
> > ans =
> >
> > 16.00000000000068
> >
> >
> >
> >
> >
> >
> >
> > So... floor dead... Any comments?
> >
> >
> >
> >
> >
> >
> >
>
> not dead, just being applied in an unsafe manner. go
back
> and read the hundred or so other threads on floating
point
> calculations over the last year or so. this is well
known
> and documented and any time you program with floating
> point variables you are going to see this. this is why
> you will commonly see things like int(x+.5) or floor
(x+.5)
> when converting from floats to ints just to be sure that
> single bit differences are masked. as far as displaying
> different values in different places, this is just a
> display issue, the underlying value hasn't changed, its
> just the way it gets printed changes. change your
display
> preferences to long e or g and see what you get, all
those
> little bit differences suddenly start to make your
numbers
> look not so precise... but that is the world of floating
> point calculations.
>

Thank you, David.
I learn it.

And I took a trial of the following statements.
Trouble slips away!!! (to somewhere :) )

y=m*x_prime+m*1+param1y;
x=y_prime/m+1/m+param1x;
y=m*x_prime+m*1+param1y;
x=y_prime/m-1/m+param1x;

Some sense of "make a room for it".
(and such idea inform other people if you someday also...)

Regards and appreciate

Ken