Talk:De Casteljau's algorithm

	This article is within the scope of WikiProject Computer graphics, a collaborative effort to improve the coverage of computer graphics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer graphicsWikipedia:WikiProject Computer graphicsTemplate:WikiProject Computer graphicscomputer graphics
Low	This article has been rated as Low-importance on the project's importance scale.

Mathematics Low‑priority

	Mathematics portal This article is within the scope of WikiProject Mathematics, a collaborative effort to improve the coverage of mathematics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.MathematicsWikipedia:WikiProject MathematicsTemplate:WikiProject Mathematicsmathematics
Low	This article has been rated as Low-priority on the project's priority scale.

Dynamic Programming

It would be nice to add a remark regarding Dynamic Programming and how the algorithm may be implemented using a tabular method or a recursive method (possibly with memoization). Also, describing the existing implementations in terms of which approach they take might be helpful (e.g., Haskell implementation is recursive whereas the Python implementation is tabular). --SomeTimeLater (talk) 16:27, 24 December 2021 (UTC)[reply]

Untitled

I would like to see this illustrated: any takers? --Phil | Talk 12:49, Sep 22, 2004 (UTC)

Illustration would be really nice. Perhaps Κσυπ Cyp would do one if asked nicely.MathMartin 13:40, 22 Sep 2004 (UTC)

