Opened 15 years ago

Closed 14 years ago

#5 closed defect (wontfix)

OsiRowCut infinity definition

Reported by: mgalati Owned by: somebody
Priority: major Milestone:
Component: Osi Base Class Version:
Keywords: Cc:

Description (last modified by mjs)

OsiRowCut::sense() uses DBL_MAX as infinity.

Change History (6)

comment:1 Changed 15 years ago by mgalati

OsiRowCut::sense( ) and others are not safe across solvers. It compares to DBL_MAX which is not the default infinity for all solvers. OsiRowCut? should have a new member infinity which can be defined at construction (default to DBL_MAX).

char OsiRowCut::sense() const
{
   if      ( lb_ == ub_ )                        return 'E';
   else if ( lb_ == -DBL_MAX && ub_ == DBL_MAX ) return 'N';
   else if ( lb_ == -DBL_MAX )                   return 'L';
   else if ( ub_ == DBL_MAX )                    return 'G';
   else                                          return 'R';
}

comment:2 Changed 15 years ago by lou

This is a fundamental problem in the COIN library. Unfortunately, finite infinity is hard-coded into much of the COIN code. It'll require a project-wide consensus to change this, and no small amount of recoding. In the meantime, the only short-term fix is to make sure infinite infinity never leaks out of the solver. I'm speaking here from experience with OsiDylp?.

comment:3 Changed 15 years ago by mgalati

It is a fundamental problem. But, fixing OsiRowCut? should not be a project-wide issue. OsiRowCut? is not tied to any solver - it is an independent object. Add a member which defines infinity and the object becomes useful - the user of OsiRowCut? is responsible for defining his/her own infinity. For backwards compatibility, make the default DBL_MAX.

comment:4 Changed 15 years ago by mjs

  • Component changed from component1 to Osi Base Class
  • Description modified (diff)

What about using the solver's infinity? OsiRowCut? itself isn't tied to a solver, but each OSI object is. Presumably, the problem loaded into an OSI object had its infinite bounds set to getInfinity().

In fact, there's code in convertToSense() and related methods that performs the same function as the above snippet and its relatives. Why shouldn't we use that? (That code uses getInfinity().) Of course, OsiRowCut? code to set infinite bounds would also have to be changed.

comment:5 Changed 15 years ago by lou

It's not that simple. For example, all the continuous presolve routines have finite infinity hard coded. If an infinite infinity leaks in, they fail. It's just not safe to use infinite infinity if that value is going to get anywhere near CoinUtils. And I'd bet a round of drinks that the same problem exists in large portions of Cgl. Still, I'm arguing from experience in Fall 2004. I don't think the situation has changed, but it might be worth a try.

comment:6 Changed 14 years ago by lou

  • Resolution set to wontfix
  • Status changed from new to closed

This ticket has passed its best-before date, and I don't see us doing anything about it in the near term. I'm going to mark it as `won't fix'.

Note: See TracTickets for help on using tickets.