[metapost] d\'ej\`a vu or turningnumber, area et caetera

[Taco Hoekwater]

Hi again,

First off: I can see that Area() will be useful, but the next release
is supposed to fix bugs, not add new stuff. And besides, the bugs in
turningnumber would still need some form of resolution. That is why
MP 0.642 will not immediately contain an "area" operator.

Some comments on such a future operator, though:
 >>
>>  vardef Area(expr P) = 
 >>  [....]

To fit into the language, I propose the following syntax for the
primitive version:
	<numeric> := area <path>
or even
	<numeric> := area <subpath> of <path>
Where the result is a proportial fraction of the bounding rectangle.

Dan, can you take this (different presentation of the result) into
account? The current version might output an <enormous number>, so
restoring the symmetry is only half of the problem.

I'd be happy to code and propose such an extension for the next
'feature' release of MP.

Dan> I know it can be symmetrized, but maybe at the cost of doubling the
> number of real multiplications. (Multiplications/divisions used be
> considered an order of magnitude more complex than additions/subtractions
> -- which may not be true any longer -- so the number was a measure of the
> cost of the algorithm in computation.) I'll look into it.

If you need to multiply/divide by an integer, try to use powers of 2.
These allow substitution by bitshifts on machines were mul/div are
actually harder than add/sub, and you don't have to worry about it
any more.


---

Now, back to the turningnumber :

> The utility of the turning number has always escaped me. It seems solely 
> designed for debugging, to catch problematic curves. MF seems to have no
> problem generating "edge structures" for such paths. And Metapost will
> happily attempt to fill them.

The only actual use I know of is that the "counterclockwise" macro in
MF uses turningnumber to reverse a path explicitly (because it would
have raised an error while coloring pixels, otherwise).

---

I don't like the use of Area() for turningnumbers, because Area()
assumes that the path is extremely well-behaved. Under that condition,
it is definately  easier (as Werner suggests) to calculate a sum of
direction angles. Counting angles is also a lot faster.

In fact, the constraints on direction angles are considerably less 
strict:  calculating the directions does not require the path to
not intersect itself at all, whereas Area() does.  A side effect
is that the angle approach can return values like "2" or "-3"
that are documented behaviour for the current algorithm.


In the real world: tests show that the actual reported bugs may in
fact be solvable by simply decreasing the size of the triangle pen
that is used (not using a new algorithm at all). If this turns out
to be the case, then that is what the next release will implement
(rule of least effort). Otherwise, Werner's implementation will
'win'.

Greetings, Taco


BTW: I noticed that neither 'directions' nor Area() even care if
   the path is cyclic or not. Just an observation, I'm not sure
   if allowing non-cyclic paths would ever be useful.