Beginner questions

[jportway]

Hi -
Could you clarify - does coulomb work entirely at compile time, so that at runtime the resulting values can be unboxed primitives? It seems to be architected to make that possible, but I am not sure from the documentation.

Also - it is not obvious (to a beginner) from the documentation exactly how Coulomb is intended to be used to represent actual values. In my application, I have several things that might be measured in metres, for instance, and I want these all to be different types. I have tried, for instance, opaque type Wavelength=Quantity[Double,Metre] - but this won't work because the type classes for Coulomb don't resolve any more. Should I be defining my own DerivedUnit for Wavelength? Or maybe using value classes? Would the value classes remain unboxed (assuming coulomb values themselves are unboxed)?

Also - is there any way to simplfy the declaration of types so I can write something like "val x:Wavelength = Wavelength(5)" or is this just a question of writing type aliases and methods by hand?

sorry if these quesions are naive - hopefully they might be useful documentation for others facing the same beginner issues.

[benhutchison]

I'm not Coulomb's author but I have used it a fair bit. My take on "how Coulomb is intended to be used to represent actual values": Replace opaque type Wavelength=Quantity[Double,Metre] with type Wavelength=Quantity[Double,Metre] opaque types are for very specific situations and this isn't one of them.

…

On Sat, Nov 4, 2023 at 12:55 AM Joshua Portway ***@***.***> wrote: Hi - Could you clarify - does coulomb work entirely at compile time, so that at runtime the resulting values can be unboxed primitives? It seems to be architected to make that possible, but I am not sure from the documentation. Also - it is not obvious (to a beginner) from the documentation exactly how Coulomb is intended to be used to represent actual values. In my application, I have several things that might be measured in metres, for instance, and I want these all to be different types. I have tried, for instance, opaque type Wavelength=Quantity[Double,Metre] - but this won't work because the type classes for Coulomb don't resolve any more. Should I be defining my own DerivedUnit for Wavelength? Or maybe using value classes? Would the value classes remain unboxed (assuming coulomb values themselves are unboxed)? Also - is there any way to simplfy the declaration of types so I can write something like "val x:Wavelength = Wavelength(5)" or is this just a question of writing type aliases and methods by hand? sorry if these quesions are naive - hopefully they might be useful documentation for others facing the same beginner issues. — Reply to this email directly, view it on GitHub <#525>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXJZHV7ZSG55D2MW5BMELYCTZVPAVCNFSM6AAAAAA64PEB32VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZVHAYDSMJTG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jportway]

Correct me if I'm wrong, but I think the problem with simply using "type" is that this, for instance, will compile fine :

type Wavelength = Quantity[Double, Meter]
type Depth = Quantity[Double,Meter]

def calculateFrequency(p:Wavelength) = ???

val notAWavelength:Depth = 5.withUnit[Meter]
calculateFrequency(notAWavelength)

This isn't type safe at all. If have several different things that all happen to be measured in metres ("wavelength" and "depth", for instance) - there is nothing stopping me passing a Depth where I'm expecting a Wavelength - this is why I was trying to use opaque types. The type safety afforded by knowing the units in which my quanitity is represented doesn't do me much good if I can just pass in a completely unrelated value.

Am I missing something here?

[benhutchison]

Ah, got you. Then I think you want to define Wavelength as a Derived Unit built on Meters.

I've never needed to define my own opaque types with Coulomb; it will break, as you've observed.

[erikerlandson]

does coulomb work entirely at compile time, so that at runtime the resulting values can be unboxed primitives?

1. Yes, coulomb is designed to work at compile time: unit errors are compile time type errors.
2. There is also coulomb-runtime - the main use case is to allow things like configuration files to be loaded, which can only be checked at runtime. At this time coulomb-pureconfig is the only unit aware config loading integration.
3. My original hope was that with the opaque type feature the expressions would indeed all compile down to unboxed numerics. That has not turned out to be the case. You might find this interesting: Boxing code generated by opaque types scala/scala3#12009

