I have been working on my project for the last one year and developed around 600+ tools. The units converter covers almost every possible unit and I am planning to add more to it.
People interested in this should check out Frink. It has been around for a while and has thousands of unit conversions with explanations, as well as a web interface for the unit conversions part
The units list is hilarious and amazingly detailed, a sample:
crocodile := megavolt // used informally in UK physics labs
...
footcandle := lumen/ft^2 // Illuminance from a 1 candela source
// at a distance of one foot
...
// In Britain, the deal is apparently any piece of wood over 6 feet long, over
// 7 wide and 2.5 inches thick. The OED doesn't give a standard size. A piece
// of wood less than 7 inches wide is called a "batten". This unit is now used
// exclusively for fir and pine.
deal := 12 ft 11 in 2.5 in // The standard North American deal [OED]
wholedeal := 1/2 deal // If it's half as thick as the standard
// deal it's called a "whole deal"!
splitdeal := 1/2 wholedeal // And half again as thick is a split deal.
...
parasang := 3.5 mile // Persian unit of length usually thought
// to be between 3 and 3.5 miles
The editorial on Hz is particularly funny and insightful.
// Beware the SI's broken definition
// of Hz. You should treat the radian as being correct, as a fundamental
// dimensionless property of the universe that falls out of pure math like
// the Taylor series for sin[x], and you should treat the Hz as being a
// fundamental property of incompetence by committee.
...
// You are perfectly right. You are perfectly wrong. You look dumb and
// unreasonable. The person arguing the opposite looks dumb and unreasonable.
//
// Hz == YOU CANNOT WIN
//
// (Insert "IT'S A TRAP" image here.)
I don't find this rambling insightful at all. Here is what the BIPM actually says about the topic:
The SI unit of frequency is hertz, the SI unit of angular velocity and angular frequency is radian per second, and the SI unit of activity is becquerel, implying counts per second. Although it is formally correct to write all three of these units as the reciprocal second, the use of the different names emphasizes the different nature of the quantities concerned. It is especially important to carefully distinguish frequencies from angular frequencies, because by definition their numerical values differ by a factor1 of 2π. Ignoring this fact may cause an error of 2π. Note that in some countries, frequency values are conventionally expressed using “cycle/s” or “cps” instead of the SI unit Hz, although “cycle” and “cps” are not units in the SI. Note also that it is common, although not recommended, to use the term frequency for quantities expressed in rad/s. Because of this, it is recommended that quantities called “frequency”, “angular frequency”, and “angular velocity” always be given
explicit units of Hz or rad/s and not 1/s.
Right, you can explain it but that doesn’t make it elegant. This is the equivalent of a function with a comment in it saying “Here be dragons!”.
One very desirable property of a units system is that incompatible quantities have incompatible units. So if I try to add 1 Joule (== 1 kg⋅m^2⋅s^−2) to 1 meter, I’m obviously doing something wrong and I just can’t continue.
But in SI I can take 1 Hertz (==1 s^-1) and add it to 1 radian/second (== 1 s^-1) and SI says sure, that’s 2 s^-1. But it’s not, that’s a totally unphysical thing to do and the answer is nonsense.
There is absolutely no guarantee that the sum of two quantities with compatible units makes any physical sense.
The issue here is that angles are inherently unitless geometrical quantities. "Radian" is merely a reminder that a number represents an angle. There is no way to make it a consistent physical unit.
This is misunderstanding. There are many situations in SI where two units boil down to the same expression in terms on fundamental units, yet addition does not make physical sense.
More clear example: both Gy and Sv are J/kg (m^2 s^-2), but to add two values, one in each of those units, you need to multiply one of them by a coefficient (that coefficient depends on the kind of radiation and specific organ that absorbed this radiation). So somewhere in the math world lives a constant that is unitless 1, but x Sv/Gy, where x != 1 (again that x depends on circumstances).
Those situations just happen. It's how physics work.
That sum to me is both physical and not nonsense, and I think your interpretation is wrong. 1 radian/second != 1 s^-1, but instead ≈ 0.159155 Hz. This is from interpreting a radian as a ratio, in which "doing" one radian in one second is only going over 1/2pi of a whole in a second. So 1 Hz + 1 radian/second, physically and sensibly to me, means ≈ 1.159155 Hz.
I am afraid you may have misunderstood them. It's not that you can't add a centimeter to an inch, it's that you have to convert units first. The unit symbols are intended to help indicate when a unit conversion would be necessary. What many find confusing is the fact that Hz and rad/s are both (in terms of basic physical units) advertised as s^-1.
To resolve the issue, you could define 1Hz as 2pi/s on the grounds that the Taylor series for sin(t) is in "units" of rad/s. You could also define one rad/s as 1/(2pi s), arguing that since the becquerel is 1/s and means "the number of times something happens per second," it would be inconsistent for frequencies to be denominated other ways, and that Hz is applicable to functions other than sin(t), including square and triangle waves, which have no relationship to angles.
I might have misunderstood them, but I tried to argue that I was indeed converting units. Namely, 1 inch + 1 cm = 1.254 in (cm->in implicitly converted).
Also, defining a Hz as 2pi/s seems to be mixing units and quantities, like a Hz is 2 [pi/s] (where [] stores units), where pi is a unit equal to 6.28 [unitless]. Intead, defining a Hz as 2pi/s is to me changing the definition of Hz, unless it's like 2pi / 2pi [1 / s].
>You could also define one rad/s as 1/(2pi s)
I was, specifically 1/2pi [1/s].
But as to your point that things like Hz are semi-meaningless unless attached to physical concepts, I'll agree with that (using a potentially different definition of semi-meaninglessness.)
My original statement that 1 Hz + 1 radian/second (i.e. 1 [1/s] + 1/2pi [1/s]) is both physical (semi-meaningless, meaning somewhat meaningful and fully meaningful when we flexibly attach it to a large range of physical concepts) and non nonsense (again, semi-meaningless until we attach to a physical concept) I think still hold.
The key to me is that we can attach physical concepts to units and measures flexibly (but not arbitarily). Hz is indeed applicable to non-sin functions, like square waves, but then we're all of the sudden talking about "the Hz of the nth harmonic of the square wave" (which has loads of relationship to angles).
If complaining about Hz one should really be consistent and not use tau not radian as the fundamental property of the universe. Like that we could get rid of all those bloddy factor 2s
Years ago, I started a project along those lines and collected a bunch of reference material about a lot of the various units. But, at some point, I had a working program but lost interest in entering all the information that would have needed to have been typed in. (This was long enough ago that there wasn't really an option to cut and paste a lot of it from online.)
It's super cool, but I'm not sure the explanation of how to calculate Fahrenheit to Kelvin is, uh, accurate. ;-) <3
"By using our Fahrenheit to Kelvin conversion tool, you know that one Fahrenheit is equivalent to 255.93 Kelvin. Hence, to convert Fahrenheit to Kelvin, we just need to multiply the number by 255.93. We are going to use very simple Fahrenheit to Kelvin conversion formula for that. Pleas see the calculation example given below."
Most of units contain very generic description because my goal was to work on the tool rather than the content part. But I will optimize it in the upcoming future since I am one guy managing everything.
> We have so many online tools available to convert Volume units, but not every online tool gives an accurate result and that is why we have created this online Volume converter tool.
Then it converts 231 in^3 to 0.99999994293884 U.S. gal, while 1 U.S. gal converts to 231 in^3.
I couldn't find a way of converting from US teaspoons to cubic light-seconds, which is my favorite demo of the GNU utility. Also, do you have a way of adding a time dimension to the conversions? E.g from kibibytes per day to megabits per second?
Tableware sets in the US commonly come with at least two different sizes of spoon. These usually bear no relation to the "measuring spoons" used to measure volume, though they are handy for stirring tea or eating soup (for the small & large spoons, respectively).
For people who cook in the US, a set of "measuring spoons" is a very common kitchen tool.
"Teaspoon" and "Tablespoon" are units of measurement of volume, not bits of silverware. "Tea spoon" and "Table spoon" or "Soup spoon" are pieces of silverware, not units of measure!
Seems like a weird statement. As someone who cooks and bakes, I use teaspoons all the time. Teaspoons for certain spices and seasonings are extremely common in recipes
The library incorporates dimensional units into the C++ type system with an emphasis on correctness (including considerations for overflow, rounding, loss of precision, etc) and minimal runtime overhead.
As a very simple example of what using this library could look like, here is a tiny code snippet taken from one of the tutorials:
In a larger program, of course, the whole point is to avoid using naked "doubles" (or floats or ints, etc) at all, and instead use the library's "Quantity" types, which encode information about their units. Conversions are done automatically, and incompatible operations become compile-time errors.
const auto time = hours(1.0)
const auto distance = miles(65.0)
const auto average_speed = distance/time;
Nice, that looks very interesting. I'll remember it in case I need to do some C++ work in the future again!
I developed a similar library for Nim, `unchained` [0]. Thanks to Nim's extensive macro system it's a pleasure to use (from a short look at the `au`'s docs my biased opinion is it beats `au` on usability :) ).
I got into Qalculate! last year and I haven't found any units in my day to day work as an engineer that weren't built in. Unit conversion is good but the bundling of it with more of the math equation is the ultimate usability win for me.
I also use this. Units are type checking for equations. Qalculate lets you enter the unit for all your known quantities, and tells you the unit for your result. If you don't get the expected unit you know you did something wrong.
I randomly picked "Inductance" as category, and the "units" it provides are basically a dozen or so variants of the "Henry": Attohenry, Gigahenry, Centihenry, Exahenry, Kilohenry, Nanohenry, ....
If this is how you get to "5000 units" then that feels a bit cheaty
Appreciate the effort you put into this. In terms of user flow, I typically need one or two of these use cases at a time. In that case, I just type my conversion into a search engine like Google, and often use their default box.
Can you share what types of use cases you've seen people use KodyTools for?
Thanks for appreciation. Actually, user does not cover all units. It only shows most common one in terms of length. There are various units in terms of weight, area, and length that are used on regional level. If you just look at the area and length category dropdown, you will be suprised.
You have: .5 * (10 m/s^2) * (15 s)^2
You want:
Definition: 1125 m
You have: sqrt((6.673E-11 N*m^2/kg^2) * (5.98E24 kg) / (6780 km))
You want:
Definition: 7671.783 m / s
Not a big fan of having social share buttons scattered across middle of workspace, a cleaner less cluttered look is better. Good work though, looks pretty thorough as far as conversions.
So, the thing about fuel economy is that it is calculated very differently in Europe versus in the US. In Europe, they do liters per 100km, whereas in the US we measure in terms of miles per gallon.
So, mi/g => l/km requires a different kind of conversion than most of the others shown. You have to first convert mi/g to g/mi, then you can convert to l/km and then multiply by 100.
Frankly, I think the European method makes a lot more sense to me, especially as you get to higher and higher levels of efficiency. With mpg, the numbers get stupidly big when you're saving relatively small amounts of fuel. With l/km, the numbers get smaller and smaller as you increase your efficiency, and it shows you how relatively little you're actually increasing the amount of fuel saved.
It looks quite extensive, and should cover almost all practical cases.
The main limitation I see is that it seems you are limited to picking the units to convert between from predefined lists. If someone gave you say a volume specified in nmi ft^2 for instance and you wanted to convert it m^3 you'd have to do nmi to m and ft^2 to m^2 and then multiply the results to get nmi ft^2 to m^3 because nmi ft^2 is not on the volume unit list.
Those cases are probably pretty rare. It is not often that you run in to people who give you say a gasoline consumption rate of 23 picoacres or give you a cookie recipe that calls for 1.6 barn megaparsecs of vanilla. (BTW, those are 0.04 gal/mile and 1 tsp, respectively).
People always mention Frink and GNU Units, but the workhorse of desktop unit-aware calculation is, in my opinion, Qalculate. In addition to being a capable scientific calculator in its own right, its killer feature is the ability to throw 'x' anywhere into an equality, and it will solve for 'x'. AS well as making to/from unit conversion even easier this also often saves you having to rewrite physics equations to isolate the quantity of interest (and thus potentially screwing up factors when eg converting mm^2 to m^2). The composition of units + symbolic calculator is greater than the sum of its parts.
Metric intervention
https://userscripts-mirror.org/scripts/show/130277
> Converting that old French system the Brits are still using to the metric standard of science. ~ foot, inch (00',00",00'00,00'00"), yard, mile, stone, Pound-mass/Lbs., Gallon ~ It will totally convert something heretical like: 1'23 1/4" x 2'12 5/8" into something elegant and civilized like 89.535 cm x 93.0275 cm
This (uhm) didn't take a year to make but it was rather useful when I needed it.
I will add it by today. It will be available in Area category by tomorrow. Thanks for letting me know. I just add units as soon as somebody let me know by twitter or email.
Funny, I would have looked in the length area, as that's how it's usually used. Part of the problem is that first you have to decide if it's 100 yards or 120 yards.
I just googled it after your comment and the conversion of football field came in terms of acre or hectare so I think Area is suitable. I will see what most people are using and based on that I will set its value.
I've never heard of anyone comparing to a football field in the Area domain. Of course this is cultural, but at least in the US - the length is what is commonly compared.
Definitely country-specific, I'd expect it to be used to describe areas (and football stadiums be used to describe "number of people"). But footy fields in Australia are typically oval shaped!
"Olympic swimming pools" can be used for length, area or volume (but "Sydney Harbours" are only used for volume).
PS just tried the tool and couldn't find any of the above "units", not even "football fields".
As an example of a completely different approach, this works out of the box in GNU units (showing both noninteractive and interactive usage):
$ units GeV/c^2
Definition: 1.7826619e-27 kg
$ units
Currency exchange rates from FloatRates (AUD base) on 2023-06-21
3761 units, 113 prefixes, 120 nonlinear units
You have: GeV/c^2
You want: [leave it blank]
Definition: 1.7826619e-27 kg
You have:
Because of these various definitions (a selection of lines pulled from /usr/share/units/definitions.units, I think I have included all the relevant ones recursively):
G- giga
giga- 1e9 # Greek gigas, "giant"
e 1.602176634e-19 C # electron charge (exact)
C coulomb
coulomb A s # charge
A ! # The ampere, symbol A, is the SI unit of electric current. […]
s ! # The second, symbol s, is the SI unit of time. It is defined […]
V volt
volt W/A # potential difference
W watt
watt J/s # power
J joule
joule N m # energy
N newton
newton kg m / s^2 # force
kg ! # The kilogram, symbol kg, is the SI unit of mass. It is […]
m ! # The metre, symbol m, is the SI unit of length. It is […]
c 299792458 m/s # speed of light in vacuum (exact)
(Fun thing, kg being the SI unit. Because of this, gram is defined as millikg!)
I really like the approach of specifying what you have, in absolutely whatever unit you like, and what you want (though I omitted that argument in this case, to just have it show the definition), and having it resolve it.
An excerpt from my ~/.units (which does have some serious stuff in it too, honest):
# Why not? (Question: is the slightly-Welsh-sounding ygazillion, yocto-gazillion, 10⁻²⁴ gazillion, greater or less than one?)
gazillion !
elephant 6.35 tonne
elephant_african 6.35 tonne
elephant_asian 5 tonne
# I want to have ranged values: elephant_baby 90–135 kg. This get complicated because of non-linear transformations, e.g. 2^(1–10) = 2–1024, but log₂-biased.
# baby_grand is also a baby
I'm not sure I understand the sarcasm (i.e. why TB/ns is an unrealistic
A.) ...one gram of DNA can store up to 215 Petabytes or [215,000 Terabytes], knowing that the human being has about 600 grams of DNA [129,000,000 TB]. (1)
B.) Now assume a human is traveling at the speed of sound in air on earth (~343m/s):
343 m/s * 129,000,000 TB * 1/1,000,000,000 s/ns,
The result is that for every kilometer the human travels at the speed of sound, the information stored in that human’s DNA yields a data transfer rate of approximately 44.3 TB/ns. Seems reasonable.
Using a human host was just an example to show there are certainly real possible applications whe magnitudes of these units is useful. DNA-based data storage doesn't necessarily mean humane genome data - you can store any data (1) in a DNA strand and the strands in a container could all be unique datasets. Possible, albeit not yet practical - but to discuss the realm of the possible you still need appropriate units, and TB/ns seems to be appropriate for such an application.
Meh, it was just an example. The point is that extremely dense data storage is now concievable, though perhaps not yet practical (e.g. using a "DNA drive") so this magnitude of units has it's place in the real world.
I think this is a great tool. Not discounting the value of work (which you started long ago) that you have done already, but I am thinking that an LLM could do it much more easily today.
Two notes: When I search for oz and ml nothing comes up. Also there should be a button to swap units like you have on xe.com (ability to swap currencies).
Many cooking utensils I have at home are either in ml or oz but not both.
As a chemical engineer, we would joke about using the worst units in problems. Had a professor specify a volumetric rate in hogsheads per fortnight for a problem once and density in stone per cubic rods
If you already have 5,800 units what's the harm of adding "typical refrigerator (volume)", "typical washing machine (volume)", "American football field (area)", etc...?
Thanks for the feedback. I never said I am not going to add. This is the only reason I shared it here so that I can get some help in adding more units.
I have already added football field in length category. Will add more soon.
https://frinklang.org/ https://frinklang.org/frinkdata/units.txt https://frinklang.org/fsp/frink.fsp