Polymorphic zero

[GoogleCodeExporter]

I suggest the creation of a polymorphic zero, in the following fashion.

The current library has:

> _0 :: (Num a) => Dimensionless a
> _0 = 0 *~ one

I propose:

> _0 :: (Num a) => Quantity d a
> _0 = Dimensional 0

This can be used in all the places where the current zero can be used, but it 
is also more general and can be used to express zero Length or Capacitance or 
Velocity etc.

(If this has been proposed and rejected elsewhere, I apologize, I tried a 
couple of searches but couldn't find anything.)

Original issue reported on code.google.com by douglas....@gmail.com on 3 Sep 2012 at 3:20

[GoogleCodeExporter]

Hmm, sounds quite reasonable and harmless on the case of zero… let me think 
about it for a day or two to see if I can come up with any objection. ;)

I'll also search my code for uses of _0, if any. By the way, could you 
elaborate on your use case that made you propose this? (I imagine I have used 
e.g. 0 *~ (meter / second) in populating some sparse matrix where a polymorphic 
_0 could have been convenient – given sufficient type signatures.)

Original comment by bjorn.bu...@gmail.com on 3 Sep 2012 at 8:21

[GoogleCodeExporter]

Sure, my use case is basically just initializing things. A lot of times the 
wrapper of a worker/wrapper pattern will need to initialize something to zero, 
or the default value of a record type will have some zero fields, and so forth.

I could write 0 *~ (meter / second), and 0 *~ farad, and so forth, but I think 
something like ParticleState { position = _0, velocity = _0 } is perfectly 
clear without units.

I suppose it might also be useful for actually polymorphic occurences. Here's 
an example from Numeric.Units.Dimensional.TF:

> sum :: forall d a . Num a => [Quantity d a] -> Quantity d a
> sum = foldr (+) (Dimensional 0 :: Quantity d a)

Could be:

> sum :: forall d a . Num a => [Quantity d a] -> Quantity d a
> sum = foldr (+) _0

Things like that. I would file this under nice-to-have, certainly the library 
is great and very useful even without it (thanks!), and it isn't difficult to 
define one's own __0 (with two underscores, in case it isn't clear from the 
font here) as I have and import it where one wants it.

Original comment by douglas....@gmail.com on 3 Sep 2012 at 8:46

[GoogleCodeExporter]

Thanks. Having browsed my code I am leaning towards accepting your proposal as 
it indeed could be nice to have, but I want to actually play with it a little 
before committing to it. I'll try to find the time ASAP.

Original comment by bjorn.bu...@gmail.com on 7 Sep 2012 at 7:50

[GoogleCodeExporter]

Doesn't this run into trouble with units like degrees Celsius, as mentioned 
under "Less conformant units" in the original announcement?

Original comment by jadenb1...@gmail.com on 25 Sep 2012 at 4:49

[GoogleCodeExporter]

Regarding degrees Celsius, do you see any additional troubles other than those 
already mentioned in the announcement? There would still be no distinction 
(unfortunately) between `_0` and `0 *~ degreeCelcius` and `0 *~ kelvin`. I 
don't see this proposal making things worse than they already are, but please 
elaborate if you do!

Original comment by bjorn.bu...@gmail.com on 25 Sep 2012 at 7:39

[GoogleCodeExporter]

No, I guess I don't see any additional troubles; but I think this is enough of 
a sore spot already, without making it 'silent' so that the programmer can run 
afoul of it without ever explicitly mentioning degrees Celsius.  (On the other 
hand, I have never used this library --it's just my gut-instinct worry-- so 
feel free to disregard this concern if it doesn't arise in real-life usage.)

Original comment by jadenb1...@gmail.com on 25 Sep 2012 at 11:08

[GoogleCodeExporter]

It seems to me that this behavior is actually correct even for temperatures. As 
the announcement says, it's mostly useful to consider dimensional values of 
temperature as relative temperatures rather than absolute (thermodynamic) 
temperature. In the same way that Time Double represents relative time rather 
than absolute (calendar) time. Not having a universal approach to handling 
situations like this is annoying, but designing one is tricky. I'm reliably 
informed that it's related to the mathematical concept of a torsor, but this 
hasn't helped me in coming up with a well-designed "answer".

How much warmer is it today than yesterday? 0 *~ degreeCelsius is a good 
answer. How warm is it today? 19 *~ degreeCelsius isn't a correctly typed 
answer.

How long should I cook this burrito in the microwave? 95 *~ second is a good 
answer. What time is it? (21 *~ hour) + (44 *~ minute) isn't a correctly typed 
answer.

Original comment by douglas....@gmail.com on 26 Sep 2012 at 1:46

[GoogleCodeExporter]

Original comment by bjorn.bu...@gmail.com on 20 Jun 2013 at 8:57

• Changed state: Started

[GoogleCodeExporter]

Original comment by bjorn.bu...@gmail.com on 20 Jun 2013 at 8:57

[GoogleCodeExporter]

Original comment by bjorn.bu...@gmail.com on 20 Jun 2013 at 8:57

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Added in version 0.12. I don't expect any problems with this change but if we 
run into any I will roll it back.

Original comment by bjorn.bu...@gmail.com on 20 Jun 2013 at 12:04

• Changed state: Completed