[gmx-developers] 64bit integers

Roland Schulz roland at utk.edu
Mon Sep 7 01:58:03 CEST 2009


ok. I'll change it then.

On Sun, Sep 6, 2009 at 4:58 PM, <hess at sbc.su.se> wrote:

> 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.
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20090906/b08716d9/attachment.html>


More information about the gromacs.org_gmx-developers mailing list