[Ipopt] Number, Index types

[Jonathan Hogg]

As far as the more modern HSL solvers (ma86/ma97) are concerned, there
is internal support for 64-bit integers for the row pointer component of
CSC format (equivalently the number of entries in coordinate format).
Pushing that to the user interface should be possible with relatively
little effort (but doubles the number of APIs we have to support, and
probably compiled code size too). However use of 64-bit integers for row
indexing is not easily supported (and presumably never required in
shared memory usage).

Jonathan.

On 16/07/16 14:58, Stefan Vigerske wrote:
> Hi,
> 
> I think it's more of the latter.
> There are some open tickets about using long instead of int for Index,
> which isn't easy for the same reasons: the interfaces to third-party
> libraries for linear algebra and system solvers would need to convert
> array contents, if Index != int or Number != double.
> 
> Stefan
> 
> On 07/15/2016 08:54 PM, Sean Hardesty wrote:
>> I am working on optimization problems arising in seismic imaging where
>> the
>> number of significant digits in the data is small, and the size of the
>> data
>> is large. It is common practice to use 32-bit floating point numbers for
>> optimization variables and 64-bit integers for indexing. I see the file
>> IpTypes.hpp has typedefs for Number and Index. I tried changing Number to
>> float and got compiler errors because other parts of the Ipopt code use
>> double interchangeably with Number. I have not looked through the
>> code, but
>> I can see that there could be issues in interfacing with BLAS and linear
>> solvers that would have to be handled carefully. Is there a simple way to
>> make it work with the different types, or is the use of the Number and
>> Index types more of an aspiration for the future?
>>
>>     Thanks,
>>     Sean Hardesty
>>
>>
>>
>> _______________________________________________
>> Ipopt mailing list
>> Ipopt at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/ipopt
>>
> 
>