[erikerlandson]

See also: https://erikerlandson.github.io/coulomb/coulomb-core.html#unit-conversions

[erikerlandson]

type Wavelength = Quantity[Double, Meter]
type Depth = Quantity[Double,Meter]

@jportway What semantic are you trying to capture here? I ask because there are some subtleties relating to the difference between a "unit" and an "abstract quantity" or "physical quantity" - for example "meter" is one unit representing the physical quantity of "length"
https://en.wikipedia.org/wiki/Physical_quantity

Your types above seem like you might be trying to capture abstract quantities, but I am not sure.

In coulomb abstract quantities are represented by base units. So "length" has no explicit type representation, but is extensionally represented as the set of all unit types that can be converted to base unit Meter.

[erikerlandson]

coulomb does not really define any concept for distinguishing meters that are wavelengths from meters that are depths. In coulomb's umwelt, they are the same, as you showed with your example.

If you want scala to prevent someone from combining "wavelength" and "depth" with a compile time type error, one suggestion off the top of the head might be:

case class Wavelength[V](value: Quantity[V, Meter])
case class Depth[V](value: Quantity[V, Meter])

[erikerlandson]

I might, in theory try to define some new concept. It might be a bit like DerivedUnit but would somehow carve off these types into their own independent algebras, so you get the benefit of coulomb's unit algebras but it (somehow) prevents you from combining things like wavelength and depth.

[erikerlandson]

A solution seems likely to involve abstracting to higher-kinded types. defining an algebra over F[V, U], where F might be Wavelength or Depth, etc, might be elegant. If I can get it right. It would be almost monoidal in nature. Unpacking the values, doing the operation, and repacking them. x: F[V,U] + y: F[V,U] = x.value + y.value (and lift back to F)

[jportway]

Hi Erik - thanks for taking the time to write such a considered answer.
In my current use case I am writing a set of types that represent values used when calculating ocean waves. This is a set of interlinked things like wavelength, frequency, etc. and many of them can also be converted from one into another when in the context of a "Dispersion relation" which provides fundamental equations defining the movement of water waves. I currently have this implemented as a system of value classes, using an implicit trait for the dispersion (since there are different sets of dispersion equations when considering deep sea, and shallow waves, for instance).

The value classes work, but there is considerable overhead introduced due to a lot of boxing and unboxing that goes on, so my hope was that I could build a similar type of system of types using Coulomb that would compile down to primitive types (given your link above it looks like this isn't currently acheivable). Type safety is important to me partly because I'm writing this code so that i can experiement freely with the system later without worrying about whether what I'm doing is valid (I'm not an expert in this domain) - and after exploring Coulomb a bit I'm impressed by the elegance of it so I'm keen to explore whether it could fit, or where i could use it in the future.

Can you explain why you don't think just representing these values as derived units (or indeed, maybe as base units) is a good idea? It seems to be working, at least in part, for me so far. The only issues I've really had so far are :

• things get a little verbose (a lot of "Quanity[Double,Wavelength]" stuff around instead of just being able to use "Wavelength" )
• I can't use the implicit context (Dispersion) that I was using before to allow converstion between these types (at least not using the Coulomb mechanism for conversions)

What other problems am I likely to run into using this approach ?

[erikerlandson]

A problem with derived units is that coulomb will consider them to be convertible. So if I define Depth and Wavelength as derived units of Meter, coulomb will implicitly convert between all three. In other words, this will compile:

val x = 1f.withUnit[Meter]
val y = 1f.withUnit[Depth]
val z = 1f.withUnit[Wavelength]

// they are all convertible because they are derived from Meter
x + y + z

This is the intended semantic of derived units. It is for capturing relations like "you can add meters and yards, with the proper conversions" or "you can add liters and cubic meters." coulomb allows all these because Yard is a derived unit of Meter, Liter is a derived unit of Meter^3, and so on.

