Circle suggestion

[hammondkd]

Motivation for this change

This is a suggestion for the circle and ellipse shapes. In most other shapes I see in the manual (e.g., trapezium, semicircle, isosceles triangle, kite), the base east, mid east, base west, and base east anchors all end up on the shape boundary. In circle and ellipse, however, they are directly beneath east and west, outside the shape border. This patch would place them on the edge of the background path for circles and ellipses as well.

Checklist

Please signoff your commits to explicitly state your agreement to the Developer Certificate of Origin. If that is not possible you may check the boxes below instead:

• Code changes are licensed under GPLv2 + LPPLv1.3c
• Documentation changes are licensed under FDLv1.2

[hmenke]

The proposal is interesting, but the implementation is problematic.

1. Evaluating cos(asin(x)) is very expensive. It's also equivalent to sqrt(1-x^2) which is maybe slightly less expensive(?). If you draw thousands of circles in a document (people do this) you'll absolutely notice the overhead.
2. asin(x) is only defined for -1 ≤ x ≤ 1. pgfmath is not super precise, so roundoff errors will cause failures.
3. The previous point is particularly important, because the argument of asin contains a division which is notoriously problematic in pgfmath and often the cause of dimension too large.

What do you think @muzimuzhi?

[hammondkd]

@hmenke The extra evaluation time is only invoked if the user somehow accesses one of the anchors on every single circle. Simply drawing a circle will not trigger it. I created a grid of 2500 circles just to check, and it was actually faster with the cos(asin(... code in there (but I'm certain that's coincidence/not significant). When I explicitly accessed the base east anchor for all 2500 circles by putting a node at that anchor, it increased the time TeX took to generate a PDF from 8.98s to 9.52s. Your mileage may vary.

Good point about sqrt(1-x^2) = cos(arcsin(x)). I initially tried using x = xc + sqrt(r^2 - (y-yc)^2), which is equivalent now that I think about it more, but that gave me a "dimension too large" error. In hindsight, I could have fixed that by normalizing y-yc first, but that introduces the same concern you had about division.

As for which is faster...I ran the same 2500 circle with base east access tests with cos(asin((y-yc)/r)) and the same with sqrt(1-sqrt(((y-yc)/r)^2)), and which one is faster is a toss-up. They both have the same range issue, but that basically means that if the text's base is ever outside the circle, Bad Things Will Happen.

Anyway...just a thought.

[hmenke]

Maybe we could use cos(90*x) as a poor approximation of sqrt(1-x^2). That doesn't have problem as we go outside of x ∈ [-1, 1]. Or we straight-up go for 1-abs(x).

The approximation only needs to be good enough to not be visually discernible for circles between 1sp and \maxdimen, right?

[muzimuzhi]

I didn't have the time to dig into, only traversed all the shapes having base east anchor from the pgfmanual.

Other circle/ellipse-based shapes whose base east and the alike anchors are not on the shape boundary: nand gate US, magnetic tape, circle split, circle solidus, ellipse split, and rounded rectangle.

Meanwhile, these circle/ellipse-based shapes do have their base east and the alike anchors on the shape boundary: semicircle and ellipse callout.