Repurpose .f.

[orlp]

I don't think there's a valid use of .f right now. If you need true division we already have c, and otherwise there is no point in making a number a float. If you for some reason really need a float it's often best to just add a .0 at some constant, or in the worst case +_.0, which is only one character longer than .f.

Instead I propose .f to be of arity two, with first argument a lambda of arity two (not sure about the best variable choices yet), and second argument a starting value (default 0) for the following:

def series_filter(a, b=0):
    last_b = b
    while True:
        while not a(b, last_b): b += 1
        print(b)
        last_b = b
        b += 1

This makes writing a program for infinite monotonic increasing sequences much shorter. For example for the primes (I used GH as a lambda variables, not sure if this is optimal):

.f!PPG2

Or the palindromic numbers:

.fq`G_`G

I like the idea behind this proposal, but I'm not entirely happy with it yet. Some points for suggestions/modifications to the proposal:

• I don't know what we should do when the second argument is a collection, maybe only generate as many terms as the length of the collection, and return the generated numbers, not print them?
• I'm not entirely happy with the second argument for the lambda, maybe we can pass in something more useful (I'm hesitant to pass in all the previously generated values, because of memory requirements).
• Maybe we can make this also work for string sequences somehow?
• Since this function takes over flow of control there is no real harm in having a high arity lambda - maybe we can pass in a lot of info about the current state in like 4 variables?

[isaacg1]

I'm fine with getting rid of the current .f. However, I would really like it if instead of just printing out these numbers, they could be post-processed somehow. Maybe make an infinite iterator?

[orlp]

@isaacg1 See the first bullet point of my proposal.

[jakobkogler]

I'm not really fond of this idea. Maybe returning the first b numbers, or only the bth number, that satisfies a(T)=True would be better. On May 12, 2015 7:57 PM, "Orson Peters" notifications@github.com wrote:

@isaacg1 https://github.com/isaacg1 See the first bullet point of my proposal.

— Reply to this email directly or view it on GitHub https://github.com/isaacg1/pyth/issues/99#issuecomment-101365858.

[isaacg1]

I think there's two good ideas here that should be separate. One is a better way to do infinite loops than #. One way to to this is as you mentioned.

The other thing that Pyth should have is something like "the first n numbers which satisfy", as jakob mentioned.

I'm in favor of making these two separate statements, something like .V, which would be an infinite for loop similar to V, and .f, which would be a first n filter.

[isaacg1]

I've implemented my ideas of .f and .V. You should tell me what you think of them, and whether they fufil your ideas.

[orlp]

@isaacg1 Order of parameters of .f should be swapped, the starting value should be the last value, and default to 1.

[orlp]

Also, I don't know how you're supposed to use .V to implement what I originally proposed.

[isaacg1]

Well, it works for the two examples you mentioned. I agree it doesn't cover the number, next number thing, but I don't see that being incredibly useful - you could just use h. For the simple cases, you just use I within .F. Switched order does sound good, though.

[orlp]

@isaacg1 I'm not seeing it - could you post a full example program using .V that prints all the primes?

[isaacg1]

.V2I!tPbb - 2 more characters than under your proposal, but it's a lot more versatile.

[orlp]

Ok, I understand now - I thought .V would be a function, returning an iterator, but's a block level thing.

[isaacg1]

Hm - that's an idea, we could do that too, maybe with .v. We'd have to add new methods to some of the functions for manipulating iterators, but it could be done.

[orlp]

I don't think it's a good idea, I was just explaining my confusion - iterators don't really fit in any portion of Pyth.

[isaacg1]

OK, I get it. Iterators could be done, but they're way off down the road, if it at all. They would only exist for manipulating infinite sequuences, of course.

[orlp]

I think generators is actually the proper word for them.

[isaacg1]

Right.