CoCoA » CoCoALib

Personally I was hoping to drop support for 32-bit platforms, but long on MinGW is only 32-bits. Does MinGW offer long long? I suppose so.

I am a bit concerned that long long may incur unnecessary overhead on some platforms.

We could also have a CoCoA typedef for a 64-bit integer (being one of int, long int or long long int). This would avoid the portability doubts related to int64_t. Not sure this is a such a good idea...?

Personally I was hoping to drop support for 32-bit platforms, but long on MinGW is only 32-bits.

Actually, MinGW-w64-compiled code is still "64-bit code" - just with this difference in the 64-bit data model (LLP64 vs LP64). The original 32-bit MinGW implementation is also rather "dead", by the way.

Does MinGW offer long long? I suppose so.

Yes, it does. And it is guaranteed to be 64 bits wide.

We could also have a CoCoA typedef for a 64-bit integer

This is indeed exactly what I had also thought about, but I was unsure whether it is really necessary when one can also just use long long in the first place.

• Pros we can simply use CoCoA_LONG everywhere where 64-bit values may occur
• Cons interfacing to GMP might become a problem (similarly for any other library which has an API using long)

Indeed, if we want to use a non-standard type for 64-bit values, it'd probably be better to use int64_t (or similar), since these are at least officially documented (but also documented as optional).

Overall, I fear that a "typedef" would cause interfacing problems. Also, I'm never inclined to put in much effort to circumvent obstacles on Microsoft platforms...

To be honest, I would also rather keep support for 32-bit platforms instead of using e.g., long longs which are maybe not compatible with GMP or int64_ts which, on the other hand, are not compatible with some (maybe even all... Haven't tested?) 32-bit platforms.

My current thoughts are that we should avoid using LL/ULL in any (normal) user interfaces, but we may use them internally e.g. they might be useful for some CRT-based methods (assuming LL-arithmetic is not much slower than for (unsigned) long) since there would be only about half as many iterations.

Winfried Bruns sent the following response by email:

That GMP ignores long long (and most likely int_64) is indeed a problem. Normaliz uses the following functions:

inline bool try_convert(long long& ret, const mpz_class& val) {
    if (val.fits_slong_p()) {
        ret = val.get_si();
        return true;
    }
    if (sizeof(long long) == sizeof(long)) {
        return false;
    }
    mpz_class quot;
    ret = mpz_fdiv_q_ui(quot.get_mpz_t(), val.get_mpz_t(), LONG_MAX);  // returns remainder
    if (!quot.fits_slong_p()) {
        return false;
    }
    ret += ((long long)quot.get_si()) * ((long long)LONG_MAX);
    return true;
}

inline bool try_convert(mpz_class& ret, const long long& val) {
    if (fits_long_range(val)) {
        ret = mpz_class(long(val));
    }
    else {
        ret = mpz_class(long(val % LONG_MAX)) + mpz_class(LONG_MAX) * mpz_class(long(val / LONG_MAX));
    }
    return true;
}

Nico Mexis sent the following by email (a few days ago):

That’s a good question. Indeed, long longs perform considerably worse (on average apparently ~ 2x worse according to this guy: https://stackoverflow.com/q/33848357/5894824).