Always keep units. Indeed! I could not agree more.
Long ago, as a primary school student, the move to metric, or Standard International units began. At first it was confusing, then it was all largely forgotten by many of my peers as everyone realized such a change was going to take a good long time(tm) to play out in general society.
Ok fine.
But for me, the most interesting thing happened to be the concept of units and how they help to solve problems!
And so it began:
Since that time, I have spent time learning about units and getting everyday references for them committed to memory and or what I can perceive to be how those units feel or look.
Today, my estimates using the trusty eyecrometer (intended) are generally useful right along with sounds and many other basics that happen in life. I can assign a unit to those and to some degree quantify experiences.
It has and will continue to be quite useful.
I strongly recommend just beginning to get familiar with units of all kinds and use them however you can, when you can.
Distressingly few programming languages offer an acceptable implementation of units. It's a wonder we get anything done.
One of the hidden gems of Julia is that it performs multiplication by juxtaposition, so if you define a variable `m`, then `2m` becomes `2 * m`. That plus overloading and multiple dispatch enables a rather nice library, Unitful[1], which does a fairly good job there.
That is an interesting observation. I started out low level in 8 bit land. To me, units broke down to whatever close representation fit into 8 maybe 16 bits... But, you are right! A BASIC with units would have been quite useful back then.
Would have caught a fair number of my bonehead errors.
Later, moving to C and various scripting languages, I just sort of kept doing the same thing. Work units out old school, then comment whatever equations made sense in the program, and then do math, deciding on fixed or floating point depending...
I will have to give Julia a look. Seems intriguing.
I have built my own implementations of units in a couple of functional languages (Haskell and Ocaml) using shadow types. How this pattern works is you tag a numeric type with an extra algebraic type defining the units and then define how the arithmetic operators handle the units. The cool thing about doing it this way is the shadow types compile away so there is zero runtime cost but you can assert and pattern match on the types and put them in your unit tests etc and your code literally won't compile if you mess the units up in some way.
You should check out Frink, a delightful unit-preserving calculator and language optimized for (but not limited to) back-of-the-envelope calculation.
Yes, it has implicit multiplication! :) It also offers exact rational fractions, transparent bigint conversion, and plus/minus intervals that automatically tracks error bars through all arithmetic operations.
I am well aware of Frink, and glad you mentioned it!
Julia has the advantage that you can do things with it that aren't unitful calculations, a classic 80% solution. Frink has the advantage that, well... it's Frink. Really nothing else like it.
Awesome! I admit I'm a bit confused though: Frink doesn't force you to use units (you could ignore them if you wanted, and even skip loading the built-in units on startup), so I'm not sure where the advantage is.
Were you thinking of a specific feature set in Julia that's lacking in Frink? Thanks.
This seems more like Fermi estimation (https://en.wikipedia.org/wiki/Fermi_problem). And it is underrated and also it is really hard. I mean, it is easy for the author here to say "look I threw it into Google and it worked" but practically I have seen many people struggle with these sorts of problems - they get the wrong numbers, they divide instead of multiply, or whatever, and the units don't really help.
"divide instead of multiply" is _precisely_ the thing that units help with. If you keep track of them correctly, and you know the units of the result you want, then it's impossible to make that mistake. (Of course there are other errors that units don't catch, but that's a pretty large class of them gone.)
As I heard it told, the concept that the units are inseparably part of the quantity can be traced back to (who else?) Leonard Euler. My problem is, Euler was so stupendously prolific that he effectively Google-bombed his own name, so trying to dig up my original source has proved futile. :-[
Keep in mind the power behind those reasonings is not really arithmetics itself. Its modelling with proportions, one of the most basic abstract model template we can use. Those are just approximations to get a sense of the scale of the problems and units we’re talking about, giving us a rough idea if we should look into this more or abandon the idea, and we should add to those models one essential feature to be helpful : margins of errors.
The same can be said of spreadsheets. No, they’re not for “calculating.” They’re for mapping your problem so you understand it. The calculations just come along for the ride.
Check out this book where associative algebra an advanced form of arithmetic that can be used as generic modelling for data that conventionallly required relational algebra with SQL and graph theory in networks.
Mathematics of Big Data Spreadsheets, Databases, Matrices, and Graphs:
Always keep units. Indeed! I could not agree more.
Long ago, as a primary school student, the move to metric, or Standard International units began. At first it was confusing, then it was all largely forgotten by many of my peers as everyone realized such a change was going to take a good long time(tm) to play out in general society.
Ok fine.
But for me, the most interesting thing happened to be the concept of units and how they help to solve problems!
And so it began:
Since that time, I have spent time learning about units and getting everyday references for them committed to memory and or what I can perceive to be how those units feel or look.
Today, my estimates using the trusty eyecrometer (intended) are generally useful right along with sounds and many other basics that happen in life. I can assign a unit to those and to some degree quantify experiences.
It has and will continue to be quite useful.
I strongly recommend just beginning to get familiar with units of all kinds and use them however you can, when you can.
They pay off nicely.
Distressingly few programming languages offer an acceptable implementation of units. It's a wonder we get anything done.
One of the hidden gems of Julia is that it performs multiplication by juxtaposition, so if you define a variable `m`, then `2m` becomes `2 * m`. That plus overloading and multiple dispatch enables a rather nice library, Unitful[1], which does a fairly good job there.
[1]: (Julia indexes by one) https://github.com/PainterQubits/Unitful.jl
That is an interesting observation. I started out low level in 8 bit land. To me, units broke down to whatever close representation fit into 8 maybe 16 bits... But, you are right! A BASIC with units would have been quite useful back then.
Would have caught a fair number of my bonehead errors.
Later, moving to C and various scripting languages, I just sort of kept doing the same thing. Work units out old school, then comment whatever equations made sense in the program, and then do math, deciding on fixed or floating point depending...
I will have to give Julia a look. Seems intriguing.
I have built my own implementations of units in a couple of functional languages (Haskell and Ocaml) using shadow types. How this pattern works is you tag a numeric type with an extra algebraic type defining the units and then define how the arithmetic operators handle the units. The cool thing about doing it this way is the shadow types compile away so there is zero runtime cost but you can assert and pattern match on the types and put them in your unit tests etc and your code literally won't compile if you mess the units up in some way.
You should check out Frink, a delightful unit-preserving calculator and language optimized for (but not limited to) back-of-the-envelope calculation.
Yes, it has implicit multiplication! :) It also offers exact rational fractions, transparent bigint conversion, and plus/minus intervals that automatically tracks error bars through all arithmetic operations.
Docs: https://futureboy.us/frinkdocs
Online REPL: https://futureboy.us/fsp/frink.fsp?fromVal=1+furlong+%2F+for...
[Unexpectedly humorous] units data file: https://futureboy.us/frinkdata/units.txt
I am well aware of Frink, and glad you mentioned it!
Julia has the advantage that you can do things with it that aren't unitful calculations, a classic 80% solution. Frink has the advantage that, well... it's Frink. Really nothing else like it.
Awesome! I admit I'm a bit confused though: Frink doesn't force you to use units (you could ignore them if you wanted, and even skip loading the built-in units on startup), so I'm not sure where the advantage is.
Were you thinking of a specific feature set in Julia that's lacking in Frink? Thanks.
What I meant is that Julia is a general purpose programming language, and Frink is a comprehensive and thorough calculation DSL.
You could use Frink for things that aren't its focus, of course. But few would want to.
I am not well aware. Thanks and just another reason why I love this little place on the web.
I learnt this way of thinking about units in my engineering degree, and it is indeed incredibly powerful and I regularly use it.
But I would classify it as "algebra" instead of "arithmetic". Being fluent in manipulations like
60 km/h = 60 km/h * h/3600s * 1000m/km
is not a trivial modality of thought to unlock!
https://en.wikipedia.org/wiki/Dimensional_analysis
This seems more like Fermi estimation (https://en.wikipedia.org/wiki/Fermi_problem). And it is underrated and also it is really hard. I mean, it is easy for the author here to say "look I threw it into Google and it worked" but practically I have seen many people struggle with these sorts of problems - they get the wrong numbers, they divide instead of multiply, or whatever, and the units don't really help.
"divide instead of multiply" is _precisely_ the thing that units help with. If you keep track of them correctly, and you know the units of the result you want, then it's impossible to make that mistake. (Of course there are other errors that units don't catch, but that's a pretty large class of them gone.)
As I heard it told, the concept that the units are inseparably part of the quantity can be traced back to (who else?) Leonard Euler. My problem is, Euler was so stupendously prolific that he effectively Google-bombed his own name, so trying to dig up my original source has proved futile. :-[
Keep in mind the power behind those reasonings is not really arithmetics itself. Its modelling with proportions, one of the most basic abstract model template we can use. Those are just approximations to get a sense of the scale of the problems and units we’re talking about, giving us a rough idea if we should look into this more or abandon the idea, and we should add to those models one essential feature to be helpful : margins of errors.
The same can be said of spreadsheets. No, they’re not for “calculating.” They’re for mapping your problem so you understand it. The calculations just come along for the ride.
Check out this book where associative algebra an advanced form of arithmetic that can be used as generic modelling for data that conventionallly required relational algebra with SQL and graph theory in networks.
Mathematics of Big Data Spreadsheets, Databases, Matrices, and Graphs:
https://mitpress.mit.edu/9780262038393/mathematics-of-big-da...
What a lovely read