Note: an argument for why should documentation live in the code is made in the section at the bottom of this answer.
I would encourage you to include the details of the algorithm as a comment, and more.
Why this algorithm?
Before explaining the algorithm itself, you must first explain why this algorithm was chosen, rather than an alternative.
The explanation can be as simple as "We will use Bezier Curves, no other alternative was explored as they performed well enough". However, if you did test alternatives, please explain why they were rejected.
The idea here is that a maintainer coming later on may have to explore again (looking for better performance or accuracy for example), and if you already did the work with algorithm X and Y, and the reasons they were rejected still apply, then said maintainer can decide to start checking another algorithm instead rather than repeating your experiments.
Why this might seem silly, seeing as you said "Bezier Curves", bear in mind that sometimes there are slight variations of algorithms/data structures/... (B-Tree, B+-Tree, B*-Tree for example). Therefore, specifying with as much precision as possible which algorithm was selected, and which source it was pulled from (preferably one available online...) can help the readers' expectations with reality.
Also, if this is a variant compared to the general text-book version, make sure it is clearly labelled as such, lest readers wonder why it seems to deviate.
How does this algorithm work?
This really depends on the team you work with. If Bezier Curves are the bread and butter of the team, then a simple one-liner might be sufficient; however if the code may end-up being read/maintained by people for which this sounds like a surf figure, describing the algorithm sounds best.
Secondly, another advantage of describing the algorithm in comments is that it makes it easy to split the description, literate programming style. That is, you first start with a general outline of the algorithm which only identify sections, and then for each section you will have a comment block and immediately under the associated code. It makes it easier to check that the code is in adequation with the comments.
Finally, a last advantage of describing the algorithm in comments is that it makes it possible to annotate the algorithm itself. You may take short-cuts (a single round of approximation rather than two is sufficient for your accuracy needs for example), or on the contrary explain why a given step is necessary (and what are the consequences of removing it); you may even fix the algorithm (if you pointed to a printed version, for example, there might be an errata...).
Since this is an implementation detail, it should not get in the way of the caller. Implementation details should be documented in the function (not outside), and depending on your documentation generator, using "pure" comments as they do not need to appear in the documentation.
Why document in the code?
I will argue that code documentation should live as close to possible to the code. The reason is simple:
- the bug tracking system might change, and even if the import tool works the IDs may change
- the source control system might change
- the repository might be re-organized, split into several, etc...
Any time such an event occur, there is a risk that links across (new) boundaries are severed.
The code is the only constant!
- without the code, you do not need the documentation
- with the code, you get the comments, and thus the documentation within
Thus documentation is therefore more likely to be available if included in the code.
There is a limit, obviously, for example text files cannot contain images, so graphics/diagrams are hard to include in comments (ASCII Art should not be underestimated, and yes, I am serious). Still text goes a long way, so at the very least you can provide a good explanation in place and then nothing prevents you from also providing a more in-depth explanation elsewhere and link to it.