John Cosgrave's page on this topic. As far as I know, there are larger ones now known -- and a diligent Mapler has coded these up. A little digging around (starting with showstat(numtheory:-fermat) leads one to the incantation:

 print(numtheory:-FermatNumberData:-known_fermat_numbers);
{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 36, 37, 38, 39, 42, 43, 48, 52, 55, 58, 61, 62, 63, 64, 66, 71, 72, 73, 75, 77, 81, 83, 88, 90, 91, 93, 94, 99, 107, 116, 117, 122, 125, 133, 142, 144, 146, 147, 150, 164, 172, 178, 184, 201, 205, 207, 215, 226, 228, 230, 232, 250, 251, 255, 256, 259, 267, 268, 275, 284, 286, 287, 297, 298, 301, 316, 329, 334, 338, 343, 353, 370, 375, 376, 380, 398, 416, 417, 431, 452, 468, 480, 544, 547, 556, 569, 579, 600, 620, 635, 637, 642, 667, 692, 723, 744, 851, 885, 906, 931, 971, 1069, 1082, 1114, 1123, 1160, 1225, 1229, 1394, 1451, 1551, 1598, 1849, 1945, 1990, 2023, 2059, 2089, 2456, 3310, 3506, 3723, 4250, 4258, 4332, 4724, 5320, 5531, 5792, 5957, 6208, 6355, 6390, 6537, 6835, 6909, 7181, 7309, 8239, 8269, 8298, 8555, 9322, 9428, 9448, 9549, 9691, 11695, 12185, 13250, 13623, 14252, 14276, 14528, 15161, 17906, 18749, 18757, 19211, 22296, 23069, 23288, 23471, 24651, 25006, 28281, 30256, 35563, 41894, 43665, 49093, 50078, 60079, 63679, 83861, 90057, 91213, 94798, 95328, 104448, 113547, 114293, 125410, 142460, 146221, 157167, 213319, 270091, 282717, 287384, 303088, 382447, 410105, 461076, 472097, 672005, 960897, 2145351, 2478782}

which shows the Fermat numbers for which something is known while numtheory:-FermatNumberData:-fermat_tab contains the actual information.

I go away for a day and I miss Joe Riel's 500th, darn. Next one to watch out for will be Will's 700. I guess he'll get that when he announces the Wiki for mapleprimes ;-). There was some action at the top of page 2 of the rankings as well -- which is the place to look to see who will likely come in to the first page next.

And I know I would probably get suckered in even though I should be working on something else. That seems to be part of what makes Wikipedia work. And MathWorld and PlanetMath and ...

I think a Wiki would be great. There is a lot of accumulated Maple knowledge out there that is hard to find -- even on mapleprimes. A Wiki could help put that somewhere much more accessible.

