rpgoldman / europa-pso

Automatically exported from code.google.com/p/europa-pso
0 stars 0 forks source link

Support 64-bit numeric data types #29

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

The ensemble team wants to be able to take advantage of the full range of
representation for 64-bit numeric data types.

Paul Morris has already done some exploration on a branch, see note below.

Assigning to Mike for now since he seems to have thought about this the most.

From Paul (see also attached diff files) :

I have been able to successfully modify Europa to use the 'long' type for
Time on the openeuropa-new 64-bit machine.  It is probably too late to use
this for the G3 delivery because I would recommend prolonged use before
delivering this to acquire confidence.  However, I would like to record
here the changes needed, and the issues that needed to be addressed, for
future use.

The core Europa files that needed to be modified are the following:

M      TemporalNetwork/base/DistanceGraph.hh
M      TemporalNetwork/TemporalNetworkDefs.hh
M      Utils/CommonDefs.hh
M      Utils/base/Utils.cc
M      ConstraintEngine/component/IntervalIntDomain.hh
M      ConstraintEngine/component/IntervalIntDomain.cc

The most extensive changes are to the IntervalIntDomain files, which were
modified to use an IntInt datatype instead of int.  I have attached diff
files for those.  IntInt is then typedefed to long in CommonDefs.

Note that because the internal representation of values in ALL Domains uses
the double type, IntervalIntDomains and hence Time must still be restricted
to at most 52 or 53 bits (the significand part of double).  I have
restricted it to 50 bits in CommonDefs just to be on the safe side.  This
is still large enough to represent millseconds.

A further issue that arises is that PLUS_INFINITY and MINUS_INFINITY are
used as generalized infinities through the Europa core code, including uses
as ints, unsigned ints, and floats, so I couldn't just reset those to 50
bit sizes.  Instead I separated out PLUS_INFINITE_TIME from PLUS_INFINITY
as separate values, and used the former for Time and IntInt uses, and kept
the latter for generalized uses.

One caveat is that durations (but not start/end times) are still restricted
to [1, PLUS_INFINITY] because there are several places in the 
NddlResource.cc and NddlToken.cc files, where IntervalIntDomain(1,
PLUS_INFINITY) is called for durations, that I didn't want to change.
Another caveat is that PLUS_INFINITY needs to be chosen so that

       PLUS_INFINITY = (int)(float)PLUS_INFINITY

because the +inff float value in the NDDL Resource definitions gets
translated to PLUS_INFINITY and is then checked to be <= PLUS_INFINITY,
which could fail if there is roundoff error in the (int)(float) cast.
I was able to make PLUS_INFINITY be INT_MAX/2 + 1, which casts ok.

These considerations allowed the following definitions to work in the
CommonDefs.hh file.

#typedef long IntInt;
#DECLARE_GLOBAL_CONST(IntInt, g_maxInt);
#DECLARE_GLOBAL_CONST(IntInt, g_infiniteTime);
#DECLARE_GLOBAL_CONST(IntInt, g_noTime);

#define PLUS_INFINITE_TIME (1125899906842624) // 250 (double mantissa)
#define MINUS_INFINITE_TIME (-1125899906842624)

// NDDL use of float +inf relies on
// PLUS_INFINITY = (int)(float)PLUS_INFINITY
#define PLUS_INFINITY ( INT_MAX/2 + 1 )
#define MINUS_INFINITY ( -INT_MAX/2 - 1 )

(These are the effective changes for INFINITE_TIME, but should be done in a
cleaner way in terms of g_maxInt and g_infiniteTime.)

Now the 'long' definitions of Time in previous versions of the
TemporalNetwork could be restored and work with a 64-bit long.

I also had to replace PLUS/MINUS_INFINITY in the DynamicEuropa files by
PLUS/MINUS_INFINITE_TIME where appropriate (i.e. for Time uses).

Paul

Original issue reported on code.google.com by miata...@gmail.com on 15 Sep 2009 at 3:47

GoogleCodeExporter commented 9 years ago
Committed in r5923.  I fully expect there to be bugs and revisions required.

Original comment by miata...@gmail.com on 1 Dec 2009 at 4:15