@ExpHP I like your question because it may suggest a functionality enhancement for Maple. It might be an improvement if elision could be enabled for expression sequences and/or contents of sets or lists.

Maybe it merits a software change request.

Another approach is to attain the functionality by coding it up. (You could hide the proc defn and the elision settings calls in a start-up, hidden code edit region, or collapsed Document block).

> restart:

> show:=proc(S)
>   local n;
>   if type(S,{set,list}) then
>     n:=nops(S)-interface(elisiontermsafter)-interface(elisiontermsbefore);
>     if n>0 then
>       return S[1..interface(elisiontermsbefore)],
>              convert(cat("...",n," terms..."),name),
>              S[-interface(elisiontermsafter)..-1];
>     end if;
>   end if;
>   S;
> end proc:

> show({a,b,c,d,e,f,g,h});
                    {a, b, c, d, e, f, g, h}

> interface(elisiontermsafter),interface(elisiontermsbefore):=2,3:

> show({a,b,c,d,e,f,g,h});
                {a, b, c}, ...3 terms..., {g, h}

> interface(elisiontermsafter),interface(elisiontermsbefore):=1,1:
> with(combinat, setpartition):
> P := {$1..12}:

> ans := setpartition(P, 6):

> show(ans);
{{{1, 2, 3, 4, 5, 6}, {7, 8, 9, 10, 11, 12}}}, ...460 terms..., 

  {{{1, 8, 9, 10, 11, 12}, {2, 3, 4, 5, 6, 7}}}

I just realized that the above has a bug. There is an unwanted closing- and opening brace pair, before and after the ellipsis term. It could be fixed up, possibly using fancier printing. Or you could just set one of the elision limits to 0. Note that in the case of a parent set the placement of the ellipsis at front or back would not be so easily controllable (new set ordering!)

> restart:

> show:=proc(S)
>   local n;
>   if type(S,{set,list}) then
>     n:=nops(S)-interface(elisiontermsafter)-interface(elisiontermsbefore);
>     if n>0 then
>       return `if`(type(S,list),`[]`,`{}`)(
>              op(S[1..interface(elisiontermsbefore)]),
>              convert(cat("...",n," terms..."),name),
>              op(S[-interface(elisiontermsafter)..-1])
>              );
>     end if;
>   end if;
>   S;
> end proc:

> show({a,b,c,d,e,f,g,h});
                    {a, b, c, d, e, f, g, h}

> interface(elisiontermsafter),interface(elisiontermsbefore):=0,3:
> show({a,b,c,d,e,f,g,h});
                    {a, b, c, ...5 terms...}

> interface(elisiontermsafter),interface(elisiontermsbefore):=0,1:
> with(combinat, setpartition):
> P := {$1..12}:

> ans := setpartition(P, 6):

> show(ans);
  {...461 terms..., {{1, 2, 3, 4, 5, 6}, {7, 8, 9, 10, 11, 12}}}

@ExpHP I like your question because it may suggest a functionality enhancement for Maple. It might be an improvement if elision could be enabled for expression sequences and/or contents of sets or lists.

Maybe it merits a software change request.

Another approach is to attain the functionality by coding it up. (You could hide the proc defn and the elision settings calls in a start-up, hidden code edit region, or collapsed Document block).

> restart:

> show:=proc(S)
>   local n;
>   if type(S,{set,list}) then
>     n:=nops(S)-interface(elisiontermsafter)-interface(elisiontermsbefore);
>     if n>0 then
>       return S[1..interface(elisiontermsbefore)],
>              convert(cat("...",n," terms..."),name),
>              S[-interface(elisiontermsafter)..-1];
>     end if;
>   end if;
>   S;
> end proc:

> show({a,b,c,d,e,f,g,h});
                    {a, b, c, d, e, f, g, h}

> interface(elisiontermsafter),interface(elisiontermsbefore):=2,3:

> show({a,b,c,d,e,f,g,h});
                {a, b, c}, ...3 terms..., {g, h}

> interface(elisiontermsafter),interface(elisiontermsbefore):=1,1:
> with(combinat, setpartition):
> P := {$1..12}:

> ans := setpartition(P, 6):

> show(ans);
{{{1, 2, 3, 4, 5, 6}, {7, 8, 9, 10, 11, 12}}}, ...460 terms..., 

  {{{1, 8, 9, 10, 11, 12}, {2, 3, 4, 5, 6, 7}}}

I just realized that the above has a bug. There is an unwanted closing- and opening brace pair, before and after the ellipsis term. It could be fixed up, possibly using fancier printing. Or you could just set one of the elision limits to 0. Note that in the case of a parent set the placement of the ellipsis at front or back would not be so easily controllable (new set ordering!)

> restart:

