Unit conversion on numeric TI-Nspire
Nelson Sousa
TI-Nspire does not.
On one hand, the way unit conversion works on TI-Nspire CAS actually
uses CAS features: it allows creating new units, defining new unit
types, converting into non-existing units (you can store 1000_potatoe
in a new unit called _kpotatoe and then convert 300_potatoe to
_kpotatoe), etc. But the actual conversion between units is not a CAS
thing, it's only numerical. So, there's nothing that hard on creating
a unit conversion program on TI-Nspire, is it?
Well, yes and no.
For those of you not that interested in knowing how the algorithm
works (although, I must tell you, its simplicity makes me very proud),
here's the link:
http://nelsonsousa.pt/index.php?lang=en&cat=2&subcat=3&article=34
Features:
- convert program: converts anything into anything. Example:
convert("c","kph") or convert("c","ft/s") are valid conversions; also
convert("600mph","c") is a valid conversion. Remark: conversion of
temperature scales in this program amounts to convert "increases in
temperature", not temperature values.
- tmp_cnv: converts temperature values between different scales
(Celsius, Fahrenheit, Kelvin and Rankine).
- value: displays a given unit or constant in SI units (usefull if
one's interested in converting a unit but doesn't know what are that's
unit's or constant's dimensions)
- help: lists all available units.
All units and constants on TI-Nspire CAS are defined, as well as all
the constants. I resisted the urge to define more and more units.
Names were kept as faithful as possible (exceptions are "minute" and
the 4 temperature scales) and the numeric values used are the same.
Limitations:
- if one chooses convenient irrational exponents for units (which is
"a bit" awkward), it's possible to convert between incompatible unit
types;
- We cannot parse expressions like "1km+500m";
- unlike TI-Nspire CAS I can't convert "c" into "cm". On TI-Nspire CAS
it gives cm*Hz as destination units. This program rejects that; all
dimensions must be explicit.
Feedback, as usual, is more than welcome. Also, feature requests are
accepted, although no warranties, either expressed or implied, are
given. ;)
-------------------------------
Algorithm starts here
-------------------------------
What's the big deal of converting units?
Well, there's nothing to it, if you convert only length units, for
example. Just define m as 1, in as 0.0254, km as 1000, etc.
The problem arises when you have more than one dimension. If you have
length units and time units you need a way to define the value of m
and s such that the program can tell the difference.
To add entropy, when area, volume, speed, etc. come into place, the
program must be able to know that length/time is speed, length^2 is
area, etc.
One way would be to use a non-canonical base of orthogonal matrices.
But having about 200 different units and 7 different fundamental units
that would mean computing hundreds of 7x7 matrices each time the
program is run (they must be defined everytime because all variables
should be local). So matrices won't do, too slow.
Then I thought: what about complex numbers? The problem is that I can
go from one complex number to another just by multiplication and I
must avoid a choice that implies that length^3/time equals mass, or
some oddity like this. But... units are only used with integer powers
and Pi is... irrational! So, the answer is: irrational multiples of
Pi, that are also irrational multiples of each other! I've used
sqrt(2), sqrt(3), sqrt(5), sqrt(7), sqrt(11), sqrt(13) and sqrt(17)
for the fundamental constants.
Now, it's just a matter of defining all units as:
m=e^(i*sqrt(2))
km=1000.m
s=e^(i*sqrt(3))
minute=60*s
etc, etc, etc.
For the derived units, well it's piece of cake: just use the
definition and multiply everything!
Define
kph = 3.6 m/s,
N = kg*m/s^2,
J = N*m
W = J/s,
etc...
So all the convert program does, after defining all of this, is simply
check whether argument1/argument2 is real or not. If it's not real,
then the angles are not the same, so the units are inconsistent. If
the result is real, then it's the numerical part on the target units!
E.g: 1 km = 1000 e^(i sqrt(2)). So, dividing by m gives 1000.
As all sqrts of prime numbers are irrational multiples of each other
and of Pi, if you have two linear combinations
c1 Pi + c2 sqrt(2) + c3 sqrt(3) + ... + c17 sqrt(17) = d1 Pi + d2
sqrt(2) + d3 sqrt(3) + ... + d17 sqrt(17)
where all coefficients are rational numbers (in the case at hand they
can be only integers), then c1=d1, ... c17=d17.
And that's how it works!
The only problem is that the program allows the user to convert
m^sqrt(3) to s^sqrt(2), but I can live with that.
Nelson
Pat Flynn
What can I say except that you are brilliant!
Pat
Nelson Sousa
thanks.
Nelson
Andy Kemp
Another stunning application of the potential of the TI-Nspire, and some truely imaginative mathematics!
Well done!
Sean Bird
Kudos,
Sean Bird
This is hugely impressive! Nelson was kind enough to send this too me last week to have a play with and it really works just how you would expect... The only slight problem is the need to use quotes round the amounts but this is unavoidable!
lafacroft
http://www.lafacroft.com where it can be with all the other Google
Group archive.
It would be quite nice if TI would integrate these functions into the
catalogue on the Nspire. Wouldn't it?
>
> - Show quoted text -
Eagle-Man
bit confused as to what you were getting at, but then when I got to
what the program actually does, I had to laugh (out loud)! That's
sheer genius! Amazing. Great job.
--Eric F.
Nelson Sousa
Thank you for your messages, you really lifted my ego. I hate to
disappoint you, but there's a bug guys, sorry.
It's fixed, you can download the updated version from the site.
Nelson