> 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 _______________________________________________ Gecode users mailing list [EMAIL PROTECTED] https://www.gecode.org/mailman/listinfo/gecode-users
