[gmx-developers] 64bit integers

[hess at sbc.su.se]

Both names are not good.
I guess gmx_large_int_t is best.
After 4.1 we will replace it with int64_t.

Berk

> The hack is cool. I guess the best is:
> size_t sz;
> printf(gmx_step_pfmt,(gmx_step_t)sz);
>
> (We will rename gmx_step_t in gmx_long_t or gmx_int64_t. This might upcast
> it from 32 to 64bit but that does not hurt. I wrote this before but
> without
> example it was not understanble)
>
>
> On Sun, Sep 6, 2009 at 9:57 AM, Sander Pronk <pronk at cbr.su.se> wrote:
>
>> Oops.. that only works in hexadecimal.
>> Sander
>>
>> On Sep 6, 2009, at 15:55 , Sander Pronk wrote:
>>
>> you're right; if it's only found in smalloc.c, you could try, as a real
>> hack:
>> size_t sz;
>>
>> #if (SIZEOF_SIZE_T > SIZEOF_INT)
>> printf("%u%u", sz >> (SIZEOF_INT*8), (unsigned int)sz);
>> #else
>> printf("%u",sz);
>> #endif
>>
>> with some additional code to leave out any leading zeroes if that's
>> important to you.
>>
>> Sander
>>
>>
>> On Sep 6, 2009, at 12:00 , Roland Schulz wrote:
>>
>> well under windows long is only 32 bit. Also size_t is usually unsigned.
>>
>> should we cast it to gmx_step_t (or some type derived from it) and then
>> print it?
>>
>> On Sun, Sep 6, 2009 at 5:01 AM, Sander Pronk <pronk at cbr.su.se> wrote:
>>
>>> I think that would be %zd according to C99. It's probably safer to use
>>> %ld, because it's C89 compliant (not all compilers support C99), and it
>>> happens to coincide with the width of size_t on all platforms I know
>>> of.
>>>
>>> Sander
>>>
>>>
>>> On Sep 6, 2009, at 06:33 , Roland Schulz wrote:
>>>
>>> Hi,
>>>
>>> in smalloc %u is used for size_t. This is not correct. Is it OK to
>>> change
>>> this to the correct %z? I'm asking, because I don't know whether it is
>>> supported by all compilers.
>>>
>>> Roland
>>>
>>> On Mon, Jul 13, 2009 at 4:36 AM, Berk Hess <hess at cbr.su.se> wrote:
>>>
>>>> Hi,
>>>>
>>>> long long int might not exist on some architectures.
>>>> To be really on the safe side, you should define a new type using
>>>> the same checks as for gmx_step_t, or simply define a new type using
>>>> gmx_step_t.
>>>>
>>>> Berk
>>>>
>>>> Berk Hess wrote:
>>>> > Hi,
>>>> >
>>>> > There is a gmx_step_t defined in include/types/simple.h which is 64
>>>> bit
>>>> > when possible.
>>>> > But for this case I would simply use long long int for the moment,
>>>> > which will be 64 bit in nearly all cases.
>>>> >
>>>> > Berk
>>>> >
>>>> > Erik Lindahl wrote:
>>>> >
>>>> >> Hi,
>>>> >>
>>>> >> Gromacs 4.1 won't require 64 bit support, but Gromacs 5 will (we
>>>> will
>>>> >> have gmx_int64_t, etc.).
>>>> >>
>>>> >>
>>>> >> On Jul 10, 2009, at 6:42 PM, Roland Schulz wrote:
>>>> >>
>>>> >>
>>>> >>> Hi,
>>>> >>>
>>>> >>> which integer type should be used for integers that should be
>>>> 64bit
>>>> >>> if available.
>>>> >>>
>>>> >>> My current problem: ndim*ndim*4 in gmx_covar overflows for more
>>>> than
>>>> >>> 7723 atoms.
>>>> >>>
>>>> >>> One could use:
>>>> >>> - long (is only 32bit on windows)
>>>> >>> - long long (is always 64bit, not defined in C89)
>>>> >>> - size_t (is the size of pointer)
>>>> >>> - same typedef
>>>> >>>
>>>> >>> - One shouldn't use long, since it wouldn't solve it on windows.
>>>> >>> - Using "long long" is slow (in this case unimportant) and will
>>>> give
>>>> >>> warning when passed to snew or memcpy.
>>>> >>> - size_t doesn't seem very clean and will give warnings when
>>>> passed
>>>> >>> to printf (unless first upcasting to "unsigned long long" and then
>>>> >>> using %llu).
>>>> >>>
>>>> >>> Is C89 support required?
>>>> >>> Is it OK to use size_t for those integers?
>>>> >>>
>>>> >>> What is the best option?
>>>> >>>
>>>> >> I would use size_t since that is ISO C at least. Check
>>>> >> include/types/simple.h - Berk has added some formats for printing
>>>> >> steps, that we should also augment to include windows, and change
>>>> so
>>>> >> they aren't so step-specific.
>>>> >>
>>>> >>
>>>> >>
>>>> >>> BTW: Is it OK to change save_calloc and save_realloc to size_t
>>>> >>> (currently "unsigned")?
>>>> >>>
>>>> >> Yes, that would agree better with ISO C.
>>>> >>
>>>> >> Cheers,
>>>> >>
>>>> >> Erik
>>>> >>
>>>> >> _______________________________________________
>>>> >> gmx-developers mailing list
>>>> >> gmx-developers at gromacs.org
>>>> >> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>> >> Please don't post (un)subscribe requests to the list. Use thewww
>>>> >> interface or send it to gmx-developers-request at gromacs.org.
>>>> >>
>>>> >
>>>> > _______________________________________________
>>>> > gmx-developers mailing list
>>>> > gmx-developers at gromacs.org
>>>> > http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>> > Please don't post (un)subscribe requests to the list. Use the
>>>> > www interface or send it to gmx-developers-request at gromacs.org.
>>>> >
>>>>
>>>> _______________________________________________
>>>> gmx-developers mailing list
>>>> gmx-developers at gromacs.org
>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>> Please don't post (un)subscribe requests to the list. Use the
>>>> www interface or send it to gmx-developers-request at gromacs.org.
>>>>
>>>
>>>
>>>
>>> --
>>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>>> 865-241-1537, ORNL PO BOX 2008 MS6309
>>> _______________________________________________
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>> Please don't post (un)subscribe requests to the list. Use the
>>> www interface or send it to gmx-developers-request at gromacs.org.
>>>
>>>
>>>
>>> _______________________________________________
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>> Please don't post (un)subscribe requests to the list. Use the
>>> www interface or send it to gmx-developers-request at gromacs.org.
>>>
>>
>>
>>
>> --
>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>> 865-241-1537, ORNL PO BOX 2008 MS6309
>> _______________________________________________
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-developers-request at gromacs.org.
>>
>>
>> _______________________________________________
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-developers-request at gromacs.org.
>>
>>
>>
>> _______________________________________________
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-developers-request at gromacs.org.
>>
>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> 865-241-1537, ORNL PO BOX 2008 MS6309
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.