[cairo] Shouldn't Cairo use/offer degrees rather than radians?

[Bill Spitzak]

Attached python shows a plausible solution for making any multiple of
M_PI_2 into the expected integers. It even avoids returning negative
zero as that surprises people some times. As far as I can tell this
works for any N*M_PI_2 or (N*.5)*pi. The discontinuities near any odd
multiple of pi/4 are pretty infinitesimal as far as I can tell, and
this version is at least as accurate with magnitude as normal sin/cos.
It also has the rather nice property of guessing right angles when
extremely huge angles are put in.

However if fails if the caller accidentally does any math using float
instead of double, and this demonstrates that failure. It is possible
to fix it with the problem of adding more noise to the output by just
doing everything in float instead of double, likely this would not
produce any unwanted artifacts for Cairo users. However at very large
N, N*M_PI_2 and N*M_PI_2F get far enough apart to actually produce
different answers even when rounded to the nearest float.


On Fri, Jun 30, 2017 at 10:51 AM, Bill Spitzak <spitzak at gmail.com> wrote:
> David's code seems to be an alternative to atan2 that returns degrees.
> It has a bunch of kludges to hide the fact that the atan2d he is
> calling internally apparently just calls atan2 and multiplies by
> 180/pi. He then has another function that is in effect calculating
> sin() and cos() and has even more kludges to detect multiples of 45
> degrees.
>
> The work needed in the second function indicates that passing degrees
> does not really help.
>
> Although it seems like it helps as far as I can tell if you don't want
> discontinuities then adjusting the sin/cos results for N*pi/2 is
> exactly the same difficulty whether degrees or radians are used.
> Basically it amounts to detecting if a/90 or a/M_PI_2 is near an
> integer, and is thus exactly the same problem.
>
>
> On Thu, Jun 29, 2017 at 11:38 PM, David Kastrup <dak at gnu.org> wrote:
>> David Kastrup <dak at gnu.org> writes:
>>
>>> Lawrence D'Oliveiro <ldo at geek-central.gen.nz> writes:
>>>
>>>> On Fri, 30 Jun 2017 07:02:36 +0200, David Kastrup wrote:
>>>>
>>>>> Lawrence D'Oliveiro <ldo at geek-central.gen.nz> writes:
>>>>>
>>>>>> On Thu, 29 Jun 2017 08:08:04 +0200, David Kastrup wrote:
>>>>>>
>>>>>>> It replaces a sin(x)/cos(x) pair by a sin(x)/sin(pi/2-x) pair.  The
>>>>>>> largest cumulative effect is at pi/4.
>>>>>>
>>>>>> So you introduce a kink at π/4. How is this any better, again?
>>>>>
>>>>> There is no kink.  None at all.
>>>>
>>>> No kink? Have a look--here’s your kink, at π/4.
>>>
>>> I have no idea what you are plotting here.  Your "fake" does not look
>>> like a _function_ of either axis, and it also doesn't have the symmetry
>>> of the sin/cos pairing of my code.  So if it is neither a function in
>>> isolation nor the actual value pair, what is it?
>>>
>>> Care to show the program you are generating your plots with?
>>
>> And show the units it is working with?
>>
>> Cutting this a bit short: can we actually skip the part where you are
>> trying to show, using bravado and ad-hoc arguments, to show that I am
>> incompetent and don't know what I am talking about?
>>
>> If you are worried about the added jitter due to the _internal_
>> implementation using the built-in sin/cos with radians as arguments,
>> I can of course add a post-correction stage (about doubling the
>> computational cost, of course) that will use the addition theorem in
>> order to get the full resolution of angles provided by the different
>> rasterization of degrees and radians.  But that's sort of pointless as
>> it will add precision amounting to something like 2^-53 .
>>
>> --
>> David Kastrup
>>
>> --
>> cairo mailing list
>> cairo at cairographics.org
>> https://lists.cairographics.org/mailman/listinfo/cairo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: angle.py
Type: text/x-python
Size: 597 bytes
Desc: not available
URL: <https://lists.cairographics.org/archives/cairo/attachments/20170630/bee19cc2/attachment.py>