.

October 6, 2006

ruby-units 0.3.3

The latest version of the ruby-units gem has just been released.

Installation

gem install ruby-units
or
gem update ruby-units

Features

  1. Significantly improved speed
  2. Will use the ‘Chronic’ gem to interpret times/dates if loaded
  3. some nice time helpers.
    ‘1 day’.from ‘now’ #=> Wed Oct 04 18:27:13 EDT 2006
    ‘1 day’.ago #=> Mon Oct 02 18:38:56 EDT 2006
    ‘7 days’.before ‘1/1/2007′ #=> Mon Dec 25 00:00:00 EST 2006
    ‘7 days’.after ‘12/25/2006′ #=> Mon Jan 01 00:00:00 EST 2007
    ‘days’.since ‘1/1/2006′ #=> 275.436 d
    ‘days’.until ‘1/1/2007′ #=> 89.7683 d

    (works for sec, min, hours, days, weeks, fortnights, years, decades, centuries….
    but not months).

    and some others..
    these helpers will automagically give you a DateTime object
    if a Time object won’t work.

    ‘years’.since ‘1/1/1900′ #=> 106.756 y
    ‘50 years’.from ‘now’ #=> 2056-10-02T18:46:55Z
  4. units can now identify themselves (sort of..)
    ‘60 mph’.unit.kind #=> :speed
    ‘9.8 m/s^2′.unit.kind #=> :acceleration
  5. some new constructors
    Unit(10,’m') #=> 10 m
  6. Now throws an exception if it donsn’t understand a unit (during creation)
  7. Temperature handling improved
    “0 tempC”.unit #=> 273.15 degK
    “310.15 degK”.to(’tempC’) #=> 37 degC
  8. Trig functions can accept angular units
    Math.sin(’90 deg’.unit) #=> 1.0
    Math.sin(’100 grad’.unit) #=> 1.0

* Filed by Kevin Olbrich at 1:50 pm under Ruby, gems, ruby-units
* 3 Comments

3 Responses to “ruby-units 0.3.3”

  1. evan
    October 6th, 2006 | 4:26 pm

    If you used a typed system as per my other comment (which I meant to post here, but posted on the old ruby-units entry instead, because I’m incompetent at commenting) you could implement higher-ordered units as arbitrary groups of scalar units.

    a = Unit.new(”1 hour”) #=> 1
    a.class #=> Unit::Hour

    a = Unit.new(”5 m/s**2″) #=> 5
    a.class #=> Unit::Multi::Acceleration
    a.classes #=> [Unit::Meter, Unit::Second, Unit::Second]
    a.order #=> 3 # the “derivativeness” of the measure, just the length of the .classes Array (not sure if you should count from 0 or from 1)

    Then you could set up the conversion in a programmatic way and automate everything. New higher-ordered unit classes would require no work for conversion, or even could be created dynamically from parsing the string at .new time:

    a = Unit.new(”3 s/f/l**2″)
    a.class = Unit::Multi::SecondFeetLiter2
    a.classes = [Unit::Second, Unit::Feet, Unit::Liter, Unit::Liter]

    I also am thinking that units should return their value by default. Also, Ruby convention for exponents is “**”. Is there a reason you want “^” instead?

    Send me an email if you are interested in discussing this more. I need to look at your code for real instead of just speculating on how it works. :)

  2. Kevin Olbrich
    October 6th, 2006 | 4:46 pm

    I’m not sure I follow your logic here. I see no reason to make typed units.
    The unit objects already understand how to do complex units.

    a = ‘5 m/s**2′.unit #=> 5 m/s^2
    a.kind #=> :acceleration

    It already handles conversions, math, and all that right now.

    FYI: Ruby and FORTRAN use ‘**’ for exponentiation, but the common way to type it out is to use a ‘^’. In fact, you can specify an exponent either way in a unit object and ruby-units will recognize them both.

    If you are concerned about using ruby-units for production code, bear in mind that it is only a 0.3 release, and not even 1.0 yet. The code itself is highly tested, but I would encourage you to write your own tests to make sure it behaves as you expect.

  3. Yurii Rashkovskii
    October 7th, 2006 | 11:07 am

    Looks very interesting, however, why not making something like

    >> 7.days.before
    >> 7.days.before.now
    >> 50.years.from.now
    >> days.since

    ?

    It would be so Rails-compatible, then :)

Leave a reply