> show:=proc(S)
>   local n;
>   if type(S,{set,list}) then
>     n:=nops(S)-interface(elisiontermsafter)-interface(elisiontermsbefore);
>     if n>0 then
>       return `if`(type(S,list),`[]`,`{}`)(
>              op(S[1..interface(elisiontermsbefore)]),
>              convert(cat("...",n," terms..."),name),
>              op(S[-interface(elisiontermsafter)..-1])
>              );
>     end if;
>   end if;
>   S;
> end proc:

> show({a,b,c,d,e,f,g,h});
                    {a, b, c, d, e, f, g, h}

> interface(elisiontermsafter),interface(elisiontermsbefore):=0,3:
> show({a,b,c,d,e,f,g,h});
                    {a, b, c, ...5 terms...}

> interface(elisiontermsafter),interface(elisiontermsbefore):=0,1:
> with(combinat, setpartition):
> P := {$1..12}:

> ans := setpartition(P, 6):

> show(ans);
  {...461 terms..., {{1, 2, 3, 4, 5, 6}, {7, 8, 9, 10, 11, 12}}}

There are various kinds of window function, and yes they can have a variety of effects. (Pls see a few comments above on your posible need to choose.)

There are various kinds of window function, and yes they can have a variety of effects. (Pls see a few comments above on your posible need to choose.)

How did you generate that image of the equation?

It is much better in appearance than what the "Maple Math" button on this site's Editor window provides.

@brian abraham These are good questions.

I suggest this link as reading material. Since I take all the data as given (ie, not a stream of data) then it can be considered as one big window in that context.

Given the earlier code, compare the following results. I've added a multiplicative term to the signal, so that it approaches zero at the end points. And then its multiplicative inverse is used to scale the result back again, following the inverse FF Transformation. Hopefully you can see some corrective effect this attempt has. (There is still some end-point effect, but remember that some amount of the actual signal is lost due to completely zeroing the high frequencies alongside spectral leakage. The topic of filtering noise while retaining signal gets advanced, as the link should explain. Also, I use a weighting only sketchily similar to that of a Gaussian window -- and I didn't give it a lot of thought. For your signal may wish to experiment with some other Window Function, eg. exp(-abs(a+i*(b-a)/n)) or something better entirely.)

Download fftfun03.mw

[I made a revision to this comment. It had an earlier, inferior code variant.]

@brian abraham These are good questions.

I suggest this link as reading material. Since I take all the data as given (ie, not a stream of data) then it can be considered as one big window in that context.

Given the earlier code, compare the following results. I've added a multiplicative term to the signal, so that it approaches zero at the end points. And then its multiplicative inverse is used to scale the result back again, following the inverse FF Transformation. Hopefully you can see some corrective effect this attempt has. (There is still some end-point effect, but remember that some amount of the actual signal is lost due to completely zeroing the high frequencies alongside spectral leakage. The topic of filtering noise while retaining signal gets advanced, as the link should explain. Also, I use a weighting only sketchily similar to that of a Gaussian window -- and I didn't give it a lot of thought. For your signal may wish to experiment with some other Window Function, eg. exp(-abs(a+i*(b-a)/n)) or something better entirely.)

Download fftfun03.mw

[I made a revision to this comment. It had an earlier, inferior code variant.]

How about this?

> f:=1/(exp(exp(x))-2):

> rdiscont(f,x);

                                {}

> limit(f,x=ln(ln(2)));

                             undefined

How about this?

> f:=1/(exp(exp(x))-2):

> rdiscont(f,x);

                                {}

> limit(f,x=ln(ln(2)));

                             undefined

@Alejandro Jakubi Maybe. I'll remove that part then, because it's not the central issue. The comments about confusion as to use of atomic identifier should stand, as they are to the point.

@Alejandro Jakubi Maybe. I'll remove that part then, because it's not the central issue. The comments about confusion as to use of atomic identifier should stand, as they are to the point.

You didn't just make C[s] into an atomic identifier. You made all of R/(j*omega*C[s]) into an atomic identifier.

Once you make a whole compund object like that into an atomic identifier then Maple can no longer see inside it. Because it has no insides. It's just a single name. That's why it's called "atomic".

If instead you make only C[s] into an atomic identifier, done consistently throughout your whole expression T, then Maple could simplifiy the thing. The same is true if you were to make several individual subscripted names into atomic identifiers, separately.

But instead you've done it to whole compound objects like R/(j*omega*C[s]) and RL/(j*omega*C[s]), inadvertantly making them opaque. They are no longer products and divisions, because you've turned them into the names of such products and divisions.

