Your assignment to f(a,b), though legal, is questionable.  If you really want to create a procedure (operator), do

f := (a,b) -> c*...

However, for this particular example, there is a second problem, the rhs contains f, so this is a questionable assigment.  What is the f doing in the expression?  Does that stand for something different from the function f? If so, then it really should have a different name.

I generally prefer to work with expression, which is how I noticed the problem.  That is,

f := c*... ;

returns a Maple error because f appears on the right side.

Your assignment to f(a,b), though legal, is questionable.  If you really want to create a procedure (operator), do

f := (a,b) -> c*...

However, for this particular example, there is a second problem, the rhs contains f, so this is a questionable assigment.  What is the f doing in the expression?  Does that stand for something different from the function f? If so, then it really should have a different name.

I generally prefer to work with expression, which is how I noticed the problem.  That is,

f := c*... ;

returns a Maple error because f appears on the right side.

You meant

plotsetup(maplet);

or

interface(plotdevice=maplet);

That also works in linux, so I'd expect it to in OSX.

I searched the Maple 12 library and found just under 600 different environmental variables.  Presumably most are not intended for use by the user. 

I hadn't noticed his handle.  Interesting.  For those not aware, the number of such lists for a given n is F(n+1), where F(n) is the fibonacci function.  This can be easily seen by the following.  Let f1(n) be the number of sequences on n bits with no two consecutive 1's and the last bit is a one.  Similarly, f0(n) is the number that end with a zero.  Then

f1(n+1) = f0(n)
f0(n+1) = f0(n) + f1(n) = f0(n) + f0(n-1)

So f0(n) is the fibonacci function.  So the total is

f(n) = f0(n) + f1(n) = f0(n) + f0(n-1) = f0(n+1) = F(n+1).

I hadn't noticed his handle.  Interesting.  For those not aware, the number of such lists for a given n is F(n+1), where F(n) is the fibonacci function.  This can be easily seen by the following.  Let f1(n) be the number of sequences on n bits with no two consecutive 1's and the last bit is a one.  Similarly, f0(n) is the number that end with a zero.  Then

f1(n+1) = f0(n)
f0(n+1) = f0(n) + f1(n) = f0(n) + f0(n-1)

So f0(n) is the fibonacci function.  So the total is

f(n) = f0(n) + f1(n) = f0(n) + f0(n-1) = f0(n+1) = F(n+1).

You don't want to call rand(2) each time.  Each call returns a new random number generator.  Better to assign the output of rand to a local and call it.  Also, here's a slight twist to your routine that avoids unnecessary assignments to 0 by advancing the loop counter (R is initialized with all 0's).

Edited

makebits2 := proc(n)
local R,V,i;
    R := rand(2);
    V := Vector(n);
    for i to n do
        if R()=1 then
            V[i] := 1;
            i := i+1;
        end if;
    end do;
    convert(V,'list');
end proc:

Actually, I see that your routine doesn't make any unnecessary assignments, but this algorithm should advance quicker.

Note that rtable has a constructor that initializes it with random values, so it should be faster to use it then modify.

makebits3 := proc(n);
local V,i;
    V := rtable(1..n,random(0..1));
    for i from 2 to n do
        if V[i-1] = 1 then
            V[i] := 0;
            i := i+1;
        end if;
    end do;
    convert(V,'list');
end proc:

You don't want to call rand(2) each time.  Each call returns a new random number generator.  Better to assign the output of rand to a local and call it.  Also, here's a slight twist to your routine that avoids unnecessary assignments to 0 by advancing the loop counter (R is initialized with all 0's).

Edited

makebits2 := proc(n)
local R,V,i;
    R := rand(2);
    V := Vector(n);
    for i to n do
        if R()=1 then
            V[i] := 1;
            i := i+1;
        end if;
    end do;
    convert(V,'list');
end proc:

Actually, I see that your routine doesn't make any unnecessary assignments, but this algorithm should advance quicker.

Note that rtable has a constructor that initializes it with random values, so it should be faster to use it then modify.

makebits3 := proc(n);
local V,i;
    V := rtable(1..n,random(0..1));
    for i from 2 to n do
        if V[i-1] = 1 then
            V[i] := 0;
            i := i+1;
        end if;
    end do;
    convert(V,'list');
end proc:

Okay, maybe its not top of the list, but I'd like to see a builtin identity procedure, possibly assigned to `()`.  So `()`(a,b,c) evaluates to a,b,c.

The need for an identity comes up rather frequently when programming and it seems a shame to require a user generated procedure, ()-> args.

While it doesn't solve the problem, I just noticed that `@`() returns the identity procedure ()->args.

Even if the OP was using some strange system of units such that [L] = [C] = [t], how would that change anything?  One cannot arbitrarily add similar units, otherwise in the SI system we could add torque to energy, which is nonsensical.  That is, aside from scaling/conversion factors, the algebraic equations don't change just because the system of units do.  So if we can show that the result is meaningless in a particular set of units, cannot we conclude that it is meaningless in any set of units?  Maybe I'm missing something.  A simple counterexample would be nice...

Even if the OP was using some strange system of units such that [L] = [C] = [t], how would that change anything?  One cannot arbitrarily add similar units, otherwise in the SI system we could add torque to energy, which is nonsensical.  That is, aside from scaling/conversion factors, the algebraic equations don't change just because the system of units do.  So if we can show that the result is meaningless in a particular set of units, cannot we conclude that it is meaningless in any set of units?  Maybe I'm missing something.  A simple counterexample would be nice...

Agreed, but the problem specified that the units of L are mH and C are uF. If it looks like a duck and quacks like a duck...

Agreed, but the problem specified that the units of L are mH and C are uF. If it looks like a duck and quacks like a duck...

I didn't notice that, but that still doesn't matter. As I showed, the only way this works is if the units of L and C match, and they don't.