All very good points you make there. What is really happening is that most users use Maple within a particular context, but Maple can be used in many many different contexts. So any list will either be skewed (because it uses a context different than the users') or superficial (tries to abstract out to what seems useful in most contexts). The list there is skewed in an obvious way: it represents those areas of particular historical strength (and use) of Maple. And by historical, I don't mind the last 5 years, I meant Maple's full 27 year history. And this is not a bad thing -- those areas really are good. What I would suggest would be to break down such a list into "task areas". What comes to mind are "basic calculus", "manipulation of maple objects", "visualization", "programming", and probably "dealing with numbers". And not in that order!

All very good points you make there. What is really happening is that most users use Maple within a particular context, but Maple can be used in many many different contexts. So any list will either be skewed (because it uses a context different than the users') or superficial (tries to abstract out to what seems useful in most contexts). The list there is skewed in an obvious way: it represents those areas of particular historical strength (and use) of Maple. And by historical, I don't mind the last 5 years, I meant Maple's full 27 year history. And this is not a bad thing -- those areas really are good. What I would suggest would be to break down such a list into "task areas". What comes to mind are "basic calculus", "manipulation of maple objects", "visualization", "programming", and probably "dealing with numbers". And not in that order!

All the points schemes that I have seen have flaws of one kind or another. Mostly they reflect they author's biases. In this case I'd say that those who designed this were hoping that the "collaborative books" would take off, and thus gave it more weight. Similarly, starting new threads in a blog was regarded highly. And, as far as building a community is concerned, I can understand that.

Note that if you use <pre> tags instead of <code> tags, your spaces will be preserved, which makes code look a lot prettier. The only disadvantage is that you need to use &lt; instead of < and &gt; instead of >. And while I'm at it, I would rewrite your procedure thus:

PlotFeasibleRegion := proc(S::{set(`<=`), list(`<=`)},xr:: name = range, yr:: name = range)
    # S is a set or list of non-strict inequalities
    # xr and yr of the form x = a..b, y = c..d
    # where x and y are the axis variables
    # The usual plot options, such as colour=..., can be specified after these
    local SS, pts, i, j, n, x, y, a, b, c, d, R;

    typematch(xr, 'x'::name = ('a'::anything .. 'b'::anything)); # always true
    typematch(yr, 'y'::name = ('c'::anything .. 'd'::anything)); # always true
    SS:= convert(S,set) union {x >= a, x <= b, y >= c, y <= d};
    n:= nops(SS);
    pts:= {seq(seq(solve({convert(SS[i], equality),convert(SS[j], equality)}),
                   j=i+1 .. n), i=1..n-1)};
    pts:= select(type,pts,'set(name=realcons)');
    pts:= select(p -> andmap(is,eval(SS,p)), pts);
    pts:= map(subs, pts, [x,y]);
    R := simplex[convexhull](pts);
    if R = {} then NULL 
    else plots[polygonplot](R,args[4..-1])
    end if;
end proc;

I find that most old-time Maple people over-use op and under-use typematch. Also, too much subs and too few eval. But nice use of andmap!

Note that if you use <pre> tags instead of <code> tags, your spaces will be preserved, which makes code look a lot prettier. The only disadvantage is that you need to use &lt; instead of < and &gt; instead of >. And while I'm at it, I would rewrite your procedure thus:

PlotFeasibleRegion := proc(S::{set(`<=`), list(`<=`)},xr:: name = range, yr:: name = range)
    # S is a set or list of non-strict inequalities
    # xr and yr of the form x = a..b, y = c..d
    # where x and y are the axis variables
    # The usual plot options, such as colour=..., can be specified after these
    local SS, pts, i, j, n, x, y, a, b, c, d, R;

    typematch(xr, 'x'::name = ('a'::anything .. 'b'::anything)); # always true
    typematch(yr, 'y'::name = ('c'::anything .. 'd'::anything)); # always true
    SS:= convert(S,set) union {x >= a, x <= b, y >= c, y <= d};
    n:= nops(SS);
    pts:= {seq(seq(solve({convert(SS[i], equality),convert(SS[j], equality)}),
                   j=i+1 .. n), i=1..n-1)};
    pts:= select(type,pts,'set(name=realcons)');
    pts:= select(p -> andmap(is,eval(SS,p)), pts);
    pts:= map(subs, pts, [x,y]);
    R := simplex[convexhull](pts);
    if R = {} then NULL 
    else plots[polygonplot](R,args[4..-1])
    end if;
end proc;

I find that most old-time Maple people over-use op and under-use typematch. Also, too much subs and too few eval. But nice use of andmap!

Recently, getting on to the front page has gotten just a little harder. Both Karel Srot and Nitroxxx have 45 points, which is a fairly high bar. Others, like TomM and Tim Van Dusen were also in the low 40s until recently, but have move up. By doing so, they displaced others (like jakubi and jan) who were on the front page rather recently. Unfortunately, we have not seen quite so much action in the leafs. Robert Israel recently got his bronze leaf -- he's moving up, I predict we'll see him on the front page shortly. It would be nice to see a few more people with gold leafs. Shall we open the bidding as to when we think that a silver leaf will be necessary to get to the front of the rankings? Note that this is tricky, because only the people with less than a silver leaf can have an effect on that!

Maple can be used a very powerful glorified calculator -- but calculators don't help you with the GRE, so why would Maple? Also, it can help you dig into and understand a concept more deeply. But the GRE isn't about deep understanding of concepts. Now, if you understand some concept just a bit and are missing some intuition, Maple can help a lot by allowing you to explore some topic, if it is computational in nature. One could think of GRE drill sessions hosted in Maple, the same way the MAA has some tests (using MapleTA). But I've never seen GRE-related stuff.

To even figure out if the integral is convergent or not at 0, one needs to know the relation between d1 and d2. If I try to compute the series expansion of the integrand at t=0 with MultiSeries, I get:

> MultiSeries[series](ss, t, 3);
Error, (in MultiSeries:-multiseries) unable to sort exponents, {-1, 1, -(-d1+d2)/(d1+d2), (-d1+d2)/(d1+d2), -(1/2)*(2*Pi*N*d1+2*Pi*N*d2)/(N*Pi*(d1+d2)), -(1/2)*(-2*Pi*N*d1-2*Pi*N*d2)/(N*Pi*(d1+d2))}

where ss is the integrand. However, I am quite sure that all those assumptions that you gave definitely helped get this far. [Note: those last 2 exponents are equal to -1 and 1, ignore them for now] If I make a change of variable so that y=1/(L*sin(t)), then it is possible to resolve that the integral is fine at y=infinity and seems integrable at y=1/L.

To even figure out if the integral is convergent or not at 0, one needs to know the relation between d1 and d2. If I try to compute the series expansion of the integrand at t=0 with MultiSeries, I get:

> MultiSeries[series](ss, t, 3);
Error, (in MultiSeries:-multiseries) unable to sort exponents, {-1, 1, -(-d1+d2)/(d1+d2), (-d1+d2)/(d1+d2), -(1/2)*(2*Pi*N*d1+2*Pi*N*d2)/(N*Pi*(d1+d2)), -(1/2)*(-2*Pi*N*d1-2*Pi*N*d2)/(N*Pi*(d1+d2))}

where ss is the integrand. However, I am quite sure that all those assumptions that you gave definitely helped get this far. [Note: those last 2 exponents are equal to -1 and 1, ignore them for now] If I make a change of variable so that y=1/(L*sin(t)), then it is possible to resolve that the integral is fine at y=infinity and seems integrable at y=1/L.

The version that I gave should work in document mode. For that matter, so should Axel's.

The version that I gave should work in document mode. For that matter, so should Axel's.