I've noticed the SINC function on the WP 34S, at least in version 3.2r3382, is giving wrong results when in angles modes other than RAD, except when the argument is 1. This is something similar to the current implementation of the Gamma function on the Prime, which gives wrong results in Degrees mode. Sorry if this has been addressed already.
Gerson.
It seems to me that Pauli has to lock after this one.
We'll be fixing any bug, wont we?
Quote:
We'll be fixing any bug, wont we?
No complaint about the Bug Fixing Department, quite the contrary :-)
Not an important bug anyway. Too few people using this function, it appears.
Can you give an example where an error is occurring?
The numbers I'm seeing here are the same as executing:
SIN
RCL/ L
i.e. sin(x) / x
- Pauli
As the argument of SINC is assumed to be in radians, I think it should be rather like:
LocR 001
STOM .00
RAD
SIN
RCL/ L
RCLM .00
Edited: 23 Aug 2013, 8:39 p.m.
Why should radians be assumed? We don't assume radians for SIN and the definition of SINC(x) is SIN(x) / x.
It is easy enough to change the behaviour but I wonder if it is necessary or desirable.
- Pauli
When in degrees or grads there is a discontinuity in x = 0. For x = 1 the function returns 1 (in accordance with the definition), but for x + epsilon and x - epsilon the function returns pi/180 or pi/200, depending on the angle mode. It appears to me sinc doesn't make sense for arguments in degrees or grads, because sinc is a continuous function and sinc(0) = 1.
Gerson.
I understand the problem now.
I see two fixes here:
Neither is difficult.
- Pauli
I don't remember ever seeing sinc using arguments in degrees, but further discussion might be necessary before either choice is made.
Here are two references:
http://mathworld.wolfram.com/SincFunction.html
http://en.wikipedia.org/wiki/Sinc_function
Gerson.
Ahem... this... misconception... again.
Let's get this over with. Degrees are practical units of angular measurement. They only make sense as arguments of circular functions (with real domain). You could measure everything in degrees provided you scaled every other variable accordingly.
x --> x *Pi/180
In fact, you are scaling the variable too in the trigonometric function, it's just you're being quiet about it:
Let's consider the Taylor series for SIN(x). Everyone here will agree with:
SIN(x)= x - x^3/3! + x^5/5! + ...
You can use this to calculate, say SIN(30º):
SIN(x=30º)= 30º - 30º^3/3! + 30º^5/5! + ... = 0.5
Please, evaluate this expression taking 30º as just x=30 and see what happens. What's going on?
The series works for x in radians, and for x in degrees we can drop the degree (º) as long as we write it down as:
SIN(x)= x*Pi/180 - (x*Pi/180)^3/3! + (x*Pi/180)^5/5! + ...
Please evaluate:
SIN(30º)= 30*Pi/180 - (30*Pi/180)^3/3! + (30*Pi/180)^5/5! + ...
Now you got it right!
You can "define" SINC in degrees as long as it is:
SINC(xº) = (180/Pi)* SIN(xº)/x
But you really don't want to use degrees for anything but real trigonometric functions... and then just to write the angles down.
Quote:This is explicitly said in the first link provided by Gerson on the SINC function (under details).
Why should radians be assumed?
Edited: 24 Aug 2013, 1:35 a.m.
The same site's definition of SIN also says the argument is in radians. Following logically on from this, the trigonometric functions shouldn't support degrees and gradians at all.
- Pauli
This makes sense. SINC is fixed. The documentation will need a minor update to match -- in degrees mode SINC(x) = SIN(x) / (PI * x / 180) and in gradians mode SINC(x) = SIN(x) / (PI * x / 200). SINC(30o) = 0.9549296585513720 = SINC(PI / 6 radians).
- Pauli
Good point, I've been too fast to a conclusion.
Manolo's explanation is the right one.
It seems that you missed the punchline of Manolo's explanation:
Quote:
But you really don't want to use degrees for anything but real trigonometric functions... and then just to write the angles down.
SINC argument should be always considered radians, independent on angle setting, just like complex trig functions.
There is simply no use case for this functions where it makes sense to treat input x=30 as 30^o
I concur with Manolo's reasoning. There's simply no use using SINC in any angular mode but RAD.
d:-)
Quote:
SINC argument should be always considered radians, independent on angle setting, just like complex trig functions.
That's my opinion as well. Probably people using SINC have their calculator set to radian most of the time, but we shoudn't count on this. SINC with arguments in degrees is just useless and inconvenient. Anyway, if someone has a good reason for that, I would like to know.
Gerson.
Quote:
There's simply no use using SINC in any angular mode but RAD.
Then why not assuming the arguments are always in radians, regardless of the angular mode? There's no inconsistency in this since the function is never used with practical angle units. A similar behavior occurs with the complex trigonometric functions, as Andrew Nikitin has reminded us. It would require a short note in page 113 of the manual, however.
Quote:
- force radian mode for SINC
I see that's what has been implemented in the latest version (2013-8-25 3448), but now 0 is causing a Domain Error that wasn't there before.
Gerson.
Edited: 24 Aug 2013, 10:32 p.m.
Bummer, accidentally took out the small x guard code.
- Pauli
And fixed in 3450.
- Pauli
Quote:Will be in next edition.
It would require a short note in page 113 of the manual, however.
d:-)
Case closed. Next! :-)
For those who missed the thread, here's an unusual problem involving SINC:
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv020.cgi?read=177273
Gerson.