Re: exponentiation of Duration's
Darren (), Carl (), Darren (): Specific units, even seconds should not be mentioned at all in the definition of Instant or Duration; instead, any particular units or calendars or whatever would just be a property of the composing class. No disrespect, but it was the abandonment of abstracty stuff like this that led to us getting a Temporal spec that made sense and could be implemented. How so? All I'm proposing is having top level markers that aren't too constraining, but everything specced below that can be quite specific and implementable. -- Darren Duncan Happy to hear that. Because in the case of spec that is so stable that it's even found its way into Rakudo in a very complete form, proposing radical spec changes like yours practically *requires* working code in the form of a patch or a completely new Temporal module, if it's to be anything more than empty talk. The Temporal module in Rakudo is written in Perl 6. It's very accessible for experimenting of the type you suggest above. Go for it. // Carl
Re: exponentiation of Duration's
On Wed, 17 Nov 2010, Richard Hainsworth wrote: Once a number has been generated, viz., by obtaining a duration, that number can be manipulated however necessary. The interpretation of the number is a matter for the programmer, not the language designer. All true. However I'd argue that you can very easily obtain a bare number as my $plain_number = $duration / $one_time_unit which makes it explicit that you're stripping the dimentionality. Then you can square it or whatever to your heart's content. Dimensioned numbers as restrictive types are useful, for uncovering bugs, including sometimes latent ones in ported code. Duration is a fairly clear example of a dimensioned quantity, and I think we should think twice about abandoning its dimensionality, and the restrictions that implies. -Martin
Re: exponentiation of Duration's
On 11/17/2010 10:08 PM, Martin D Kealey wrote: Dimensioned numbers as restrictive types are useful, for uncovering bugs, including sometimes latent ones in ported code. Duration is a fairly clear example of a dimensioned quantity, and I think we should think twice about abandoning its dimensionality, and the restrictions that implies. If using strict dimensioned quantities, the restriction would not be that you cannot square it: it would be that you cannot assign the squared duration to an incompatible lvalue; and cannot add it to a value that is not also a squared duration. Thus use strict dimensions; # strict should be default in p6? my Duration $x = ...; sleep $x; # OK my $y = $x ** 2; # OK sleep $y; # error (no candidate for dispatch) my $z = $x + $y; # error (dimensionality mismatch) The question, to my mind, is how to implement a no strict dimensions pragma. perhaps all dimensioned quantities would implement a role, that the pragma would tweak, to add implicit conversions to/from Numeric. I do think that the dimensionality of Duration needs to be in the context of a broader framework.
Re: exponentiation of Duration's
I think that Instant and Duration should simply be declarational roles that don't have any implementation code to compose. Composing Instant or Duration into a type simply says that the objects of that type represent a point on a timeline or an amount of time. Specific units, even seconds should not be mentioned at all in the definition of Instant or Duration; instead, any particular units or calendars or whatever would just be a property of the composing class. Said 2 roles would *not* specify that values would numify or strify or boolify in any particular way, such as seconds or otherwise; this is strictly a property of the composing class. Said 2 roles could define particular methods such as, assuming we're just talking one-dimensional: Instant - Instant -- Duration Instant + Duration -- Instant Instant - Duration -- Instant Duration + Duration -- Duration Duration - Duration -- Duration Duration * Numeric -- Duration Duration / Numeric -- Duration Duration / Duration -- Numeric (rational in general) Duration div Duration -- Numeric (integral) Duration mod Duration -- Duration (rational in general) I don't see that multiplying a Duration, or having arbitrary exponentiation, makes any sense when talking one-dimensional, especially when we're being completely units-agnostic. A specific implementing type may have a concept of dimensionality, but I would think that these 2 roles don't. Perhaps a suitable analogy is to look at the level of abstraction that Numeric has relative to composing classes. Do we want Instant and Duration to include concepts like dimensionality, such as like Numeric may include Complex, or do we want it to explicitly be one-dimensional (though units agnostic), like Real? And whatever choice we pick, maybe there should be suitable generic names given to the complementary concept of what I mentioned. -- Darren Duncan
Re: exponentiation of Duration's
To clarify, by define particular methods I mean that said 2 roles would require composing classes to define them, not to include the code themselves. -- Darren Duncan Darren Duncan wrote: I think that Instant and Duration should simply be declarational roles that don't have any implementation code to compose. Composing Instant or Duration into a type simply says that the objects of that type represent a point on a timeline or an amount of time. Specific units, even seconds should not be mentioned at all in the definition of Instant or Duration; instead, any particular units or calendars or whatever would just be a property of the composing class. Said 2 roles would *not* specify that values would numify or strify or boolify in any particular way, such as seconds or otherwise; this is strictly a property of the composing class. Said 2 roles could define particular methods such as, assuming we're just talking one-dimensional: Instant - Instant -- Duration Instant + Duration -- Instant Instant - Duration -- Instant Duration + Duration -- Duration Duration - Duration -- Duration Duration * Numeric -- Duration Duration / Numeric -- Duration Duration / Duration -- Numeric (rational in general) Duration div Duration -- Numeric (integral) Duration mod Duration -- Duration (rational in general) I don't see that multiplying a Duration, or having arbitrary exponentiation, makes any sense when talking one-dimensional, especially when we're being completely units-agnostic. A specific implementing type may have a concept of dimensionality, but I would think that these 2 roles don't. Perhaps a suitable analogy is to look at the level of abstraction that Numeric has relative to composing classes. Do we want Instant and Duration to include concepts like dimensionality, such as like Numeric may include Complex, or do we want it to explicitly be one-dimensional (though units agnostic), like Real? And whatever choice we pick, maybe there should be suitable generic names given to the complementary concept of what I mentioned. -- Darren Duncan
Re: exponentiation of Duration's
Darren (): Specific units, even seconds should not be mentioned at all in the definition of Instant or Duration; instead, any particular units or calendars or whatever would just be a property of the composing class. No disrespect, but it was the abandonment of abstracty stuff like this that led to us getting a Temporal spec that made sense and could be implemented. // Carl
Re: exponentiation of Duration's
Carl Mäsak wrote: Darren (): Specific units, even seconds should not be mentioned at all in the definition of Instant or Duration; instead, any particular units or calendars or whatever would just be a property of the composing class. No disrespect, but it was the abandonment of abstracty stuff like this that led to us getting a Temporal spec that made sense and could be implemented. // Carl How so? All I'm proposing is having top level markers that aren't too constraining, but everything specced below that can be quite specific and implementable. -- Darren Duncan
exponentiation of Duration's
A recent rakudo commit [1] is a quick fix for #78896 [2] to allow exponentiation of Duration's. I'm uneasy with allowing this and I think the spec probably meant not to but is badly worded [3]: Durations allow additive operations with other durations, and allow any numeric operation with a number as the other argument: $duration * $duration# WRONG, durations aren't geometric $duration * 2# ok, a duration twice as long 2 * $duration# same What are your thoughts? [1] https://github.com/rakudo/rakudo/commit/d9e22463479927fa8f1f594753979022de35970d [2] http://rt.perl.org/rt3/Ticket/Display.html?id=78896 [3] https://github.com/perl6/specs/commit/32abb95b9776e1cb7672c8a6a77612c86b37aea2#L0R1333
Re: exponentiation of Duration's
Am 17.11.2010 10:31, schrieb Kris Shannon: A recent rakudo commit [1] is a quick fix for #78896 [2] to allow exponentiation of Duration's. And it did so with a real world use case in mind. I'm uneasy with allowing this and I think the spec probably meant not to but is badly worded [3]: Durations allow additive operations with other durations, and allow any numeric operation with a number as the other argument: $duration * $duration# WRONG, durations aren't geometric $duration * 2# ok, a duration twice as long 2 * $duration# same What are your thoughts? I've summarized my thoughts here, before I read your email: http://perlgeek.de/blog-en/perl-6/real-world-strikes-back.html Another example: current Duration % Duration is forbidden. But I have a very good use case: suppose I want to organize a 60 minutes session, and it's filled with presentations, each 8 minutes long. How long do I have for the introduction, if I fit in as many presentations as possible? The operation $session_duration % $presentation_duration answers me that. Why am I not allowed to carry out that operation? Because some designer thought I'd be better off not doing that operation. Wow, awesome reason/sarcasm. [1] https://github.com/rakudo/rakudo/commit/d9e22463479927fa8f1f594753979022de35970d [2] http://rt.perl.org/rt3/Ticket/Display.html?id=78896 [3] https://github.com/perl6/specs/commit/32abb95b9776e1cb7672c8a6a77612c86b37aea2#L0R1333
Re: exponentiation of Duration's
On 11/17/10 14:03, Moritz Lenz wrote: Am 17.11.2010 10:31, schrieb Kris Shannon: $duration * $duration# WRONG, durations aren't geometric $duration * 2# ok, a duration twice as long 2 * $duration# same What are your thoughts? I've summarized my thoughts here, before I read your email: http://perlgeek.de/blog-en/perl-6/real-world-strikes-back.html Ignoring the sarcasm, Moritz's blog and reply seem reasonable about what should be defined by perl. Once a number has been generated, viz., by obtaining a duration, that number can be manipulated however necessary. The interpretation of the number is a matter for the programmer, not the language designer. To illustrate, lets take a different problem. Suppose we have lengths in $x and $y, then the dimension of $a = $x * $y is of area, not of length. Is it really consistent to forbid $x = $x * $y in case the $x may be mistakenly interpretted as a length and not an area? In the same vein, $duration * $duration has the physical dimension of duration squared. True that is not the dimension of duration, and so assigning it to a duration variable might cause a problem of physical interpretation. Neverthless, it doesn't seem to me that trapping dimension errors is something a programming language should be doing. Or am I missing something? Richard
Re: exponentiation of Duration's
Am 17.11.2010 12:55, schrieb Richard Hainsworth: On 11/17/10 14:03, Moritz Lenz wrote: Am 17.11.2010 10:31, schrieb Kris Shannon: $duration * $duration # WRONG, durations aren't geometric $duration * 2 # ok, a duration twice as long 2 * $duration # same What are your thoughts? I've summarized my thoughts here, before I read your email: http://perlgeek.de/blog-en/perl-6/real-world-strikes-back.html Ignoring the sarcasm, Moritz's blog and reply seem reasonable about what should be defined by perl. Please note that my sarcasm applied only to one particular sentence, not to the whole mail :-) Once a number has been generated, viz., by obtaining a duration, that number can be manipulated however necessary. The interpretation of the number is a matter for the programmer, not the language designer. To illustrate, lets take a different problem. Suppose we have lengths in $x and $y, then the dimension of $a = $x * $y is of area, not of length. Is it really consistent to forbid $x = $x * $y in case the $x may be mistakenly interpretted as a length and not an area? In the same vein, $duration * $duration has the physical dimension of duration squared. True that is not the dimension of duration, and so assigning it to a duration variable might cause a problem of physical interpretation. Indeed. Just as a data point, in physics duration squared does exist. Just think of the definition of acceleration, which is the second time derivative of position. Approximation of derivative as a finite fraction makes it a = x / t^2. (And I might add that it also appears in force, energy and power that way). Neverthless, it doesn't seem to me that trapping dimension errors is something a programming language should be doing. Thank you for phrasing it much better than I managed to. Cheers, Moritz
Re: exponentiation of Duration's
On 11/17/2010 01:46 PM, Moritz Lenz wrote: Just as a data point, in physics duration squared does exist. On the other hand, i can see why an Instant can't be used as a linear value: it does not have a clear origin (or zero value). Therefore the multiplication of two Instant may results in different results based on where you place the zero, unless you first convert the Instant in a Duration (e.g. seconds since 1 jan 1970) Oha
Re: exponentiation of Duration's
Am 17.11.2010 14:02, schrieb Oha: On 11/17/2010 01:46 PM, Moritz Lenz wrote: Just as a data point, in physics duration squared does exist. On the other hand, i can see why an Instant can't be used as a linear value: it does not have a clear origin (or zero value). That's correct, and the reason that nobody argued for changing Instant so far. Therefore the multiplication of two Instant may results in different results based on where you place the zero, unless you first convert the Instant in a Duration (e.g. seconds since 1 jan 1970) Right. And therefore having to do the conversion explicitly is a good thing -- you immediately see which epoch was used. Cheers, Moritz
Re: exponentiation of Duration's
I'm not convinced that the type system shouldn't be helping with dimensional analysis, but at least it shouldn't hurt. By all means, let the programmer raise a Duration to a power - but the type of the result should not also be Duration. In the absence of automatic dimension tracking, just return a plain number. On Wednesday, November 17, 2010, Moritz Lenz mor...@faui2k3.org wrote: Am 17.11.2010 14:02, schrieb Oha: On 11/17/2010 01:46 PM, Moritz Lenz wrote: Just as a data point, in physics duration squared does exist. On the other hand, i can see why an Instant can't be used as a linear value: it does not have a clear origin (or zero value). That's correct, and the reason that nobody argued for changing Instant so far. Therefore the multiplication of two Instant may results in different results based on where you place the zero, unless you first convert the Instant in a Duration (e.g. seconds since 1 jan 1970) Right. And therefore having to do the conversion explicitly is a good thing -- you immediately see which epoch was used. Cheers, Moritz -- Mark J. Reed markjr...@gmail.com
Re: exponentiation of Duration's
Mark (): I'm not convinced that the type system shouldn't be helping with dimensional analysis, but at least it shouldn't hurt. By all means, let the programmer raise a Duration to a power - but the type of the result should not also be Duration. In the absence of automatic dimension tracking, just return a plain number. Or, by Ockham, since Duration is now deprived of its only task -- making life harder for the programmer -- remove it altogether from the language and just put a number type in its place, representing number of seconds. // Carl
Re: exponentiation of Duration's
I still have uses for Durations. For instance, I want to dispatch a different .Stringy method to Durations than to Nums. It's convenient to me that the difference between two Instants has a different type than the difference between 1654321681.123 and 1654321021.65438. I just think Durations should be Liskov substitutable for Rats. I don't give any credence at all to the school of thought that the language designer can think of every legitimate mathematical operation for the difference between two instants. But I still want to use the type system to do MMD. Cheers, Mason On Nov 17, 2010, at 08:56 AM, Carl Mäsak wrote: Mark (): I'm not convinced that the type system shouldn't be helping with dimensional analysis, but at least it shouldn't hurt. By all means, let the programmer raise a Duration to a power - but the type of the result should not also be Duration. In the absence of automatic dimension tracking, just return a plain number. Or, by Ockham, since Duration is now deprived of its only task -- making life harder for the programmer -- remove it altogether from the language and just put a number type in its place, representing number of seconds. // Carl
Re: exponentiation of Duration's
On 11/17/2010 02:56 PM, Carl Mäsak wrote: Or, by Ockham, since Duration is now deprived of its only task -- making life harder for the programmer -- remove it altogether from the language and just put a number type in its place, representing number of seconds. I could be wrong but this reminds me that a Duration could not be only based in seconds, but also in other units (which may automagically be converted to seconds) and also those seconds may be leap or not. Maybe the point is that really the power of a Duration should not be performed, unless you coerce the Duration in a specific unit value? Extending a bit more, does an Instant be specified in a TimeZone? Could an Instant be incremented by Day units? What happen if this increment change from daylight saving to normal time? HTH Oha
Re: exponentiation of Duration's
On Wed, Nov 17, 2010 at 2:20 PM, Oha o...@oha.it wrote: I could be wrong but this reminds me that a Duration could not be only based in seconds, but also in other units (which may automagically be converted to seconds) and also those seconds may be leap or not. Maybe the point is that really the power of a Duration should not be performed, unless you coerce the Duration in a specific unit value? I was thinking about larger scale durations - sometimes seconds are just an irrelevence http://dinosaurs.about.com/od/dinosaurbasics/a/dinosaurages.htm ( URL says it all ) Steve
Re: exponentiation of Duration's
Am 17.11.2010 15:20, schrieb Oha: On 11/17/2010 02:56 PM, Carl Mäsak wrote: Or, by Ockham, since Duration is now deprived of its only task -- making life harder for the programmer -- remove it altogether from the language and just put a number type in its place, representing number of seconds. I could be wrong but this reminds me that a Duration could not be only based in seconds, but also in other units (which may automagically be converted to seconds) That's indeed a possible use case, but no such thing is specced at the moment. and also those seconds may be leap or not. They are not. As S02 says. Maybe the point is that really the power of a Duration should not be performed, unless you coerce the Duration in a specific unit value? S02 is pretty explicit that usage of Duration as a numerical value assumes seconds as a unit. Extending a bit more, does an Instant be specified in a TimeZone? Read S02. Could an Instant be incremented by Day units? Only if you define a day as 24 * 60 * 60 seconds. What happen if this increment change from daylight saving to normal time? Instants and Durations don't have such a concept. Please read S02. Cheers, Moritz
Re: exponentiation of Duration's
If I'm following this correctly, shouldn't we just say that Duration does Num? That way, a Duration can be used exactly like a Num is (with units measured in seconds); but it could also have special capabilities above and beyond what a Num can do, if such capabilities are needed. More generally, I wonder if maybe we _should_ provide a tool to help with dimensional analysis: a role that does Num, but also tracks the units for you. The simplest version would leave it up to the programmer to handle unit conversions (e.g., divide a Dimensional that uses the seconds unit by a Dimensional that contains 86400 for its value and seconds/day for its units to get a Dimensional that uses the days unit, rather than providing built-in unit conversion routines). Indeed, th simplest form of Dimensional ought to be able to work with arbitrary units. The idea here isn't to place limitations on anything, but rather to make it easier to track additional data that's relevant to the calculations being performed. With this in place, Duration would be synonymous with Dimensional, measured in 'seconds'. That said, it's possible that this would open up a can of worms. Would it? If so, it can be postponed; Perl 6 has this nice little versioning ability that lets us retroactively alter roles; so one could easily put together a Dimensionality module at a later date that redefines what a Duration is. -- Jonathan Dataweaver Lang
Re: exponentiation of Duration's
Am 17.11.2010 17:50, schrieb Jon Lang: If I'm following this correctly, shouldn't we just say that Duration does Num? Num is a class (think floating point number). The role you're looking for is probably either Numeric or Real. If we say that Duration inherits from Rat or FatRat, it automatically does both roles. That way, a Duration can be used exactly like a Num is (with units measured in seconds); but it could also have special capabilities above and beyond what a Num can do, if such capabilities are needed. Right. That's what role composition, inheritance and possibly other forms of subtyping are about. More generally, I wonder if maybe we _should_ provide a tool to help I think this question can only be answered in a meaningful way if somebody actually implements such a thing as a module (which should be entirely possible in Rakudo right now). Then we'll see if people take it up and use it. That said, it's possible that this would open up a can of worms. Would it? Another reason to prototype it as a module. Cheers, Moritz
Re: exponentiation of Duration's
Moritz Lenz wrote: Am 17.11.2010 17:50, schrieb Jon Lang: More generally, I wonder if maybe we _should_ provide a tool to help I think this question can only be answered in a meaningful way if somebody actually implements such a thing as a module (which should be entirely possible in Rakudo right now). Then we'll see if people take it up and use it. That said, it's possible that this would open up a can of worms. Would it? Another reason to prototype it as a module. Agreed. I'll look into writing something up. That said, I'm short on time, so don't hold your breath waiting for me to do it. I've been thinking about this some more: perhaps the dimensionality feature, if included at all, should be done as a trait; e.g., 5 seconds would be C 5 but units(sec) , or something to that effect. That way, you could easily add units to Num, Rat, Int, Complex, or anything else that could reasonably be dimensional, and they would continue to be usable in their original context. With respect to Instant and Duration, my gut instinct would be to change things so that in the default Perl setting, Duration goes away and is replaced by Num; but the Dimensionality module would modify Instant to be aware of units, and to act accordingly (e.g., Instant - Instant returns Num but units(sec); Instant + Num looks for units on the Num and throws an exception if it finds the wrong ones, or none). If you don't want to bother with dimensionality, use the standard perl setting; if you want perl tracking these things for you, use Dimensionality. In short, take Duration out of the default setting, but make its added functionality available by means of a module. -- Jonathan Dataweaver Lang
