Got a tip for us? Let us know
Aug 26, 2013, 05:32 AM  #1 
using float to calculate sin cos and tan
im trying to calculate sin cosine and tan but im getting the wrong calculation
what am i doing wrong Code:
 (IBAction)sin:(id)sender { float result = sin([conv_display floatValue]); [conv_display setFloatValue:result]; }  (IBAction)cos:(id)sender { float result = cos([conv_display floatValue]); [conv_display setFloatValue:result]; }  (IBAction)tan:(id)sender { float result = tan([conv_display floatValue]); [conv_display setFloatValue:result]; } Last edited by Nermal; Aug 26, 2013 at 05:39 AM. Reason: added code tags 

0 
Aug 26, 2013, 09:29 AM  #2  
Quote:
2. What results do you get? I'd first want to see what results you get before giving any other advice. 

0 
Aug 26, 2013, 09:45 AM  #3 
1. Use doubles instead of floats.
2. What is conv_display and what is [conv_display floatValue] returning? Is it an angle? 3. Angles used by computers are in radians. If [conv_display floatValue] is an angle in degrees you need to convert it from degrees to radians to pass them to trigonometric functions. 4. Why do you take the cosine of [conv_display floatValue] and then set [conv_display floatValue] to it's cosine? Here is some useful code: Code:
#include <math.h> //M_PI defined in this header double degreesToRadians(double x) { return((x / 360.0 ) * (2.0 * M_PI)); }/*double degreesToRadians(double x)*/ double radiansToDegrees(double x) { return((x / (2.0 * M_PI)) * 360.0); }/*double degreesToRadians(double x)*/ Last edited by Senor Cuete; Aug 26, 2013 at 10:05 AM. Reason: typo 

0 
Aug 26, 2013, 09:57 AM  #4  
Quote:
double acos(double x) calculates inverse cosine and returns a value in the range 0 to pi double atan(double x) calculates inverse tangent and returns a value in the range >pi/2 to <pi/2. There is also double atan2(double y, double x) which calculates inverse tangent of y/x, which works for all four quadrants.
__________________
Retina iMac, 15" MacBook Pro, Mac mini with Yosemite Server, 7 other Macs and 5 iOS devices in the household. Yes, it's too many. 

0 
Aug 26, 2013, 10:07 AM  #5  
Quote:


0 
Aug 26, 2013, 05:43 PM  #6 
It's more likely "trigonometric functions in maths express angles in radians". Otherwise even simple formulas like sin' = cos, cos' = sin, would become very, very complicated.


0 
Sep 4, 2013, 08:47 AM  #7 
I have used sin and cos many times and I never mix math with ObjectiveC. I feel like it is easier to use the C scalar types like float, double, and int and then convert the answers I need into ObjectiveC objects later.


0 
Sep 4, 2013, 06:17 PM  #8 
Since nobody has mentioned it, if you are doing trig with float, use the float versions of the trig functions: sinf, cosf, tanf, etc.


0 
Sep 5, 2013, 06:55 AM  #9 
More importantly, if you use a few million of these operations, for example within 3d graphics, there is usually a way to avoid them altogether. But unless you have a very good reason, you should avoid float altogether and use double instead.


0 
Sep 5, 2013, 10:41 AM  #10 
Yes. C (and by inference, ObjectiveC) performs all calculations in double (or larger), never in float, so these float functions can actually end up being less efficient to use once you figure in the conversion times. The only reason to use float is to save memory storing large arrays of values, but with the large RAM sizes these days I wouldn't even bother unless I had a hundred million values to store.
__________________
Retina iMac, 15" MacBook Pro, Mac mini with Yosemite Server, 7 other Macs and 5 iOS devices in the household. Yes, it's too many. 

0 
Sep 5, 2013, 11:15 AM  #11  
Quote:
Quote:
void vvsinf(float *outputArray, const float *inputArray, const int *pointerToArrayLength); void vvcosf(float *outputArray, const float *inputArray, const int *pointerToArrayLength); void vvtanf(float *outputArray, const float *inputArray, const int *pointerToArrayLength); And of course, for extra speed, you can compute sin and cos in one pass with void vvsincosf(float *outputSinArray, float *outputCosArray, const float *inputArray, const int *pointerToArrayLength); There are inverse trig functions, exp and log functions, and a bunch of others, as well as all of the above in double precision if that floats your boat. For more basic operations such as arithmetic on arrays there is vDSP, which even lets you do things like Xj = (Aj + Bj) * (Cj  Dj) all in one pass. That is also the library with FFT functions. From my experience, if you are performing multiple operations on large arrays, it is fastest to process the arrays in chunks that fit in the processor's cache. Operating on 1024 floats at a time with vectorized functions has worked well for me. Last edited by Qaanol; Sep 5, 2013 at 11:31 AM. 

0 
Sep 5, 2013, 01:25 PM  #12  
Quote:
Code:
vmul.f32 Code:
float y = ... float z = ... float x = y * z; When do you ever know or can even measure an angle to more than 6 decimal places accuracy? 

