Re: Shouldn't Cairo use/offer degrees rather than radians?

A function like this might be useful:

  cairo_rotate_2(cairo_t*, double x, double y)

This would rotate it so the x axis is angled by atan2(y,x). I am not
sure if it should also scale by hypot(x,y) or normalize the vector.
This can be implemented without any trig functions.


On Fri, Jun 30, 2017 at 12:31 PM, Bill Spitzak <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>>>> David Kastrup <[email protected]> writes:
>>>>
>>>>> Lawrence D'Oliveiro <[email protected]> writes:
>>>>>
>>>>>> On Fri, 30 Jun 2017 07:02:36 +0200, David Kastrup wrote:
>>>>>>
>>>>>>> Lawrence D'Oliveiro <[email protected]> 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
>>>> [email protected]
>>>> https://lists.cairographics.org/mailman/listinfo/cairo
-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo