duckduckgo / zeroclickinfo-goodies

DuckDuckGo Instant Answers based on Perl & JavaScript
https://duckduckhack.com/
Other
974 stars 1.77k forks source link

Conversions Goodie could be expanded for more physical concepts #318

Closed mintsoft closed 10 years ago

mintsoft commented 10 years ago

The new conversions Goodie currently only handles mass, it could be extended to handle all unit conversions! Such as:

Distance: (feet, miles, metres, lightyears) Area & Volume (Hectare, acre, m² | litre, cm³, fluid oz) Time: (seconds, days, years) Velocity: (mph, m/s, furlongs/fortnight) Force (Pounds force, Newtons) Temperature: (°C, °F, Kelvin, Rankine) Pressure (Pascal, bar, psi, N/m²) Energy (Calorie, KCal, Joule, BTU) Power (Watts, BHP, BTU/h) Angles (Degrees (°), rads)

Obviously this is a load of extra functionality not really 1 PR's worth.

cc @elohmrow feel free to take a crack at any of these if you like :)

elohmrow commented 10 years ago

:)

I was only going for emulating the google weights / measures converter, without using W|A.

I am planning to work on the timezone converter as well (move it from W|A to a goodie - https://duck.co/ideas/idea/39/change-timezone-converter-instant-answer-to-a-good) this week.

I would gladly add as much as this functionality as possible.

mintsoft commented 10 years ago

@elohmrow good to hear, I'll probably take a whack at a few of these myself this week. Now we've got something in-place for conversions we can make it even more awesome! :+1:

elohmrow commented 10 years ago

excellent :)

elohmrow commented 10 years ago

@mintsoft it may need to have different bones to handle something other than weights ... it very simplistically uses 'metric ton' as a base unit ... when you query, it converts whatever weight you entered (say, 'oz') to 'metric ton', then grabs value (all hash values are relative to metric ton).

i don't know the usual ddg way to do this (this was my first open source contribution), but it seems to lean toward atomic modules. so question for you would be: should we put all this new functionality in one module ('Conversions.pm'), or, should we do something more like 'Conversions::Weights', .., 'Conversions::Energy', ..?

this is interesting to me also because i plan to write a timezone converter, so that could be 'Conversions::TimeZone'.

interested in your thoughts, and thanks!

mintsoft commented 10 years ago

@elohmrow currently there isn't a really a hard-and-fast rule that I know of. Then again, I can't think of a goodie of comparable potential complexity either.

Personally I'd probably opt for extending the Conversion goodie to support as many physical concepts as possible however I can see how this might get unweildy. We can always store the conversion information in a separate file that we read in instead of having it within the source itself it it starts getting too cluttered.

Other people might have different thoughts however!

mwmiller commented 10 years ago

Any chance we could run a full-blown Frink interpreter? :smile:

mintsoft commented 10 years ago

@mwmiller I've not seen that before, it's amazing!

elohmrow commented 10 years ago

Never seen that before ... Looks cool :)

sent by a bradDroid - please expect bradVity! On Feb 9, 2014 6:47 AM, "Rob Emery" notifications@github.com wrote:

@mwmiller https://github.com/mwmiller I've not seen that before, it's amazing!

— Reply to this email directly or view it on GitHubhttps://github.com/duckduckgo/zeroclickinfo-goodies/issues/318#issuecomment-34571839 .

elohmrow commented 10 years ago

@mintsoft @mwmiller ~ anybody started on this yet? can we come to a consensus on the best attack before it's started on?

mwmiller commented 10 years ago

@elohmrow I have not started on this nor have any real plans to do so. It's going to be a huge project, so I'd rather let someone with an abiding interest (like yourself) take the lead.

moollaza commented 10 years ago

What about, as a smaller step we incorporate a lib like: https://metacpan.org/pod/Math::Units?

This seems like a much easier integration, which should enable quite a bit more functionality for the Goodie.

mintsoft commented 10 years ago

@moollaza Absolutely that sounds like a good first step. I can probably do it this weekend, unless anyone else wants to?

elohmrow commented 10 years ago

I'll try to take a peek tonight, since I have a wee bit of time :)

mintsoft commented 10 years ago

@elohmrow go for it!

elohmrow commented 10 years ago

I think Math::Units may not be ready for this use.

