On 16 December 2017 at 14:26, Berthold Stoeger <[email protected]> wrote: > On Freitag, 15. Dezember 2017 15:04:49 CET Lubomir I. Ivanov wrote: >> On 15 December 2017 at 11:24, Berthold Stoeger >> >> <[email protected]> wrote: >> > On Mittwoch, 13. Dezember 2017 23:34:32 CET Dirk Hohndel wrote: >> >> > On Dec 13, 2017, at 11:31 AM, Berthold Stoeger >> > >> > Concerning the float warning, I have a patch that turns all float >> > calculations into double calculations sitting around for a few weeks. I >> > think float is like short: only to be used in very specific >> > circumstances. But I'll let the pros decide. >> >> i would post the patch as a PR. >> 'float' is more like 'int' (32bit), so it's good to have a small data >> type with less precision and not always rely on 'double' or (64bit >> long). > > From a bit-representation point of view, this is correct. From a more abstract > language point of view I rather get the impression that > - short ~ float > - int ~ double > - long ~ long double > - long long ~ unsupported (is your FP algorithm numerically unstable?) > The reason being that floating point literals (e.g. 1.0) represent doubles. > You > have to actively force single-precision floating point calculations by writing > things like "x * 1000.0f". >
ok, i see what you mean. "double" is the default floating point format in C. so yes, "float" is like a non-default sized type e.g. "short", yet one's variable might fit in a "short" and it's perfectly fine to use the non-default type. while nowadays we don't have much of a size restrain using the smaller type, it could be a good indication that we don't actually need the whole 64bit precision for this variable. the same way one could use a "char" vs an "int". on the other hand, if this causes more trouble than benefits, it's probably best to just convert all the calculations to be with "doubles", have consistency and silence the -Wall warnings. lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
