Harmonious "Convergence" The Alternating Harmonic Series is a well known convergent series.



"Clearly", it is obvious that it converges to the natural log of 2. Or does it?

Since the series is not absolutely convergent, by simply rearranging the terms, I can make it approach anything I want. Suppose I want the series to converge to e. All I'd have to do is this:



If you didn't catch the pattern, there isn't an obvious one. Here's how it works:


Consider the terms of the alternating harmonic series in terms of positive and negative terms.
Add together just enough positive terms to exceed our target (e). (aka sum &gt; target)
Subtract the next negative term.
Go back to 2.


Note that at step 2, if our sum == target, you should add another positive term.

From this we can define a sequence associated with each number as follows:


Follow the algorithm above
For each positive term, output 1.
For each negative term, output 0.


Let's call this sequence the "Harmonious Bit Pattern" of a number. For example, the HBP of e begins as:

1, 1, 1, 1, &lt;32 times&gt;, 0, 1, 1, &lt;54 times&gt;, 0, 1, 1, ...


Your challenge:

You will be given:


a rational input target in the range [-10, 10] (note: even reaching 10 via the harmonic series takes many millions of terms). This may be a decimal (aka 1.1) or you may take a rational directly (aka 12/100)
a positive int n input, specifying the number of terms of the Harmonious Bit Pattern to output.


You are expected to output the exact Harmonious Bit Pattern of the target to the specified number of terms. You may output space separated values, comma separated, no separation, etc; just as long as the pattern of 0s and 1s is clearly visible and is read left to right with consistent separation.

Test Cases

&gt;&gt;&gt; 0, 1
1
&gt;&gt;&gt; 0, 2
10
&gt;&gt;&gt; 0, 7
1000010
&gt;&gt;&gt; 1, 10
1101011011
&gt;&gt;&gt; 1.01, 3
110
&gt;&gt;&gt; 1.01, 24
110101101101101101101101
&gt;&gt;&gt; 2.71, 32
11111111111111111111111111111111
&gt;&gt;&gt; 2.71, 144
111111111111111111111111111111110111111111111111111111111111111111111111111111111111111101111111111111111111111111111111111111111111111111111111
&gt;&gt;&gt; -9.8, 100
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000


Note that since -9.8 is so large, the first 1 that would be output is somewhere around the 149496620th term (that was computed via floats, so the value might not be exact).
Perl, 69 bytes

use bigrat;$s+=.5/($s&gt;$ARGV[$_=0]?-++$n:++$p-++$_/2),print for 1..pop


Takes inputs as command line arguments.

Explanation: bigrat enables fractions everywhere for accurate calculations. $s is the current sum of terms, $ARGV[0] is the target value, pop (same as $ARGV[1]) represents the number of terms, $p and $n represent the positive and negative term counts. $_ is either 1 or 0 depending on whether a positive or negative term was added.