Re: [Haskell] [ANN] quantities 0.3.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell] [ANN] quantities 0.3.0

Auke Booij
On 15 April 2014 20:29, John David Reaver <[hidden email]> wrote:
> Hello! I am happy to publicly announce the quantities package:

I think haskell-cafe is more appropriate for these kinds of libraries.
Anyway, welcome.

> From the description on Hackage:
>
>    A library for creating and manipulating physical quantities,
>    which are a numerical value associated with a unit of
>    measurement. Included is an expression parser and a huge list
>    of predefined quantities with which to parse strings into a
>    Quantity datatype. Once created, a quantity can be converted
>    to different units or queried for its dimensionality. A user
>    can also operate on quantities arithmetically, and doing so
>    uses automatic unit conversion and simplification.
>

not sure if "quantities" is an appropriate name for your package: an
integer, a float, complex numbers - those are quantities. doesn't this
package parse units?

> Just to get a taste of how this package works, here are some
> examples:

why can i only "unsafely" create quantities using strings? what if i
know upfront what kind of a unit i want to deal with? from the looks
of it, this library is only good for dealing with human-readable input
- surely that's not the only use case you had in mind?

> >>> fromString "min => s"
> Right 60.0 second

can't we find some elegant way to express this in haskell, instead of
having to invent a scripting language of sorts?
On a similar note, your "magnitude :: Quantity -> Double" sounds a bit
like unsafeCoerce: why would you want to forget that your quantity has
a unit?

From your documentation:

> >>> fromString "m => 3 ft"
> Left (ScalingFactorError 3.0 foot)

Why isn't the outcome of this 3.28084/3=1.09361 or something along
those lines? (this is just a suggestion, I'm not saying this is a bad
thing.)

> >>> fromString "2 ft + 6 in => ft"
> Right 2.5 foot

Oh, so you are trying to support arbitrary arithmetical input!
Then again, there is no way to add two "Quantity"s.


I have the feeling the goal of your package is a bit unclear: do you
want to implement a framework to type-safely compute with units? Or do
you just want to write something that parses string input to typed
data?

In the former case, have you considered the discussion on the haskellwiki [1]?

In the latter case, why don't you write it on top of an existing units package?


Well, that was a big rant, I hope you can use some of it.

Auke.

[1]: http://www.haskell.org/haskellwiki/Physical_units
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell] [ANN] quantities 0.3.0

John David Reaver
Thanks for the feedback!

> not sure if "quantities" is an appropriate name for your
> package: an integer, a float, complex numbers - those are
> quantities. doesn't this package parse units?
 
Wikipedia and this dictionary
quantities are associated with units of measurement. This package
does indeed parse units. When a magnitude is associated with
those units, you get a quantity. I think the name "quantities" is
totally appropriate.

> why can i only "unsafely" create quantities using strings? what
> if i know upfront what kind of a unit i want to deal with? from
> the looks of it, this library is only good for dealing with
> human-readable input - surely that's not the only use case you
> had in mind?

> can't we find some elegant way to express this in haskell,
> instead of having to invent a scripting language of sorts?

Using the type system to handle units is incorporated into some
other libraries. I couldn't find a library that parses units from
strings, so I made one. I certainly plan to add this
functionality in the future.

> On a similar note, your "magnitude :: Quantity -> Double"
> sounds a bit like unsafeCoerce: why would you want to forget
> that your quantity has a unit?

You don't "forget" it has units. Sometimes you just want to get
the magnitude, like after you perform a conversion operation, for
instance.


> Oh, so you are trying to support arbitrary arithmetical input!
> Then again, there is no way to add two "Quantity"s.

There is indeed:


> I have the feeling the goal of your package is a bit unclear:
> do you want to implement a framework to type-safely compute
> with units? Or do you just want to write something that parses
> string input to typed data?

Currently, it parses string input. I am a contributor to a Python
package called pint, which was a huge inspiration to this library.

In my day job, I develop a commercial Python GUI application for
petroleum engineering that needs to convert between many units.
One feature of this application is a user can enter arbitrary
units of their choice to for plots and data so they don't have to
convert units by hand when using the application. I wanted to
bring that functionality to Haskell.

> Well, that was a big rant, I hope you can use some of it.

I did, thanks!

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell] [ANN] quantities 0.3.0

Auke Booij
On 15 April 2014 21:30, John David Reaver <[hidden email]> wrote:

>> why can i only "unsafely" create quantities using strings? what
>> if i know upfront what kind of a unit i want to deal with? from
>> the looks of it, this library is only good for dealing with
>> human-readable input - surely that's not the only use case you
>> had in mind?
>
>> can't we find some elegant way to express this in haskell,
>> instead of having to invent a scripting language of sorts?
>
> Using the type system to handle units is incorporated into some
> other libraries. I couldn't find a library that parses units from
> strings, so I made one. I certainly plan to add this
> functionality in the future.

