I think the output of this algorithm is the first sequence in the lexicographical order (counting -1 as earlier in the alphabet than 1) with all its partial sums non-negative. So there is a certain greedy flavour to it (in the sense that each time a new prime p comes along, it will set f(p)=-1 unless that is provably not a valid continuation of the sequence so far).

1) Set p = -1 unless this pushes the partial sum below zero;
2) Fill in composite numbers myopically (ie, no look-ahead) until either
2a) you reach a prime (go to step 1); or
2b) the series goes negative, in which case backtrack and change the sign of the last prime p which was set equal to -1 to a +1 (then go to the beginning of step 2 again).

On the down side, there’s no obvious limit to the amount of backtracking that may be required. On the up side, I didn’t get close to getting in trouble when I was generating the first few elements of the sequence.

I’m going to be busy for a while now, so probably won’t get the chance to do anything more systematic on this for a while – in particular I would have liked to check that the hand calculations below can be relied on…

I get the impression from Thomas’s plot that the genuinely greedy algorithm I then suggested gives, as expected, not a very good result. So perhaps it’s worth going back to the original idea, as Ian was doing above. Here is what I had envisaged. Instead of setting all as yet unspecified values to zero when evaluating future partial sums, one sets them to 1. The problem I have with this is that when I fix the value of , then I will definitely increase some of the later partial sums (because however I do it I’ll change some 1s to -1s and I won’t change any -1s to 1s) so I don’t have any reason to suppose I can keep them all positive. But perhaps some limited backtracking would be enough to deal with this problem when it arises, as Ian suggests. I’m interested to see that the sequence Ian has produced below is better than (as far as it goes).

{1, -1, 1, 1, -1, -1, 1, -1, 1, 1, -1, 1, 1, -1, -1, 1, -1, -1, 1,
-1, 1, 1, -1, -1, 1, -1, 1, 1, -1, 1, 1, -1, -1, 1, -1, 1, -1, -1, 1,
1, 1, -1, 1, -1, -1, 1, -1, 1, 1, -1, -1, 1, -1, -1, 1, -1, 1, 1, -1,
-1, 1, -1, 1, 1, -1, 1, 1, -1, -1, 1, -1, -1, 1, 1, 1, 1, -1, -1, -1,
-1, 1, -1, 1, 1, 1, -1, -1, 1, -1, 1, 1, -1, 1, 1, -1, -1, 1, -1, -1,
1, -1, 1, 1, -1, -1, 1, -1, 1, 1, -1, -1, 1, -1, -1, 1, -1, 1, 1, -1,
1, 1, -1, 1, 1, -1, -1, -1, -1, 1, 1, 1, -1, 1, -1, -1, 1, -1, 1, 1,
-1, -1, 1, -1, 1, 1, -1, 1, -1, 1, -1, 1, -1, -1, 1, -1, 1, 1, 1, -1,
-1, -1, -1, 1, 1}

Thomas, if you put this as input into your program does it go negative even if all subsequent primes are set to 1?

{1, -1, 1, 1, -1, -1, 1, -1, 1, 1, -1, 1, 1, -1, -1, 1, -1, -1, 1,
-1, 1, 1, -1, -1, 1, -1, 1, 1, -1, 1, 1, -1, -1, 1, -1, 1, -1, -1, 1,
1, 1, -1, 1, -1, -1, 1, -1, 1, 1, -1, -1, 1, -1, -1, 1, -1, 1, 1}

When you say that the rough idea you had doesn’t work, Tim, do you mean that you’ve convinced yourself that the backtracking is an issue, or just that you haven’t convinced yourself that it’s not?

The idea is that, as usual, you define on each prime in turn. Each time you do so, you work out all the consequences that follow just from multiplicity.

We can think of the process as follows. We start with the sequence 1 0 0 0 … At the next stage, we set f(2)=-1 and work out the consequences of that, which gives us the sequence 1 -1 0 1 0 0 0 -1 0 0 … . Note that the partial sums of this sequence are all positive. At the next stage we are obviously forced to choose , which gives us a sequence that starts 1 -1 1 1 0 -1 0 -1 1 0 0 1 0 … . At the stage after that, we have to choose f(5)=1, because otherwise the partial sum up to 8 would be negative. (Here I depart from my previous approach, where I could have set f(5)=-1 and compensated for it by setting f(7)=1. But I’m not quite sure whether I have an algorithm that does that kind of compensation systematically.) So now we have a sequence that begins 1 -1 1 1 1 -1 0 -1 1 -1 0 1 0 0 1. I don’t know without going off and doing some calculations, but I think it is probably safe at this point to let f(7) be -1. And so on.

At each stage, it is provably possible to continue the algorithm without backtracking. Indeed, if all the partial sums of the sequence so far are non-negative and you set f(p)=1, then the partial sums along the multiples of p are all non-negative, and all multiples of p previously took the value zero, so no partial sum has been decreased. So the idea is that you try out f(p)=-1. If it leads to a negative partial sum somewhere then you set f(p)=1 and continue.

The unintelligent nature of this algorithm leads me to think that its partial sums may grow pretty fast, but I’m still interested to know, just in case they don’t.

I’ve launched a run up to but it loks like it’ll take a while to complete.

http://demonstrations.wolfram.com/UsingZetaZerosToComputeASummatoryLiouvilleFunction/

The formula that determines its oscillations is

where are the zeta zeros on the critical line. This is apparently proved using Perron’s formula, which in turn relies on information about the Dirichlet series defined by the Liouville function. I don’t know if some approach like this could be useful to us.

As for the numerical aspect, yes I understood many ideas should be tested, for instance I had looked at the forward idea but it didn’t work well. I’ll give a go at your latest “positive constraining” one and try others too, and report the results.

A general idea that could perhaps underlie an algorithm is that if the partial sums are on their way down anyway then there is no need to help them along. That to me suggests an algorithm that looks ahead a bit. For instance, if you’ve chosen the values up to , then perhaps you could calculate the partial sum up to 2p, ignoring the places where is not yet defined, and choose accordingly.

Here’s an idea that probably won’t work, but I can at least explain the motivation behind it. It’s a different sort of greedy algorithm that keeps the partial sums as small as possible but insists that they are all positive. The way it does this is as follows. It starts by setting for all primes . It then looks at 2 and sees whether it can change while keeping all partial sums positive. Finding that it can, it changes to -1. It then can’t change (or the sum up to 3 would be -1) so it doesn’t. It can change to -1 so it does that.

It seems possible that this could result in the function , in which case it works but doesn’t give anything interestingly new. If that happens, then one could make a few “wrong” choices to start with.

The reason for doing it is that if the algorithm knows that it mustn’t go below zero, then it will be very careful to slow things down if the partial sums seem to be decreasing to zero too fast. In other words, it might lead to a natural damping tendency.

I’m not sure what you want to know. I subscribed to the feeds wiki’s recent changes, comments for Gowers’s Weblog, posts Gowers’s Weblog and finally articles on WordPress with the tag polymath5. I’m using Firefox with the addon NewsFox. (I’m not sure that is the best RSS reader. It makes my Firefox freeze from time to time). This is a much easier way to keep up that just pressing F5 on this blog and on the wiki all the time, but I don’t know how you do? Please ask again if I didn’t answered you question.