On Feb 24, 6:05 am, markjr...@gmail.com (Mark J. Reed) wrote:
Fair enough: official TAI is only known exactly after the fact.
Does official TAI means what BIPM says it means, and just plain
TAI means whatever perl6 wants it to mean?
TAI is an achievement for technical merits, but even moreso
On Tue, Feb 23, 2010 at 10:02:02AM +0300, Richard Hainsworth wrote:
- Time Zone, which can differ from GMT by halves of an hour.
quarter hours in at least one place (Nepal)
This doesn't affect your reasoning.
Also, time zone abbreviations are ambiguous. PST can be
Pacific Standard Time,
On Mon, Feb 22, 2010 at 6:50 PM, Daniel Ruoso dan...@ruoso.com wrote:
So why have the duration TAI-based?
Simply because TAI is supposedly immutable as a scale, so it's predictable.
Gregorian time is not immutable and timezone definitions are not anyhow
predictable.
OK, this seems to be a
On Tue, 23 Feb 2010, Nicholas Clark wrote:
On Tue, Feb 23, 2010 at 10:02:02AM +0300, Richard Hainsworth wrote:
- Time Zone, which can differ from GMT by halves of an hour.
quarter hours in at least one place (Nepal)
This doesn't affect your reasoning.
Also, time zone abbreviations are
Em Dom, 2010-02-21 às 21:09 -0800, Larry Wall escreveu:
I now see that the most important determinant of DateTimes is
neither the Dates nor the Times themselves, but which TZ you're in.
I propose renaming Temporal to TZ, so we get TZ::Date, TZ::Time, etc,
since they're all dependent primarily
Em Dom, 2010-02-21 às 21:28 -0800, Larry Wall escreveu:
On Sat, Feb 20, 2010 at 10:39:20AM -0500, Mark J. Reed wrote:
: I just want to know what Perl 6 time zero is.
Well, there's no such thing as time 0 in Perl 6, in the sense that
Instant is more-or-less opaque.
I'd just like to add that
On Mon, Feb 22, 2010 at 1:13 PM, Daniel Ruoso dan...@ruoso.com wrote:
Em Dom, 2010-02-21 às 21:28 -0800, Larry Wall escreveu:
On Sat, Feb 20, 2010 at 10:39:20AM -0500, Mark J. Reed wrote:
: I just want to know what Perl 6 time zero is.
Well, there's no such thing as time 0 in Perl 6, in the
On Mon, Feb 22, 2010 at 1:31 PM, Mark J. Reed markjr...@gmail.com wrote:
Not according to S0, which says that an Instant will numify to the
^
S02.
number of TAI seconds since the TAI epoch. That's not opaque.
--
Mark J. Reed markjr...@gmail.com
On Mon, Feb 22, 2010 at 4:38 PM, Daniel Ruoso dan...@ruoso.com wrote:
The biggest difference proposed by the use of TAI is that when you ask
for the number of seconds between 2008-12-31T23:59:59+ and
2009-01-01T00:00:00+ you'll get 2 because of the leap second. But
you don't need to
On Mon, Feb 22, 2010 at 4:38 PM, Daniel Ruoso dan...@ruoso.com wrote:
And my point is precisely that the spec doesn't define it because it is
implementation and architecture dependant.
And what's the point of making it so? If you require arithmetic
results in TAI seconds, I don't see the
longer than the rest, so you can no longer do a simple
multiplication to convert to seconds. (Unless you're looking for a
POSIX time stamp instead of the actual length of the interval.)
I submit that if the inputs and outputs of Temporal are UTC, then Perl
is using UTC, not TAI. Is it TAI
2010/2/22 Mark J. Reed markjr...@gmail.com
If the interface between Perl time and human time is going to be done
through UTC, then I don't see the point in specifying that it's TAI
behind the scenes. Especially if you're not specifying the epoch.
The number of seconds between two points in
On Feb 22, 2:23 pm, markjr...@gmail.com (Mark J. Reed) wrote:
I submit that if the inputs and outputs of Temporal are UTC, then Perl
is using UTC, not TAI. Is it TAI internally?
Only the time scale which is approved by the ITU-R for use in radio
broadcasts has any international backing
To add to Daniel's comment.
Lets recast the time/date discussion in another way.
The way times and dates are quoted (human time) depends on:
- religion denomination: the Jewish, Muslim, and Bahai religions have
their own calendars as part of their religions; Orthodox and Catholic
(including
On Feb 19, 10:30 pm, la...@wall.org (Larry Wall) wrote:
2000 would have been a lovely epoch if only the astronomers had kept
their grubby hands off of civil time.
The astronomers might love to have the power to control something like
that, but I'm afraid that none who are alive now can take
quo there will be leap seconds.
I apologize to all the living astronomers for maligning them. :)
I now see that the most important determinant of DateTimes is
neither the Dates nor the Times themselves, but which TZ you're in.
I propose renaming Temporal to TZ, so we get TZ::Date, TZ::Time, etc
On Sat, Feb 20, 2010 at 10:39:20AM -0500, Mark J. Reed wrote:
: I just want to know what Perl 6 time zero is.
Well, there's no such thing as time 0 in Perl 6, in the sense that
Instant is more-or-less opaque. But it's currently specced to the
TAI epoch, if you force it. I could be argued into
I don't see the need for keeping UTC within a second of UT, either. I
also think the Gregorian correction is a little silly, but at least it
only rears its head 3 times in 400 years.
Still, that horse has sailed, right? Perl 6 is using TAI, and the
burden of correcting for civil time is on the
S02 says that if pressed, an Instant will numify into a count of
atomic seconds since the TAI epoch - but what is the TAI epoch? TAI
is normally expressed in the same terms as civil time - year, month,
date, hour, minute, second, fraction of second, according to the
Gregorian calendar, or else as
2000 would have been a lovely epoch if only the astronomers had kept
their grubby hands off of civil time. But no, we still have to put up
with leap seconds in civil time, for no good reason that I can discern.
We should adjust civil time once a century or so, I think. After all,
civil time is
(re subject: does it go `Ding!' when there's Stuff?)
On Feb 20, 2010, at 00:30 , Larry Wall wrote:
but an astronomer? But no, many millions of computers have to
accommodate
to the convenience of a very few people. And most computers still
don't
know how to do even that accommodation,
On Sat, 2 May 2009, Timothy S. Nelson wrote:
Hi. Can someone (Dave Rolsky?) please tell me why rewriting
S32/Temporal in terms of Enum roles would be bad? See the example of Enum
day roles here:
http://www.rakudo.org/node/39
Because day and month names are hardly universal, and forcing
HaloO,
Larry Wall wrote:
That seems a bit ugly though. Another way would be to define ± as
simple half-open Range and then overload comparison:
multi sub infix:==(Num $x,Range $r) {
$x == any($r.minmax);
}
This is strange. Having 1 == 1..3 and 3 == 1..3 as true is
not what I
HaloO,
Jon Lang wrote:
@a[50%] # accesses the middle item in the list, since Whatever is
set to the length of the list.
I don't understand what you mean with setting Whatever. Whatever is
a type that mostly behaves like Num and is used for overloaded
postcircumfix:[ ]:(Array @self:
Em Qui, 2009-02-26 às 17:01 +0100, TSa escreveu:
$y.error = 0.001;
$x ~~ $y;
Looking at this I just started wondering... why wouldn't that be made
with:
my $y = 10 but Imprecise(5%);
$x ~~ $y;
daniel
TSa wrote:
HaloO,
Jon Lang wrote:
�...@a[50%] # accesses the middle item in the list, since Whatever is
set to the length of the list.
I don't understand what you mean with setting Whatever. Whatever is
a type that mostly behaves like Num and is used for overloaded
postcircumfix:[
Daniel Ruoso wrote:
Em Qui, 2009-02-26 às 17:01 +0100, TSa escreveu:
$y.error = 0.001;
$x ~~ $y;
Looking at this I just started wondering... why wouldn't that be made
with:
my $y = 10 but Imprecise(5%);
$x ~~ $y;
That's not bad; I like it.
--
Jonathan Dataweaver Lang
On 2009 Feb 26, at 13:00, Jon Lang wrote:
I'm not sold on the notion that Num should represent a range of values
Arguably a range is the only sane meaning of a floating point number.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator
I don't know how relevant this is; but this sounds like the sort of
optimization that pure functional programming allows for - that is, if
the compiler ever sees a call like asin(sin($x)), it might optimize
the code by just putting $x in there directly, and bypassing both the
sin and asin calls -
Jon Lang wrote:
TSa wrote:
Jon Lang wrote:
�...@a[50%] # accesses the middle item in the list, since Whatever is
set to the length of the list.
I don't understand what you mean with setting Whatever. Whatever is
a type that mostly behaves like Num and is used for overloaded
On Feb 26, 2009, at 14:27 , Jon Lang wrote:
Jon Lang wrote:
Brandon S. Allbery wrote:
Jon Lang wrote:
I'm not sold on the notion that Num should represent a range of
values
Arguably a range is the only sane meaning of a floating point number.
Perhaps; but a Num is not necessarily a
Martin D Kealey wrote:
On Thu, 26 Feb 2009, Jon Lang wrote:
asin is not the inverse function of sin, although it's probably as close
as you can get. And even there, some sort of compiler optimization could
potentially be done, replacing the composition of asin and sin (both of
which have the
HaloO,
Doug McNutt wrote:
Thinking about what I actually do. . .
A near equal test of a float ought to be a fractional error based on the
current value of the float.
$x tested for between $a*(1.0 + $errorfraction) and $a*(1.0 -
$errorfraction)
I strongly agree that checking relative
I think the use of % for the modulus operator is too deeply ingrained
to repurpose its infix incarnation.
I do quite like the magical postfix %, but I wonder how far it should
go beyond ±:
$x += 5%; # becomes $x += ($x * .05)? Or maybe $x *= 1.05 ?
$x * 5%; # becomes $x * .05 ?
Mark J. Reed wrote:
I do quite like the magical postfix %, but I wonder how far it should
go beyond ±:
$x += 5%; # becomes $x += ($x * .05)? Or maybe $x *= 1.05 ?
$x * 5%; # becomes $x * .05 ?
If it works with ±, it ought to work with + and -. Rule of thumb: if
there's no easy way to
At 13:58 -0500 2/25/09, Mark J. Reed wrote:
I do quite like the magical postfix %, but I wonder how far it should
go beyond ±:
$x += 5%; # becomes $x += ($x * .05)? Or maybe $x *= 1.05 ?
$x * 5%; # becomes $x * .05 ?
For ratio-like comparisons for effective equality of floats some
On Wed, Feb 25, 2009 at 02:34:50PM -0800, Jon Lang wrote:
: Mark J. Reed wrote:
: I do quite like the magical postfix %, but I wonder how far it should
: go beyond ±:
:
: $x += 5%; # becomes $x += ($x * .05)? Or maybe $x *= 1.05 ?
: $x * 5%; # becomes $x * .05 ?
:
: If it works with ±,
On Feb 23, 2009, at 3:56 PM, mark.a.big...@comcast.net wrote:
Instant
Moment
Point
PointInTime
Timestamp
Event
Jiffy
Time
Juncture
On Mon, Feb 23, 2009 at 5:01 PM, Graham Barr gb...@pobox.com wrote:
Juncture
As has already been pointed out, that has extremely high potential for
being confused with Junctions.
--
Mark J. Reed markjr...@gmail.com
On Mon, Feb 23, 2009 at 11:54:44PM -0600, Chris Dolan wrote:
On Feb 23, 2009, at 11:16 PM, Larry Wall wrote:
if $x ~~ $y ± $epsilon {...}
where infix:± turns the single value into a range for the
smartmatch.
That's very cool. However, my first impression is that $y ± $epsilon
On Tuesday, 24. February 2009 17:59:31 Larry Wall wrote:
So it might be better as a (very tight?) operator, regardless of
the spelling:
$x ~~ $y within $epsilon
This is a pretty add-on to smartmatch but I still think
we are wasting a valueable slot in the smartmatch table
by making
On Tue, 2009-02-24 at 12:31 -0800, Jon Lang wrote:
$y ± 5 # same as ($y - 5) | ($y + 5)
$y within 5 # same as ($y - 5) .. ($y + 5)
Oh, that's just beautiful.
-'f
Daniel Ruoso wrote:
What about...
if $x ~~ [..] $x ± $epsilon {...}
That would mean that $x ± $epsilon in list context returned each value,
where in scalar context returned a junction, so the reduction operator
could do its job...
(I'm assuming that you meant something like if $y ~~ [..]
Em Ter, 2009-02-24 às 13:34 -0800, Jon Lang escreveu:
Daniel Ruoso wrote:
if $y ~~ [..] $x ± $epsilon {...}
Junctions should not return individual values in list context,
It is not the junction that is returning the individual values, but the
infix:± operator...
daniel
TSa wrote:
Larry Wall wrote:
So it might be better as a (very tight?) operator, regardless of
the spelling:
$x ~~ $y within $epsilon
This is a pretty add-on to smartmatch but I still think
we are wasting a valueable slot in the smartmatch table
by making numeric $x ~~ $y simply mean
On Tue, Feb 24, 2009 at 1:39 PM, Daniel Ruoso dan...@ruoso.com wrote:
Em Ter, 2009-02-24 às 13:34 -0800, Jon Lang escreveu:
Daniel Ruoso wrote:
if $y ~~ [..] $x ± $epsilon {...}
Junctions should not return individual values in list context,
It is not the junction that is returning the
Thinking about what I actually do. . .
A near equal test of a float ought to be a fractional error based on
the current value of the float.
$x tested for between $a*(1.0 + $errorfraction) and $a*(1.0 - $errorfraction)
If you're dealing with propagation of errors during processing of
data
Doug McNutt wrote:
Thinking about what I actually do. . .
A near equal test of a float ought to be a fractional error based on the
current value of the float.
$x tested for between $a*(1.0 + $errorfraction) and $a*(1.0 -
$errorfraction)
If you're dealing with propagation of errors during
On Tue, Feb 24, 2009 at 04:54:35PM -0800, Jon Lang wrote:
: Half-baked idea here: could we somehow use some dwimmery akin to
: Whatever magic to provide some meaning to a postfix:% operator?
: Something so that you could say:
:
: $x within 5%
:
: And it would translate it to:
:
: $x within
On 2009 Feb 23, at 8:34, Ruud H.G. van Tol wrote:
Martin D Kealey wrote:
Ah, we want a noun that isn't readily confused as an adjective.
Suitable terms might include: Instant Jiffy Juncture Moment
Occasion Snap Tick ...
Once :)
Then?
--
brandon s. allbery
On Tue, 24 Feb 2009, Jon Lang wrote:
$y ± 5 # same as ($y - 5) | ($y + 5)
$y within 5 # same as ($y - 5) .. ($y + 5)
I suspect that we're running against Huffman here, given the likely
usage -- ranges *should* be used at pretty much every floating point
equality test, whereas
On Wed, 25 Feb 2009, I wrote:
$y + ±5 # same as ($y - 5) | ($y + 5) (also same as $y - ±5)
$y ± 5# same as ($y - 5) .. ($y + 5)
A further question: should such ranges be [closed], (open) or [half-open)?
I would argue for half-open because then exactly one of a set of consecutive
Martin D Kealey wrote:
Ah, we want a noun that isn't readily confused as an adjective.
Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap Tick
...
Once :)
--
Ruud
not to be mixed
with Urzeit.
I'm not sure but isn't instant in English just a very short
duration? One says in an instant from which you can derive
a point in time only through the concept of now as a point in
time.
I like Instant as the name of the concept because it has a
temporal meaning which
On Mon, 23 Feb 2009, Ruud H.G. van Tol wrote:
Martin D Kealey wrote:
Ah, we want a noun that isn't readily confused as an adjective.
Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap
Tick ...
Once :)
Hmm. Temporal::OnceUponATime
for Temporal::Instant as well :).
I personally think that Instant is probably as good as we're going to
get, but am naturally not opposed to the search for a better alternative.
Point is probably the second-best option I've seen
On Mon, Feb 23, 2009 at 4:56 PM, mark.a.big...@comcast.net wrote:
Instant
Most apropos. Classes are nouns, so the adjectival meaning doesn't
cause a conflict, IMHO: an instant has nothing to do with instant
coffee.
Moment
Also apropos, and with a history in the field (Calendrical
Calculations
On 2009-Feb-23, at 10:09 am, TSa wrote:
I also think that time and numbers in general should be treated in
a fuzzy way by smart match.
My thought is to have == take a :within adverb, at least for imprecise
types like Num, that could be used to specify how close values need to
come in order
On Mon, Feb 23, 2009 at 09:08:39PM -0700, David Green wrote:
On 2009-Feb-23, at 10:09 am, TSa wrote:
I also think that time and numbers in general should be treated in
a fuzzy way by smart match.
My thought is to have == take a :within adverb, at least for imprecise
types like Num, that
Larry Wall wrote:
snip
This still seems to be confusing implementation issues with the point
I'm trying to make about the basic nature of time.
Duration and Instant are both simple (but typed) Num semantics
on seconds. There are no integers unless you specifically ask for
an interpretation in
enough to require a
module.
I also think some really basic parsing would be suitable -- no more
than the ability to understand strings in the same default ISO format
used for displaying dates and times, e.g.
my Temporal::Date $christmas = 2009-12-25;
As I said in the spec, you _can_
On Fri, 20 Feb 2009, Dave Rolsky wrote:
Renamed Temporal::Instant to Temporal::DateTime
Hmm. We had some mailing list discussion about this, and agreed on
Instant. I'd like to see your reasons in favour of DateTime.
Because DateTime makes sense and is a clear description of what
-ins should
be immutable for simplicity.
Date/time math was something else I'm also very keen to have. The
other built-ins play happily with operators -- why wouldn't the temporal
ones? By mutating operators, do you mean multi operators? If so, I
urge you to:
No, by mutating I mean anything
On Mon, 23 Feb 2009, Timothy S. Nelson wrote:
Renamed Temporal::Instant to Temporal::DateTime
Hmm. We had some mailing list discussion about this, and agreed on
Instant. I'd like to see your reasons in favour of DateTime.
Because DateTime makes sense and is a clear description
On Mon, 23 Feb 2009, Martin D Kealey wrote:
On Mon, 23 Feb 2009, Timothy S. Nelson wrote:
Renamed Temporal::Instant to Temporal::DateTime
Hmm. We had some mailing list discussion about this, and agreed on
Instant. I'd like to see your reasons in favour of DateTime.
Because
processing functionality to a specific calendar
is restrictive, whereas focussing on an underlying handling of time
using an accepted synchronisation standard allows for easier extensions.
d) This would mean that the functionality of dates should be handled by
modules.
Thus Temporal::Gregorian
was something else I'm also very keen to have. The
other built-ins play happily with operators -- why wouldn't the temporal
ones? By mutating operators, do you mean multi operators? If so, I urge
you to:
No, by mutating I mean anything which changes the object. As I said, I
think it's best
On Thu, Feb 19, 2009 at 7:26 PM, Dave Rolsky auta...@urth.org wrote:
After some discussion I made a number of drastic revisions to
S32-setting-library/Temporal.pod
What I want to see in Perl 6 is a set of very minimal roles that can be used
to provide a simply object from gmtime() and
, and not a concrete class? What would
one instant do that another can't? Representing a specific moment in
time sounds like a very concrete thing to me.
Presumably the core would also ship with a class that does the
Temporal::DateTime role.
However, it'd also be nice for things on CPAN6 to be able to satisfy
On Fri, Feb 20, 2009 at 2:39 AM, David Green david.gr...@telus.net wrote:
Why can't we just have time() that takes a :tz adverb and dispense with
gmtime() and localtime()?
It depends on what sort of value time() returns. In the caes of
Perl5, the return value is completely independent of time
Dates starting at midnight is fine, but I agree that a Date shouldn't
automatically coerce into midnight on that date. If it's going to
autocoerce at all, I'd recommend noon instead, but better to force the
programmer to pick what they mean.
On Fri, Feb 20, 2009 at 2:32 AM, David Green
David Green wrote:
I don't like dates just starting at midnight because I've run into too
many awkward cases where $time $date doesn't do what you mean because
it assumes 0:00:00 when you meant 23:59:59. I'd rather have dates
becomes time-ranges.
And not all midnights exist, because time
I'm getting a bit lost following precisely what's being proposed. What
I'm sort of feeling is that there are two fundamental immutable types
needed: Instants and Durations:
multi sub infix:- (Instant, Instant -- Duration)
multi sub infix:+ (Instant, Duration -- Instant)
multi sub infix:-
On Fri, Feb 20, 2009 at 02:07:05PM -0600, Dave Rolsky wrote:
On Fri, 20 Feb 2009, Dave Whipp wrote:
I'm getting a bit lost following precisely what's being proposed. What
I'm sort of feeling is that there are two fundamental immutable types
needed: Instants and Durations:
multi sub
On Fri, 20 Feb 2009, Larry Wall wrote:
Duration and Instant are both simple (but typed) Num semantics
on seconds. There are no integers unless you specifically ask for
an interpretation in minutes, hours, fortnights, what have you.
The basic flow of time is continuous and stable in Perl 6, or
- Original Message -
From: Dave Rolsky auta...@urth.org
That will make it clear
that there's no way to calculate one month from today using the core API.
one month from today is ill-defined regardless what time system you are
using. There are dates from which one month from today
On Fri, 2009-02-20 at 15:33 -0600, Dave Rolsky wrote:
Of course, if you're dealing with TAI only, you're safe for constants up
to ONE_WEEK.
So we just define ONE_MONTH as 4 * ONE_WEEK, right?
*duck*
-'f
On Fri, 20 Feb 2009, mark.a.big...@comcast.net wrote:
one month from today is ill-defined regardless what time system you
are using. There are dates from which one month from today can be
reasonably argued to be any of 5 different days. This is why bank
contracts are always to be written to
Assuming the Gregorian calendar, one month from today is well
defined for 98.15% of all dates, and there are a few logical options
for the other 1.85%. It's true you can't define one month as a
constant amount of time, but providing a method to return one month
after a given date is a reasonable
Just to clear up ahead of time, the consensus both here and on IRC
seemed to be that in the core, we put a basic Temporal::Instant object that
about powerful enough to deal with:
- localtime/gmtime functionality
- ctime, mtime, etc, in stat()
- nanoseconds or whatever needed
After some discussion I made a number of drastic revisions to
S32-setting-library/Temporal.pod
What I want to see in Perl 6 is a set of very minimal roles that can be
used to provide a simply object from gmtime() and localtime(). These
objects should not handle locales, proper Olson
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
On Thu, 19 Feb 2009, Martin D Kealey wrote:
Rather, let's have immutable time values, and methods which return other
values where various computations (*1) have been applied. Provide
constructors which take the Y/M/D/h/m/s/dst_now/dst_rule
keen to have. The
other built-ins play happily with operators -- why wouldn't the temporal ones?
By mutating operators, do you mean multi operators? If so, I urge you to:
- Read my comments lower down in this e-mail about the infix:~
operator, which will give you some appropriate
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
+role Temporal::DateTime {
+has Temporal::Date $!date handles year month day day-of-week;
Can't do this, I think; this would require an instance of
Temporal::Date, which is a role and can't be instantiated. That's why I was
using
On 2009-Feb-19, at 4:39 pm, Martin Kealey wrote:
2. Date isa Instant works sensibly: anywhere that expects an
Instant, you
can give it a Date. (Assuming we all agree that dates start at
midnight, but
then we *are* talking specifically Gregorian dates.)
I don't like dates just starting at
On 2009-Feb-19, at 11:26 am, Dave Rolsky wrote:
What I want to see in Perl 6 is a set of very minimal roles that can
be used to provide a simply object from gmtime() and localtime().
These objects should not handle locales, proper Olson timezones,
string parsing, user-defined formatting, or
101 - 186 of 186 matches
Mail list logo
