I just published the first release of alchemist. I...

# feed

[kevin.cianfarini]

I just published the first release of alchemist. It allows representing SI quantities like Joules, Watts, Kilometers, Kilograms, etc and is modeled after kotlin.time.Duration. It also allows for logical arithmetic like power = energy / duration.

* Documentation
* Repository

[Sargun Vohra]

this is really cool!

[kevin.cianfarini]

Thanks!

[Joel Denke]

This is awesome, covering almost all SI units exists. Want me to start experiment with physics, thermodynamic and chemistry again 😁 Would be awesome if I could done this in college for a lot of repetetive things. Unit conversion, especially UK and US special stuff killing me, like miles vs km or water/boat stuff in general 😂

[Piotr Krzemiński]

https://github.com/vsirotin/si-units and https://github.com/nacular/measured welcome to the team 😄 some comparison of the three would be a good topic for a talk or an article

[kevin.cianfarini]

I expect the main differences are:

• alchemist models everything as value classes.
• alchemist intentionally does not allow modeling arbitrary values. This is done so that we can model quantities as value classes.
• alchemist uses simple APIs that don't overload keywords like as or in. All of the quantities exposed in alchemist are modeled off of Duration.
• alchemist prevents integer overflow or underflow, instead opting to clamp values to Long.MAX_VALUE or Long.MIN_VALUE, which are treated as infinite values internally.

[altavir]

Why not contribute to existing libraries made for that. I also see several issues with the library:
• significant namespace pollution for numbers.
• The effect of value classes must be measured. I don't believe that the effect in common use cases would be sufficient to make it critical.
• Using Saturated numbers have its benifits, but it blocks common mathematical operations as well.
If you are really interested in pursuing this direction, I recommend to start discussion in #CEXV2QWNM. There are several known approaches to unit management and they have their own pros and cons. It is important to have a single API in this regard for other libraries, otherwise it would be unusable. So we must start with design document for that.

[kevin.cianfarini]

Thanks for the feedback!

[Klitos Kyriacou]

So with 3 APIs so far and counting, will someone come up with an slf4j for units? A "Simple Units Façade 4 Kotlin"? ("suf4kt", pronounced "suffocate" 😉 )

[altavir]

@Klitos Kyriacou I don't think so. But if we do, we need a discussion about it. There are a lot of tradeoffs here.

[Klitos Kyriacou]

Thanks, but I wasn't really serious: whereas logging is a very common thing in all kinds of applications, types for units and measures is fairly specialised and so I wouldn't expect there to be a real need for a common API.

[altavir]

I am actually serious here. I want to build an ecosystem for simulation (and physics in particular). And some common APIs for that so different libraries and frameworks could interoperate. But it requires thorough discussion.