Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: r25445 - docs/Perl6/Spec/S32-setting-library

1 view
Skip to first unread message

Darren Duncan

unread,
Feb 19, 2009, 4:52:20 PM2/19/09
to perl6-l...@perl.org
pugs-c...@feather.perl6.nl wrote:
> Author: autarch
> Date: 2009-02-19 19:14:48 +0100 (Thu, 19 Feb 2009)
> New Revision: 25445
>
> Modified:
> docs/Perl6/Spec/S32-setting-library/Temporal.pod
> Log:
> This is a very drastic revision (hopefully this won't turn into a revert war ;)

I agree with your changes in general. Let the base Temporal just be basic roles
and let implementing
classes fill out more details, provide operators and system services and
formatting and locales and timezones and so on.

> Renamed Temporal::Instant to Temporal::DateTime

As per my previous post, I recommend having both, like this:

role Instant {
has Int $.year;
...
has Rat $.second;
}

role DateTime is Instant where defined $.year ... and defined $.second;

role Date is Instant where defined $.year ... and defined $.day;

role Time is Instant where defined $.hour ... and defined $.second;

So something like that. So Date and Time mean all Date|Time details, and
DateTime means all details of both. And Instant means any combination of
defined or not of said member attributes. And that's actually why I advocated
Instant as a name for that more-broad-than-DateTime thing.

So please provide all 4 roles, that's what I strongly support.

-- Darren Duncan

P.S. I will be away from a computer during Fri-Sun and much of today too so if
I don't chime in then it is not due to disinterest.

Darren Duncan

unread,
Feb 19, 2009, 6:36:36 PM2/19/09
to perl6-l...@perl.org
Dave Rolsky wrote:

> On Thu, 19 Feb 2009, Darren Duncan wrote:
>> So something like that. So Date and Time mean all Date|Time details,
>> and DateTime means all details of both. And Instant means any
>> combination of defined or not of said member attributes. And that's
>> actually why I advocated Instant as a name for that
>> more-broad-than-DateTime thing.
>
> Is there a way in which a class which does the Date role could change
> the type $.year so it was "Int|Undef"?
>
> I'd prefer to leave the notion of an incomplete Date(|Time|DateTime) out
> of the core, because it makes everything more complicated.
>
> If, OTOH, I couldn't make OnCPAN6::DateTime::Incomplete do the DateTime
> interface, that'd be a good argument for changing the core interface.

I was under the impression that Perl typed containers are allowed to hold Undef
by default, eg when you say "has Int $foo" that allows an Undef $foo by default.
So in that case I'm already getting what flexibility I want by default if that
is how the roles are declared. Correct me if I'm wrong. -- Darren Duncan

Larry Wall

unread,
Feb 19, 2009, 6:58:51 PM2/19/09
to perl...@perl.org, perl6-l...@perl.org
On Thu, Feb 19, 2009 at 05:05:32PM -0600, Dave Rolsky wrote:
> On Thu, 19 Feb 2009, Darren Duncan wrote:
>
>> As per my previous post, I recommend having both, like this:
>>
>> role Instant {
>> has Int $.year;
>> ...
>> has Rat $.second;
>> }
>>
>> role DateTime is Instant where defined $.year ... and defined $.second;
>>
>> role Date is Instant where defined $.year ... and defined $.day;
>>
>> role Time is Instant where defined $.hour ... and defined $.second;
>>
>> So something like that. So Date and Time mean all Date|Time details,
>> and DateTime means all details of both. And Instant means any
>> combination of defined or not of said member attributes. And that's
>> actually why I advocated Instant as a name for that
>> more-broad-than-DateTime thing.
>
> Is there a way in which a class which does the Date role could change the
> type $.year so it was "Int|Undef"?

Doesn't have to. Int already comes with an undefined value known as
Int, aka the protoobject. Only subset types (and their cousins, native
types) can restrict values to being defined, and they do so on the
primarily on basis of constraints, and only secondarily on whether the
underlying storage can represent an undefined value. So an Int can be
undefined, but an int can't. A Num can be undefined, but a num can only
approximate that with NaN.

So the built-in types may certainly represent incomplete information.

That being said, I'm thinking that all actual times represented by
floats in Perl are TAI time, not the Unix pseudo time with hidden
leap seconds. I sure wish they'd done away with civic leap seconds
in 2000 and said we'll put in a leap minute or two on century breaks...

Well, leaving that rant aside, I'm still tempted to say that times
in Perl 6 are TAI seconds since 2000. Standard TAI would work too.
In any case, I think if Perl is to be taken seriously for scientific
computing its native seconds shouldn't be varying in length. And I
also think with the advent of ubiquitous GPS we're getting to the
point where nearly all computers will know the correct atomic time.
Time is on our side, as it were...

Larry

Timothy S. Nelson

unread,
Feb 19, 2009, 8:11:57 PM2/19/09
to perl6-l...@perl.org
On Thu, 19 Feb 2009, pugs-c...@feather.perl6.nl wrote:

> Author: autarch
> Date: 2009-02-19 19:14:48 +0100 (Thu, 19 Feb 2009)
> New Revision: 25445
>
> Modified:
> docs/Perl6/Spec/S32-setting-library/Temporal.pod
> Log:
> This is a very drastic revision (hopefully this won't turn into a revert war ;)

I hope not. My plan is to argue about them on the mailing list, and
hope that we'll come to some reasonable consensus :).

I'd also like to say a mea culpa -- I had a commit ready to go before
I asked Dave/autarch to make the appropriate changes, but I forgot to commit
it :). So some of the stupid things are things I should've done myself.

I've noticed that a number of my objections were scattered various
places throughout my reply, so I'm taking the liberty of grouping a few things
together by argument :).

Formatters
==========

> removed all references to ...
[snip]
> Format specifiers - this could come from locales (CLDR specifies this)
> or strftime, but again, it's more complicated than is needed
[snip]
> Added iso8601 output for every role, and made that the
> stringification. ISO8601 is unambiguous world-wide, easy to read, and
> easy to output.

I'm quite keen to have something here as a formatter. I was hoping
for CLDR, but I'd be happy with even a subset of CLDR that does what we want.
Or even, failing that, with the ISO8601 part being implemented as a formatter.

> + # These always return the long English names
> + method month-name () returns Str; # "January"
> + method day-name () returns Str; # "Tuesday"

This is one reason I was wanting a formatter -- then we wouldn't need
all these functions. People could just go $time.format('MMMM') and get what
they want. Like I said though, the core might be better off with a subset of
CLDR that does month name, day name, and the ISO8601 stringification.

> + # returns the date formatted in ISO8601 style - 2008-01-25
> + method iso8601 () returns Str
> + { [ self.year, self.month, self.date ].join('-') };

I was hoping we could leave this also to a formatter that would be
called upon by infix:{'~'}.


DateTime math
=============

