OT Sine Rule [was Re: Functional programming]

[Chris Angelico]

On Wed, Mar 5, 2014 at 1:25 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
>
> The Sine Rule, or Law of Sines, tells us that the ratio of the
> length of a side and the sine of the angle opposite that side is constant
> for any triangle. That is:
>
> a/sin(A) == b/sin(B) == c/sin(C)

Oh! Right. Now I remember. Yeah. Still, it looks wrong to... well,
what I said next:

> On Wed, 05 Mar 2014 00:01:01 +1100, Chris Angelico wrote:
>> but you're taking the sine
>> of a ratio. That... seems wrong, gut-feeling-wise.
>
> Well of course it's wrong. Given the intended geometric meanings of the
> function parameters, the quantity calculated is meaningless. But
> mathematically, it's okay to calculate the sine of a ratio of two other
> quantities. It's just a number. These even a whole lot of double-angle
> formulae that allow you to calculate sin(2*x) given sin(x), or sin(x/2)
> given sin(x), etc.

What I meant there was "ratio of side lengths". The definition of sine
is that, in a right triangle, the ratio of the lengths of the side
opposite an angle and the hypotenuse is the sine of that angle. So I
consider sine to be a function that takes an angle and returns a
side-length-ratio, and arcsine does the reverse. It's like asking for
the length of an integer and getting back a string - it just looks
wrong. The sine of double an angle makes sense - it's still an angle.
You don't multiply an angle by a side length, you don't take the sine
of a number of meters per second, and you don't calculate the number
of parsecs it takes you to get to Kessel. The units are just wrong.
Maybe there's some specific situation where that makes sense, but I'd
call it "formula smell". And note that your corrected form still
applies the functions the way I describe - the units are maintained.
(Technically the sine of an angle is a pure number, a straight ratio.
I'm not sure that "pure number" is a unit - it's kinda the absence of
any unit - but that's still something to be maintained.)

> But, giving that ratio physical or geometric meaning is another story,
> and in this case the semantics of the function is entirely bogus. That
> was my point -- the compiler cannot possibly tell what the function is
> intended to do, it can only check that it is self-consistent.

Right. It's a consequence of a type system that distinguishes floating
point from string, but not angle_in_degrees from length_in_meters.
It's theoretically possible to build a type system that's like that
(sometimes you can subclass to do that, and create explicit operations
only), but I've never really felt the need to. But that's the theory
behind some forms of Hungarian notation - identifying a "data type"
concept that's broader than the compiler knows.

>> You take the sine of
>> an angle and get a ratio, or the arcsine of a ratio and get an angle.
>> Also, trig functions apply only to right triangles,
>
> Not quite. Or to put it another way, not at all :-)
>
> Trig functions are *defined* in terms of right-angled triangles, but
> (say) the sine of 30° is 0.5 regardless of whether that 30° angle is in a
> right-angled triangle, an acute triangle or an obtuse triangle. 30° is
> 30° regardless of what the rest of the triangle is doing.

Yes indeed. Like I said, I'm a bit rusty on all that, and forgot about
the ways of using them in non-right triangles :) But that 0.5 doesn't
have intrinsic meaning if you don't have a right triangle around it;
it needs something else to give it useful meaning, like another
angle's sine.

ChrisA