What you did wrong was misinterpret a question about products as if it were a question about sums.

You wrote, "I have a maple exercise where it ask me to find the limit of a sum...".

But the picture is that of product, using capital Greek Pi instead of capital Greek Sigma. That's why those are the graphic symbols used for products and sums, because they are a kind of abbreviation ("P" as in Pi for product, and "S" as in Sigma for sum).

> f:= 2*k/(2*k+11);

                              2 k   
                            --------
                            2 k + 11

> g:= sum(f,k=1..n);

            6508   11    /    13\   11                 
        n + ---- - -- Psi|n + --| - -- gamma - 11 ln(2)
            315    2     \    2 /   2            
      
> limit(n^(11/2)*g,n=infinity);

                            infinity

> g:= product(f,k=1..n);

                                        (1/2)
                   10395 GAMMA(n + 1) Pi     
                   --------------------------
                                /    13\     
                        64 GAMMA|n + --|     
                                \    2 /     

> limit(n^(11/2)*g,n=infinity);

                         10395   (1/2)
                         ----- Pi     
                          64          

Or, using the inert forms of the two commands, to show the graphic symbols for product and summation,

> restart:

> f:= 2*k/(2*k+11);

                              2 k   
                            --------
                            2 k + 11

> g:= Sum(f,k=1..n);

                           n           
                         -----         
                          \            
                           )     2 k   
                          /    --------
                         ----- 2 k + 11
                         k = 1         

> limit(n^(11/2)*value(g),n=infinity);

                            infinity

> g:= Product(f,k=1..n);

                           n             
                       ,--------'        
                          |  |           
                          |  |     2 k   
                          |  |   --------
                          |  |   2 k + 11
                         k = 1           

> limit(n^(11/2)*value(g),n=infinity);

                         10395   (1/2)
                         ----- Pi     
                          64          

acer

What you did wrong was misinterpret a question about products as if it were a question about sums.

You wrote, "I have a maple exercise where it ask me to find the limit of a sum...".

But the picture is that of product, using capital Greek Pi instead of capital Greek Sigma. That's why those are the graphic symbols used for products and sums, because they are a kind of abbreviation ("P" as in Pi for product, and "S" as in Sigma for sum).

> f:= 2*k/(2*k+11);

                              2 k   
                            --------
                            2 k + 11

> g:= sum(f,k=1..n);

            6508   11    /    13\   11                 
        n + ---- - -- Psi|n + --| - -- gamma - 11 ln(2)
            315    2     \    2 /   2            
      
> limit(n^(11/2)*g,n=infinity);

                            infinity

> g:= product(f,k=1..n);

                                        (1/2)
                   10395 GAMMA(n + 1) Pi     
                   --------------------------
                                /    13\     
                        64 GAMMA|n + --|     
                                \    2 /     

> limit(n^(11/2)*g,n=infinity);

                         10395   (1/2)
                         ----- Pi     
                          64          

Or, using the inert forms of the two commands, to show the graphic symbols for product and summation,

> restart:

> f:= 2*k/(2*k+11);

                              2 k   
                            --------
                            2 k + 11

> g:= Sum(f,k=1..n);

                           n           
                         -----         
                          \            
                           )     2 k   
                          /    --------
                         ----- 2 k + 11
                         k = 1         

> limit(n^(11/2)*value(g),n=infinity);

                            infinity

> g:= Product(f,k=1..n);

                           n             
                       ,--------'        
                          |  |           
                          |  |     2 k   
                          |  |   --------
                          |  |   2 k + 11
                         k = 1           

> limit(n^(11/2)*value(g),n=infinity);

                         10395   (1/2)
                         ----- Pi     
                          64          

acer

@Alejandro Jakubi I think that using 2D Math input for summation can be OK, as long as one knows what one is getting. This can be achieved by deliberately typing it in. There's already enough subtlety in the distinctions amongst the `sum`, `Sum`, and `add` commands that any more difficulty from the palette makes it all too much for the inexperienced user.

The main palette problem is that the Expression palette only has an entry for the `sum` command. We've see more than enough posts on this forum from members using `sum` to do summation with a literal (non-symbolic) finite upper value for the index, and then running amok of the lack of special evaluation rules for `sum`.

So I'd suggest that anyone wanting 2D Math input for summation do it by typing, as a reminder of what one is asking for. Type in the first three characters only (and not yet the left-bracket), and then hit the command-completion keystrokes (Ctl-space on MS-Windows). That way one can get the 2D input form of inert `Sum`, or active `sum` and be aware (at time of authoring, at least) of what is being requested.

What else does 2D Math need, to not hammer the new user so hard on this topic? Allowing for 2D Math representation of calls to `add` would be nice. But in order for this to not create more confusion it would have to be accompanied by a hover-over/balloon/tool-tip for 2D summation symbols already appearing in a worksheet, so that one could tell at a glance what underlies the graphic. Having to convert 2D Math input to 1D and back again using context-menu actions, just to discover what is being represented, is very user-unfriendly. This would also help with the inert/active forms, since the distinction between black and gray summation graphics is visually weak and not generally known.