> removed all references to ...
[snip]
> Any sort of date or time math
[snip]
> Got rid of all mutating operators on everything. The built-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:
- Read my comments lower down in this e-mail about the infix:<~>
operator, which will give you some appropriate background
- See http://perlcabal.org/syn/S03.html#Smart_matching which appears to
me to make the ~~ operator do all kinds of things (although I could be
wrong here). Actually, the point I'm making is much more easily seen
by finding "=head1 Smart matching" in
http://svn.pugscode.org/pugs/docs/Perl6/Spec/S03-operators.pod

Other things
============

> Here's the changes in summary:
>
> removed all references to ...
>
> Locales, including eras, which come from a locale - this is a vast and complicated domain
>
> Alternate calendars - also vast and complicated
>
> String parsing of any sort - ditto, see the pattern here? ;)
>
> Comparing dates or times to durations - this just doesn't make
> sense. Is 2009-02-23 greater or less than 5 days?

I agree, this was stupid :).

> 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.

One of my (unmentioned) reasons for not calling it DateTime is that I
was expecting the CPAN module to be called DateTime, and didn't want to stamp
on any names. But that's not as high a priority.

> Got rid of Temporal::Subsecond and just made Temporal::Time allow for
> sub-second resolutions. Not sure if this is best done with an
> $.attosecond attribute or as a decimal number.

See other discussions on the mailing list.

> Renamed Temporal::Timezone to Temporal::TimeZone::Observance. The
> latter is a simple thing which represents the offset, isdst flag, and
> short name for a given local time. This information should be
> available on all supported platforms. TimeZones themselves are
> complicated and very much platform-dependent. Better to leave this as
> a separate CPAN6 distro.

Bewdy mate! :) [to translate that into non-Australian, it's
"Beauty, mate", or "I'm pleased, friend"].

> Added numification overloading for Temporal::DateTime, which gives us
> comparison for free.

Cool :).

In case I didn't say this elsewhere, I'd be happy to see localtime and
gmtime disappear in favour of other temporal constructors. And surely time()
could be merged in as well?

> + method infix:{'~'} return Str { self.iso8601 };

Also, while I may be wrong, my reading of S13 says that operator
overloading is not attached to an object (although maybe it's allowed to be
defined in it. That means that instead of

method infix:{'~'} return Str { self.iso8601 };

...you'd need to write one of:

Temporal::Date multi sub infix:{'~'}(Temporal::Date $self, Temporal::Date $other)
multi sub infix:{'~'}(Temporal::Date $self, Temporal::Date $other --> Temporal::Date)

Note also that I've been quite sloppy in not declaring return values
on a lot of these functions; if you'd like to fix that, feel free. Oh, and it
may also be that the first of those above should have the multi before the
Temporal::Date.

> +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 "does" instead. I don't know what the alternative is, but I'll leave
that to you :).

> + has Temporal::Time $!time handles <hour minute second fractional-second>;
> + has Temporal::TimeZone::Observance $!timezone handles <offset isdst>;

Ditto :).

HTH,


---------------------------------------------------------------------
| Name: Tim Nelson | Because the Creator is, |
| E-mail: way...@wayland.id.au | I am |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----

Timothy S. Nelson

unread,
Feb 19, 2009, 11:17:19 PM2/19/09
to Larry Wall, perl...@perl.org, perl6-l...@perl.org
On Thu, 19 Feb 2009, Larry Wall wrote:

> Well, leaving that rant aside, I'm still tempted to say that times
> in Perl 6 are TAI seconds since 2000. Standard TAI would work too.

I've wondered sometimes about the idea of having a dual/moving epoch.
By this, I mean that you have eg. two Ints, one which represents the years
since 1AD or whatever, and the other of which represents the number of seconds
from the beginning of that year. I'm sure many of you can see the advantages
and disadvantages of that scheme better than I can, but I thought I'd throw it
out there so you can all see whether or not you like it.

Chris Dolan

unread,
Feb 19, 2009, 11:49:15 PM2/19/09
to Timothy S.Nelson, Larry Wall, perl...@perl.org, perl6-l...@perl.org
On Feb 19, 2009, at 10:17 PM, Timothy S. Nelson wrote:

> On Thu, 19 Feb 2009, Larry Wall wrote:
>
>> Well, leaving that rant aside, I'm still tempted to say that times
>> in Perl 6 are TAI seconds since 2000. Standard TAI would work too.
>
> I've wondered sometimes about the idea of having a dual/moving
> epoch. By this, I mean that you have eg. two Ints, one which
> represents the years since 1AD or whatever, and the other of which
> represents the number of seconds from the beginning of that year.
> I'm sure many of you can see the advantages and disadvantages of
> that scheme better than I can, but I thought I'd throw it out there
> so you can all see whether or not you like it.
>

I don't see the advantage of either of those. TAI 2000 is just UTC
1970 plus a constant offset. 1AD is just UTC 1970 minus a bigger
constant offset. Sure, those are slightly easier epochs for a human
(ignoring the Julian/Gregorian shift), but not any easier for a
computer. UTC 1970 has the big advantage that it is already the
underlying value returned by most operating systems and many date/
time libraries, so there's no extra additive operation to perform if
that's what you want.

A much more important issue is the use of integer seconds.
Milliseconds is a much more useful precision for humans and micro- or
nanoseconds is a better precision for machines. I think Time::HiRes
with a better API as a builtin would be a big win.

Aside: I just learned the other day that Java's Thread.sleep(long
millis, int nanos) method just rounds the nanos to the nearest millis
and invokes Thread.sleep(long millis). I guess that's a forward
looking API for when the OS really can timeslice that small, but it's
a little silly today.
http://krugle.org/kse/entfiles/jdk/sun.com/jdk-1.5/j2se/src/share/
classes/java/lang/Thread.java#246

Maybe Perl 6 should be really forward looking and include a time
dilation factor so it can be the first language designed from the
ground up for interstellar travelers who want to use a non-inertial
reference. Or GPS? :-)

Chris

Timothy S. Nelson

unread,
Feb 20, 2009, 1:36:16 AM2/20/09
to Chris Dolan, Larry Wall, perl...@perl.org, perl6-l...@perl.org
On Thu, 19 Feb 2009, Chris Dolan wrote:

> On Feb 19, 2009, at 10:17 PM, Timothy S. Nelson wrote:
>
>> On Thu, 19 Feb 2009, Larry Wall wrote:
>>
>>> Well, leaving that rant aside, I'm still tempted to say that times
>>> in Perl 6 are TAI seconds since 2000. Standard TAI would work too.
>>
>> I've wondered sometimes about the idea of having a dual/moving epoch.
>> By this, I mean that you have eg. two Ints, one which represents the years
>> since 1AD or whatever, and the other of which represents the number of
>> seconds from the beginning of that year. I'm sure many of you can see the
>> advantages and disadvantages of that scheme better than I can, but I
>> thought I'd throw it out there so you can all see whether or not you like
>> it.
>>
>
> I don't see the advantage of either of those. TAI 2000 is just UTC 1970 plus
> a constant offset. 1AD is just UTC 1970 minus a bigger constant offset.
> Sure, those are slightly easier epochs for a human (ignoring the
> Julian/Gregorian shift), but not any easier for a computer. UTC 1970 has the
> big advantage that it is already the underlying value returned by most

