@Kitonum I don't know if you are any sort of instructor or professor, as are many of the regular posters on MaplePrimes. If so, then surely you realize that while your Answer is technically correct, it violates the pedagogic "spirit" of the Question. To begin with, you've made no use of the fact that the list is sorted.

@audi001 You've failed to define dS__c and you've defined dS__a twice. Surely this was unintentional. Once you've set the correct dS__c, run the solve again. This time, there's a good chance that it'll run out of memory, that there'll be no solution, or that it simply takes too much time. In any of those cases, repost and we'll see what we can do. We'll start by setting some of the 10 parameters to 0 or 1 and trying to solve again.

I deleted your Question that was nearly the same as the one above.

"Warning, solutions may have been lost" is a common response from solve. It generally indicates that solve suspects that there are solutions, or that there are more solutions than it has found, but it can't find them due to limitations of its algorithms. It has nothing to do with running out of memory.

Please follow the instructions in my Answer below.

Hamid: While Mehdi has shown how to use if-then in the loop only because you explicitly asked about that, I must add that there's no good reason to do that.

@tomleslie Sorry, I don't know that. Doing the appropriate solve commands explicitly, I get the result whether I use decimals or fractions.

@Adam Ledger This is much simpler: floor(5^n/4) = (5^n-1)/4 for nonnegative integer n. Therefore, sum(5^n*floor(5^n/4), n= 1..N) = 5/96*(5*25^N - 6*5^N + 1). It's a shame that Maple can't automatically get that initial simplification for floor. The summation is trivial after that, being the difference of two geometric series.

The error is unrelated to what you show in the screenshot. We'd need to see the whole worksheet. Use the green up-arrow on the toolbar in the MaplePrimes editor to upload a worksheet. My first guess is that x1 and or x2 have been previously defined.

@sand15 No, Maple is not implicitly selecting a specific real interval for x or y when solve(sin(x)=y, x) returns arcsin(y). Both the domain and co-domain of arcsin are the complex numbers, as is true for nearly all of Maple's mathematical functions.

Your title indicates that you want to compute the 2nd derivative of f at 0. Yet your ODEs have no f. Did you mean that you want the 2nd derivative of U at 0?

You must not have transcribed your code correctly to your Question. You say that sub_var is the list that you present. Yet you have the line

for sub_var in subs do

which indicates that subs is the list and sub_var iterates over that list's entries.

@rallezet Yes, that would be fairly easy. If you tell me the coordinates of the center of the ball as a function of t, I'll do it.

@tomleslie Lower residuals are not necessarily better in the real-number setting. Consider the function

f:= x-> ((x+2)^3*(x-3)^2 + eps)*exp(-2*x)

where, as usual, eps is a small positive number. To be concrete, let eps = 10^(1-Digits). It's obvious that f has a unique real root, and that that root is slightly less than -2. Indeed, fsolve returns -2. as the root. And it's obvious that 0 < f(3) < f(-2), so 3 has a lower residual.

@Vaishnavi You need to execute the entire worksheet. Simply executing the fsolve command is not enough. One way to execute the entire worksheet is to press !!! on the toolbar.

@Adam Ledger I kinda agree with you about that. However, long-standing tradition of at least 60 years, in all computer languages that I'm aware of, is that for hexadecimal (and only for hexadecimal) the letters A-F are used for digits over 9. It's important for the human reading of computer memory dumps that the more-compact one-character-per-digit form be used. Hexadecimal is the only base that facilitates that dump reading. That being said, it's essentially only an accident that the BBP algorithm works in base 16. The meta-algorithm that derives the summation formulas might return a formula in any other base. I'm sure that they'd publish a base-10 formula if they could find one.

@vv It is not worth it to increase the precision by increasing the value of Digits. Hardware-float computation is in my experience 20 - 30 times faster than software float (at the same precision). So, if the hardware floats give you only 1 correct digit, that's still better than using software floats to get, say, 9 correct digits. To get the next digit, it's better to increase d by 1 and do the hardware-float computation again. And, we should be able to get more than 1 correct digit with the hardware floats.

A hardware float has a 53-bit mantissa. One bit is the sign bit. That leaves 52-bits of precision, which is 13 hexadecimal digits. So that is the theoretical limit of accuracy of this method. So I don't know why there was talk of d+20 a few messages back.