So I would advise you to just select individual names like C[s] with the mouse, before using the right-click context menu to convert to atomic identifier. It works ok for me using just the keyboard for entry, too. Eg, using exactly these keystrokes

  Shift-r
  /
  j
  Space
  o
  m
  e
  g
  a
  Ctl-Space          (command completion, to get the Greek symbol)
  Space
  Shift-c
  Ctl-Shift-_
  s
  Enter

That produces this for me, in Maple 14 and 12 on Windows, with only the C_s as an atomic name.

> lprint(%);

R/(j*omega*`#msub(mi("C"),mi("s"))`)

And it typesets as  with only the  as atomic. The R, j, and omega are unattached and free for simplification.

I'm sorry, but to me your posted example looks like user error, unless you are using some (old) version where the 2D Math entry of atomic identifiers is itself different from above and buggy..

`Or else what?' said Alice, for the Knight had made a sudden pause.

`Or else it doesn't, you know. The name of the song is called "Haddocks' Eyes."'

`Oh, that's the name of the song, is it?' Alice said, trying to feel interested.

`No, you don't understand,' the Knight said, looking a little vexed. `That's what
 the name is called. The name really is "The Aged Aged Man."'

`Then I ought to have said "That's what the song is called"?' Alice corrected herself.

`No, you oughtn't: that's quite another thing! The song is called "Ways and Means":
 but that's only what it's called, you know!'

`Well, what is the song, then?' said Alice, who was by this time completely bewildered.

`I was coming to that,' the Knight said. `The song really is "A-sitting On A Gate":
 and the tune's my own invention.' 

You didn't just make C[s] into an atomic identifier. You made all of R/(j*omega*C[s]) into an atomic identifier.

Once you make a whole compund object like that into an atomic identifier then Maple can no longer see inside it. Because it has no insides. It's just a single name. That's why it's called "atomic".

If instead you make only C[s] into an atomic identifier, done consistently throughout your whole expression T, then Maple could simplifiy the thing. The same is true if you were to make several individual subscripted names into atomic identifiers, separately.

But instead you've done it to whole compound objects like R/(j*omega*C[s]) and RL/(j*omega*C[s]), inadvertantly making them opaque. They are no longer products and divisions, because you've turned them into the names of such products and divisions.

So I would advise you to just select individual names like C[s] with the mouse, before using the right-click context menu to convert to atomic identifier. It works ok for me using just the keyboard for entry, too. Eg, using exactly these keystrokes

  Shift-r
  /
  j
  Space
  o
  m
  e
  g
  a
  Ctl-Space          (command completion, to get the Greek symbol)
  Space
  Shift-c
  Ctl-Shift-_
  s
  Enter

That produces this for me, in Maple 14 and 12 on Windows, with only the C_s as an atomic name.

> lprint(%);

R/(j*omega*`#msub(mi("C"),mi("s"))`)

And it typesets as  with only the  as atomic. The R, j, and omega are unattached and free for simplification.

I'm sorry, but to me your posted example looks like user error, unless you are using some (old) version where the 2D Math entry of atomic identifiers is itself different from above and buggy..

`Or else what?' said Alice, for the Knight had made a sudden pause.

`Or else it doesn't, you know. The name of the song is called "Haddocks' Eyes."'

`Oh, that's the name of the song, is it?' Alice said, trying to feel interested.

`No, you don't understand,' the Knight said, looking a little vexed. `That's what
 the name is called. The name really is "The Aged Aged Man."'

`Then I ought to have said "That's what the song is called"?' Alice corrected herself.

`No, you oughtn't: that's quite another thing! The song is called "Ways and Means":
 but that's only what it's called, you know!'

`Well, what is the song, then?' said Alice, who was by this time completely bewildered.

`I was coming to that,' the Knight said. `The song really is "A-sitting On A Gate":
 and the tune's my own invention.' 

@AlbertoVe What are you trying to accomplish with all those nested `assuming` calls?

How is this, for getting positive u1 as a function of varying Csusp? You have to comment out your original line that did assignment to Csusp, for it to work. (And, after also removing every original `assume` call.)

new_e4:=simplify(e4) assuming u1>0:
find_u1_given_Csusp:=CSUSP->fsolve(eval(new_e4,Csusp=CSUSP)):

find_u1_given_Csusp(0.001);

plot(find_u1_given_Csusp,0.0001..0.01);

@AlbertoVe What are you trying to accomplish with all those nested `assuming` calls?

How is this, for getting positive u1 as a function of varying Csusp? You have to comment out your original line that did assignment to Csusp, for it to work. (And, after also removing every original `assume` call.)

new_e4:=simplify(e4) assuming u1>0:
find_u1_given_Csusp:=CSUSP->fsolve(eval(new_e4,Csusp=CSUSP)):

find_u1_given_Csusp(0.001);

plot(find_u1_given_Csusp,0.0001..0.01);