## Simple Series

Today I created two new test files in t/spec/S03-operator. series-simple.t has some early tests for arity-1 series — that is to say, either series generated from the relationships between the first few elements, or series generated by an arity-1 closure. (The two forms are processed more or less identically — the first form generates an arity-1 closure internally.) The initial tests just compare the first five (or so) elements from an infinite list to what we think they should. After pondering a bit, I did come up with a simple arity-1 closure which is both deterministic and neither arithmetic nor geometric:

```> (1, { 1 / ((1 / \$_) + 1) } ... *).batch(10).perl.say
(1, 1/2, 1/3, 1/4, 1/5, 1/6, 1/7, 1/8, 1/9, 1/10)
```

series-arity0.t only has one series so far:

```    my @rolls = ({ (1..6).pick } ... *).batch(20);
is +@rolls, 20, 'Got the number of rolls we asked for';
is @rolls.grep(Int).elems, 20, 'all the rolls are Ints';
is @rolls.grep(1..6).elems, 20, 'all the rolls are in the Range 1..6';
```

Unfortunately, this case went to the old series operator code, which couldn’t handle it. For the moment, I have crafted a simple alternative which passes this test:

```our multi sub infix:<...>(Code \$lhs, Whatever) {
gather {
loop {
my \$i = \$lhs.();
my \$j = \$i;
take \$j;
}
}
}
```

So the next step would seem to be to add limiting here. The spec has some specific language on the subject, which I believe must be brand-new: “If any value in the series is eqv to the limit value, the series terminates, including that final limit value. For any value after the first lefthand value, if that value and the previous value fall on opposite sides of the limit, the series terminates without including either the limit value or the value that exceeded the limit.” That should be pretty easily to implement, I think.

One question that popped into my head while I was thinking about this. Is there anything in the current spec that says the values returned by the series must be of the same type? We’re already violating that with most geometric series (they start with an Int, and quickly move to Rats). It seems to me there might be interesting examples where each element might be of a different type. Imagine a arity-0 generator that randomly selects one of a handful of types to return a fresh instance of…

### 3 Responses to “Simple Series”

1. Larry Wall Says:

No, there are no type constraints, other than those imposed by the signature of the generator, which interestingly enough check the *previous* value or values, but not the next value (unless the function specifies a return type as well). It is certainly possible for a function to generate values that it cannot itself handle, and the behavior for that could be better specified.

• colomon Says:

Thanks for the clarification! (And oooooo, I sense a new test coming on.)

One more question: is the “on opposite sides” test for the limit intended to be tested with `cmp`?

2. Larry Wall Says:

Yes. Of course, cmp is currently defined only for two args of the same type.