You could turn off these implicit conversions with a strict policy:
https://erikerlandson.github.io/coulomb/coulomb-core.html#coulomb-policies

Or you could make them all base units, in which case it will consider Depth and Wavelength to be totally different non-convertible quantities, in much the same way that, say, Meter and Second are different.

The problem with all of the above, in my opinion, is that things like Depth or Wavelength are not really units, per se. They are abstract quantities, or concepts, that are measured in units. And trying to shoe-horn them into unit definitions works at best as a kludge.

I am fooling around with a new kind of definition that I think will better capture this abstract quantity semantic better, and its relation to actual units. I may have a quick prototype today. I suspect you will be able to define implicit relations like Dispersion over these new types, as you were before.

[erikerlandson]

OK, so here is a prototype concept:

coulomb/core/src/main/scala/coulomb/quantity.scala

Line 642 in cf677ed

object test:

In operation it looks like this:

scala> import coulomb.*, coulomb.syntax.*, coulomb.scoped.*, coulomb.testunits.{*, given}, coulomb.test.{*, given}, algebra.instances.all.given, coulomb.ops.algebra.all.given, coulomb.policy.standard.given, scala.language.implicitConversions

scala> val d1 = Depth(1d.withUnit[Meter])
val d1: coulomb.test.Depth[Double, coulomb.testunits.Meter] = coulomb.test$given_ScopedQuantityConstructor_Depth$$anon$1@369d5736
                                                                                                                                                                                                                                              
scala> val d2 = Depth(1d.withUnit[Yard])
val d2: coulomb.test.Depth[Double, coulomb.testunits.Yard] = coulomb.test$given_ScopedQuantityConstructor_Depth$$anon$1@1cb20b87
              
// adding with convertible units works                                                                                                                                                                                                                                
scala> (d1 + d2).quantity
val res0: coulomb.Quantity[Double, coulomb.testunits.Meter] = 1.9144

// good: this is an error, seconds are not a length                                                                                                                                                                                                                                              
scala> val d3 = Depth(1d.withUnit[Second])
-- Error: ----------------------------------------------------------------------
 1 |val d3 = Depth(1d.withUnit[Second])
   |                                   ^
   |                               unit type Second not convertable to Meter
   |----------------------------------------------------------------------------
                                                                                                                                                                                                                                              
scala> val w1 = Wavelength(1d.withUnit[Meter])
val w1: coulomb.test.Wavelength[Double, coulomb.testunits.Meter] = coulomb.test$given_ScopedQuantityConstructor_Wavelength$$anon$2@1089bfb9

// this should be a type error
// LOL this crashed the compiler, which is like a kind of type error                                                                                                                                                                                                                                              
scala> d1 + w1
java.lang.AssertionError: assertion failed while typechecking rs$line$6
[error] java.lang.AssertionError: assertion failed
[error] 	at scala.runtime.Scala3RunTime$.assertFailed(Scala3RunTime.scala:11)
[error] 	at dotty.tools.dotc.ast.tpd$.TypeApply(tpd.scala:60)
[error] 	at dotty.tools.dotc.ast.tpd$TreeOps$.appliedToTypeTrees$extension(tpd.scala:985)

So, this isn't quite as clean as I'd like, but I think I can automatically instantiate ScopedQuantityConstructor using scala-3 metaprogramming, and clean up a couple other things so there is very minimal boilerplate.

Probably AbstractQuantity is a better name than ScopedQuantity.

You can see above that my attempt to add a Depth with a Wavelength failed (which is good!) but instead of failing with a type error I literally crashed the compiler (lol not great!)

[erikerlandson]

@armanbilge lol check out the compiler crash above 🤣

[erikerlandson]

I'm not 100% convinced this is a thing coulomb should officially support. It raises at least as many questions as it answers. For example, what, if any, definition is there for Depth * Wavelength - these types are not closed under multiplication, power, etc.

If all you want is to properly distinguish Depth from Wavelength, then standard case classes are arguably sufficient:

