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
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 allb...@ece.cmu.edu 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 markjr...@gmail.com
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
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
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
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-
