[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YOxO0C2JaFeExLry@smile.fi.intel.com>
Date: Mon, 12 Jul 2021 17:16:48 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Jarkko Nikula <jarkko.nikula@...ux.intel.com>
Cc: Joe Perches <joe@...ches.com>, linux-i2c@...r.kernel.org,
linux-kernel@...r.kernel.org,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
wsa@...nel.org
Subject: Re: [PATCH v2 1/3] units: Add SI metric prefix definitions
On Tue, Jun 08, 2021 at 11:42:46AM +0300, Jarkko Nikula wrote:
> On 6/7/21 10:09 PM, Joe Perches wrote:
> > On Mon, 2021-06-07 at 18:23 +0300, Andy Shevchenko wrote:
> > > +#define HECTO 100L
> > > +#define DECA 10L
> >
> > Should it be DECA or DEKA or both?
> >
> > https://www.nist.gov/pml/weights-and-measures/metric-si-prefixes
> > deka Example: dekameter da 10**1 Ten
> >
> > > +#define DECI 10L
> > > +#define CENTI 100L
> > > +#define MILLI 1000L
> > > +#define MICRO 1000000L
> > > +#define NANO 1000000000L
> > > +#define PICO 1000000000000LL
> > > +#define FEMTO 1000000000000000LL
> >
> > IMO: Might as well include all the prefixes up to 10**24
> >
> > EXA ZETTA YOTTA, ATTA ZEPTO YOCTO
> >
> > And how do people avoid using MILLI for KILO, MEGA for MICRO, etc...
> > The compiler won't care but usage could look odd.
> > I find this patch creates more confusion than solves a real problem
> (typo where one zero is missing or one extra) and adds potentially needless
> churn. For instance I don't assume much use for the HECTO now or in the
> future.
>
> How about if absolutely necessary just adding only KILO, MEGA and GIGA and
> questionable defines only after when the real needs arises and can see does
> "1/1000L" etc define cause any troubles to real calculations?
You are probably looking to the I2C codebase, while I based my choice on other
sightings. I agree about the usage count for DECI/CENTI et al., but having them
defined targets at least the following:
1) occupies namespace so if we need them in the future there will be no
ambiguity;
2) provides a name for multipliers for the code to read and understand the
semantics better.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists