KUnitConversion

[Garret Wassermann]

> I'm the maintainer for KUnitConversion, you can find the maintainer in
> the metainfo.yaml file in each Framework repo [aside: perhaps we need
> to generate a page with this listed?].  I'm also the person looking at
> KStandards, or KCodes as I'm now calling it.  For now KCodes will be
> sticking to the ISO code support and not doing any unit conversion
> stuff, that's a long way away if at all. At the moment I'm talking to
> the Wikidata people about improving their ISO code data so we can just
> become a consumer of their data, rather than having to maintain it on
> our own. I'm hoping to have that resolved soon and will push the code
> forward at that point.

Hi John,
Thanks for the info! I am new to much of this stuff, so let me ask a
potentially dumb question -- what are the ISO codes? From past
conversations I assume you mean switching between formats/currencies
for different countries, but I would appreciate any elaboration so
I understand what is going on and how to help better.

Would unit conversions even go together with the ISO codes, or
would they be better off split off as two different libraries? (perhaps
KStandards for unit conversions and KCodes for ISO?)

> KUnitConversion does have it's limitations which is why I'm thinking
> about how to improve or replace it, but that won't happen any time
> soon so it's best to keep improving it in the meantime.  The main
> thing I dislike is every unit regardless of category being in a single
> enum, which can lead to nonsense like trying to convert 1 meter in
> degrees Celsius. That's a version 2 fix though

That bothers me as well. I am also bothered by what seems to be
(from my admittedly quick look over the source code) a lack of
extensibility. More below.

> You say there are units and features you need
> that we don't support?  The obvious place to start is to implement
> those in the existing library so we understand them better if once we
> get around to designing a new api.  The best place to discuss these is
> always here on list, so can you say what it is you are missing?

A little bit of context -- I'm working on some academic software
and think proper unit conversion would be a great help for some
problems long term. I have done work with electricity/magnetism in
past, but am currently working on a heat transfer project.

Volts, Amperes, Ohms, Teslas and the like are missing, despite being
regular SI units (although magnetism especially uses many CGS
units, so this is where I think such a library may come in handy).

>From heat transfer, more compound units such as a thermal conductivity
(watt per meter-kelvin) are missing, and of course being able
to translate between metric and the old BTUs would be nice.

I am glad to start adding these units to play with the idea, but I think
ultimately it shows a limitation of the current design. It is missing
a few SI base units, and several categories of common units,
and the thought of adding a new category for EVERYTHING out there
seems a bit silly.

A library that allows one to define new derived units in terms of
base units and register them with the library would be really cool.
it could be useful for anyone no matter how specialized the field,
rather than having to update the library itself every time someone
wants a new unit.

I would also like to see a library that allows basic arithmetic with
these units. Perhaps overloaded operators to allow one to add or
multiply quantities and preserve the correct resulting units.
Being able to for example set a = 2 kg, and b = 9.8 m/s^2,
then type c = a * b and have the library know that
c has the unit of Newtons now (or at least, know how to combine
the units and show the resulting kg*m/s^2 and check that it is
equivalent to a newton). It will be useful
as a sanity check on my work, though I also see this being
useful for more educational oriented software.

Obviously this is my whole laundry list of ideas/interests. I am not
sure what is feasible and what might be harder than I expect, but
if we can bounce ideas around and settle on a path forward, I will
be glad to contribute when I can!

In the meantime, I can write up some basic classes for the extra
units I currently need, and see how that fits into the library.

Thanks for your help,

Garret