> operating systems and many date/time libraries, so there's no extra additive

> operation to perform if that's what you want.

Having now read the Wikipedia page on time_t, I withdraw my suggestion
:).

> A much more important issue is the use of integer seconds. Milliseconds is a

The new interface looks like it will cope with something small fairly
well. Dave Rolsky is doing a good job, even though I think there may be room
for improvement :).

> Maybe Perl 6 should be really forward looking and include a time dilation
> factor so it can be the first language designed from the ground up for
> interstellar travelers who want to use a non-inertial reference. Or GPS?

I'm not a rocket surgeon, but we'd need a $.velocity to calculate
that, wouldn't we?

:)

Daniel Ruoso

unread,
Feb 20, 2009, 12:21:50 PM2/20/09
to Dave Rolsky, perl6-l...@perl.org, perl...@perl.org
Em Sex, 2009-02-20 às 10:40 -0600, Dave Rolsky escreveu:
> On Fri, 20 Feb 2009, Daniel Ruoso wrote:
> > If we're going to use an epoch, it should be the Operating System's
> > epoch. Anything else will lead to confusion and disorder ;P
> And which OS epoch would that be?

The one where the program is being run.

The only way of being actually cross platform is to providing more
semantics to the value, choosing an arbitrary epoch that is not going to
be consistent with the epoch used in the OS is simply being annoying.

daniel

Mark J. Reed

unread,
Feb 20, 2009, 12:17:59 PM2/20/09
to Timothy S. Nelson, Chris Dolan, Larry Wall, perl...@perl.org, perl6-l...@perl.org
Considering time scales, there are three that significantly
interrelate, and no matter what Perl 6 uses internally, it needs to be
able to convert to and from these:

TAI: continuous count of time using SI seconds as measured by atomic
clocks, 60 seconds in every minute, 60 minutes in every hour, 24 hours
in every day.

UTC: TAI with an offset, as corrected for the actual revolution of the
Earth: usually 60 seconds in a minute, but occasionally 59 or 61. 60
minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in
every day (86399, 86400, or 86401 seconds).

time_t: the value you get by taking the UTC time since Jan 1, 1970 at
midnight and converting to a simple count of seconds, pretending there
have been no leap seconds along the way.

Right now as I type this it is 17:13:38 UTC. That's 17:14:12 in TAI
(which is 34 seconds ahead of UTC until the next leap second). The
corresponding time_t value is 1,235,150,018, but there have actually
been 1,235,150,042 seconds since the UNIX epoch.

Larry Wall

unread,
Feb 20, 2009, 12:25:45 PM2/20/09
to perl...@perl.org, perl6-l...@perl.org
On Fri, Feb 20, 2009 at 02:21:50PM -0300, Daniel Ruoso wrote:

Perl 6 will have a type system, unlike C.

Larry

Larry Wall

unread,
Feb 20, 2009, 12:11:24 PM2/20/09
to perl...@perl.org, perl6-l...@perl.org
On Fri, Feb 20, 2009 at 10:40:04AM -0600, Dave Rolsky wrote:
> I don't care what epoch we standardize on, as long as it's consistent
> across platforms.

Indeed, as long as it's well-typed we can actually pick whatever epoch
we want and assume that proper platform-specific conversions can be
automatically applied. And if that's not possible, we'll need to
speak to the language designer.

And I'd still argue that a 100-year language should use 2000 for its
epoch. As should a 1000-year language... :)

But leaving that aside, a properly written time algorithm doesn't have
to know its epoch, given sufficient language support and a stable
timebase (which POSIX time ain't as long as it ignores leapseconds).

The other thing I'll be on the warpath about is any suggestion of
making integer fractions of seconds any part of the normal time
interface. Such interfaces are always going to be wrong somewhere
eventually. Regardless of their declared type, normal Perl 6 times and
durations should be calculated in Num or Rat, whatever the best
approximation to the real continuum is. I am unlikely to look
kindly on any kind of fixed-point solution for normal user times.
(All this comes with the major caveat that experts and time mavins
can of course use whatever formats they want for their particular
application. I'm only talking about the default representation of
time in Perl 6.)

Basically, I want yottaseconds and yoctoyears calculated with the same
datatype for normal time. No discontinuities allowed, though of
course precision is going to be relative. That's construed as a
feature.

Larry

Larry Wall

unread,
Feb 20, 2009, 1:17:53 PM2/20/09
to perl...@perl.org, perl6-l...@perl.org
On Fri, Feb 20, 2009 at 08:12:36AM -0600, Dave Rolsky wrote:
> That's certainly fine with me, but I think we'd still want some simple
> objects on top of them, rather than handing people a single epoch numbre
> to deal with.

Certainly, we'll be depending on the type system to keep these things
straight. I'm not suggesting the user use bare Nums as anything other
than naive durations for APIs such as sleep(). I'm more interested
in the mathematical purity (counting floating point as pure *cough*)
of the operations, and the proper use of the type system to keep the
units straight. I'm also interested in killing the POSIX concept of
time as soon as possible, at least as the default view of reality.

By the by, I'm also inclined to agree with those who prefer "Instant"
to "DateTime" on aesthetic grounds.

Larry

Daniel Ruoso

unread,
Feb 20, 2009, 1:59:47 PM2/20/09
to Larry Wall, perl...@perl.org, perl6-l...@perl.org
Em Sex, 2009-02-20 às 10:53 -0800, Larry Wall escreveu:
> Perhaps we could just go with Instant and Duration as top-level roles
> since they're rather fundamental to lots of computing. As builtins
> they would presumably come with appropriate operators predefined. And
> as roles they could be tweaked by a derived class to mean something
> slightly different, if the need arises.

That's exactly the kind of solution I was hoping for ;)

We still will need to think on the API to that, and that's where looking
at p5 DateTime makes sense ;)

daniel

Larry Wall

unread,
Feb 20, 2009, 1:53:13 PM2/20/09
to perl...@perl.org, perl6-l...@perl.org
On Fri, Feb 20, 2009 at 03:31:03PM -0300, Daniel Ruoso wrote:
: Em Sex, 2009-02-20 às 10:17 -0800, Larry Wall escreveu:
: > By the by, I'm also inclined to agree with those who prefer "Instant"

: > to "DateTime" on aesthetic grounds.
:
: I should note that I'm insisting on DateTime just as the reference p5
: module in CPAN, I don't oppose it being called Instant in Perl 6.

And I should clarify that by Instant I was referring to a particular
data type, not the module that defines it.

I suppose Temporal is as good a module name as any, though Temporal::Instant
does seem a bit redundant...

On the other hand, Instant::Duration is just wrong. Perhaps we could


just go with Instant and Duration as top-level roles since they're
rather fundamental to lots of computing. As builtins they would
presumably come with appropriate operators predefined. And as roles
they could be tweaked by a derived class to mean something slightly
different, if the need arises.

Larry

Chris Dolan

