Compare with:

select(n-> numtheory:-tau(n)::odd, {$1..1000});

@Christopher2222 Isn't bookmarking handled much more elegantly by your web browser?

@acer A sans-serif font is more-tiring to read for regular-sized main-body text. This is well known among font experts. (How many professionally printed books have you ever seen in a sans-serif font?) This is something that not even StackExchange always gets right: math.stackexchange.com uses a good serifed font, whereas stackoverflow.com does not. Serifs were invented for a reason; they're not just decoration.

The previous version of MaplePrimes also used a sans-serif font, but I think that it's now been changed to a worse one. You may be able to use your browser settings to override MaplePrimes font selection. I've already done this in FireFox. Here's how: Options => Content => Fonts & Colors => Advanced, then uncheck "Allow pages to choose their own fonts..."

Your code is difficult to work with. Please redo it without using the same letter A in both cases. The second case overwrites the first. Then I can't compare the two sets of coefficients at the end.

Also, you claim that these sets of coefficients are different. Yes, they appear different, but are you sure that they're truly different? I'm not saying that they're the same. I just want to know what makes you so sure that they're different. Can you provide numeric values of the parameters that prove that they're different?

@tsunamiBTP The bug that you encountered---that files with certain special characters in the name can't be uploaded---also existed in the prior version of MaplePrimes. Unfortunately, the error message only says something akin to "Error, couldn't upload file."

@awass Yes, it would've been easy enough for solve to have been coded this way. But Maple does provide a mechanism by which you can redefine procedures to accept input for which they weren't originally intended, using very few lines of code: overload.

local solve:= overload([
   proc(V::Vector) option overload; :-solve(convert(V,set), _rest) end proc,
   :-solve
]);

You can put that in an initialization file.

@Moses Tenne The command to get 70 digits of precision is as you originally wrote:

Digits:= 70;

The 70-digit number that you entered is nonsense to Maple, and I'm baffled as to why you didn't get an error message. The part at the end, `70.*^-38, violates several rules of Maple syntax. Try

9.1256223744000000041048405246803968037257471953759678468102033290122\
7075175300672646212456658597e-38;

The interface command that I gave only affects the precision at which numbers are displayed; it has no effect on how they are stored or computed. If displayprecision is set at -1 (which I think is the default), then numbers are displayed at whatever precision they are stored.

@J4James Please don't use the title line of a Reply to hold information which should be placed in the body of the Reply. As you can see, it gets cut off, and so I can't see your error message.

convert(..., piecewise, ...) needs to be told a variable with respect to which to break into intervals. So how about this?

convert(simplify(sol), piecewise, y) assuming 1 < x, x <= y;

This doesn't seem to require any expand or collect.

@Scot Gould I already figured out the problem and Answered below, so this is a moot point, but you need to run the problematic command after issuing the trace command in order to get any useful information. The output of the trace command itself is just a list of the procedures for which you've used the trace command---pretty much worthless information. What trace does is modify the procedure so that when it is run debugging information will be printed.

You may be able to simplify out the Heun functions if you supply two initial conditions for the ODE.

Give the command

interface(displayprecision= -1);

If the value returned is not -1, then that was your problem, and it should now be corrected. If the value returned is -1, then something else is going on, and you'll need to post a worksheet. The displayprecision can be set by default from the Optionn -> Tools menu. If you need help with that, let me know.

I don't have your fieldplot command, so I can't test this, but you can: Give the command trace(RealDomain:-log, RealDomain:-ln), then do the command that fails. You might get some useful information.

@vv Yes, the memoization really speeds things up, and it's a suitable replacement for your remember table, which isn't allowed in evalhf.

I realized my error, and came back to fix it, but you noticed it first. I've corrected the Answer.

@Bryon Thanks, I found them.

It should've been designed to work correctly if one includes the option Support= -5..5 to the Distribution command. However, it doesn't. So I think that this is a design bug.