Zbr's days.
←May→
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
←2007→
Months
Jan Feb Mar
Apr MayJun
Jul Aug Sep
Oct Nov Dec

About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Sun, 20 May 2007

First Bezier curve.

Here is a result:

Bezier: initial result

Bezier curve construction is very sensitive to the order of the control points, since resulted Bezier curve is a weighted sum of Bernstain polynomials, which do not depend on control points, but each polynomial is multiplied with the single control point, so mixing them results in completely different picture, while pixel image will still be the same.

As a conclusion, it is not possible to use raw pixel data obtained from captha images, instead they must be converted into ordered set of points, which represents control steps: end points, crosses and rounds.
When this task is solved, it will be quite simple to construct a letter using several Bezier curves and start working with it.
Back to drawing board...

/devel/math/bezier :: Link / Comments (0)

Where is a bug in this code?
 

#include 

int main()
{
	float u;
	for (u=0.0; u <= 1.0; u += 0.1) {
		printf("%f ", u);
	}
	return 0;
}
Result:
0.000000 0.100000 0.200000 0.300000 0.400000 0.500000 0.600000 0.700000 0.800000 0.900000
But if step is 0.2 everything is correct and I can reach 1.0:
0.000000 0.200000 0.400000 0.600000 0.800000 1.000000
Using this loop:
	for (u=0.0; u <= 1.0;) {
		u += 0.1;
		printf("%f <= %f : %d\n", u, 1.0, u<=1.0);
	}
I got following output:
0.100000 <= 1.000000 : 1
0.200000 <= 1.000000 : 1
0.300000 <= 1.000000 : 1
0.400000 <= 1.000000 : 1
0.500000 <= 1.000000 : 1
0.600000 <= 1.000000 : 1
0.700000 <= 1.000000 : 1
0.800000 <= 1.000000 : 1
0.900000 <= 1.000000 : 1
1.000000 <= 1.000000 : 0
Result is always the same on different compilers (3.2.3, 3.3.2, 4.1.1, 4.1.2) and different arches (x86, x86_64, ppc32), so I expect it is not a bug, but a feature...
Further analysis shown, that using -Wfloat-equal, which is not in -W -Wall warning sets, compiler prints a warning for u == 1.0 comparison, but not for the example above.
I'm stumbled quite a bit...

More fun if I use smaller step like 0.0001, above loop resulted in following output:
...
0.063200 <= 1.000000 : 1
0.063300 <= 1.000000 : 1
0.063400 <= 1.000000 : 1
0.063501 <= 1.000000 : 1
       ^
Floating point math is very strange even for things which are supposed to be simple.
Above computations should be corect, since sum does not produce neither overflow, nor uncertain result, but nevertheless some error appeared.

/devel/other :: Link / Comments (0)