unread,
Feb 20, 2009, 2:36:12 PM2/20/09
to Mark J. Reed, Timothy S. Nelson, Chris Dolan, Larry Wall, perl...@perl.org, perl6-l...@perl.org

Yes, just as I said: a constant offset between each of the proposed
epochs. But my point remains: from the user's point of view it doesn't
matter which epoch you choose to use behind the scenes, so you might as
well pick the one that's easiest on the software (time_t) and leave the
transformations to the libraries.

Chris

Brandon S. Allbery KF8NH

unread,
Feb 22, 2009, 1:37:54 AM2/22/09
to Daniel Ruoso, Brandon S. Allbery KF8NH, Dave Rolsky, perl6-l...@perl.org, perl...@perl.org


Strongly disagree: Perl6 is a high level language; it should not
force me to operate at a level where the OS's version of time is
visible, but should always present a higher level abstraction. I
should *never* have to work with a time_t unless there is some
particular reason I need it (e.g. some network protocol or binary file
format demands it), then there can be an FFI call from a library to
obtain it or generate a Perl6 time from it.

Quite frankly I won't miss time_t.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] all...@kf8nh.com
system administrator [openafs,heimdal,too many hats] all...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university KF8NH


PGP.sig

Brandon S. Allbery KF8NH

unread,
Feb 22, 2009, 1:39:42 AM2/22/09
to Chris Dolan, Brandon S. Allbery KF8NH, Mark J. Reed, Timothy S. Nelson, Larry Wall, perl...@perl.org, perl6-l...@perl.org
On 2009 Feb 20, at 14:36, Chris Dolan wrote:
>> UTC: TAI with an offset, as corrected for the actual revolution of
>> the
>> Earth: usually 60 seconds in a minute, but occasionally 59 or 61. 60
>> minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in
>> every day (86399, 86400, or 86401 seconds).
>>
> Yes, just as I said: a constant offset between each of the proposed

Read again; a leap second was added at the end of last year, that's
not exactly "constant".

PGP.sig

Chris Dolan

unread,
Feb 22, 2009, 12:42:51 PM2/22/09
to Brandon S.Allbery KF8NH, Mark J. Reed, Timothy S. Nelson, Larry Wall, perl...@perl.org, perl6-l...@perl.org
On Feb 22, 2009, at 12:39 AM, Brandon S. Allbery KF8NH wrote:

> On 2009 Feb 20, at 14:36, Chris Dolan wrote:
>>> UTC: TAI with an offset, as corrected for the actual revolution
>>> of the
>>> Earth: usually 60 seconds in a minute, but occasionally 59 or
>>> 61. 60
>>> minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in
>>> every day (86399, 86400, or 86401 seconds).
>>>
>> Yes, just as I said: a constant offset between each of the proposed
>
> Read again; a leap second was added at the end of last year, that's
> not exactly "constant".

You missed the trivial point I was trying to make: the number of
seconds between January 1, 1970 UTC (aka time_t epoch) and January 1,
2000 TAI *epochs* is a constant. I did not claim that the time
systems differed by a constant. An epoch is an instant in time from
which other times are measured, so you can measure UTC time flowing
from a TAI epoch and vice versa.

Astronomers do this all the time to avoid the complexity that the
Earth's rotation precesses, so the time to orbit the Sun once it not
exactly the same as a solar year. Astrometric coordinates are thus
claimed relative to an epoch, say B1950 or J2000, and can be easily
transformed between epochs.

Nevertheless, Larry has closed the issue declaring that Perl 6 will
use TAI, and I'm cool with that. With just 30-odd lossy exceptions
in the last 40 years, we can translate between TAI and time_t as
needed. When the OSes catch up and stop using time_t, it will be a
glorious day.

... unless we decide to use Stardates instead. Floating point time
would be cooler. :-)

Chris

Martin D Kealey

unread,
Feb 22, 2009, 6:35:24 PM2/22/09
to perl6-l...@perl.org
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 the thing
> is. Instant is incredibly ambiguous, and not a common term for such
> things.

I think people are starting to argue at cross purposes here.

An instant and a date-time are NOT the same thing.

Barring limitations imposed by the speed of light and aberrations caused by
relativity, and an instant occurs everyone at the same time.

A date-time, if it's really true to its name, represents some 40-ish
different instants, depending on which timezone it's interpreted in.


At some point you have to decide which fictions are useful vs where you
really need to hold out for reality.

* First fiction: the speed of light is infinite, so instants really are
universal. Unless you're writing GPS control software, you're probably OK
with this.

* Second fiction: the earth rotates at exactly 1/1440 rpm, so UT1=UT.
POSIX's "epoch seconds" pretty much enforce belief in this, so if you don't
want to believe it, you're going to have to build your own time libraries
from scratch.

* Third fiction: the day matches the rotation of the earth. In some places
the law requires you both to believe and disbelieve this simultaneously.
(For example, it may require that you're billed 10 minutes for a phone call
that started at 01:55 and finished at 03:05.)

* Fourth fiction: it's legally the same time everywhere on earth, especially
for registration of births, deaths and marriages. (For example, if I move
from my native New Zealand to, Hawaii, I will 23 hours older at my next
legal birthday than I would be if I remained in NZ. Probably I'd be a day
younger when I die too.)

* Fifth fiction: everyone speaks English.


It seems there is scope for multiple types, starting with Instants (which
must believe fiction 1 and may or may not believe fiction 2), DateTime
(which is agnostic about fiction 3), and "Localtime" and "Date" (which
believe fictions 3 and 4).

For each of these you have corresponding variants of Duration.

So my question is, which of these fictions should the core temporal type(s)
believe or disbelieve? Then we should name them appropriately.

-Martin

PS: IMHO core types should believe 1 & 2, and disbelieve 3 & 4, and avoid
doing anything that depends on believing 5.

Timothy S. Nelson

unread,
Feb 22, 2009, 11:01:15 PM2/22/09
to Martin D Kealey, Dave Rolsky, perl6-l...@perl.org
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 DateTime makes sense and is a clear description of what the thing
>>> is. Instant is incredibly ambiguous, and not a common term for such things.
>>

>> Hmm. Ah, I can see why it's ambiguous. For those who missed it, think of
>> what "instant" means in the context of "Instant coffee". I think I still
>> slightly prefer "instant", but I don't mind much any more :).
>
> Ah, we want a noun that isn't readily confused as an adjective.
>
> Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap Tick ...

The originator of "Instant" rejected "Moment" on the basis that in
physics, it's used in a variety of ways such as "moment of inertia", etc. My
personal feeling is that Occasion has other connotations we don't want.

Anyway, $Larry has decreed that it be Instant, unless you've given him
an idea above. I like jiffy, myself, but Wikipedia says "In computing, a
jiffy is the duration of one tick of the system timer interrupt". If we take
that as gospel, we probably want to avoid it. I'd also avoid calling
something "Snap" unless it breaks :). Tick has similar problems to Jiffy. I
don't know anything about Junctures, except that the potential for confusion
with the Perl6 feature "Junction" is huge.

