3 ms·

Can someone break this down for me? val speed = 5.4 m/s // Type = Float[m/s] I understand that the speed variable is automatically assigned a type of Float[m/s

Can someone break this down for me? val speed = 5.4 m/s // Type = Float[m/s] I understand that the speed variable is automatically assigned a type of Float[m/s] based on the m/s there, but I'm confused about how the units are just placed at the end of the value assignment: val speed = {value} {unit} Is this just a F# property that units can be added at the end of value assignment, and F# interprets them as units correctly? Also, anyone know of methods for incorporating units as types in Python? It would be great to have an equivalent method as demonstrated here, where dividing types automatically creates a new type unit, and perhaps even associates with a related type, i.e: type(kg / (m * m * m)) == density

AaronFriel 5y ago
I think the syntax for expressions was extended to allow a `<unit expression>`, with or without angle brackets, at the end of any numeric expression. They're erased at compile time, so at runtime or via reflection you can't inspect the dimensions of a value. The only value of the units - which isn't insignificant - is the compile time checking. Unfortunately the same isn't as easily done in Python: 1. You would need to reify these units as actual constants with overridden operators to track values, and some wacky (if even possible) mypy type shenanigans. 2. The types aren't erased and so would impact the performance of any critical code. F# isn't quite used in high frequency trading, but it does target numeric heavy users like those wanting to write scientific workloads, and units help improve correctness there. But if the types are computed at runtime and not erased, it would be an enormous hit to performance. Unless you can figure out some way to get "3.0 * m" to be a plain old datatype (float) in Python while still retaining type info in mypy/pylance/pyrite. Perhaps there's a way, but I'm not sure. Edit: This Python library seems to be trying to solve for these issues! https://pint.readthedocs.io/en/0.10.1/ https://pint.readthedocs.io/en/0.10.1/ I'm not sure if they've actually solved the runtime performance problem, but I suppose as long as you're not doing unit assignment/conversion in a loop, it should be fine.

AaronFriel 5y ago

I think the syntax for expressions was extended to allow a `<unit expression>`, with or without angle brackets, at the end of any numeric expression. They're erased at compile time, so at runtime or via reflection you can't inspect the dimensions of a value. The only value of the units - which isn't insignificant - is the compile time checking. Unfortunately the same isn't as easily done in Python: 1. You would need to reify these units as actual constants with overridden operators to track values, and some wacky (if even possible) mypy type shenanigans. 2. The types aren't erased and so would impact the performance of any critical code. F# isn't quite used in high frequency trading, but it does target numeric heavy users like those wanting to write scientific workloads, and units help improve correctness there. But if the types are computed at runtime and not erased, it would be an enormous hit to performance. Unless you can figure out some way to get "3.0 * m" to be a plain old datatype (float) in Python while still retaining type info in mypy/pylance/pyrite. Perhaps there's a way, but I'm not sure. Edit: This Python library seems to be trying to solve for these issues! https://pint.readthedocs.io/en/0.10.1/ https://pint.readthedocs.io/en/0.10.1/ I'm not sure if they've actually solved the runtime performance problem, but I suppose as long as you're not doing unit assignment/conversion in a loop, it should be fine.