case class Depth(d: Quantity[Double, Meter])
case class Wavelength(w: Quantity[Double, Meter])

[jportway]

Hi Erik,
I obviously can't comment about the scope of your project. Certainly, as you say, case classes (or possibly value classes based on Quanitities ?) would work; my main reason for not wanting to use case classes like this is simply performance (I'm doing mathematical operations on millions of these things), and this is likely not a priority for your project.

However, maybe there needs to be some clarification in the Coulomb documentation about the scope of what you mean by a unit? Especially after having read your posting "Your Data Type is a Unit" - Wavelength felt to me like it should be a unit, but perhaps it is better represented as something that is expressed in terms of a unit (ie. a class which has a single property which has the type of a unit as you have given above). It's entirely possible that this is just my own peculiar misunderstanding - but it seems to me that this might be an area which would be ambiguous for lots of newcomers who would not know when to derive their own unit types and when to be using the existing types. Some guidance would be helpful.

Thanks so much for the effort and thought you have put into resolving this. I am going to continue to experiment with various ways of using Coulomb to represent these kinds of types, and if i come up with anything useful I'll post if back here.

[erikerlandson]

@jportway your questions are interesting, and I'm happy to explore them! While I am pleased with what coulomb does and how it does it, the relation of unit quantities to other abstractions could be very fruitful if I can figure out a satisfying way of representing it.

In terms of performance at scale, it's been on my to-do list for a long time to support something like VectorQuantity[V, U], where the underlying data and bulk operations are all done efficiently over something like Vector[V] or Array[V]. Maybe now is a good time to finally spin up on the scala-3 collection redesign and resurrect #50

[erikerlandson]

also #81

[benhutchison]

I think I hit the same crash, in Coulomb based code. Some case they didn't expect, but Stucki fixed it. And the error output wil be improved in a future version toio. scala/scala3#16861 (comment)

…

On Mon, 6 Nov 2023, 3:27 am Erik Erlandson, ***@***.***> wrote: @armanbilge <https://github.com/armanbilge> lol check out the compiler crash above 🤣 — Reply to this email directly, view it on GitHub <#525 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXJZA2RIIF2P7BNA5TFCDYC646BAVCNFSM6AAAAAA64PEB32VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TIOBQGEZDK> . You are receiving this because you commented.Message ID: ***@***.***>

[erikerlandson]

aha, cool that they have a fix for it

[erikerlandson]

@jportway I started a pull request for doing efficient collections: #530

It defines a QuantityVector[V, U] that properly implements scala's IndexedSeq[Quantity[V, U]] API. So far the only real "optimization" it supports it that the values are stored separately, unboxed, and only lifted to Quantity on access.

scala> import coulomb.*, coulomb.syntax.*, coulomb.units.si.{*, given}, coulomb.collection.immutable.*

scala> val qv = QuantityVector(1f.withUnit[Meter], 2f.withUnit[Meter])
val qv:
  coulomb.collection.immutable.QuantityVector[Float, coulomb.units.si.Meter] = QuantityVector(1.0, 2.0)
                                                                                                                            
scala> qv.values
val res0: Vector[Float] = Vector(1.0, 2.0)
                                                                                                                            
scala> qv(0)
val res1: coulomb.Quantity[Float, coulomb.units.si.Meter] = 1.0

[erikerlandson]

Actually, I'm not sure to what extent "unboxed values" are even a thing in scala 3. Looking at the actual collection implementations, they do not appear to be trying to unbox elements, or use @specialized - to the extent that I can figure out what the new principle is, they seem to be proposing transparent inline as the way to get unboxing style of optimizations.

[erikerlandson]

This is all slightly frustrating to me, since I badly want Quantity[V, U] to compile as a "raw" V. I spent a lot of effort trying to leverage opaque and transparent inline and metaprogramming myself, but as I mentioned earlier (above) the actual byte code doesn't indicate this is happening as much as I'd hoped.