Units

[joshcol9232]

Maybe have optional units in calculations, and convert the output into SI units. The units could be distinguished in some way, such as curly brackets or something: 10{m/s}.

Then in calculations, the output could be returned as SI units, or maybe we could add some other syntax like 10{m/s} = {miles/hour} and it would output in the desired unit.

This would be useful for things like physics/engineering etc where you are given units in various forms. So for example you could do 3{cm} * 100{GHz} to get the speed of a wave in {m/s} (c = wavelength * frequency), or instead do 3{cm} * 100{GHz} = {km/hour} to get it in kilometers per hour.

I think this would be quite tough to implement but I am just throwing out some ideas :)

[PaddiM8]

Yeah, I want this too. I'm currently exploring various ways of implementing this. Thanks for the suggestion!

[PaddiM8]

I created a branch for the development for units. At the moment, it is not stable at all and mostly experimental. Branch: https://github.com/PaddiM8/kalk/tree/units
I was able to do the following:

unit m = 100cm
5m/25cm
>> 20
25cm/5m
>> 0.05

[PaddiM8]

Update: It now works for a lot more types of expressions. There are still a lot that needs to be done, but I feel like this is actually going to work! When you write eg. unit deg = (rad*180)/pi it will automatically create a inverted one, eg. unit rad = (deg*pi)/180 so that you can do unit conversion both ways without defining it for both.

What's next? Well... making it so that the inverter can invert built-in functions (eg. sin to asin), a to keyword that let's you convert between units, more error checking, unit tests, adjusting the angle unit system so that you can still set degrees as the default angle unit if you want to, and some more things.

When it comes to parsing... What @Eggmund suggested would probably be much faster and less awkward to parse, but I think this way might actually work out great! We'll see though, might have to change it.

Damn it, all the files weren't added in the first commit... my enter key is wonky

[joshcol9232]

Nice work! Looks good :) . I was thinking an external crate such as simple_units (although I have no idea if this crate in particular is any good) could be used to have most common units predefined, so that units like m do not need to be defined. Or instead I wouldn't mind helping out with defining some common units within kalk. However this will probably interfere with variables made by the user unless some special syntax is used (such as the curly brackets i suggested ;) ).

[PaddiM8]

I just merged it with master (and made it clear in the README it's still experimental). Hm yeah, I've been thinking about which units should be included by default. I've made it simple to define standard units (add them in the INIT constant in prelude.rs), and did include deg/rad units by default. As you said, having too many default units could clash with user-defined variables... A solution could be to provide sets of units, that the user can choose to use. Eg. one for physics units, one for day-to-day units, etc. Thank you for helping out with this btw!

[joshcol9232]

Nice, and no worries happy to try and help :) It is a great project and I will probably end up using it quite a bit myself lol. I have an idea on conversion:

• Provide the base SI units (which are the standard units that most other scientific units are derived from, see: https://en.wikipedia.org/wiki/SI_base_unit), which is only 7 units so should be fine in terms of clashes.
• Units should be defined in terms of SI units. For example, degrees celsius would be unit C = K + 273, where K is the SI unit Kelvin. Or another example, unit miles = m * 1000 * 1.609344 where m is the SI unit.
• During calculation, convert all units into SI units, then once finished convert the answer back into the user's desired unit. This makes it absolutely certain that all scientific equations people may use work fine and produce the correct output.

I like the idea of having sets of units, maybe even allow users to create/save/share unit sets would be cool. I am happy to help out wherever possible.

[joshcol9232]

With that last suggestion, I guess the user can already do that with the to syntax. However for making conversion easier to handle, maybe having the base SI units as built in units will make conversion easier, as every defined unit will then be able to be boiled down to the base SI units, and can then be converted into the desired unit.

[PaddiM8]

Hm yes, providing the SI units is probably a good idea.

[matu3ba]

Hey @PaddiM8 , you can likely just use parts of rink or ping the maintainer. The project is specialised on unit conversion. You project looks to have more focus on math formula stuff with variables, sums etc.

[jhugman]

Not sure if this helps. I wrote the guts of https://turo.io : a calculator/notepad that supports units.

I saw this issue, so thought I'd write down some things that I learned or wish I'd learned earlier. I hope it's helpful.

• add a user-definition language, preferably that the user can re-define the built in one. User-defined sets sound fab!
• Start at dimensions, and build everything on top of that. Being able to reason about units is almost impossible if you don't.
• Naming dimensions should be part of the definition language. e.g. unit 1 mph = 1 mile/hour, Speed
• Simple ratios (e.g. 1s = 1000ms, 1 fortnight = 14 days) between units seem to work for 95% of the time. It makes the maths /much/ easier if you can depend upon it. It becomes possible to do arbitrarily complicated unit conversions. I never worked out how to deal with:
  • non-linear units e.g. dB get weird when combining with other units e.g. dB/m^2
  • linear units with an offset e.g. temperature. Complex conversions like 1 lb/°F in kg/°C are similarly weird.
• I love the idea of finding the inverse of a unit definition, but I think this ends in Let's Write A CAS.
• If you can depend on the number representation's accuracy, converting into and out of a single unit per dimension (e.g. 12 inch to feet converts 12 inches to m then m to feet) simplifies things hugely. It's not the end of the world if you can't depend on the accuracy of your numbers, but you'll need to eat the complexity of avoiding accumulating errors.
• Make every operation unit aware; each familty of operations has its own rules: e.g. 1 lb + 1 kg, 5 miles / 10 seconds, sqrt(1 acre), sin(pi/4 radians). Freeing the user from /when/ to convert as well as /how/ to convert becomes magical.
• In the parser, treat the unit as any other term. I wish I'd discovered this earlier. (e.g. $ x == x $ and (x + y) m), with a precedence between * (explicit multiplication) and ^ (raised to the power of).

I haven't a lot of bandwidth at the moment to help, but I wish you well in your endeavour.

[PaddiM8]

@jhugman Thank you so much, this is incredibly valuable! This will definitely help when I find the time to do proper units!

[ghost]

As a sidenote, I would also suggest looking at qalc for ideas on how to handle this feature.

[ad-si]

And I would suggest looking at https://github.com/sharkdp/insect, which also has very good unit support 😁