so then why are you reinventing those units libraries? in other words,
why did you write Quantity instead of reusing a similar data type from
an existing library?

>> On a similar note, your "magnitude :: Quantity -> Double"
>> sounds a bit like unsafeCoerce: why would you want to forget
>> that your quantity has a unit?
>
> You don't "forget" it has units. Sometimes you just want to get
> the magnitude, like after you perform a conversion operation, for
> instance.

but you do forget it has units! it says it right there: magnitude
takes a Quantity, and gives back only the Double it contains. I don't
know what definition of "forget" you're working with...

your magnitude function suggests that to do some complicated
calculation on some Quantity inputs, you first "unpack" them to
Doubles, do your calculations, and then repack them into Quantities.
that means my calculations are not type-safe against mixing up units
anymore: why would we even store the unit of some number in the first
place, if we have to (temporarily) forget those units the moment we
start doing any serious calculations?

Mind you: it is not acceptable to have to rewrite all my existing
calculations to use your functions. I wrote +, I meant +, so I should
be able to use + --- not your addQuants or subtractQuants. Maybe
making Quantity an instance of the right type classes solves this
entire issue?

>> Oh, so you are trying to support arbitrary arithmetical input!
>> Then again, there is no way to add two "Quantity"s.
>
> There is indeed:
> http://hackage.haskell.org/package/quantities-0.3.0/docs/Data-Quantities.html#v:addQuants
apologies, hadn't seen it.

However, that leaves me with the impression that there are two ways to
add two quantities: "inside the string", such as with
> >>> fromString "ft + 12in"
or in haskell, using addQuants.

Although it is of course perfectly allowed to implement the same
functionality twice (yes, the same functionality: the essence is that
you add two quantities. the fact that the exact input data is
different doesn't bother me as a mathematician), this smells of bad
library design. Not saying it is, just saying it leaves a bad taste:
there is no clear reason why you need both. Again, what exactly is the
purpose of your library?

>> I have the feeling the goal of your package is a bit unclear:
>> do you want to implement a framework to type-safely compute
>> with units? Or do you just want to write something that parses
>> string input to typed data?
>
> Currently, it parses string input. I am a contributor to a Python
> package called pint, which was a huge inspiration to this library.

my impression is that, in general, people try to stick with the unix
mentality when it comes to designing the goals of a package: do one
thing, and do it well.

you are doing several things.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell] [ANN] quantities 0.3.0

Sylvain HENRY
2014-04-15 22:54 GMT+02:00 Auke Booij <[hidden email]>:
On 15 April 2014 21:30, John David Reaver <[hidden email]> wrote:

> Using the type system to handle units is incorporated into some
> other libraries. I couldn't find a library that parses units from
> strings, so I made one. I certainly plan to add this
> functionality in the future.

so then why are you reinventing those units libraries? in other words,
why did you write Quantity instead of reusing a similar data type from
an existing library?

Most libraries only support static checking of units (AFAIK). Supporting unit parsing from a string is great. When we will rewrite Google with Haskell, we will need it ;) (try to type "(1m + 1ft + 2 yards + 50in) * 5 / (8 km/h) in minutes" for instance).

You cannot ask him why his library only supports string input, then ask him to provide an additional Haskell DSL that is not unsafe and finally reproach him for wanting to support both approaches. For his needs (at least in the Python GUI app he describes), he can either use an external DSL approach (parsing strings) or use an Haskell EDSL with System.Eval.Haskell (or an equivalent). The former may be preferred.

-- Sylvain

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell] [ANN] quantities 0.3.0

John David Reaver
Most libraries only support static checking of units (AFAIK).

I found that to be the case. Indeed, if would be nice to integrate
both approaches elegantly. I haven't figured out how yet.

> (try to type "(1m + 1ft + 2 yards + 50in) * 5 / (8 km/h) in minutes"
> for instance).

I had to try it using quantities :)

>>> fromString "(1m + 1ft + 2 yard + 50in) * 5 / (8 km/h) => minute"
Right 0.16513500000000006 minute

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell] [ANN] quantities 0.3.0

Tom Ellis
On Tue, Apr 15, 2014 at 03:25:19PM -0700, John David Reaver wrote:
> > Most libraries only support static checking of units (AFAIK).
>
> I found that to be the case. Indeed, if would be nice to integrate
> both approaches elegantly. I haven't figured out how yet.

This seems to be a specific instance of the general problem of type checking
code which is loaded at runtime.

Tom
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe