Re: series operator issues
Hi, Am 22.07.2010 17:18, schrieb Jon Lang: When I last reviewed the writeup for the series operators, I noticed two issues: First, why is the RHS argument a list? You only ever use the first element of it; so why don't you just reference a single value? The idea is that you can continue series: 1, 2, 3 ... 10, 20, 30, ... 100, etc. Second, I'm trying to think of a simple and intuitive way to write up a series expression for: triangle numbers: 0, 1, 3, 6, 10, 15, 21, etc. Use the right tool for the right job: 17:32 @moritz_ rakudo: say ~[\+] 0..6 17:32 +p6eval rakudo 925a9b: OUTPUT«0 1 3 6 10 15 21» square numbers: 0, 1, 4, 9, 16, 25, 36, etc. 17:34 @moritz_ rakudo: say ~(1..10).map(* ** 2) 17:35 +p6eval rakudo 925a9b: OUTPUT«1 4 9 16 25 36 49 64 81 100» Or with a bit of a math trick: 17:36 @moritz_ rakudo: say ~(1, { $_ + 2 * .sqrt + 1} ... 100) 17:36 +p6eval rakudo 925a9b: OUTPUT«1 4 9 16 25 36 49 64 81 100» factorials: 1, 1, 2, 6, 24, 120, 720, 5040, etc. 17:33 @pmichaud rakudo: say ~[\*] 1..6 17:33 +p6eval rakudo 925a9b: OUTPUT«1 2 6 24 120 720» The difficulty that I'm running into is that there's no reasonably straightforward way of computing a given term solely from the previous one or two items in the list. The difficulty you're running into is that you're trying to use the wrong tool for the job. Just don't use the series operator when it's not easy to use. Perl 6 has other mechanism too, which are better suited for these particular problems. The series operator is intented to be a relatively powerful (and yet simple to use) tool to generate some common series. For other cases, the full power of Turing-complete Perl 6 stands at your disposal (to which you probably need to revert when you want both index *and* previously computed values, *and* can't rely on other operator magic). Cheers, Moritz
Re: series operator issues
On Thu, Jul 22, 2010 at 11:41 AM, Moritz Lenz mor...@faui2k3.org wrote: The difficulty you're running into is that you're trying to use the wrong tool for the job. Just don't use the series operator when it's not easy to use. Perl 6 has other mechanism too, which are better suited for these particular problems. In general, I'd agree. However, there is something to be said for the underlying question: is there a way to get at the iteration index from the lambda in a series? It seems like that's something that it's not unreasonable to want. I also think it's doable without a special tool: 0, { state $i = 1; $^a + $i++ } ... * That should work, no? Granted, state doesn't seem to work in Rakudo, unless I'm mis-understanding how to use it, but that's the idea. -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
Re: series operator issues
On Thu, Jul 22, 2010 at 9:25 AM, Aaron Sherman a...@ajs.com wrote: On Thu, Jul 22, 2010 at 11:41 AM, Moritz Lenz mor...@faui2k3.org wrote: The difficulty you're running into is that you're trying to use the wrong tool for the job. Just don't use the series operator when it's not easy to use. Perl 6 has other mechanism too, which are better suited for these particular problems. In general, I'd agree. However, there is something to be said for the underlying question: is there a way to get at the iteration index from the lambda in a series? It seems like that's something that it's not unreasonable to want. I also think it's doable without a special tool: 0, { state $i = 1; $^a + $i++ } ... * That should work, no? Granted, state doesn't seem to work in Rakudo, unless I'm mis-understanding how to use it, but that's the idea. Kludgey; but possibly doable. Another possibility that might work would be to use the default list parameter to count the previous elements: +...@_. That would be notationally more compact, but would also potentially wreak havoc on the computational efficiency of the model; and while you could get the index number from it, it wouldn't always be quite as simple as counting its elements. But what I'd really like to see would be for the index to be passed into the step function via a named parameter. Yes, it would be a special tool; but it would be much more in keeping with the keep simple things easy philosophy that Perl 6 tends to promote: 0, { $^a + $:i } ... * # series of triangle numbers 0, { $^a + (2 * $:i - 1) } ... * # series of square numbers { $:i ** 2 } ... * # series of square numbers 1, { $^a * $:i } ... * # series of factorials -- Jonathan Dataweaver Lang
Re: series operator issues
On Thu, Jul 22, 2010 at 1:13 PM, Jon Lang datawea...@gmail.com wrote: I also think it's doable without a special tool: 0, { state $i = 1; $^a + $i++ } ... * Kludgey; but possibly doable. Well, it's kind of what state is there for. But what I'd really like to see would be for the index to be passed into the step function via a named parameter. Of course, you say the index as if there is such a thing. In reality, there's no reason for the series operator to keep an index unless it's explicitly being indexed (e.g. by postcircumfix:[]) Yes, it would be a special tool; but it would be much more in keeping with the keep simple things easy philosophy that Perl 6 tends to promote: 0, { $^a + $:i } ... * # series of triangle numbers 0, { $^a + (2 * $:i - 1) } ... * # series of square numbers { $:i ** 2 } ... * # series of square numbers 1, { $^a * $:i } ... * # series of factorials I do have to admit that that's awfully clean-looking, but the implementation would force a closure in a series to behave differently from a closure anywhere else. Without changing closure definitions and without extending the syntax any, you could make the series operator do a little bit more introspection work and if a parameter is named index, track an index value and pass it by name, passing any remaining parameters positionally from the previous n values as normal. That makes your examples: 0, { $^a + $^index } ... * 0, { $^a + (2 * $^index - 1) } ... * { $^index ** 2 } ... * 1, { $^a * $^index } ... * Not changing the syntax of closures seems like a reasonable goal at this late stage. -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
Re: series operator issues
On Thu, Jul 22, 2010 at 11:35 AM, Aaron Sherman a...@ajs.com wrote: On Thu, Jul 22, 2010 at 1:13 PM, Jon Lang datawea...@gmail.com wrote: Yes, it would be a special tool; but it would be much more in keeping with the keep simple things easy philosophy that Perl 6 tends to promote: 0, { $^a + $:i } ... * # series of triangle numbers 0, { $^a + (2 * $:i - 1) } ... * # series of square numbers { $:i ** 2 } ... * # series of square numbers 1, { $^a * $:i } ... * # series of factorials I do have to admit that that's awfully clean-looking, but the implementation would force a closure in a series to behave differently from a closure anywhere else. How so? Without changing closure definitions and without extending the syntax any, you could make the series operator do a little bit more introspection work and if a parameter is named index, track an index value and pass it by name, passing any remaining parameters positionally from the previous n values as normal. ...which differs from my example in several ways, all of which are detrimental: it puts the index in among the positional parameters, meaning that odd things would have to happen if you ever decide to use, say, $^i and $^j as your prior items parameters; and it locks you into a specific name for the index instead of letting you choose one of your own liking. That makes your examples: 0, { $^a + $^index } ... * 0, { $^a + (2 * $^index - 1) } ... * { $^index ** 2 } ... * 1, { $^a * $^index } ... * Not changing the syntax of closures seems like a reasonable goal at this late stage. Who said anything about changing the syntax? $:i is perfectly valid syntax that is already spelled out in S06, under Placeholder Variables. Granted, it's rarely used; but it exists. And unless I'm missing something, this would be a perfectly valid use for it. Essentially, my suggestion is this: if the step function's signature (or implied signature, in the case of a function with placeholder variables) includes any named parameters, then the index is used as the argument corresponding to the first one. (the only catch would be if you decide to use the slurpy named placeholder, since the compiler can't be expected to know which keys are being used inside the block; in this case, it would be fair to assume that index is to be used, or maybe 0.) As such, the above examples could also be done as: 0, - $a, :$i { $a + $i } ... * # series of triangle numbers 0, sub ($_, :$x) { $_ + (2 * $x - 1) } ... * # series of square numbers { %_{0} ** 2 } ... * # series of square numbers 1, { @_[0] * %_0 } ... * # series of factorials My own preference would be to angle for the more compact form that I originally illustrated, unless and until its limitations force me to do otherwise. But then, TIMTOWTDI. -- Jonathan Dataweaver Lang
Re: series operator issues
On Thu, Jul 22, 2010 at 4:52 PM, Jon Lang datawea...@gmail.com wrote: I do have to admit that that's awfully clean-looking, but the implementation would force a closure in a series to behave differently from a closure anywhere else. How so? Unlike some of you, I haven't managed to memorize all of the synopses. For poor dolts like me who have only read some sections once, it would be nice if you could clarify the more obscure syntax ;-) Without changing closure definitions and without extending the syntax any, you could make the series operator do a little bit more introspection work and if a parameter is named index, track an index value and pass it by name, passing any remaining parameters positionally from the previous n values as normal. ...which differs from my example in several ways, all of which are detrimental: it puts the index in among the positional parameters, No, that's not true. Sure, if you used the syntax I used, then it's allowed to be passed either way, but since the series operator will always pass it by name, the only positionals are the remaining parameters (I did test this out before sending my mail, just to verify that $^x could be passed as :x... or as a positional). More importantly the syntax you used works just as well, and as far as ... is concerned, there's no substantial difference. So... what are you suggesting? That any named-only parameter is passed the index? Or that a named-only parameter called i is passed the index? If the latter, then you're suggesting the same thing as I am, but with a different name (I prefer the longer name, given the restrictions it places on the closure). If you're suggesting that this apply to any named-only parameter, I don't think that's a good idea. That's even MORE restrictive than what I suggested (remember, it's usually going to be a closure, defined right there, but even the Synopsis gives one example of using an existing subroutine). meaning that odd things would have to happen if you ever decide to use, say, $^i and $^j as your prior items parameters; Why? and it locks you into a specific name for the index instead of letting you choose one of your own liking. Well, true, but you have to have some convention, and a name is a common way to establish such conventions in a parameter-passing API... Essentially, my suggestion is this: if the step function's signature (or implied signature, in the case of a function with placeholder variables) includes any named parameters, You meant named only then the index is used as the argument corresponding to the first one. Named only... first... these terms are non-miscible, aren't they? I don't think named-only parameters have an ordering. -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
r31789 -[S32] DateTime immutable, leap seconds validation
Author: masak Date: 2010-07-22 23:54:10 +0200 (Thu, 22 Jul 2010) New Revision: 31789 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32] DateTime immutable, leap seconds validation The rest of this message is from Kodi++, who prepared the combined spec/Rakudo patch: There are two major changes here: DateTimes are now immutable and DateTime constructors now validate leap seconds. tai-utc should provide a hash, not a subroutine, but this doesn't work when Rakudo is compiled. It shouldn't be too hard to write a Perl 5 script, to be run as part of Rakudo's build process, that automatically updates the leap-second table in tai-utc.pm. I haven't run DateTime-strftime.t because ++supernovus is moving strftime out of Rakudo, and hence DateTime-strftime.t out of pugs. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-22 19:08:46 UTC (rev 31788) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-22 21:54:10 UTC (rev 31789) @@ -15,8 +15,8 @@ Created: 19 Mar 2009 -Last Modified: 20 Jul 2010 -Version: 16 +Last Modified: 21 Jul 2010 +Version: 17 The document is a draft. @@ -66,10 +66,10 @@ =head1 CDateTime -A CDateTime object describes the time as it would appear on someone's -calendar and someone's clock. You can create a CDateTime object from an -CInstant or from an CInt; in the latter case, the argument is -interpreted as POSIX time. +A CDateTime object, which is immutable, describes a moment in time as it +would appear on someone's calendar and someone's clock. You can create a +CDateTime object from an CInstant or from an CInt; in the latter +case, the argument is interpreted as POSIX time. my $now = DateTime.new(now); my $now = DateTime.new(time); @@ -94,7 +94,7 @@ Another multi exists with CDate :date instead of C:year, C:month and C:day (and the same defaults as listed above). -All four of the aforementioned forms of Cnew accept two additional named +All of the aforementioned forms of Cnew accept two additional named arguments. C:formatter is a callable object that takes a CDateTime and returns a string. The default formatter creates an ISO 8601 timestamp (see below). C:timezone is a callable object that takes a CDateTime to @@ -123,17 +123,45 @@ With all the above constructors, if you attempt to pass in values that are outside of the ranges specified in the list above, you'll get an -exception. An exception will also be thrown if the particular day -doesn't exist in that month (for example April 31st) or in that non-leap -year (for example February 29th 2006). By default, no such checking is -done against leap seconds. This class also explicitly does not check -against ambiguous or invalid local times caused by Daylight Saving Time. +exception. An exception will also be thrown if the given day (like 31 April +2000 or 29 February 2006) or second (like 23:59:60 on 1 January 2000) +doesn't exist. The same checks are run when you produce an object with +Cclone: +my $dt = DateTime.new(:year(1999), :month(1), :day(29)); +say $dt.clone(:year(2000), :month(2)); # 2000-02-29T00:00:00Z +say $dt.clone(:year(1999), :month(2)); # WRONG; 1999 was a common year + +However, this class explicitly does not check against ambiguous or invalid +local times caused by Daylight Saving Time. + +To convert an object from one time zone to another, use the Cin-timezone +method: + +my $dt = DateTime.new('2005-02-01T15:00:00+0900'); +say $dt.hour; # 15 +$dt = $dt.in-timezone(6 * 60 * 60); # 6 hours ahead of UTC +say $dt.hour; # 12 + +The Cutc method is shorthand for Cin-timezone(0). + +The Ctruncated-to method allows you to clear a number of time values +below a given resolution: + +my $dt = DateTime.new('2005-02-01T15:20:35Z'); +say $dt.truncated-to(:hour); # 2005-02-01T15:00:00Z + +An argument of C:week yields an object with the date of the last Monday +(or the same date, if it already is a Monday) and with hours, minutes, and +seconds all set to zero: + +say $dt.truncated-to(:week); # 2005-01-31T00:00:00Z + There's one additional constructor: Cnow. It works just like CDateTime.new(now) except that there is no positional parameter and the C:timezone argument defaults to the system's local time zone. -=head2 Get methods +=head2 Accessors There are methods Cyear, Cmonth, Cday, Chour, Cminute, Csecond, Ctimezone, and Cformatter, giving you the corresponding values of the @@ -178,52 +206,11 @@ C$dt.timezone($dt, True); otherwise, C$dt.offset returns C$dt.timezone as is. -=head2 Set methods - -To set the the day of a CDateTime object to something, just assign to -its public accessor: - -$dt.day = 15; - -The same methods exists for all the values you can set in the -constructor: Cyear, Cmonth, Cday,
Re: series operator issues
On 23 July 2010 01:41, Moritz Lenz mor...@faui2k3.org wrote: Use the right tool for the right job: square numbers: 0, 1, 4, 9, 16, 25, 36, etc. (1..10).map(* ** 2) Or even just: (1..10) »**» 2 Note that you can also get most of the effects you want by using @_ in the series' generator block. For example, here are all the square numbers: 0, { @_**2 } ... * and all the factorials: 1, { (@_+1) * @_[*-1] } ... * or all the factorials more prettily but less inefficiently: 1, { [*] 1...@_ } ... * However, those *are* clunky and nigh unreadable, so I certainly wouldn't object to having the index of the next generated element readily available as an explicit variable in a series' generator block. That would make all manner of evil both easier and cleaner. ;-) Damian
Announce: Rakudo Perl 6 compiler development release #31 (Atlanta)
On behalf of the Rakudo development team, I'm happy to announce the July 2010 development release of Rakudo Perl #31 Atlanta. Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine (see http://www.parrot.org). The tarball for the July 2010 release is available from http://github.com/rakudo/rakudo/downloads. Please note: This is not the Rakudo Star release, which is scheduled for July 29, 2010 [1]. The Star release will include the compiler, an installer, modules, a book (PDF), and more. The Rakudo Perl compiler follows a monthly release cycle, with each release named after a Perl Mongers group. The July 2010 release is code named Atlanta in recognition of Atlanta.pm and their Perl 5 Phalanx project [2], which they selected for its benefits to Perl 6. Some of the specific changes and improvements occurring with this release include: * Rakudo now properly constructs closures in most instances. * Undefined objects can now autovivify into arrays or hashes when subscripted with .[ ] or .{ } . * Arrays can now handle infinite ranges. * Generic, multi-level Whatever-currying now works, e.g. (1, 1, *+* ... *). * The REPL shell now remembers lexical declarations in susbsequent lines. * The open() subroutine now returns a Failure instead of throwing a fatal exception. * Rakudo now provides $*ARGFILES for reading from files specified on the command line. * Added $*PERL, moved %*VM to $*VM. * Simple binding operators := and ::= now work. * Simple feed operators == and == now work. For a more detailed list of changes see docs/ChangeLog. The development team thanks all of our contributors and sponsors for making Rakudo Perl possible, as well as those people who worked on parrot, the Perl 6 test suite and the specification. The following people contributed to this release: Patrick R. Michaud, Jonathan Worthington, Moritz Lenz, Solomon Foster, Carl Masak, Bruce Gray, Martin Berends, chromatic, Will Coke Coleda, Matthew (lue), Timothy Totten, maard, Kodi Arfer, TimToady, Stephen Weeks, Patrick Abi Salloum, snarkyboojum, Radu Stoica, Vyacheslav Matjukhin, Andrew Whitworth, cognominal, Tyler Curtis, Alex Kapranoff, Ingy döt Net, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯, mathw, lue, Вячеслав Матюхин If you would like to contribute, see http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org mailing list, or ask on IRC #perl6 on freenode. The next release of Rakudo (#32) is scheduled for August 19, 2010. A list of the other planned release dates and code names for 2010 is available in the docs/release_guide.pod file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. Have fun! [1] http://rakudo.org/node/73 [2] http://code.google.com/p/atlanta-pm-code/ -- Will Coke Coleda
Re: series operator issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/22/10 11:18 , Jon Lang wrote: Second, I'm trying to think of a simple and intuitive way to write up a series expression for: triangle numbers: 0, 1, 3, 6, 10, 15, 21, etc. square numbers: 0, 1, 4, 9, 16, 25, 36, etc. factorials: 1, 1, 2, 6, 24, 120, 720, 5040, etc. I don't think anyone seriously expects the series operator to be a dwimmy OEIS. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxJLGkACgkQIn7hlCsL25X2jACeIwN4EBe96dS4WEBm1Ik14dQW JNwAoJaASMvMGVickzIgdBDclNM2KhJq =9ej6 -END PGP SIGNATURE-