[gecode-users] Extending Integer Variable

[Filip Konvička]

> Well, nothing is easy ;-)
> 
> As it comes to double one should keep in mind that most CPUs have parallel
> functional units for floats: so, that just runs in parallel to the integer
> and address arithmetic. I once did a little profiling to see what effect it
> has for double and it was considerably less than what I had expected. The
> big problem with doubles start if you store them in memory, bandwidth and
> alignment are the typical problems. But for intermediate results that should
> be okay. But I agree, 64 bit should also be fine. The reason why we didn't
> go for that is that I looked at the assembly code that was generated by gcc
> at that time (maybe three years ago)... It just made me cry. As soon as long
> long becomes C++ standard (maybe relying on the de-facto C++0x standard -
> most likely C++09 - would already be good enough) we will go for 64 bits.
> The main motivation for us is that we use double only for integers which
> limits precision to 48 bits.

:-) I think I've seen some discussions on the gcc mailing lists 
concerning long long arithmetics, maybe some year ago or so...so maybe 
it is better now.

> 128 bits can be tinkered okay. Either rely on compiler extensions and if
> they are not available hack it yourself. 
> 
> Yes, however small the set of propagators might be, we will be interested. I
> would believe that much of the IntVar stuff can serve as a good starting
> point for you. If one gets really serious about float intervals, it becomes
> tricky: it requires symbolic representation of the arithmetic expressions as
> well as variable centered propagation. Quite different.

That's interesting. (Read: I don't understand that :-)) What is 
variable-centered propagation? Do you have any papers about the matter? 
The only implementation of floatvars I've seen so far is the XRI library 
for Mozart, so I was not thinking about doing anything special yet.

I can see that symbolic representation can be useful, but it depends on 
what quality/performance ratio you target. Personally I target 
performance (the tradeoff I see here is that I might not get bit-precise 
filtering).

> Watch out: for some x64 it is still that long is 32 bits (Windows). On
> others it is 64 (MacOS, Linux?). Only long long is 64 at least.

Yes, I was referring to gcc. On Windows things tend to be 
backwards-compatible as *long* as possible :-D

Cheers,
Filip