There will be people who want to do finite non-symbolic summation, and use 2D Math input for it, and not know/want to handle premature evaluation due to the lack of special evaluation rules on `sum`.

@Alejandro Jakubi I think that using 2D Math input for summation can be OK, as long as one knows what one is getting. This can be achieved by deliberately typing it in. There's already enough subtlety in the distinctions amongst the `sum`, `Sum`, and `add` commands that any more difficulty from the palette makes it all too much for the inexperienced user.

The main palette problem is that the Expression palette only has an entry for the `sum` command. We've see more than enough posts on this forum from members using `sum` to do summation with a literal (non-symbolic) finite upper value for the index, and then running amok of the lack of special evaluation rules for `sum`.

So I'd suggest that anyone wanting 2D Math input for summation do it by typing, as a reminder of what one is asking for. Type in the first three characters only (and not yet the left-bracket), and then hit the command-completion keystrokes (Ctl-space on MS-Windows). That way one can get the 2D input form of inert `Sum`, or active `sum` and be aware (at time of authoring, at least) of what is being requested.

What else does 2D Math need, to not hammer the new user so hard on this topic? Allowing for 2D Math representation of calls to `add` would be nice. But in order for this to not create more confusion it would have to be accompanied by a hover-over/balloon/tool-tip for 2D summation symbols already appearing in a worksheet, so that one could tell at a glance what underlies the graphic. Having to convert 2D Math input to 1D and back again using context-menu actions, just to discover what is being represented, is very user-unfriendly. This would also help with the inert/active forms, since the distinction between black and gray summation graphics is visually weak and not generally known.

There will be people who want to do finite non-symbolic summation, and use 2D Math input for it, and not know/want to handle premature evaluation due to the lack of special evaluation rules on `sum`.

@Christopher2222 Your new version which uses StringTools:-Parsetime makes the very common mistake of building up a list (or set) by repeated concatenation. This results in a collection of increasing length lists being created, and having to be subsequently memory-managed and garbage collected.

Think of the collection of longer and longer instances of list `a` as if they were all stacked and arranged in a triangle. That has area, which is to say that this implementation incurs a quadratic cost (of resources). Fortunately, there are some common remedies for this common malady. Often, `seq` or `map` can get used instead, to form just a single list, and they can often reinstate (near) linear cost. Maybe see here, and for fun here too.

restart:

newdaytoday := proc (d1, m1, y1, d2, m2, y2)
local i, j, k, a, startinterval, endinterval;  
uses StringTools:
  a := []:
  for k from y1 to y2 do
    for j from 1 to 12 do
      for i from 1 to 31 do
        if ParseTime("%Y-%m-%d", cat(k, "-", j, "-", i)):-weekDay = -1 then break: end if:
        a := [op(a), cat("", ParseTime("%Y-%m-%d", cat(k, "-", j, "-", i)):-monthDay,
                         "/", ParseTime("%Y-%m-%d", cat(k, "-", j, "-", i)):-month,
                         "/", ParseTime("%Y-%m-%d", cat(k, "-", j, "-", i)):-year)]:
      end do:
    end do:
  end do:
  startinterval := ParseTime("%Y-%m-%d", cat(y1, "-", m1, "-", d1)):-yearDay:
  endinterval := ParseTime("%Y-%m-%d", cat(y2, "-12-31")):-yearDay
                 - ParseTime("%Y-%m-%d", cat(y2, "-", m2, "-", d2)):-yearDay+1:
  a[startinterval .. -endinterval];
end proc:

newerdaytoday := proc (d1, m1, y1, d2, m2, y2)
local i, j, k, a, startinterval, endinterval;  
uses StringTools:
  a := [seq(seq(seq(`if`(ParseTime("%Y-%m-%d", cat(k, "-", j, "-", i)):-weekDay = -1, NULL,
                    cat("", ParseTime("%Y-%m-%d", cat(k, "-", j, "-", i)):-monthDay,
                        "/", ParseTime("%Y-%m-%d", cat(k, "-", j, "-", i)):-month,
                        "/", ParseTime("%Y-%m-%d", cat(k, "-", j, "-", i)):-year)),
                    i=1..31), j=1..12), k=y1..y2)];
  startinterval := ParseTime("%Y-%m-%d", cat(y1, "-", m1, "-", d1)):-yearDay:
  endinterval := ParseTime("%Y-%m-%d", cat(y2, "-12-31")):-yearDay
                 - ParseTime("%Y-%m-%d", cat(y2, "-", m2, "-", d2)):-yearDay+1:
  a[startinterval .. -endinterval];
end proc:

S1:=newdaytoday(25,12,1900,15,3,1950):
S2:=newerdaytoday(25,12,1900,15,3,1950):
evalb(S1=S2);

plots:-display(
   plot([seq([i,time(newdaytoday(25,12,1900,15,3,1900+i^2))],i=1..15)],color=red),
   plot([seq([i,time(newerdaytoday(25,12,1900,15,3,1900+i^2))],i=1..15)],color=green));

