GAMS `eps` isn't the same as Numpy EPS

[jebob]

GAMS eps is a special value for an arbitrarily a small number [sic] and has all the logic of an infintesimal,

• eps * 100 == eps
• eps + 1e-100 == 1e-100

An eps in a GDX is currently converted to np.finfo(float).eps, defined as "The smallest representable positive number such that 1.0 + eps != 1.0." which is about 2.220446049250313e-16 on my machine. This is in line with the python definition but doesn't have the infitesimal properties.

• np.finfo(float).eps + 1e-100 == np.finfo(float).eps returns True due to floating point error

I propose changing all references to np.finfo(float).eps to np.finfo(float).tiny, which is about 2.2250738585072014e-308 on my machine.

[jebob]

Sadly, the literature on what epsilon is seems to be inconclusive.

[jebob]

Actually, in GAMS eps eq 0, so maybe it should map to zero?

[jebob]

The documentation for the embedded code feature shows they map EPS to 0 (default) or 4.94066E-324.

[elainethale]

@jebob - I think it makes sense to follow what GAMS does and either map to ~1E-300 or 0. I lean toward the former (or explicitly providing the option), because in my experience part of the point of preserving eps values in GDX is to indicate that something is there/something has been calculated rather than is missing. That is, if the default maps eps to 0, that information (an actual rather than a missing value in the GDX file) may get lost.

[jebob]

Makes sense to me, I lean towards 1e-300 as well.