0 
Sep 5, 2013, 01:59 PM  #13  
Quote:
I just did some checking and by default (at least) LLVM generates OS X code like you are seeing. However when I tried gcc on a Linux system and Visual C++ under Windows, it worked like I described.
__________________
Retina iMac, 15" MacBook Pro, Mac mini with Yosemite Server, 7 other Macs and 5 iOS devices in the household. Yes, it's too many. 

0 
Sep 5, 2013, 03:21 PM  #14  
Quote:


0 
Sep 5, 2013, 03:35 PM  #15  
Quote:
BTW. Apple's libraries represent time as seconds since some base date using floating point. Using "float" would give you a resolution of 16 or 32 seconds. 

0 
Sep 5, 2013, 04:47 PM  #16  
Quote:
__________________
Retina iMac, 15" MacBook Pro, Mac mini with Yosemite Server, 7 other Macs and 5 iOS devices in the household. Yes, it's too many. Last edited by talmy; Sep 5, 2013 at 04:58 PM. 

0 
Sep 5, 2013, 05:41 PM  #17  
Quote:
A compiler is allowed to do operations at a higher precision than necessary. And it is allowed to do _some_ operations at a higher precision than necessary, and not others. So if a and x are the same, and b and y are the same, you'd think that a+b and x+y are the same, right? Not if a+b is calculated in long double precision, and x+y in double precision only. It's not a problem today, because on current Intel processors double precision is faster than long double, so long double is only used when you tell the compiler, but a few years ago (before the release of the first Intel Mac) there were eight "long double" floatingpoint registers and nothing else, so that kind of thing would happen. In an extreme case, "if (a + b != a + b) printf ("Weird"); " would actually print "Weird". 

0 
Sep 5, 2013, 11:43 PM  #18  
Quote:
Even expecting two numbers to be equal is a delusion when using FP math. See above. That's normal with FP. And should be taught as such. 

0 
Sep 6, 2013, 12:02 AM  #19  
Quote:
__________________
Retina iMac, 15" MacBook Pro, Mac mini with Yosemite Server, 7 other Macs and 5 iOS devices in the household. Yes, it's too many. 

0 
Sep 6, 2013, 01:35 AM  #20 
Ugh. Working with single precision is a nightmare. Even doing the calculations in double precision then storing the result in single precision sucks. Then it's time to compare! Hooray, let's get some machine delta going on, etc. FP is generally awful, and we make the same mistakes with FP over and over. If you're doing math whose result is important, there are numerical libraries in many languages that can shield you from the garbage. I feel like the burden is on the programmer to prove the tiny precision float (and double, in many cases) provides is guaranteed to work for the use case.
Lee 

0 
Sep 6, 2013, 03:44 AM  #21  
Quote:
If something heavy falls on your head, it might kill you even wearing a helmet. So safety helmets shouldn't be worn because they give you a false sense of security. You can get lost in the woods with a map. So throw away your map before you enter any forest; it only gives you a false sense of security. Quote:
Sure, nothing will go mysteriously wrong if you use float. Things will go wrong in a completely welldefined way, IEEE 754 makes sure of that. Last edited by gnasher729; Sep 6, 2013 at 04:01 AM. 

0 
Sep 6, 2013, 10:54 AM  #22  
Quote:


0 
Sep 6, 2013, 10:59 AM  #23  
Quote:
Quote:
A typical theodolite measures angles to one arc second or 1 60th of a 60th of a degree or 0.00027777777777777... degrees. Precise survey techniques like turning angles left and right or winding up an instrument in highorder surveys result in subsecond accuracy. Astronomical algorithms give constants to long precision because it's necessary to get correct results. The position of any planet is calculated using theories like the VSOP 87 theory which use many hundreds of terms. see: http://www.phpsciencelabs.us/vsop87/. The smallest corrections change the angle by way less than six decimal places but are needed to calculate the problem correctly. High accuracy astronomical calculations are expected to calculate the positions of objects to less than one arc second and to do this you have to calculate the intermediate results to much greater accuracy to avoid rounding errors. I recommend Astronomical Algorithms by Jean Meeus: http://www.willbell.com/math/mc1.htm 

0 
Sep 6, 2013, 11:54 AM  #24  
Quote:
MerriamWebster Dictionary.com Wikipedia (last sentence of the section) 

0 
Sep 6, 2013, 11:57 AM  #25  
Quote:
 Quote:
__________________
Retina iMac, 15" MacBook Pro, Mac mini with Yosemite Server, 7 other Macs and 5 iOS devices in the household. Yes, it's too many. 

0 
«
Previous Thread

Next Thread
»
Thread Tools  Search this Thread 
Display Modes  
Similar Threads  
thread  Thread Starter  Forum  Replies  Last Post 
My sin is Pride. What is yours?  jack170794  iPhone and iPod touch Apps  0  Aug 6, 2013 11:53 PM 
The one Application nearly a SIN not to have on your Mac  MacGuru100  Mac Applications and Mac App Store  2  Jun 23, 2013 02:44 AM 

All times are GMT 5. The time now is 03:56 AM.