Approximating a Semicircle with a Cubic Nonrational Bezier Curve

At times I have had the need to approximate a semicircle with two quadratic Bezier curves.

Recently I wanted to approximate a semicircle with one Bezier curve. I decided to do this with a non-rational cubic Bezier curve.

First I made a cubic Bezier curve with a control polygon whose points correspond to a unit square.


Then I plotted a circle against the Bezier curve to see how close the Bezier curve was to a semicircle. It wasn't very close. So I knew I needed to adjust the Y values of P1 and P2 to bring down the curve. But how much? I evaluated the Bezier curve parametrically at t = 0.5 and determined that the y value at t = 0.5 was 0.75 or 3/4.

The radius of the semicircle is 0.5. I needed to move the Bezier curve down from 0.75 to 0.5. To do this I adjust the Y value of points P1 and P2 by:

yValueOffset = radius * 4.0 / 3.0

The resulting Bezier control polygon and curve is shown in the following image.
That looks more like a semicircle. Following is the same image with the semicircle plotted against it for reference.



For most situations this approximation will suffice. However, I decided to try and get it a bit closer! The next change was done by some calculations which yielded a value that was very close but to tell the truth my math and the complexity of the blending functions where such that I am not sure at this time if my conclusions are correct. (Note: Don't let your math skills get too rusty!)

While I endeavor to get the correct solution to the problem I will at this time share with you an easy value to remember that tightens up the Bezier curve close to the circle. The magic number is 0.05.

By insetting points P1 and P2 in the X value only the resulting Bezier control polygon and curve are shown in the following image.



Notice how nicely this cubic non-rational Bezier curve approximates a semicircle.

Here is an enlarged image so that you can see how nicely the curve fits the semicircle. (Click Image to see larger view.)



So, in summary:

xValueInset = Diameter * 0.05
yValueOffset = radius * 4.0 / 3.0

P0 = (0,0)
P1 = (xValueInset, yValueOffset)
P2 = (Diameter - xValueInset, yValueOffset)
P3 = (Diameter, 0)

This gives a pretty good approximation to a semicircle using only one Bezier curve.

Dilbert Mashups are fun!

Many of us enjoy the Dilbert comic strip. The new site allows for mashups where you can change the comments of the last cell of the strip.

Please check out mine! I enjoy trying to think of a new punch line.

http://dilbert.com/users/geoffrey_slinker/

You may have to create an account.

Please make comments or share links to your own mashups.

Measure or Listen?

Following are thoughts directed at Managers. This could be a Team Lead, a Technical Manager, a Product Manager, and especially a Process Manager.

Why "especially a process manager"? Because in my experience they often want to measure stuff!

Measuring isn't good or bad. Measuring isn't the only thing to do either and it may not be the first thing to do. In my opinion it is never the first thing to do.

If you are working on a software development team and it is experiencing some difficulty what do you do to get "control" of the situation?

Suppose the code is in a state of thrashing in that one bug fix seems to create new bugs.

What would you do?

Maybe you would do this:
1) Are they doing code reviews? How many of you are doing code reviews before check-in?
2) Are there regression tests? How much code coverage do we have with our tests?
(I will stop here for brevity)

For a process manager does everything have a process solution? If the perfect process is in place and there are failures does it mean that the people are wrong? Just a couple of thought questions.

Now to the point.

If there are problems then ask those that are experiencing the problems what they think the problems are and how they think the problems can be addressed. Listen carefully to their responses.

I have worked on many products where the software's design had reached its limit of usability. This includes software that I myself designed. There comes a time where weaknesses and inefficiencies become grossly apparent and it is time to address the core issues. While working on these products (with very large code bases) I have seen the fixes create new bugs and the code stability thrashes about. In each of these instances I have been asked what is wrong and I have said, "We need time to build a new foundation, the code has become a mess of add-ons and kludges and it is only going to get worse." Most every time the response is, "We do not have time for that. We will do code reviews and have someone start on writing tests to get better coverage." And most every time the thrashing problem does not go away. The thrashing seems to lessen but I propose that it lessens only because less code is being written due to the fact that more time is spent in code reviews and writing regression tests.

Do you have an example where you felt you knew how to address the "real" problem but was never asked? Is it always a matter of improving the process that will make the bugs go away?

Well, some of you are probably saying, "He wants cowboy programming. He never has liked Process Managers and gives them grief whenever he can. He never has worked on a large project with many developers or he would know that process is what holds it all together." Well, say what you may, that is your prerogative and that is what I am doing here!

I still say this, "Listen first." What does listen mean? It means hearing and understanding. Understanding is the key. This key makes it difficult for managers that do not have technical backgrounds for if they do not understand the problem or the proposed solution. How do such know if the suggestion is good or bad? If the manager doesn't understand the technical issues and only understands process then how can the manager do anything but suggest process changes to address every problem?

Listen first. Measure later.

Geoff

p.s. Maybe you have heard, Measure twice and cut once. It is a saying used by carpenters. It doesn't apply to software. Sorry.

Delivering Software Faster...

Delivering software faster than what or who?

I know the following statement is not generally accepted, but for me it has been a constant my entire career.

"Software is done when it is done. It takes as long as it is going to take."

I have noticed in current discussion that the idea of incremental delivery is some how being changed exclusively into the idea of faster delivery. This incremental delivery is delivery to the customer and not solely to a QA team.

I prefer incremental development of software. I believe in enough planning to divide the software into some type of conceptual model with vocabulary and metaphors to describe the abstract notion. Then I believe in enough planning to organize these abstractions in such a way that the pieces can be developed in a manner to utilize as many working in parallel as possible. Finally I believe that each piece is developed completely following the adage of finishing what you start before you start something else.

For me the above paragraph is enough to be the basis for a good software development process. With all of the books, articles, and methods available I feel that the above statement in contrast is concise and sufficient.

As for "delivering faster", well faster than what?

What can delay software delivery?
Poor programming skills.
Lazy people.
Burdensome I.T. policies.
Buggy hardware.
Low morale.
...
...
...

You add to the list anything you want that you have experienced that slows down development and thus delays software delivery. When you encounter one of these "things" that slows down development then address it in context and in a timely manner. That's the best that anyone can do. After you have addressed it then you can develop policies and practices to avoid it in the future.

For instance, coupling slows down software development. One way it does so it that the human developer can not recall all of the places a piece of code is used and thus may not understand all of the side effects of a change. Problem identified. One solution is to develop the software with regression tests so that when a change is made any issues from coupling may surface. Policy and procedure to avoid unidentified coupling issues is to use a development practice like Design by Use, Test First Programming, Test Driven Development, or some other approach that facilitates the creation of a code base with "built-in" regression tests.

The code will be done when it is done and not a day before. It may ship before it is done, that happens all the time!

Geoff