IOW, none of them are perfect :).

Ruud H.G. van Tol

unread,
Feb 23, 2009, 8:34:26 AM2/23/09
to perl6-l...@perl.org
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

Timothy S. Nelson

unread,
Feb 23, 2009, 4:37:30 PM2/23/09
to Ruud H.G. van Tol, perl6-l...@perl.org

Hmm. Temporal::OnceUponATime :).

Mark A Biggar

unread,
Feb 23, 2009, 4:56:33 PM2/23/09
to Timothy S. Nelson, perl6-l...@perl.org, TSa
Instant
Moment
Point
PointInTime
Timestamp
Event
Jiffy
Time

Mark Biggar%0D%0Amark%40biggar.org%0D%0Amark.a.biggar%40comcast.net%0D%0Ambiggar%40paypal.com


Larry Wall

unread,
Feb 24, 2009, 12:16:59 AM2/24/09
to perl...@perl.org, p6l Language
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 could be used to specify how close values need to
> come in order to be considered equal.
>
> So instead of:
> if abs($x-$y)<$epsilon { ... }
>
> you could say:
> if $x==$y :within($epsilon) { ... }
>
> which makes your tests for equality look like tests for equality.
>
> I'd even suggest that the :within be mandatory, to guarantee that the
> coder is aware that "$x==$y" is probably not DWIM. Of course, there
> should also be an easy way to set epsilon across a scope, like:
>
> use Num :precision(0); # force exact matches in this block

Or just:

if $x ~~ $y ą $epsilon {...}

where infix:<ą> turns the single value into a range for the smartmatch.

Larry

Chris Dolan

unread,
Feb 24, 2009, 12:54:44 AM2/24/09
to Larry Wall, perl...@perl.org, p6l Language
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" maps more naturally to "any($y-$epsilon, $y+$epsilon)" than
to a range.

Chris

Darren Duncan

unread,
Feb 24, 2009, 2:07:49 AM2/24/09
to perl6-l...@perl.org
Larry Wall wrote:
> On Fri, Feb 20, 2009 at 03:31:03PM -0300, Daniel Ruoso wrote:
> : Em Sex, 2009-02-20 às 10:17 -0800, Larry Wall escreveu:
> : > By the by, I'm also inclined to agree with those who prefer "Instant"
> : > to "DateTime" on aesthetic grounds.

Yay, I consider that a blessing.

Also yay on your war-pathing against integer fraction of seconds units, another
blessing.

> : I should note that I'm insisting on DateTime just as the reference p5
> : module in CPAN, I don't oppose it being called Instant in Perl 6.
>
> And I should clarify that by Instant I was referring to a particular
> data type, not the module that defines it.

And I was meaning the same.

> I suppose Temporal is as good a module name as any, though Temporal::Instant
> does seem a bit redundant...
>
> On the other hand, Instant::Duration is just wrong.

Well, yes. Instant means a point in time and Duration means an amount of time.

I think Instant and Duration should be the type/role names and Temporal should
be the name of the module declaring them.

Perhaps we could
> just go with Instant and Duration as top-level roles since they're
> rather fundamental to lots of computing.

Do you mean "top level" as in not existing under some declaring module, or as in
being imported into the main name-space by default?

As builtins they would
> presumably come with appropriate operators predefined. And as roles
> they could be tweaked by a derived class to mean something slightly
> different, if the need arises.

Sounds good to me.

One remaining issue though (perhaps already resolved in an email I didn't read
yet) is whether these default builtins would be defined in terms of seconds
since an epoch or in terms of a calendar with YMDHIS (the seconds being a
non-integer) etc. I'm inclined to prefer the latter since that is more
future-proofed (a specified date+time that is in the future won't change on you
between storage and retrieval with persistent memory).

-- Darren Duncan

Larry Wall

unread,
Feb 24, 2009, 11:59:31 AM2/24/09
to perl...@perl.org, p6l Language
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"
> maps more naturally to "any($y-$epsilon, $y+$epsilon)" than to a range.

I'm using ą more in the engineering sense than the mathematical sense.
Maybe there's some way to finesse it to mean both, though I suspect
any such scheme would make it difficult to catch brainos. If there's
a subtle distinction between

if $x ~~ $y ą $epsilon {...}

and

if $x == $y ą $epsilon {...}

then it will be sure to trip people up.

It would be possible to make it a method:

if $x ~~ $y.within($epsilon)

but that does late binding, too late to give info to the optimizer.
The adverbial solution might or might not have the same problem.
In any case, adverbs on operators tend to be a design smell.

So it might be better as a (very tight?) operator, regardless of
the spelling:

$x ~~ $y within $epsilon

For what it's worth, ą does happen to be in Latin-1, and therefore
officially fair game for Standard Perl. By the way, the mathematical
definition can be derived from the engineering definition with

if $x == ($x ą $epsilon).minmax.any

The problem with defining it the other direction is that junctions
tend to lose ordering information of their eigenstates, and we can't
just flip mins and maxes when we feel like it, or degenerate null
ranges get broken.

Larry

Jon Lang

unread,
Feb 24, 2009, 3:31:13 PM2/24/09
to perl...@perl.org, p6l Language
Larry Wall wrote:
> So it might be better as a (very tight?) operator, regardless of
> the spelling:
>
>    $x ~~ $y within $epsilon

I like this: it's readable and intuitive. As well, it leaves ±
available for use in its mathematical sense.

> For what it's worth, ± does happen to be in Latin-1, and therefore


> officially fair game for Standard Perl.  By the way, the mathematical
> definition can be derived from the engineering definition with
>

>    if $x == ($x ± $epsilon).minmax.any


>
> The problem with defining it the other direction is that junctions
> tend to lose ordering information of their eigenstates, and we can't
> just flip mins and maxes when we feel like it, or degenerate null
> ranges get broken.

OTOH, there aren't going to be very many cases where you're going to
want to derive either from the other. You're more likely to derive
both from the same base stock:

$y ± 5 # same as ($y - 5) | ($y + 5)
$y within 5 # same as ($y - 5) .. ($y + 5)

--
Jonathan "Dataweaver" Lang

Daniel Ruoso

unread,
Feb 24, 2009, 3:59:25 PM2/24/09
to Larry Wall, perl...@perl.org, p6l Language
Em Ter, 2009-02-24 às 08:59 -0800, Larry Wall escreveu:
> I'm using ± more in the engineering sense than the mathematical
> sense.

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...

daniel

Geoffrey Broadwell

unread,
Feb 24, 2009, 4:31:16 PM2/24/09
to Jon Lang, perl...@perl.org, p6l Language
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


Jon Lang

unread,
Feb 24, 2009, 4:39:39 PM2/24/09
to TSa (Thomas Sandlaß), p6l Language
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 $x == $y. What
> is the benefit?

Larry's suggestion wasn't about ~~ vs. ==; it was about "within" as an
infix operator vs. "within" as a method or an adverb.

--
Jonathan "Dataweaver" Lang

Jon Lang