Just added the illustration and few words disscussing the geomtric interpretation of what is going on. The image was prepared in Asymptote ([1]), I include herewith the sources in case someone wishes to modifie the image one day (don't worry about licensing, I release it under public domain). Pkoprowski 17:36, 7 October 2006 (UTC)[reply]

Is there a reason the images from the Bezier_curves page aren't shown here? RaydenUni 20:33, 18 December 2006 (UTC)[reply]

Image sources

size(10cm,4cm);

real t = 0.33;

pair[][] P = {{(0,0), (0.25,1.5), (1,2), (1,0)},

{(0,0), (0.5,1), (1,2), (1,0)}, {(0,0), (0.5,1), (1,2), (1,0)}, {(0,0), (0.5,1), (1,2), (1,0)}};

path C[] = {nullpath, nullpath, nullpath, nullpath};
path g,ctr,d;
g = P[0][0]..controls P[0][1] and P[0][2]..P[0][3];
d = scale(0.025)*unitcircle;

int i,j,k;
C[0] = P[0][0]--P[0][1]--P[0][2]--P[0][3];
for(i = 1; i <= 3; ++i) {

for(j = 0; j <= 3-i; ++j) { P[i][j] = (1-t)*P[i-1][j] + t*P[i-1][j+1]; C[i] = C[i]--P[i][j]; }

for(k =  0; k < 3; ++k) {
   draw(shift((2*k,0)) * C[k]);
   for(i = 0; i < 4-k; ++i) {
       string L = format("$P_%d$",i);
       label(L, shift((2*k,0)) * P[k][i], i < (4-k)/2 ? W : E);

filldraw(shift((2*k,0)) * shift(P[k][i])*d); }

   draw(shift((2*k,0)) * C[k+1], dashed);
   for(i = 0; i < 3-k; ++i)

draw(shift((2*k,0)) * shift(P[k+1][i])*d);

   draw(shift((2*k,0)) * g);
}

I'm confused. What is little b? --jivy 16:48, 29 October 2005 (UTC)[reply]

Never mind. For anyone else who was wondering this, little b is the Bernstein basis polynomial. --jivy 03:58, 30 October 2005 (UTC)[reply]

Never mind little b, what about all the other variables? 129.11.146.164 (talk) 10:23, 12 November 2008 (UTC)[reply]

Would it be more clear to say that bi,n(t) is the Bernstein basis polynomial? I don't see what little b means just by itself.Ten-K (talk) 10:58, 3 March 2010 (UTC)[reply]

de or De

The article header says "The correct title of this article is de Casteljau's algorithm. The initial letter is capitalized due to technical restrictions." However, according to the style guides I have handy (NY Times and USGPO), it should be capitalized here (regardless of any technical restrictions). The NYT Manual of Style and Usage says that, while the "de" particle remains in lowercase when it appears in the interior of a sentence, it should be capitalized when it begins a sentence or a headline or a subhead. The USGPO Style Manual goes even farther, saying that "de" (also d', da, della, du, van, and von) should be capitalized unless preceded by a forename or title. So according to the latter, that first sentence should read "The correct title of this article is De Casteljau's algorithm." But then, it's not needed, is it? :-) The Wikipedia style guide http://wiki.riteme.site/wiki/Capitalization#Compound_names mentions this case only for the Dutch: Franky van der Elst, but Van der Elst, Franky in a list.--BillFlis 12:14, 2 May 2006 (UTC)[reply]

German article in english Wikipedia?

The article http://wiki.riteme.site/wiki/De_Casteljau%27s_algorithm is written in german. Is this a mistake, a stopgap until an english translation becomes available or something else? -- Roland Kaufmann Insert non-formatted text here

Haskell

I fail to see how using Haskell clarifies the algorithm. Should have been pseudocode or something with a transparent procedural syntax. Angry bee (talk) 20:30, 31 May 2010 (UTC)[reply]

I think that the example Haskell code implements the algorithm rather lucidly, though I was initially confused by its choice of variable names. -vk (talk) 03:15, 11 May 2013 (UTC)[reply]

I totally agree. For the vast majority of people, a procedural implementation would be clearer, like the one found here. —Ben FrantzDale (talk) 13:31, 10 October 2014 (UTC)[reply]

From someone who is familiar with programming in general but not Haskell, the current example is rather opaque. An example like linked above would be very helpful. --Miguelmurca (talk) 10:17, 29 January 2018 (UTC)[reply]

Haskell does not clarify. It is, of course, of use to Haskell programmers, but not to anybody else. JDAWiseman (talk) 16:42, 20 January 2019 (UTC)[reply]

Numerical stability

The intro says that this algorithm is "slower for most architectures when compared with the direct approach, it is more numerically stable". I believe it, based on the fact that this algorithm is based entirely on linear interpolation between points, and so it should be well behaved and doesn't involve taking the difference of large powers of numbers, but this should be expanded upon. —Ben FrantzDale (talk) 13:33, 10 October 2014 (UTC)[reply]

Stopping condition

Recursive algorithms need a stopping condition. Please could the stopping condition be explained more overtly? JDAWiseman (talk) 16:42, 20 January 2019 (UTC)[reply]

It seems there is a well known, simple, and good criterium for this:

A well-known flatness test is both cheaper and more reliable than the

ones you have tried. The essential observation is that when the curve

is a uniform speed straight line from end to end, the control points

are evenly spaced from beginning to end. Therefore, our measure of how

far we deviate from that ideal uses distance of the middle controls,

not from the line itself, but from their ideal *arrangement*. Point 2

should be half-way between points 1 and 3; point 3 should be half-way

between points 2 and 4.

Source: https://comp.graphics.algorithms.narkive.com/w4co31vm/adaptive-subdivision-of-bezier-curves

It should be verified, I am not sure the description is that accurate. However, it would be very useful to add this "flatness criterium" to the wiki page, I believe. 151.19.174.11 (talk) 18:12, 11 March 2024 (UTC)[reply]

Are the bounds for the indices i and j correct?

Going through this article and working the example out by hand brought to me attention that the bounds of the indices might not be correct. The index $i=0,\dots, n-j$ is used denote control points and the index $j=1, \dots, n$ the iteration. But shouldn't it be $i=0,\dots,n$ and $j=1,\dots,n-i$.

If we consider the example where $n=2$ and start on the last control point, $i=2$, we should get $j=1,\dots, 0$ which tells us that there is no iteration for the last control point (as expected). Just to make sure my point is clear, if you consider the first control point, $i=0$, then $j=1,\dots, n$ (again, as expected).

I'm still new at this, so I didn't feel comfortable enough to edit. I wasn't sure if there was something I was missing. Twotontwentyone (talk) 00:26, 20 June 2023 (UTC)[reply]