Craig DeForest wrote:
Yet another point: there are plenty of non-obvious reductions that people
worry about, such as N m - J (energy) but m N - m N (torque); but
it's probably not worth worrying about such things: if the coder knows that
s/he wants a torque, s/he should be able to ask for
Craig DeForest wrote:
Yow -- units would be extra cool for perl6: I know of no other language that
has units support built in. It would go a long way toward making perl6 the
language of choice for students in the physical sciences...
Frink is built around this idea:
Larry Wall wrote:
... SKIP ...
Okay, that looks scary, but if as in my previous message we define
chars as the highest Unicode level allowed by the context and the
string, then we can just write that in some notation resembling:
substr($a, 5`Chars, 10`Chars);
or whatever notation we end up
Markus Laire wrote:
Larry Wall wrote:
Now, I admit that I've handwaved the tricksy bit, which is, How do
you know, Larry, that substr() wants 5`Codes rather than 5`Meters?
It's all very well if you have a single predeclared subroutine and
can look at the signature at compile time, but you wrote
On Mon, 2005-03-28 at 15:07, Rod Adams wrote:
Markus Laire wrote:
So do you actually envision perl6 to allow a junction of units on
numbers? This would have huge implications, depending on what exactly
is possible with these units...
# import proper MMD-subs for + - * etc...
On Mon, 2005-03-28 at 16:00, Larry Wall wrote:
I've always thought that we should make use of the database of the
units program for standardized names of units. The units database
has a pretty good list of which units are just differently scaled
units of the actual underlying fundamental
The problem with using the units(1) database is that it only deals with
multiplicative relations -- so, e.g., it won't handle temperature.
Units resolvers are not so hard to come by -- the strategy is to try to break
each compound unit out into a collection of fundamental quantities that
are
On Mon, 2005-03-28 at 17:48, Craig DeForest wrote:
The problem with using the units(1) database is that it only deals with
multiplicative relations -- so, e.g., it won't handle temperature.
Well, that's fine. You don't have to get everything from one source.
Larry is right though, units is a
On Monday 28 March 2005 05:48 pm, Craig DeForest wrote:
The problem with using the units(1) database is that it only deals with
multiplicative relations -- so, e.g., it won't handle temperature.
[EMAIL PROTECTED]:~$ units
2084 units, 71 prefixes, 32 nonlinear units
Among those nonlinear units
From: [EMAIL PROTECTED]
The problem with using the units(1) database is that it only deals with
multiplicative relations -- so, e.g., It won't handle temperature.
So the temperature functions available in units(1) aren't defined in the
database? They're hard-coded? I find that unlikely.
In
10 matches
Mail list logo