unread,
Feb 24, 2009, 4:34:13 PM2/24/09
to Daniel Ruoso, Larry Wall, perl...@perl.org, p6l Language
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 ~~ [..] $x ±
$epsilon {...}", since matching a value to a range that's centered on
that value is tautological.)

Junctions should not return individual values in list context, since
it's possible for one or more of said values to _be_ lists. That
said, I believe that it _is_ possible to ask a Junction to return a
set of its various values (note: set; not list). Still, we're already
at a point where:

if $y ~~ $x within $epsilon {...}

uses the same number of characters and is more legible. _And_ doesn't
have any further complications to resolve.

--
Jonathan "Dataweaver" Lang

Daniel Ruoso

unread,
Feb 24, 2009, 4:39:46 PM2/24/09
to Jon Lang, Larry Wall, perl...@perl.org, p6l Language
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

Doug McNutt

unread,
Feb 24, 2009, 7:18:24 PM2/24/09
to perl6-l...@perl.org
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 the fractional error is usually the one that's important.
Finances might be different but floating dollars have their own set
of problems relating to representation of decimal fractions.
--

--> A fair tax is one that you pay but I don't <--

Jon Lang

unread,
Feb 24, 2009, 7:54:35 PM2/24/09
to Doug McNutt, perl6-l...@perl.org
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 processing of data the
> fractional error is usually the one that's important. Finances might be
> different  but floating dollars have their own set of problems relating to
> representation of decimal fractions.

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 0.05 * $x

?

Something along the lines of:

1. infix:<within> sets Whatever to its lhs while evaluating its rhs
2. postfix:<%> returns the requested percentage of Whatever; if
Whatever is undefined, return the requested percentage of 1.

--
Jonathan "Dataweaver" Lang

Larry Wall

unread,
Feb 24, 2009, 9:30:50 PM2/24/09
to perl...@perl.org, perl6-l...@perl.org
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 0.05 * $x
:
: ?
:
: Something along the lines of:
:
: 1. infix:<within> sets Whatever to its lhs while evaluating its rhs
: 2. postfix:<%> returns the requested percentage of Whatever; if
: Whatever is undefined, return the requested percentage of 1.

The semantic magic is trivial; what we'd say is that if C<within> has
a 1-ary closure for its right argument, it calls that with its left
argument to calculate the epsilon. The syntactic magic is another
matter. We could easily define postfix:<%> that just translates 5% to
{ 0.05 * $_ }, but we'd have to weigh that against the infix use of %.
So basically it could be done, but we'd have to require whitespace
on the infix:<%> form.

Interestingly, though, assuming we have multies for Code:($) as well
as as Whatever, things like $x * 5% would also work automatically.
Which we'll probably have anyway, if we want things like

grep (* % 3) == 1, @list

to work. It basically looks like Whatever is mutating into a
mechanism for currying 1-ary functions, though of course it won't
work if you try to curry infix:<..> with it, or any other operator
that treats Whatever idiosyncratically. You'd basically have to
know which operators Do What You Mean, which could be construed as an
arbitrary list. Makes me wonder if this is one of those "new mistakes"
we're trying to make with Perl 6. :)

But my gut-level feel is that, although this is a feature that
you can easily shoot your foot off with, the actual code comes
out quite readable. And I think people can pretty easily learn
the default transformation of (* op 42) to { $_ op 42 }. On the other
hand, * is so hardwired in to our consciences as wildcarding and
quantifying that constructs like "abc" xx * also look natural.

So I'm gambling that this is a new mistake we want to make. The
alternative would be to create a different way of writing simple
closures, but we already have that in { $_ op 42 } if you want it.

I do very much like the fact that, unlike in Haskell, you curry
with an explicit placeholder, not by leaving things out. (Of course,
this is a requirement in Perl anyway because its parser depends
heavily on term/infix alternation.)

Larry

Brandon S. Allbery KF8NH

unread,
Feb 24, 2009, 11:15:07 PM2/24/09
to Ruud H.G. van Tol, Brandon S. Allbery KF8NH, perl6-l...@perl.org

"Then"?

PGP.sig

TSa

unread,
Feb 25, 2009, 1:33:15 PM2/25/09
to perl6-l...@perl.org
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 errors in floating point
algorithms is ubiquitous and thus the creation of relative
ranges deserves a dedicated operator. So I wanted to make the
heretic proposal to use % for that. That is

$x % $y;

to actually mean

$x * (1 - $y/100) ..^ $x * (1 + $y/100);

I think that this reads good for numeric matches:

if $x ~~ $y % 5 { say "within five percent" }

even though postfix % and infix ± read even better:

if $x ~~ $y ± 5% { say "within five percent" }

and so I'm proposing to add these and 'within' as ASCII fallback
for ±.

The intended semantics could be achieved with postfix % returning
a Ratio type for which infix ± has an overloaded version that
creates a relative range as given above. Other operators that
don't have overloads for Ratio use it as a Num. This is much
easier than the closure generation with subsequent currying as
proposed by Larry elsewhere in this thread. This nicely allows

$x += 5%;

to mean

$x += $x * 0.05;

But defining the corresponding overloads of infix + is tricky
for infix:<+>:(Ratio,Num) because it could mean to increase the
Ratio and return a Ratio or ignore the Ratio type and return a
plain Num. I think the latter is saner.

BTW, in numerics one usually needs small values so we could have
a .ppm postfix operator that also returns a Ratio, albeit one
that is smaller by a factor of 10000. Alternatively a triple
application of % gives the same ratio. And of course we should
have ‰ (promille) and ‱ (permyriad) as well. And when we are at
it .ppb and .ppt are common as well. At least Wikipedia has them.
There one also finds that ratios are expressed with the SI prefixes
like nano without a unit or U for uno. But I guess at the latest
this all belongs into a Ratio (standard?) module.

Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan

Mark J. Reed

unread,
Feb 25, 2009, 1:58:49 PM2/25/09
to TSa, perl6-l...@perl.org
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 ?

Jon Lang

unread,
Feb 25, 2009, 5:34:50 PM2/25/09
to Mark J. Reed, TSa, perl6-l...@perl.org
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 answer "5% of what?" then default to "5% of
1.0", or 0.05. +, -, and ± would need to be set up to provide the
necessary answer for "of what?" by means of setting Whatever; and by
basing it on Whatever, you have other options, such as:

@a[50%] # accesses the middle item in the list, since Whatever is
set to the length of the list.

--

Concerning "-> $val, $err { [..^] $val - $err, $val + $err }" vs "->
$val, $err { any $val - $err, $val + $err }": I'm not sold on the
notion that Huffman coding might imply that ± should go with the
former. Perhaps an argument can be made for it; but I suspect that
the relative commonness of the two uses is extremely similar (which,
per Huffman coding, would imply that their names should have similar
lengths). Whichever one we go with, we have a conundrum: if we use ±
as the name of the latter, the conundrum is that the only other
intuitive name for the former that has thus far been proposed (i.e.,
"within") is too long; if we use ± as the name for the former, the
conundrum is that no other intuitive name has been proposed for the
latter.

