search

Vidabe / cooking-units

A small units package for cookery books and recipes
7 stars 1 forks source link

Define derived units #14

Closed Vidabe closed 3 years ago

Vidabe commented 6 years ago

Just an idea. Define a command which allows to connect two units. For example:

\newcookingderive{km}{h}{/}

would create the unit km per h, but also km per s, km per min, miles per s, etc. This would need a proper interface, but the idea is basically: Derive from two or more units a whole new set of units.

Vidabe commented 6 years ago

(Just some notes) Currently I think the command would look something like this

\newcookingderivative{ km , h }{#1@#2}{(#1)/(#2)}

In the first argument the units are given. The second defines the unit-key (km@h because a slash is not allowed) and the third argument would take the calculation. This would simply parse through for all unit-keys connected to km (after defining it) (m, in, etc.) and h (d, h, s, etc.).

Problem: If I define km, the unit group length has 7 entries. Time has 5 entries. This alone defines 35 new units. Furthermore, each of this 35 new units gets a key with 35 different values. Those must be calculated. So, each unit gets 35 values. If I am not mistaken this means that 35*35= 1225 times the values must be calculated. In my test cases, this takes quite a long time. A tad too long.

And that is for 2 units. For 3 or more it would take even longer.

So, either I change the design of this command or I rework how the keys-values are created. I was never really happy with how I did it, maybe I redesign it. Could calculate the needed value only when needed and then store it for later uses. Hmmmm ...

Vidabe commented 5 years ago

I decided to implement a experimental version. Currently I am not sure if there is really a reason to implement this. Furthermore, the new syntax is going to be

\newcookingderivative{ km , h }{#1@#2}{(#1)/(#2)}{\sfrac{#1}{#2}}

because I forgot this in the update above.

Depending on the units this creates more keys then I like (trying to figure out how to replace keys (kg=g, etc.) as a whole), but currently it's experimental, so ... yeah.

Vidabe commented 3 years ago

I am kinda happy with the current implementation, which does not create keys, but stores them into a huge property list. Not perfect (an algorithm which decomposes the input would probably be the best, maybe I should check regexp out), but it works.