It does not handle (at least): multi-word units, plural units, several standard units / variants (like 'kilogramme', 'stone') ... these misses alone failed 8 of 15 tests in the suite.

So ... we could use it in conjunction with Conversions and 'fall back' on Conversions when Math::Units vomits, or extend Math::Units first, then use it, or augment current stuff with Math::Units to handle things simply not added in yet.

I'll go with whatever most people want to do - just lemme know ;)

elohmrow commented 10 years ago

one other thing we could do if the benefit of using Math::Units is high enough is convert the units Conversions might receive into ones Math::Units understands. For example, 'kilogramme' could be turned in to 'kilo' before passing on to Math::Units::convert().

a bigger issue would be errors like this, reported from the tests: "conversion of unit 'ton' to 'kilos' failed (incompatible units?) "

mintsoft commented 10 years ago

@elohmrow I think I'd probably favour converting into units that Math::Units work with like you suggest. A preliminary look at the source suggests that units should work?

'ton' => '2000 lb'
'lb'  => '453.59237 g'

maybe "ton to grams", I think it may only support american spellings

elohmrow commented 10 years ago

just had a nice chat with the maintainer of Math::Units ... here's what he suggested (quoted with his permission):

"I’d suggest that that be done in a sub class like Math::Units::FromHuman (and maybe have a corresponding Math::Units::ToHuman) that could normalize human input into what the underlying values that Math::Units needs to operate on."

that sounds like what we already basically were thinking about.

he also said he would not have the time to work on such extensions for some time, but would be happy to accept patches if that's the direction we want to go in.

the last question for now then may be: do we knock out those patches first, or do we just make it work now and then hook in to those patches later? my vote is the former.

moollaza commented 10 years ago

@elohmrow that sounds like a great plan. FWIW I found Math::Units after a pretty quick search, there may already be a better library on CPAN for conversions. Does anyone happen to know if that's the case?

elohmrow commented 10 years ago

there appear to be some, like Math::Calc::Units and Convert::Units ... but they are both at 4+ years of not being developed (like Math::Units), and missing some things.

i am beginning to think what happens is people try to write something small, like, say, a ddg goodie to convert between weights :), and then they realize it's a much bigger problem space.

it will take a non-trivial amount of work to make Conversions.pm work with Math::Units, and at the cost of at least: namespace bloat and speed.

so right now a bit of cognitive dissonance has crept in - at some level, i think it would be faster and easier and just as useful to simply add to the existing Conversions.pm. also, since it is written without using many add-on modules (Scalar::Util::looks_like_number() being the only include, and that could be taken out), it currently is easier to maintain.

who knows :)

mintsoft commented 10 years ago

@elohmrow I sense you feel a bit overwhelmed with the scope of generalising this goodie a little? Do you have your version with Math::Units implemented to hand so I can take a look?

elohmrow commented 10 years ago

nah - not overwhelmed. i'm just not seeing Math::Units right now as being as useful as what is already implemented.

just working on all options :)

i had a Math::Units version last night. Without further massaging inputs, it fails 8/15 tests. So there's work that would need to go in to that version to get it to do what it already does.

i have another version right now with length measures put in, to test the idea of how extendible what is already written is. i'll be testing that tonight.

jagtalon commented 10 years ago

Let's start small--we can always expand on the functionality over time.

elohmrow commented 10 years ago

okey dokey ... here's what i did ... i expanded what's already there to accommodate N different unit types. i added units of length, so now it handles length and mass. this is VERY rough (code could definitely be improved), but it works (passes all tests). i've put it here: https://github.com/elohmrow/zeroclickinfo-goodies/commit/d6c09726a414d5b076de9d65e18a389708cca3f3

now, if you want to add, say, units of time for time conversions, you only need to add a new @times and push (@types, @times), and you'll be able to convert mass, length, and time.

mintsoft commented 10 years ago

New PR for this: https://github.com/duckduckgo/zeroclickinfo-goodies/pull/356

mintsoft commented 10 years ago

This is basically closed now by #356 any units can be added by extending Convert::Pluggable on https://github.com/elohmrow/Convert-Pluggable

Many Thanks @elohmrow !

elohmrow commented 10 years ago

many thanks @mintsoft @mwmiller @moollaza @jagtalon !!!!