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

[Bill Spitzak]

Sorry I forgot to add:

David may have a point, though it is not exactly what he is stating.

Degrees have the property that "interesting" angles are more immune to
data transformations than radians. float(90) == double(90), while
float(M_PI_2) != double(M_PI_2). This can mean that you get the
expected sin and cos for "interesting" angles more often.

Where he is wrong is in thinking degrees make it easier to arrive at
these integers from an angle. I don't think it makes any difference as
you need to do an fmod or some equivalent in both cases.


On Fri, Jun 30, 2017 at 12:23 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> 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