INFINTY macro
Opened this issue · 4 comments
The INFINITY macro poses quite a few problems for windows users. If possible, I'd like to avoid using it.
You can attempt to compile (develop branch) ECOS on an ubuntu machine with
CFLAGS="-ansi" make
It should error out with something about INFINITY not being defined. For ANSI C compilers, INFINITY isn't defined in math.h.
Alternatively, we could drop Windows support (its C compiler is stuck with c89--not sure if that's changed) and claim that ECOS is now c99 (?) compliant instead of ANSI compliant. This will probably also save us the hassle of converting // to /* ... */ in future pull requests as well. Personally, I like this option; but given the number of Windows users who use CVXPY, it may not be feasible.
Anyway, maybe just #define INFINITY some-very-large-number? might do it? I did this for Windows with DBL_MAX, but I haven't thoroughly tested it.
Hi Eric, I think that the INFINITY for very large number should work fine.
In my case it is used to make sure a backtracking linesearch does not stray
outside the
feasible set. Can use the largest representable double?
On Fri, Mar 27, 2015 at 12:07 PM, Eric Chu notifications@github.com wrote:
The INFINITY macro poses quite a few problems for windows users. If
possible, I'd like to avoid using it.You can attempt to compile (develop branch) ECOS on an ubuntu machine with
CFLAGS="-ansi" make
It should error out with something about INFINITY not being defined. For
ANSI C compilers, INFINITY isn't defined in math.h.Alternatively, we could drop Windows support (its C compiler is stuck with
c89--not sure if that's changed) and claim that ECOS is now c99 (?)
compliant instead of ANSI compliant. This will probably also save us the
hassle of converting // to /* ... */ in future pull requests as well.
Personally, I like this option; but given the number of Windows users who
use CVXPY, it may not be feasible.Anyway, maybe just #define INFINITY some-very-large-number? might do it?
I did this for Windows with DBL_MAX, but I haven't thoroughly tested it.cc @tiagoakle https://github.com/tiagoakle @hanwang
https://github.com/hanwang—
Reply to this email directly or view it on GitHub
#116.
Santiago Akle
+1 650 919 4833
tiagoakle@gmail.com
Hi,
regarding special numbers, there are also a few comparisons with NAN in ecos.c. These comparisons fail when built with Intel ICC and with FPU traps enabled due to invalid value usage.
Could these x != NAN comparisons be also changed to standard !isnan(x) ?
Sorry to respond so late: I've been heads down in other projects and have only recently got around to catching up.
So we can certainly use the standard isnan functions (macros?), but those only ship with certain compilers and are not part of ANSI C. In particular, this doesn't work well with Windows compilers.
Our best bet is to probably define our own versions of these functions when they aren't already defined and include the library otherwise. It requires a bit of dancing with the C preprocessor, so any help would be welcome. I tried to do this several months ago but ran out of time and gave up.
If the current isinf() definition is sufficient for Windows, using _isnan(x) should suffice too, eg.
#define isnan(x) (_isnan(x))
according to https://msdn.microsoft.com/en-us/library/aa298428(VS.60).aspx