Re: series operator issues
On 2010-07-23, at 4:25 am, Moritz Lenz wrote: > I'm still not convinced. [that there should be a special index variable] > Yes, it would be convient, but I've yet to see a non-contrived example where > it's actually necessary, and which can't be implemented trivially with other > Perl 6 tools. I see it like the situation with "self". Sure, it's not necessary, it's easy to specify it explicitly, and so on, but nevertheless it feels somehow too heavy not to deserve some sugar. My own first instinct was to use map or a loop to produce those a series of squares or factorials or whatever... on the other hand, the series operator does naturally come to mind when you're thinking about a series! > The series code is already rather complex (and thus slow), and having to add > introspection to find out whether the production code object accepts a named > parameter 'i' is not going to help in any way. I do agree that having a special named parameter isn't the way to do it, though. What if there were a special keyword instead? (Again, like the situation with 'self'.) If you used the word "index" (or "counter" or "n"?) in a loop or series or anywhere else suitable, it could be detected at compile-time. It shouldn't be any worse than making your own counter, and might even be better (since Perl needs its own counter for some loops, maybe it could make it available rather than having to define one of your own as well). -David
Re: series operator issues
Am 23.07.2010 00:29, schrieb Damian Conway: 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.>;-) I'm still not convinced. Yes, it would be convient, but I've yet to see a non-contrived example where it's actually necessary, and which can't be implemented trivially with other Perl 6 tools. The series code is already rather complex (and thus slow), and having to add introspection to find out whether the production code object accepts a named parameter 'i' is not going to help in any way. IMHO we are in the "what can we add?" phase, while we should be in the "what can we take away?" design phase. Cheers, Moritz
Re: series operator issues
If we expected Perl6 to be able to recognize these series and continue them based on nothing but the first few elements, that would be a dwimmy OEIS. (And an OEIS module that did that by consulting the real OEIS would be cool, outside of core.) But that's not what this is about. This is just wanting to be able to write the ones that have simple mathematical expressions (closed or not) using simple Perl 6 expressions with the series operator. On Friday, July 23, 2010, Brandon S Allbery KF8NH wrote: > -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- > -- Mark J. Reed
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-
Re: series operator issues
On 23 July 2010 01:41, Moritz Lenz 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
Re: series operator issues
On Thu, Jul 22, 2010 at 4:52 PM, Jon Lang 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
Re: series operator issues
On Thu, Jul 22, 2010 at 11:35 AM, Aaron Sherman wrote: > On Thu, Jul 22, 2010 at 1:13 PM, Jon Lang 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 1:13 PM, Jon Lang 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 9:25 AM, Aaron Sherman wrote: > On Thu, Jul 22, 2010 at 11:41 AM, Moritz Lenz 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 11:41 AM, Moritz Lenz 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
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
series operator issues
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? 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. 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. There _is_ a simple way to compute the next item from the previous item and the index number, or even strictly from the index number; but there is no way that I'm aware of to get the index number into the step function. -- Jonathan "Dataweaver" Lang