@Rouben Rostamian  I could also note that the numeric values are attained when accessing the converted list.

And the behavior allows both the Vector and the list entries to be updated when the assigned values for a and b change. That aspect of consistency might be considered desirable.

Download Vector_list.mw

@tomleslie 

Sure, that seems a fine way to compute r(n) quickly even for large n. Great point!

But the original question was about why n*exp(1)*GAMMA(n,1) didn't immediately produce an integer, so my Answer was intended as an explanation (and workaround) for using that closed-form result.

The crossover value of n for timing of my method and yours seems to be about n=2500 or so (on my 64bit Linux, Maple 2017.3). But your method is always quick, and certainly straightforward, while mine appears to require less increase in memory allocation.

Download crossover.mw

Since Kitonum kindly pointed out that GAMMA(n,1) doesn't produce an "expanded" result like integer*exp(-1) for n>50, here is a revised version which does.

For large n>100 it is faster than evaluating the sum only after substituting the integer value of `n`. For very large n it is much faster.

Download exp_combine_2.mw

Another faster way to get the final results as explicit integers, for n>50, is,

S:=unapply('combine'('convert'(simplify(value(r)),elementary),exp),n);

@Jjjones98 My code assumes (at least) that there is one local minimum per revolution, and that a full revolution involves rotating by two Pi radians, no? Do your parameter values change that!?

If in doubt then please just attach what you've got so far in an uploaded worksheet (bug green arrow). Hammering out such details would likely be easy to do. How long you'd need to wait would just depend on people's schedules (e.g. I'm away from a computer today)

@Jjjones98 

Ignore the animation, as you certainly don't need to do anything by rough visualization. The main point of the code I showed there was the way to (programmatically) run until the next event, as a repeated operation, storing the phi values for each perihelion event. Just look at the line where I print a message using each, in a loop. You could do whatever you want with the stored perihelion event phi values. Compare them, compare their differences, or whatever you want. Recall that your original difficulty was in getting your hands on those phi values, and my code gets you those.

As for your plotting question, I don't understand what you mean by, "for r(phi) against r for a range of phi".

@nm Forced splitting of radicals can produce a result which is not valid , ie. not a correct factorization.

@brian bovril It consistently works fine for me, as long as I ensure that the generated images folder/directory is present in the same location as the exported .html file (or copy of same).

When I exported to .html from the Maple GUI there was a popup menu asking about "HTML Export Options", and there I chose "GIF" for representing "Math expressions".

If I copy the .html file to a new location but do not copy its whole associated images folder in a corresponding, new relatively located folder/subdirectory, then naturally the best my browser can do is show the value from the alt tags of the img items.

@nm Yes, it is arbitrary with which of the terms you want to associate the extra factor.

Some of the responders on that other forum noted that too. There were multiple (Mathematica and mathematical) solutions and not all of them always merged any extra, independent term. You didn't specify which you wanted.

If you really want I could treat any -1 term specially and merge with the first factor. The same goes for the `content`.

The original answers here wrapped the "factors" in calls to ``() so that we could multiply them all together while retaining the grouping. Recall that you did not originally specify the format you wanted.

It always saves time and effort to be as clear as you can about what you want, up front.

@nm Returning a list, without wrapping with ``().

splitprod_B.mw

Are there not .gifs (or other image files) that can get produced when you export to .HTML? If so then did you mail yourself those too, keeping any directory/folder structure?

What happens if you just have a +- beastie in regular input and output (and not in any constructed Table thing)? Does it export the same way?

@rlopez When I installed Maple 2017 there was definitely no purple color to Atomic Variables by default.

I think that a strong visual cue is needed, on by default.

But the main point I was trying to make is that the new behavior of the GUI  wrt subscripts is too heavy handed.

The lack of default strong visual cues is a side issue. Replacing a name upon copy&paste is an outright bug. And the italic font for numeric subscripts is poor.

The new behavior of only providing double-underscore subscripts for atomic names is also related to why symbols/accents over-the-symbol are misplaced. They are mis-centered over basename+subscript instead of just over the basename. Even the Layout palette no longer provides a properly typeset 5-way msubsup any more.

It's a curious history, to be sure.

There are lots of little things to it, such as how atomic subscripted names appeared in purple in Maple 17, which was a useful visual cue, since people can forget which they have.

In Maple 2017 the only visual cues that I know of to distinguish between typeset subscripted names (ie. Atomic Variables rather than indexed names) is what the input drop-menu of the Context Bar shows when the mouse focus is put on the name, or whether the subscript is in italic or roman. And the latter distinction only occurs for numeric subscripts.

One aspect that I find especially interesting is that the "new" form of the atomic subscripted name with the double-underscore structure prints in Maple 2017 with a numeric subscript in upright roman font when entered in 2D Input mode (ie. x__1), but then the output displays the subscript in italic. If that output is copy&pasted into a 2D Input area then it also displays the subscript in italic. In Maple 15, in contrast, the atomic identifier displayed in output with the subscript in upright roman font.

So a natural question is: how can one obtain an atomic name -- subscripted by a number -- that displays in output with the subscript in upright roman font? The old form still prints that way in output. Eg, `#msub(mi("x"),mn("1"))`  entered with single left-quotes. But if one copies such output to a 2D Input area then it gets pasted in as the underlying x__1 and output once more displays the subscript in italic font.

Moreover changing the indexed name, as 2D Input, to an Atomic Variable in Maple 2017 will replace it with the double-underscore version. And the palette entry for the literal subscripted name available on the Layout palette also constructs the double-underscore form. So there's no easy way to produce that msub name as above (unless one makes a concatenating procedure to do it).

So it appears that numeric subscripts in atomic names -- that appear with upright roman font in typeset output -- are possible,  but only with inconvenient input. And they won't survive copy&paste.

@Chrras Save an empty Worksheet, to which you've made those settings, somewhere on your computer that you won't delete.

Then use the menubar and change your default Start Page to that. Ie, on the main menubar select Tools -> Options -> Interface and then change the Open worksheet at startup drop-menu item to be Specified worksheet . That's open a popup that lets you choose the customized empty Worksheet that you saved.

At that point you'd be able to use the Start page item on the menubar (its icon looks like a house, it's in the middle), instead of File -> New .

@das1404 Try this in your older version.

@Christopher2222 What has changed, it seems, is that in Maple 12.02 the Statistics:-MovingAverage command did copy over attributes from its input Array to its returned Array. But in Maple 2017.3 that does not happen. I've edited my Answer above to mention this. I don't see how it would make sense for MovingAverage to simply copy over audio qualities which imply rate of play or duration (sampling rate), since the output length needn't match the input length.