So: what we need are proposals for short, understandable names for
each operator. Suggestions?

--
Jonathan "Dataweaver" Lang

Doug McNutt

unread,
Feb 25, 2009, 7:36:51 PM2/25/09
to perl6-l...@perl.org
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
thought might be given to operating on the mantissa part of the IEEE
float. For normalized floats it's possible to get nearly equal tests
by simply truncating the mantissa at some number of bits and
comparing the floats as longs for equality. I suspect most technical
users would have no problem in specifying a number of significant
bits. They certainly can do it with decimal digits. Rounding from 52
to, say, 16 bits ought to be easy in binary.

But then with everyone using processors with floating point hardware
the efficiency might not be important.

--
--> Marriage and kilo are troubled words. Turmoil results when
centuries-old usage is altered in specialized jargon <--.

Larry Wall

unread,
Feb 25, 2009, 9:46:16 PM2/25/09
to perl...@perl.org, perl6-l...@perl.org
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 ą, it ought to work with + and -. Rule of thumb: if

: there's no easy way to answer "5% of what?" then default to "5% of
: 1.0", or 0.05. +, -, and ą would need to be set up to provide the

: necessary answer for "of what?" by means of setting Whatever; and by
: basing it on Whatever, you have other options, such as:
:
: @a[50%] # accesses the middle item in the list, since Whatever is
: set to the length of the list.

Coolness.

: Concerning "-> $val, $err { [..^] $val - $err, $val + $err }" vs "->


: $val, $err { any $val - $err, $val + $err }": I'm not sold on the

: notion that Huffman coding might imply that ą should go with the


: former. Perhaps an argument can be made for it; but I suspect that
: the relative commonness of the two uses is extremely similar (which,
: per Huffman coding, would imply that their names should have similar

: lengths). Whichever one we go with, we have a conundrum: if we use ą
: as the name of the latter, the conundrum is that the only other


: intuitive name for the former that has thus far been proposed (i.e.,

: "within") is too long; if we use ą as the name for the former, the


: conundrum is that no other intuitive name has been proposed for the
: latter.
:
: So: what we need are proposals for short, understandable names for
: each operator. Suggestions?

I'm not sure we should give up on unification so soon. Hmm.

Here's another approach. Suppose we define

$a ą $b

to mean something

$a ..^ $b :interval

and :interval causes the Range object to return $a and $b in list
context. Then, since any() supplies list context, we could write

if $x == any($a ą $b) {...}

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);
}

Of course, that would potentially introduce a failure mode where
people say == when they mean ~~, or vice versa. Maybe that wouldn't
be a big problem in practice.

Larry

TSa

unread,
Feb 26, 2009, 10:59:16 AM2/26/09
to perl6-l...@perl.org, perl...@perl.org
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 expect. I think for consistency with lists and
arrays a range should numify to the length of the list it
represents. That is, we have 'a'..'z' == 26 and 4..6 == 3.

Thinking of string ranges, how would infix ± treat these?
'm' ± 3 === 'j'..'p' seems reasonable albeit not overly
useful. The overload infix:<±>:(Str,Ratio) will hardly work.

BTW, here is a correct implementation of relative error
range creation:

multi infix:<±> (Num $x, Ratio $r --> Range of Num)
{
if $x == 0
{
# range instead of plain 0 to comply with sig
return 0..0;
}
elsif $x < 0
{
return $x * (1 + $r) ..^ $x * (1 - $r);
}
else
{
return $x * (1 - $r) ..^ $x * (1 + $r);
}
}

The interesting thing is that 0 comes out as a special number
that is exact as far as relative error goes. Note that it can't
be subsumed by the other cases because that would produce 0..^0
which fails for 0 ~~ 0..^0 since that means 0 <= 0 < 0 which
is false.

Daniel Ruoso

unread,
Feb 26, 2009, 11:11:09 AM2/26/09
to TSa, perl6-l...@perl.org
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

unread,
Feb 26, 2009, 11:01:16 AM2/26/09
to perl6-l...@perl.org
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: Whatever $i). So *-1 just casts
the -1. Postfix % would do the same for Ratio. Then one can overload
postcircumfix<[ ]>:(Array @self: Ratio $r) and multiply $r with the
size of the array to calculate the index. BTW, this indexing reminds
me of the way how textures are indexd in OpenGL. With that in mind
the index ratio could also interpolate between entries of a texture
array.


> Concerning "-> $val, $err { [..^] $val - $err, $val + $err }" vs "->
> $val, $err { any $val - $err, $val + $err }": I'm not sold on the
> notion that Huffman coding might imply that ± should go with the
> former. Perhaps an argument can be made for it; but I suspect that
> the relative commonness of the two uses is extremely similar (which,
> per Huffman coding, would imply that their names should have similar
> lengths). Whichever one we go with, we have a conundrum: if we use ±
> as the name of the latter, the conundrum is that the only other
> intuitive name for the former that has thus far been proposed (i.e.,
> "within") is too long; if we use ± as the name for the former, the
> conundrum is that no other intuitive name has been proposed for the
> latter.
>
> So: what we need are proposals for short, understandable names for
> each operator. Suggestions?

I think the junctive alternative is of little use. A numeric Range has
its primary purpose as the rhs of a smartmatch that checks numbers. We
have no proper range arithmetic that renders the semantics of
approximated exact numbers.


So here comes some rant about Num as the type that in contrast to Rat
carries an approximation error and an approximation closure that can be
called to decrease the error. That is e.g. sqrt(2) returns such a thing
that can be called again to continue the iteration. Numeric equality
checks would then not only compare the approximate values but also the
identity of the iteration closure. Whereas ~~ would check if the lhs
number's interval falls into the range of the rhs which is build from
the current approximation and the error. The approximation closure is
never invoked by ~~. Infix ± would then not create a range but a Num
with explicit error. That is, it is syntactic sugar for

$y.error = 0.001;
$x ~~ $y;

where I think the error should always be the relative error. Hmm, or the
relative error is indicated by the Ratio type. This gives the following
ways to write literal Nums:

my $x = 10 ± 0.01; # absolute error, no approximation closure
my $y = 10 ± 0.1%; # same with relative error

10.001 == $x; # false because undecidable
10.001 ~~ $x; # true

The falsity of == is due to the fact that 10.001 is exact and therefore
the errors aren't the same. That is 10 ± 0.1 == 10 ± 0.01 is false
because their is no approximation closure to decrease the error on the
lhs. Num equality is a rare event! 9 ± 0.1 < 10 ± 0.1 is easily true
because 9.1 < 9.9. Even 10 ± 0.1 == 10 ± 0.1 could be false, so that
only exact values and values with the identical approximation closure
can be equal. Assuming that the basic arithmetic operations are exact
because they use the Rat type the approximation system should manage to
have sqrt(2) / 2 == 1 / sqrt(2). I think that succeeds because the Rat
returned by sqrt(2) is the same, division preserves the relative error
and the approximation closure is the same.