Having a better order of complexity is more important (maybe only eventually...) than a constant factor speedup.In your revision you could also optimize multiple instances of the very same ParseTime invocation by doing it just once, assigning its value, and then reusing that assigned varaiable. Ie, inside you inner loop,

        T:=ParseTime("%Y-%m-%d", cat(k, "-", j, "-", i));
        if T:-weekDay = -1 then break: end if:
        a := [op(a), cat("", T:-monthDay,
                         "/", T:-month,
                         "/", T:-year)]:

But for a duration of 200 days, that code change only brings a constant factor 15% speedup. The overall performance still grows quadratically, and that is what is characterizing the performance here.

acer

@DuncanA 

This kind of CPU load, just to get a reminder, is a terrible idea.

acer

@Christopher2222

Problem 1) Reducing the working precision of a computation just to manage the output display is a bad idea. It's much better to compute with default (or higher, if required) precision and then manage the display separately. Whether one printf's, of evalf's final floats, or uses the displayprecision mechanisms of GUI or `interface` is more a matter of taste or practical consideration -- what matters more is that these are postprocessing approaches, instead of affecting the actual floating-point computations.

Problem 2) Using the multiple-argument syntax of the evalf command to control its precision is not best, in general. The evalf and evalf,details help-pages describe the indexed calling sequence instead.

Sure, the OP might just want to handle only 10.0/50.0 or things just as simple. But maybe more complicated expressions are to be handled, and this was just an illustrative example.

Also, and this is more important, all kinds of other people read the solutions posted in this forum. We should strive for better general solutions, since people will re-use the posted methodolgy and all too often latch on to bad programming habits.

Good coding practice doesn't get the attention is deserves. That's why too many people get into unfortunate habits with respect to `cat` vs `||`, `assign` vs 2-argument `eval`, expressions vs procedures, and a lot of other things that they don't really understand well.

@Christopher2222

Problem 1) Reducing the working precision of a computation just to manage the output display is a bad idea. It's much better to compute with default (or higher, if required) precision and then manage the display separately. Whether one printf's, of evalf's final floats, or uses the displayprecision mechanisms of GUI or `interface` is more a matter of taste or practical consideration -- what matters more is that these are postprocessing approaches, instead of affecting the actual floating-point computations.

Problem 2) Using the multiple-argument syntax of the evalf command to control its precision is not best, in general. The evalf and evalf,details help-pages describe the indexed calling sequence instead.

Sure, the OP might just want to handle only 10.0/50.0 or things just as simple. But maybe more complicated expressions are to be handled, and this was just an illustrative example.

Also, and this is more important, all kinds of other people read the solutions posted in this forum. We should strive for better general solutions, since people will re-use the posted methodolgy and all too often latch on to bad programming habits.

Good coding practice doesn't get the attention is deserves. That's why too many people get into unfortunate habits with respect to `cat` vs `||`, `assign` vs 2-argument `eval`, expressions vs procedures, and a lot of other things that they don't really understand well.

> nops(daytoday(25,12,1899,15,3,1900));
                               82

> nops(daytoday(25,12,2099,15,3,2100));
                               82

acer

@Christopher2222 For your code example I see the very same output in the 32bit Windows versions of Maple 14.01 as well as in Maple 12.02, 13.00, and 15. I just don't see the difference in output that you've ascribed to Maple 14.

I mean in the Standard GUI, when running in a Worksheet. With either 1D or 2D input. And the same, for either "Extended" or "Maple Standard" Typesetting level.

@Christopher2222 For your code example I see the very same output in the 32bit Windows versions of Maple 14.01 as well as in Maple 12.02, 13.00, and 15. I just don't see the difference in output that you've ascribed to Maple 14.

I mean in the Standard GUI, when running in a Worksheet. With either 1D or 2D input. And the same, for either "Extended" or "Maple Standard" Typesetting level.

An example. The second result below is correct to both places after the decimal point, after rounding. The first result is inaccurate.

> restart:

> evalf[2]( (1-sqrt(5))/2 );

                             -0.60
> restart:

> evalf( (1-sqrt(5))/2 ):

> evalf[2]( % );

                             -0.62

acer

An example. The second result below is correct to both places after the decimal point, after rounding. The first result is inaccurate.

> restart:

> evalf[2]( (1-sqrt(5))/2 );

                             -0.60
> restart:

> evalf( (1-sqrt(5))/2 ):

> evalf[2]( % );

                             -0.62

acer

@Joe Riel I was feeling ambivalent about showing the 1-level eval alternative, for the top-level computation, because this post contains just one of several reasons why I think that procedures are very useful and important. Ease of workflow, debugging, profiling... the list goes on. But it's good that you mention it, so that readers will be more informed about their choices for programming. Thanks.

For me, the Maple's programming language is the gem that lies at the heart of the product. Fancy GUI, nice plots, slick formula output, that's all well and good. But the jewel -- the thing that lets you accomplish so much -- is the powerful programming language. It is the best and most important part of the product, not just for advanced users but for all users.