|
Math library question
Most math libraries I've run into solely use radians for arguments. The problem is that nobody in the real world uses radians. How come Math libraries never seem to implement interfaces that use degrees?
Philo
Philo
Sunday, May 23, 2004
I suppose they figure it's easier for you to write "degrees * Math.PI / 180", than it is for them to write all the wrappers...
As to why they chose radians over degrees in the first place, perhaps radians are the standard in math circles (no pun intended), even though degrees is preferred by non-mathematicians? Just a guess...
Joe
Sunday, May 23, 2004
I heard an explaination for this once but I dont recall the details. It has something to do with the relation to Pi and the infinite string of decimals.
Its like, some operations are better to do with radians because you can get exact results as oppsed to an infinate string of decimals. Other operations are better to do with degrees for the same reason.
Eric Debois
Sunday, May 23, 2004
I probably lost touch with the real world some time ago, but I always work in radians. Mathematicians and physicists use them because it makes the equations simpler - eg if you differentiate sin(x) where x is expressed in radians you get cos(x). If you're working with complex numbers, then you can write exp(i.x) = cos(x) + i.sin(x), which simplifies the handling of some differential equations. If you try and use degrees instead, you end up with factors of 180/pi cropping up all over the place. After a while radians just come to seem the natural way to do things - just as working with logs to the base e instead of base 10 does.
I should add that my wife and son think I'm barking mad.
as
Sunday, May 23, 2004
Oh, I'm well aware of the mathematical reasons for using Pi. The only problem is that I think most developers are generally coding against the real world, where bearings are in degrees, offsets are in degrees, torque angles are in degrees...
In fact, I cannot think of a single *practical* angle measurement in anything but degrees.
I'd be interested to find out the proportion of times Math libraries are called with the Pi/180 factor compared to without - I'm thinking the factor is there a signficant majority of the time it's there, since if you're working in radians, you're not in .Net or Java... (I could be wrong, of course. :) )
Philo
Philo
Sunday, May 23, 2004
"In fact, I cannot think of a single *practical* angle measurement in anything but degrees."
You sound like someone raised on English units complaining that they cannot think of a single practical length measurement in anything but feet.
But anytime you are interested in the length of an arc, the area of a pie slice, the surface area on a sphere, you are going to end up working in radians.
Practically speaking, the only case I can think of where degrees are superior are nautical distances (a minute's a mile), and even that is sort of a biassed historical accident (one minute of arc on earth surface being the definition of a nautical mile).
Is there some particular advantage to measuring torsion angles in degrees, beyond the fact that everybody does it that way?
Danil
Sunday, May 23, 2004
Philo, welcome to GIS.
Sunday, May 23, 2004
Philo,
You seem to be incorrect in your initial supposition.
The mathematical trig functions use radians _by definition_. If a sin function did not take radians, it would not be the sin function any more, it would be something else.
In the real world of engineering (electrical and otherwise) it is IMHO much more normal to need the function that takes radians than one that takes degrees.
Ian
Sunday, May 23, 2004
"You sound like someone raised on English units complaining that they cannot think of a single practical length measurement in anything but feet."
You're so right. Those whole four years of advanced mathematics - I slept through those. Never mind the two semesters of power and transmission lines I suffered through.
"Is there some particular advantage to measuring torsion angles in degrees, beyond the fact that everybody does it that way?"
Spoken like a true engineer. Now, since I'm designing and building applications and user interfaces to be used by the "everybody" referenced above...
"You seem to be incorrect in your initial supposition.
The mathematical trig functions use radians _by definition_. If a sin function did not take radians, it would not be the sin function any more, it would be something else."
? Where did you get this?
The sine of an angle in a right triangle is the ratio of the length of the opposite side to the hypotenuse. The angle may be measured in any units desired - it's just an angle.
Now, the neat thing about radians is that the measurement of an angle can be defined as the length of the arc subtended by that angle in a circle of radius 1. But the definition of "sine" isn't dependent on that at all, that I'm aware of; just as the linear measurements have no units whatsoever.
I could redefine all of geometry using the angular measurement "philo" where 360 degrees = 42 philos. The entire discipline would survive just fine. ( sin(5.25)=.7071 )
Philo
Philo
Sunday, May 23, 2004
Philo, get back to work.
Bill
Sunday, May 23, 2004
Yo, Philo. Radians is based off of PI...case you didnt know. So, in a matter of speaking, radians isnt all that arbitary.
Anon-y-mous Cow-ard
Sunday, May 23, 2004
"? Where did you get this?"
Probably from the definition of the trig functions (although I remembered it from high school the way you described it).
http://mathworld.wolfram.com/Sine.html
http://mathworld.wolfram.com/Cosine.html
Tom H
Sunday, May 23, 2004
The x87 FPU seems to use radians instead of degrees; a math library that does the same is thinner (more efficient).
To implement support for both in your interface, you may overload with a new defined type:
double sin(double radians);
struct Degree
{
double value;
};
double sin(Degree degrees);
Christopher Wells
Sunday, May 23, 2004
Sigh.
Having (almost) got a maths degree I think I'm qualified to answer this one. This may get a bit technical, but you guys asked for it by ignorantly presuming radians to be arbitrary or silly. Ha.
First, from a purely mathematical point of view:
Yes, sin is /defined/ as taking radians. And this definition is /not/ an arbitrary one. Radians are the only natural way to define the sin function. Rather like e is the 'natural' base to use for logarithms, multiples of Pi are the 'natural' way to measure angles.
The simplest way to explain this is to say that differentiating sin and cos only 'works' if you work with radians. Working in radians, sin differentiates to give cos, cos to give -sin, etc.
If however we make up a silly sin function (call it SillySin) which takes argument in degrees, it doesn't differentiate to give cos, silly or otherwise. Why?
SillySin(x degrees) = ProperSin( x * Pi/180 )
so
d/dx SillySin(x) = Pi*180 * ProperCos( x * Pi/180)
= Pi*180 * SillyCos(x)
You get lots of factors of Pi*180 popping out that shouldn't be there if things are going to work out right.
And yes, until you start differentiating things there isn't really any obvious reason for using radians - hence why radians mode on your calculator seem a bit pointless and confusing until you do a calculus course. But really, I would have hoped people on here would remember some calculus at least...
Infact when mathematicians are building up calculus using limits in a very strict way one stage at a time, the sin function is typically /defined/ as a power series:
sin(x) = x - x^3/3! + x^5/5! - x^7/7! + ...
And the symbol Pi is /defined/ as the smallest zero of the sin function on the positive part of the real line (once you've shown that such a root exists uniquely). That's right, mathematicians don't define Pi as anything to do with circumference/diameter ratios. It's actually /defined/ as a root of the sin function. You might be tempted to think this definition is arbitrary and we could just as easily define 180 degrees as the first root of the sin function but that just wouldn't work, for reasons outlined above, and many others.
But for the computer scientists out there - why should a function that calculates sin on a computer, for simple purposes, not take degrees? fair question I guess.
Because, all the algorithms for actually /calculating/ the sin function, operate on radians. One example would be the power series above - to calculate the sin of an angle to a given accuracy, you sum up the first however-many terms of that sequence (figuring out how many terms you need to some to get a given accuracy would be a matter for numerical analysis)
This only gives the right answer if the number you input is in Radians. So if the input was given in degrees, the function would only have to convert it into radians first anyway, before it could do anything useful with it. As I said, radians is just the natural way of doing trigonometry, and using any other angle measure only involves converting it to radians when you want to actually do any of the calculations. If that bugs you, write a little inline wrapper function that converts, or something.
Matt
Sunday, May 23, 2004
Should a programmer deliver a program that elegantly accomplishes the problem domain in the way that makes sense to the programmer, or...
should a programmer deliver a program that does what the user needs it to do?
That was the root of my question. I still don't think that the mathematical basis of sine has anything to do with the fact that AFAIK, 99% of common usage measures angles in degrees.
Calculators can perform trig functions in degrees and radians - WTF can't Math library functions? Sure, I can do the 180/Pi thing myself - but I shouldn't have to.
Philo
Philo
Sunday, May 23, 2004
Matt gives a great answer.
As an engineer I'll just add that Philo's belief that "The problem is that nobody in the real world uses radians" is not correct. As an engineer (optics) I work in radians as much as degrees. It just depends on whether I'm dealing with optical alignment (radians) or hardware orientation(degrees).
And quite often I want both radians and degrees, so I just toss in pi/180 and 180/pi factors as needed.
Also, per Matt's explanation of the power series approximation to Sin(x) == x for small values of x (in radians). This is very useful, and radians are the unit of choice for first-order analyses.
DaveF
Sunday, May 23, 2004
Philo
Maybe the answer is that the math functions are generally written by mathematical purists to whom the sine function is just something that operates on a real (or complex) number to give another real (or complex) number, and from this perspective sin(90) = 0.8939..., not 1, and degrees or radians don't enter into it. There's not reason in theory why the library writer should not provide different functions which do what you want, and IIRC Fortran provides SIND etc as well as SIN etc. Personally I'd hate to see the C standard library cluttered up in this way, but obviously opinions differ - personally I'd get rid of log10 as an unnecessary excrescence. On the other hand, the .NET & Java libraries are so big already that a few more features probably wouldn't hurt.
As a matter of interest, my calculator also has the ability to calculate using grads, rather than degrees or radians. Does anyone in the real world use these, and if so what for?
as
Monday, May 24, 2004
Philo is making a very simple point that some people seem to be ignoring: the interface should allow for a person to pass degrees as an argument, because when it comes to angles, most people *think* in degrees. Whatever happens inside the function is irrelevant. If calculators can do it, math libraries should be able to as well.
Monday, May 24, 2004
However, now that everyone expects computer trig functions to accept radian arguments, changing them to degrees would be confusing.
Julian
Monday, May 24, 2004
Damit Philo, take the five minutes out of your busy posting schedule to write a freaking wrapper class that takes degrees or philos or whatever you want.
Most of the world of developers who use them use radians for trig functions.
I am glad to have a more efficient sin function for wavelet analysis, fourier transforms, 3D graphics, and scores of other applications.
Dennis Atkins
Monday, May 24, 2004
As many have pointed out by now, it's a user interface problem. You should handle the conversion in the user interface, not in the underlying code that does the work.
Architecturally you should probably even save any intermediate results in radians, and just convert for display.
Jan Oosting
Monday, May 24, 2004
Interesting question.
Think of how OOP would handle it. There'd be sin(radians) and sin(degrees). However, most convenient for programmers is sin(number). Programmers don't want to type sin(new Radian(2*pi)), and library authors don't want to create sin-degrees().
Tayssir John Gabbour
Monday, May 24, 2004
"As many have pointed out by now, it's a user interface problem"
Yep.
Except that for a library, *I* am the user.
Philo
Philo
Monday, May 24, 2004
Hmm, come to think of it, if you had optional parameters, you could flag degrees. Like in lisp,
(sin 90 :degrees)
Tayssir John Gabbour
Monday, May 24, 2004
Yeah Philo, why you using C anyway? Lisp is the way to go.
It's the best.
Dennis Atkins
Monday, May 24, 2004
Philo, all mathematical calculations must be done using standard units. For trigonometry this means radians. While for a novice, not using degrees, might seem unintuitive, any experienced mathematical coder can tell you that not using standard units will lead to spaghetti code and loads of bugs. Ask NASA what happens if you don't use standard units. Just accept it and life will be a thousand times easier.
Like Jan Oosting says convert to and from degrees in the GUI. Define Rad2Deg() and Deg2Rad() methods yourself if they aren't yet available.
Overloading the Sin() method with a degrees variant, suggested by some, is a disastrously bad idea and typically done only by coders inexperienced with mathematics. Like Matt indicates, imagine you have a few hundred Sin() methods in your code, which one is in radians and which one is in degrees? Stick to the standard and you will know. Introducing non-standard unit calculations will bring you into problems sooner rather than later. Someone hit me with a clue stick pretty hard when I did that my first time.
Jan Derk
Monday, May 24, 2004
Okay Jan, do me a favor would you? Tell the entire global aviation community that they're using the wrong units when they measure flight courses.
You also have to get every compass in the world "fixed"
All those sextants are wrong; surveying tools too.
And we need the earth renumbered while you're at it.
Once you get all that fixed then we can sit down and talk about what units of measurement are "natural" for sines and cosines. Until then, I don't think it's unreasonable to suggest that a trig library for use in business applications provide for both radians and degrees.
Philo
Philo
Monday, May 24, 2004
I happen to have flown aircraft, hold a Master of Science in Aeronautics and have programmed helicopter simulation and performance software, which is all about transformations and trigonometry, for several years. So that might provide me with some authority. To answer you question: All those things you mention are human interfaces using non-standard units on historic grounds. Any software driving those interfaces uses standard units *under the hood*. Well, at least it should.
And of course it is not a perfect world. In a perfect world all humans would think in standard units, speak one language, hold one currency and we would all drive on the right side of the road. At least the Russians do it right. Their aircraft altimeters are in meters instead of feet. Planes collide in midair, because pilots have to convert from feet to meter or vice versa in their head. If it were up to me we would all go metric on January 1st 2005. If Sweden can change road sides from left to right on 1 day... On the other hand safer does not always mean better. Part of my travel fun is communicating with people using hands, feet and a mixture words from half a dozen of languages. And I can't help smiling when a scuba diver student tells his instructor he is 12 stones when asked for his weight.
Jan Derk
Monday, May 24, 2004
Hmmm. That sounds awfully arrogant.
This is usually when somebody much smarter than me comes along and proves me wrong.
Jan Derk
Monday, May 24, 2004
IIRC grads were introduced by the french during the revolution. Sometimes used by surveyors to avoid degree's minutes' s seconds problems (i.e. it's a decimal degree)
Note this is may be folklore, but I seem to remember my dad selling early TI calculators as they had "grads" to surveyors.
Peter Ibbotson
Monday, May 24, 2004
Yep, as pointed out above, any radian/degree conversions should be done in the UI layer, the code that does the actual work should store intermediate results in radians. Firstly because it'd be a pointless waste of CPU cycles converting them from degrees and back again however many times whenever you need to do a calculation, and secondly because doing that will likely worsen any rounding errors in the floating point representation.
I recognise people like to look at nice round numbers in degrees, but radians are the only way to go for doing actual calculations. So convert for the UI at the last possible stage. If typing *180/Pi really hurts you that much just write a Rad2Deg() function or something. I think having a version of sin that operates on degrees only encourages people to use units in silly ways. Any input in degrees should be converted to radians at the first opportunity, and stored that way so calculations can be done with it with the proper sin functions in the natural way.
Matt
Monday, May 24, 2004
Just a quickie...
is e natural? it looks pretty thought up to me (for dealing with differentiation, that is)
Monday, May 24, 2004
e^x is natural in the sense that it's what you get if you look for a function whose derivative is its own value (with the constraint that f(0) = 1) and then evaluate that function at x=1. It can also be defined as the limit in a compound-interest calculation as the compounding interval drops to zero.
IMHO the best way to handle angles and other units is to stick with one internal representation (radians, meters, etc) and translate to/from a more "user-friendly" representation in the interface. (with this design you could easily allow the user to toggle between different sets of units). If this won't do, then you are probably doing something really complicated like a symbolic algebra system (Mathematica) and don't need my suggestions :)
Dan Maas
Monday, May 24, 2004
// macro to convert degrees to radians
#define DEG2RAD(x) ( ( x ) * 0.017453292519943295769236907684886 )
Drum roll please.... Here's my DEG2RAD macro! Used in all of my games code. It's nifty, it's sturdy and it mows the lawn!
More seriously, I believe that historically, you would find that the folks who developed these libraries would be people with math and science backgrounds.
Most hardware chips floating point trig functions take radians as arguments. Remember if you were coding a math library for a computer pre-FPU era you'd have to code the sin/cos etc.. functions by hand most likely in assembly. I'd bet you'd have to hire a mathematician to write the function and he would just naturally use radians or the thought of using degrees would take more coding and not be worth the effort. I'm sure you can think of some more reasons. Also the engineers who make the hardware don't seem to agree that degrees are best.
The 80386 floating point instructions take radians as arguments:
http://webster.cs.ucr.edu/AoA/DOS/ch14/CH14-5.html#HEADING5-58
So in short, the answer is historical and hardware related. I don't think it would be easy to change this historical convention. It evolved the way it did. So your best bet is to simply write a macro or inline function or a wrapper or an API or an abstraction layer or what have you.
Name
Monday, May 24, 2004
Yes, any FPU hardware will take radians. But this isn't an arbitrary choice either, as I said, the power series (or any other method for calculating sin) takes argument in radians, so the hardware needs to work with radians anyway, and would have to convert to them if it wasn't given radians.
Really I think it's not even that helpful to think of radians as a 'unit' like the metre or the kilogram. It's dimensionless and completely non-arbitrary. Sin(Pi) just /is/ 0 - that's what the sin function /is/. There's no too ways about it. Writing '180 degrees' is really just shorthand for 'Pi'...
The question about e - you're right it does seem pretty arbitrary as a base until you start doing some differentiation. When you find that the defining property of e^x is that it differentiates to give e^x. This means that e's crop up all the time in solutions to differential equations, probability distributions, and countless other things.
It might (? haha) also interest you to hear that the exponential function e^x is actually used by mathematicians to /define/ what we mean by putting a number to a power in general (when the power may be irrational).
We can define integer powers easily enough - 2^3 := 2*2*2 for example. We can even define it for rational powers, eg 2^(1/3) is the cube root of two. (A little bit of work is involved to show that a cube root actually /exists/ uniquely before you can define this, but I'll gloss over that).
But how do you /define/ what is meant by, say, 2 to the power Pi ? 2 to the power sqrt(2) ? for any arbitrary real number?
The answer is, you first define the exponential function e^x on the real numbers, either by a power series
exp(x) := 1 + x + x^2/2! + x^3/3! + ...
or equivalently as the solution to d/dx exp(x) = exp(x), exp(0) = 1.
You then define the natural log function, ln, as the inverse to this (having shown that an inverse function exists because exp is strictly increasing).
You then /define/ what a to the power x means in general, by:
a^x := exp(x*ln(a))
for any positive real a. (for negative a we need to start introducing complex numbers and it gets a bit nastier).
Hopefully that gives some insight into why e is 'natural' - we really have no way of thinking about a continuous function f(x) = a^x in general, until we find a way to define the exponential function, in which a takes the special value e. Then every other base is defined in terms of that. We couldn't define everything in terms of, say, 2^x, because, until we have the exponential function, we can only meaningfully define what 2^x means for rational powers.
Also it helps to notice that (from the above infact) for a different base a, say:
d/dx (a^x) = ln(a) * (a^x)
A natural (base e) logarithm pops out 'as if by magic' when you differentiate an arbitrary a^x. Rather like a Pi/180 conversion factor pops out 'as if by magic' if you differentiate the (silly) sin function that takes degrees.
Matt
Monday, May 24, 2004
"is e natural? it looks pretty thought up to me (for dealing with differentiation, that is)"
Yes it is - read or listen to the Feynman lecture on Algebra. It's one of the lectures on Physics, slotted in as an entertainment lecture. If I understand the history correctly, he first wrote and delivered the lecture to his fellow scientists at Los Alamos during the war. Very clear.
Back to the original problem: I'm inclined to think that the real problem is that the math library accepts as the argument to its trigonometric functions a number, when it should really be insisting upon an angle. Then it wouldn't matter what the source of the angle is.
I'm thinking of Barton and Nackman, and the work they published with enforcing units via templates in C++.
"Is there some particular advantage to measuring torsion angles in degrees, beyond the fact that everybody does it that way?
Spoken like a true engineer. Now, since I'm designing and building applications and user interfaces to be used by the "everybody" referenced above..."
Hey Philo - the next time you ask somebody an honest question in an attempt to broaden your own understanding, and get a snippy answer in response, remember that you have it coming.
Danil
Monday, May 24, 2004
The reason we use degrees instead of radians goes back to ancient Egypt. They were trying to work out how time and geometry fit together. Their numbering system didn't work with fractions very well, but it serves as the basis of navigation and cartography to this day:
http://deseretnews.com/dn/view/0,1249,515040547,00.html
Tom H
Monday, May 24, 2004
Might also help to note that e, pi, and the sin and cos functions, are intimately connected, as you see when you start looking at complex numbers, and these connections all depend upon using radians for the sin and cos functions, and base e for the exponential:
e^(i*x) = cos(x) + i*sin(x)
cos(x) = [ e^(i*x) + e^(-i*x) ] / 2
sin(x) = [ e^(i*x) - e^(-i*x) ] / 2*i
e^(i*pi) + 1 = 0
Matt
Monday, May 24, 2004
Philo, you make a good point. It might be useful for the math functions to provide a degree interface for trigonometric functions. After all, most math libraries provide a function that takes a logarithm to the base 10, so there is certainly good precedent for doing this, and it would avoid some programming errors.
Contrary to some of the other postings here, for standard geometry, I see no reason why the trig functions can't be equally well defined in just about any arbitrary units for angle measurement. There also isn't any problem defining approximations for trig functions using degrees instead of radians.
For many mathematical operations, it is convenient to have trig functions defined to use radians, so I would be unhappy if the only trig functions available used degrees, since I would then have to write conversions in more places.
I can't take seriously the argument that the trig functions should use only radians because that is the 'natural' measure. After all, we make many compromises on units. For example, our units of length and time should be such that the speed of light is one, so e=m. I seem to remember that quantum mechanics works much better if Plank's constant (h) is one (or is it h bar is one)? Finally, whoever came up with units of weight such that Avogadro's number isn't something more convenient certainly did humanity a disservice. My vote is that we junk the metric system and come up with something more reasonable.
Dan Brown
Monday, May 24, 2004
Interesting points... but radians needn't have any connection to anything in the physical universe to define or make sense of them - sure, units with dimension can be defined so as to make certain physical constants into nice numbers, but radians are dimensionless and are a purely mathematical construct. So the analogy doesn't quite carry over...
Yeah I know for basic trig (finding sides of triangles, etc) it doesn't really make a lot of difference what you use. Unless you're doing small angle approximations, say, or you want the formula for area of circle segments to work out nice.
Although your calculator/computer still needs to convert the angle to radians to actually calculate the sin for you, even if it is just to find the x coordinate for a spaceship in a game, or whatever. So may aswell store the angles in the format the computer needs to use anyway. I still think it's best to be consistent, and measure angles in the way which makes sense for more complex tasks too.
Sorry if I got a bit carried away though... It's guess it's just... once you've seen the beauty of the maths that underlies these functions in complex analysis and stuff, any other measure of angle seems somewhat arbitrary. I'm sure people will go ahead and store everything in degrees if thats what floats their boat. Infact I used to when I wrote computer games as a kid, before I'd done any calculus.
Matt
Monday, May 24, 2004
or as people have mentioned in this thread, the math library can have a simple conversion function "float radians(float degrees)". then you say sin(radians(degrees_entered))
(or better yet use typing and let the types know how to covert to eachother)
mb
Monday, May 24, 2004
Phile, override the damn Sin function.
Alex
Monday, May 24, 2004
Can't override a static method.
Philo
Philo
Monday, May 24, 2004
I'm embarssed to say I spent about 2 hours trying to figure out why my drawing function was producing such bizarre output. It never crossed my mind that sin() took radians until I googled a little bit. I never claimed to be brilliant :)
Lee
Monday, May 24, 2004
<quote>
I can't take seriously the argument that the trig functions should use only radians because that is the 'natural' measure.
</quote>
Sure, why make it easy on yourself using the SI unit for plane angles when you can do it the hard way?
The fact that all trigonometry libraries work in radians should have been a big hint, but apparently they are all wrong.
You know, you can also use the angle between your upper body and the centerline of your cylindrical body part as plane angular unit. It works just fine. But please don't make me debug your code, as I have had enough of crappy code full of conversions and exotic units created by wise asses who think they are smarter than the National Institute of Standards and Technology.
Jan Derk
Monday, May 24, 2004
The oil industry is probably one of the worst offenders, they have units of measure that you simply wouldn't think possible in an international industry. They also have 'standard' calculations that only work for some weird, perverse set of inputs because who ever wrote them (IADC, SPE) rolled three or four conversion factors and maybe a constant of proportionality into a single figure. To cap the lot they also have so called engineers who insist on implementing calculations that are dimensionally incorrect.
The worst I recall was trying to explain that mass of mixture = mass of fluid + mass of additive, but volume of mixture != volume of fluid + volume of additive if additive was soluble. How basic can you go and still claim an 'engineering' degree?
All past now, thank Heavens!
Gaius
Monday, May 24, 2004
"The fact that all trigonometry libraries work in radians should have been a big hint, but apparently they are all wrong."
Act as the world is; do not act as you wish it was.
I thought of two more reasons for working in degrees when the UI is in degrees...
1) Accuracy - sin(67 + 90) is going to be more accurate than sin(60 * Pi/180 + Pi/2) when you're working on a digital computer. (hint: Math.Pi != Pi; 60 * Math.Pi/180 != Pi/3)
2) Readability of code. It's obvious that bearing = bearing + 90 is a right turn, but bearing=bearing+Pi/2 looks like an adjustment to a measure. It's like the difference between i=i+1 and i=i + counterVar.
The world generally operates in degrees; trig functions operate in radians. Somewhere between the trig functions and the world the numbers have to change. I'm just saying I don't think it would be such a bad idea for that change to happen just inside the boundary of the Math libraries instead of just outside.
I'm still thinking of writing a DateTime library that only accepts ticks. After all, that's the natural representation of time to the computer - converting to months, days, and minutes is your problem...
Philo
Philo
Monday, May 24, 2004
>> "1) Accuracy - sin(67 + 90) is going to be more accurate than sin(60 * Pi/180 + Pi/2) when you're working on a digital computer. (hint: Math.Pi != Pi; 60 * Math.Pi/180 != Pi/3)"
How is that more accurate than using a macro or an inline function?
#define DEG2RAD(x) ( ( x ) * 0.017453292519943295769236907684886 )
sin(DEG2RAD(67 + 90));
I believe in this case Radians is the way the world acts and you are trying to act as you wish it was.
Name
Monday, May 24, 2004
Philo, in scientific and engineering applications there are rarely such concepts as "when the UI is in degrees." A component spec from one manufacturer, for example, may express something as RPM, and another express the same thing as radians per second, and another as degrees per hour. Or users in one country may always use "feet per minute," while others use "meters per second."
So to hardcode any UI input field to "degrees" or "feet" or "meters" or whatever your desired internal representation is, would just invite user error as they have to pull out the calculator. Instead, in science and engineering apps you usually have another field so they can select the units.
Thus it does not matter what units your math libraries expect, as you'd still always need to do the conversion from user input to your internal representation.
I don't know if you're just posting this as a rant why the world doesn't all use the same units and speak the same engineering languages, but your argument for "degrees" is certainly pedantic...
Ron
Monday, May 24, 2004
Philo,
If I could defrock you of your EE degree, I would.
hoser
Monday, May 24, 2004
WOE, I'm not sure a full defrocking is called for, just for daring to suggest the parameter to the trig functions be in degrees rather than radians.
I'd support a burning effigy, though!
Ron
Monday, May 24, 2004
It goes to everything wrong with the software industry. I remember talking to a guy who wrote software at a diesel engine company. He was frustrated that the mechanical engineers would not model their software requirements using Booch methodology.
Look dip-stick, you work for a diesel engine company. The subject is diesel engines, not OO. Adapt to your environment, don't expect it to adapt to you.
Matt gave a great explanation of why radians are used.
Ignored, without rebuttal.
hoser
Tuesday, May 25, 2004
"Act as the world is; do not act as you wish it was." - Philo
Please either take your own advice or start using metric decrees, of which there are 100 decrees to a a full revolution.
"1) Accuracy - sin(67 + 90) is going to be more accurate than sin(60 * Pi/180 + Pi/2) when you're working on a digital computer. (hint: Math.Pi != Pi; 60 * Math.Pi/180 != Pi/3)"
This statement is incorrect, Philo.
Dennis Atkins
Tuesday, May 25, 2004
My head hurts.
OffMyMeds
Tuesday, May 25, 2004
"Philo, in scientific and engineering applications there are rarely such concepts as "when the UI is in degrees." "
Ahhh... so your position is that the Math libraries are only to be used in scientific and engineering applications. Gotcha.
Is there a business.Math library somewhere that we mere mortals can use?
Seriously though - this started as a simple inquiry as to whether there was something I was missing about why Math libraries don't accept degrees, like every calculator in the world does (you guys need to go bitch out TI and HP for doing it wrong)
Now I don't mind there being a basic difference of opinion about whether the conversion is best done just inside or just outside the wrapper - no skin off my nose, I can do the math.
What I *object* to is this pedantic insistence that I'm wrong, I don't know what I'm doing, and I'm an idiot for doing some basic angular manipulation in degrees instead of radians. What *really* ticks me off are those fools who seem completely oblivious to the fact that a huge number of people who make angular measurements in the real world use degrees and never touch radians. For you guys, stop operating at 1.5707963267948966192313216916398 to reality.
[visions of the CO of a ship saying "Helmsman, come 0.2618 left, steady on new course 4.7124"]
Philo
Philo
Tuesday, May 25, 2004
I think the difference is human -> human and human -> computer and computer -> computer communication.
Sure the CO tells another human the Helmsman to follow this course in degrees because that's how we communicate, but let's suppose the ships steering is done with a computer so this guy enters the degrees into the computer and then they are converted to radians before being processed by the computer hardware or software libraries which natively use radians for reasons that have already been discussed.
Name
Tuesday, May 25, 2004
I think a couple things are getting conflated here.
The original question, I think has been covered - why do math libraries assume numbers represent radians? Because some choice has to be made, arbitrary though it may be, and radians is a reasonable expert choice.
"Even though nobody in the real world uses radians" is demonstrated to be false.
The existance of an area where degrees is technically superior is still unanswered. The main argument is that degrees are very commonly used, isn't that reason enough?
I'm inclined to agree with Philo on this one - yes of course. Although if you have two client populations with different needs, you've got a problem satisfying both.
Of course, in a math library, the client audience is some subset of the programming population, so those are the needs that must be met.
I'm inclined to say that if your market is experienced programmers, you need to use radians because that's what they expect [from their experiences in the C Standard Library, among other things -- mm, I wonder if Plaugher's book discusses the why of the choice made in the standard library].
If your market is a more popular audience [ie, non-programmers trying to accomplish some task so that they can get on with their real work]... I think you've got a problem. It really isn't reasonable to ask each client of the trig library to duplicate the deg2rads conversion, or to wrap the trig methods for itself. On the other hand, there is a point of diminishing returns - should the libraries be standardized to support deg, grad, fraction of circle, pizza slices....
I still have trouble imagining some of the applications. In my experience [not necessarily representative, but which did include coursework in celestial navigation, courtesy USN], people don't apply trigonometric functions to directions, even though those directions are expressed in degrees. Tangent of a course correction? Sine of Latitude? These make about as much sense to me as Cosine of temperature.
So the examples I've seen so far haven't been much help to me in appreciating the extent of the problem.
Danil
Tuesday, May 25, 2004
Oops - let me clarify one thing. I *never* meant to say or imply that Math library trig functions should *only* take degrees - I was asking about either overloading the operator:
sin(double radians)
sin(double angle, enumerator angleUnits)
or having alternate functions that took degrees (dcos, dsin, dtan, etc)
As for the application - celestial navigation is all trigonometry. The trig is cleverly hidden with charts, compasses, and lookup tables, but it's there. Ditto relative motion afloat - maneuvering boards let you calculate closest point of approach, relative courses and speeds without touching a calculator, but if you want to do any of these digitally, you're going to be up to your knees in trig functions and angles in degrees.
Philo
Philo
Tuesday, May 25, 2004
namespace Philo {
inline double sin(double x) { return std::sin(x*pi/180); };
//...
};
Something like that...
You can be right in your own little world.
(Its not nice to fool with mother nature)
hoser
Tuesday, May 25, 2004
Of course I'm missing the point but for what it's worth...
You can have alternate names (dsin, dcos...). My favorite because it's less wordy.
You can overload based on number of parameters:
sin (double radians)
sin (double angle, enumerator angleUnits) // weird.
You can overload based on the type of parameter
sin (double radians);
sin (degrees angle);
With the degrees() constructor declared as explicit. So sin(90) will compute for radians, and sin(degrees(90)) will compute for degrees.
Or you can templatize:
sin<degrees>(double angle);
(with the default template argument being radians).
Alex
Tuesday, May 25, 2004
Matt, I have to say, the e^iv way to express a complex number is pure beauty. Esp. e^i(pi) + 1 = 0. Most beautiful.
And thanks for the explanation on e. I know why e is used in differentiation and integration etc., though I haven't read quite as much math as I would've liked just yet.
Marc
Wednesday, May 26, 2004
 Recent Topics
Fog Creek Home
|