The problem with the approximation closure is that it becomes more and
more complex during calculations. So we need to cut it off e.g. so that
it is at most one level deep. Also the error is than fixed at the level
of the input.

Another question is if we define some arithmetic on these closures
so that asin(sin(2)) == 2 exactly. I think this is doable by e.g. an
'is inverse' trait on code objects. This would allow asin to extract
the integer 2 from the sin approximation closure and return it. Pi
would be the identity of an approximation closure and it is not required
from an implementation to render sin($x) == sin($x + 2*pi) even though
it is imaginable if $x contains a Num that has pi as approximation
closure so that an exact modulo can be put into the approximation
closure of sin's return value.

Jon Lang

unread,
Feb 26, 2009, 1:00:48 PM2/26/09
to TSa, perl6-l...@perl.org
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:<[ ]>:(Array @self: Whatever $i). So *-1 just casts
> the -1. Postfix % would do the same for Ratio. Then one can overload
> postcircumfix<[ ]>:(Array @self: Ratio $r) and multiply $r with the
> size of the array to calculate the index. BTW, this indexing reminds
> me of the way how textures are indexd in OpenGL. With that in mind
> the index ratio could also interpolate between entries of a texture
> array.

I'm not certain about the exact mechanism to use; all I know for
certain is that I want a kind of dwimmery with postfix:<%> that
returns a percentage of some other value when it's reasonably easy to
decide what that other value should be, and a percentage of the number
one otherwise. Perhaps that _is_ best handled by means of a "Ratio"
type (or whatever), perhaps not. If so, I think that Rat (as in "a
Rational Number") should be kept distinct from "Ratio" (as in "a
portion of something else"). Perhaps the latter should be called a
"Portion" rather than a "Ratio".

> So here comes some rant about Num as the type that in contrast to Rat
> carries an approximation error and an approximation closure that can be
> called to decrease the error. That is e.g. sqrt(2) returns such a thing
> that can be called again to continue the iteration. Numeric equality
> checks would then not only compare the approximate values but also the
> identity of the iteration closure. Whereas ~~ would check if the lhs
> number's interval falls into the range of the rhs which is build from
> the current approximation and the error. The approximation closure is
> never invoked by ~~. Infix ± would then not create a range but a Num
> with explicit error.

I'm not sold on the notion that Num should represent a range of values
(and I use "range" here in its mathematical sense of "any number
that's between the given lower and upper bounds", as opposed to its
Perlish sense of "a discrete list of numbers"). However, I _do_ like
the idea of distinguishing between "is exactly equal to" and "is
approximately equal to"; and tracking the margin of error would be
essential to getting the latter option to work.

> Another question is if we define some arithmetic on these closures
> so that asin(sin(2)) == 2 exactly.

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 - but only because both sin and asin are pure
functions (i.e., they don't produce any side effects).

As well, I have a certain fondness for the idea of lazy evaluation of
mathematical functions (and pure functions in general), on the premise
that whenever you actually carry out an operation such as sqrt or sin,
you potentially introduce some error into the value with which you're
working; and if you postpone the calculation long enough, you may find
that you don't need to perform it at all (such as in the
aforementioned "asin(sin(2))" example).

--
Jonathan "Dataweaver" Lang

Doug McNutt

unread,
Feb 26, 2009, 1:10:02 PM2/26/09
to perl6-l...@perl.org
>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 - but only because both sin and asin are pure
>functions (i.e., they don't produce any side effects).

Don't get too hung up on that example.

If $x is 2*pi, asin(sin($x)) would return 0.0 and not 2*pi.
--

--> From the U S of A, the only socialist country that refuses to admit it. <--

Jon Lang

unread,
Feb 26, 2009, 1:06:14 PM2/26/09
to Daniel Ruoso, TSa, perl6-l...@perl.org

That's not bad; I like it.

--
Jonathan "Dataweaver" Lang

Brandon S. Allbery KF8NH

unread,
Feb 26, 2009, 1:06:56 PM2/26/09
to Jon Lang, Brandon S. Allbery KF8NH, TSa, perl6-l...@perl.org
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.

PGP.sig

Jon Lang

unread,
Feb 26, 2009, 2:27:47 PM2/26/09
to TSa, perl6-l...@perl.org
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
>> postcircumfix:<[ ]>:(Array @self: Whatever $i). So *-1 just casts
>> the -1. Postfix % would do the same for Ratio. Then one can overload
>> postcircumfix<[ ]>:(Array @self: Ratio $r) and multiply $r with the
>> size of the array to calculate the index. BTW, this indexing reminds
>> me of the way how textures are indexd in OpenGL. With that in mind
>> the index ratio could also interpolate between entries of a texture
>> array.
>
> I'm not certain about the exact mechanism to use; all I know for
> certain is that I want a kind of dwimmery with postfix:<%> that
> returns a percentage of some other value when it's reasonably easy to
> decide what that other value should be, and a percentage of the number
> one otherwise.  Perhaps that _is_ best handled by means of a "Ratio"
> type (or whatever), perhaps not.  If so, I think that Rat (as in "a
> Rational Number") should be kept distinct from "Ratio" (as in "a
> portion of something else").  Perhaps the latter should be called a
> "Portion" rather than a "Ratio".

Another possible approach would be to define postfix:<%> as returning
a code block:

sub postfix:<%>(Num $x) generates { $x / 100 * ($_ \\ 1.0) }

This would allow it to partake of nearly all of the same dwimmery of
which Whatever can partake, save for the purely Whatever stuff.

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 floating point number - at
least, it shouldn't always be.

Doug McNutt wrote:


> Jon Lang wrote:
>> 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 - but only because both sin and asin are pure
>> functions (i.e., they don't produce any side effects).
>

> Don't get too hung up on that example.
>
> If $x is 2*pi, asin(sin($x)) would return 0.0 and not 2*pi.

True enough: 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 potential to
intensify error) with a normalization of the value into the -pi ..^ pi
range (which might also introduce error).

--
Jonathan "Dataweaver" Lang

Brandon S. Allbery KF8NH

unread,
Feb 26, 2009, 3:17:29 PM2/26/09
to Jon Lang, Brandon S. Allbery KF8NH, TSa, perl6-l...@perl.org
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 floating point number - at
> least, it shouldn't always be.

But that's not the point; it's "can be" that matters, not "must be".

Martin D Kealey

unread,
Feb 26, 2009, 8:02:02 PM2/26/09
to Jon Lang, TSa, perl6-l...@perl.org
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 potential to intensify error) with a normalization of the
> value into the -pi ..^ pi range (which might also introduce error).

Hmmm ... the normal mathematical range of arc-sine is (-π,+π], rather than
[-π,+π), especially where complex numbers are concerned: arg(-1) == +π.
(Well, so much for consistently using lower half-open ranges.)

-Martin

Jon Lang

unread,
Feb 26, 2009, 8:27:57 PM2/26/09
to Martin D Kealey, TSa, perl6-l...@perl.org

...you're right. Sorry; my error.

--
Jonathan "Dataweaver" Lang

0 new messages