0

I am trying to integrate FDLIBM library (http://www.netlib.org/fdlibm/) into my Swift based (with some objc and c code too) iOS app. However, some of functions there are conflicting with math.h which is automatically included in iOS, i.e. sin, cos,acos, asin, pow, etc. So the project does not compile. I do need to use these functions in the FDLIBM.

These are some of the functions defined in fdlibm.h (http://www.netlib.org/fdlibm/fdlibm.h) which are duplicate to math.h

/*
 * ANSI/POSIX
 */
extern double acos __P((double));
extern double asin __P((double));
extern double atan __P((double));
extern double atan2 __P((double, double));
extern double cos __P((double));
extern double sin __P((double));
extern double tan __P((double));

extern double cosh __P((double));
extern double sinh __P((double));
extern double tanh __P((double));

extern double exp __P((double));
extern double frexp __P((double, int *));
extern double ldexp __P((double, int));
extern double log __P((double));
extern double log10 __P((double));
extern double modf __P((double, double *));

extern double pow __P((double, double));
extern double sqrt __P((double));

Does anyone have a solution for this? Any advice and tips will be appreciated. Thanks.

Update: To give more background about what I am doing, we are building a cross platform app (Android and iOS for now) using the same backend service. There are critical float point calculations we need to make sure the results are the same for both side. Based on our testing, the results of sin(), cos() and some other functions in fdlimb on Android is different from the results of using same functions in math.h in iOS. So I am trying to integrate fdlibm into iOS to see if we can get the same results.

So if there is a way to solve the root problem, which makes the floating point calculation exactly the same for iOS and Android for these functions pow(), sin(), cos(), asin(), acos(), atan2(), I don't have to integrate fdlibm.h

Zhao
  • 904
  • 1
  • 11
  • 34
  • C does not support _methods_. Sure this is not Objective-C only? – too honest for this site Feb 24 '16 at 19:46
  • @Olaf thanks for the reply. I meant to say functions. I just modified the description to make it clearer. Thanks. – Zhao Feb 24 '16 at 19:55
  • Why do you want to use the fdlibm implementations instead of the native libm? – Stephen Canon Feb 24 '16 at 20:00
  • @StephenCanon we are build cross platform apps using the same back end service. We want to make sure the calculation for floating point the same for both iOS and Android. I am not very familiar with the native libraries in iOS. I did see a `libm.tbd` in iOS earlier but was not sure if that is the same as `fdlibm`. If it is the same as fdlibm, I definitely want to give it a try. We tried to compare results in fdlibm in android with those in math.h in iOS, the results are not exactly the same. Thanks for pointing it out. – Zhao Feb 24 '16 at 20:05
  • 2
    It will require more than just using fdlibm to get identical cross-platform results; you'll need to ensure that, e.g. fma formation is disabled on all platforms, that NEON is either used or not used for floating-point arithmetic uniformly on both platforms, that flush-to-zero is either enabled or disabled uniformly, etc. You'll also need a story for x86 if you're targeting it (specifically, disabling x87 code generation). This is a complex goal without easy solutions. – Stephen Canon Feb 24 '16 at 20:10
  • 1
    (And to answer your question, the iOS libm is not the same as fdlibm; they do share some history, but have diverged almost completely over the past 15 years or so). – Stephen Canon Feb 24 '16 at 20:14
  • @StephenCanon thanks a lot for the information. This is very helpful. Myself is have very little knowledge about this. Our architect made the decision, and I am trying to figure it out to verify. I will definitely pass these information over to our architect. Btw: when you mean native libm, do you mean the ones in `math.h` or the one in `libm.tbd` in iOS? I have no idea about what's in `libm.tbd`. Really appreciate your replies! – Zhao Feb 24 '16 at 20:16
  • I see. thanks a lot for the clarification. Appreciate it! :) – Zhao Feb 24 '16 at 20:17
  • libm is the name of the dynamic library; math.h is the name of the header that declares the interfaces. They are two views of the same thing. – Stephen Canon Feb 24 '16 at 20:17
  • @AlexWien I guess that's the case. Thanks for the reply. Have a good day. :) – Zhao Feb 24 '16 at 20:26
  • 1
    From the comments this looks to much work, consider a work around, e.g on server side round all floating points such that the last digit would be removed. (Java once detected a difference in the last digit between two plattforms and decided to calculate all Math in Software) – AlexWien Feb 24 '16 at 21:07
  • @AlexWien thanks a lot for the advice, I think that's good alternative solution although our app might not be able to afford that round trip to server. I will bring this up to the team to decide though. For our case, it seems for some situations, it is exactly the difference between last digit. For example `sin(40023beb78080000) = 3fe84cb583f88ddc` versus `sin( 40023beb78080000) = 3fe84cb583f88ddd`. Add the numbers are converted to hex string due to some known iOS swift print bug. Really appreciate your help. We will think about other workaround too if none mentioned here works for us. :) – Zhao Feb 24 '16 at 21:27

2 Answers2

1

Just in case this is helpful to other people in the future: we ended up renaming all the conflicting functions and resolve any duplicate declarations. Now it works pretty well although there are a lot of warnings. Later plan is to wrap this into a dynamic framework to consume. Maybe later we can even open source it.

Zhao
  • 904
  • 1
  • 11
  • 34
0

From the comments this looks to much work, consider a work around, e.g on server side round all floating points such that the last digit would be removed.
Sun (Java) once detected a difference in the last digit between two plattforms and decided to calculate all Math in Software. They called that StrictMath.

AlexWien
  • 28,470
  • 6
  • 53
  • 83