@JacquesC Indeed, your Reply above just triggered an email notification to me because I must've participated in this thread, but my post isn't now shown below!

@dharr Actually, the extra digits are not needed to perform the arithmetic. The real reason that high Digits works around the problem is that it forces the use of software floats. If we use software floats and keep Digits low, the arithmetic still works, as in

Digits:= 10:
eval(
     .1126460951*t-0.7049523744e-1-1.090463096*10^1390*exp(-1.597924898*t),
     t= 2000.5
);
      168.9538494

@fzfbrd Your worksheet contains the line

CrssOfVds:= VDS-> ArrayInterpolation(Vds, Crss, V);

This line is erroneous because VDS doesn't occur on the right-hand side of the arrow. (The line is not a syntax error because one is allowed to define a constant function, i.e., a function that doesn't depend on its parameter(s).) This line should be

CrssOfVds:= VDS-> ArrayInterpolation(Vds, Crss, VDS);

as it was in your Reply to my Answer below. If you claim that having it that way causes the subsequent evalf(Int(...)) to throw the error

invalid input: evalf expects its 2nd argument, n, to be of type posint, but received numeric,

then please post an executed worksheet showing that error.

@shoeless You wrote:

While the int() command gives me an (expanded) symbolic solution, the same command placed into a function definition will not :/ Seemed odd, e.g. HIG:=T->int(); Any idea why?

Do you mean Why doesn't the command HIG:= T-> int(cos(T), T) return HIG:= T-> sin(T)? The command is a function (more properly called a procedure) definition, not a procedure invocation. No expression in the procedure's body or header is evaluated until the procedure is invoked (*footnote), i.e., a value is supplied for T. In the case of this procedure, that value may simply be the global name 'T'. But this isn't the usual case. For example, it may be required that T be a number rather than a name. But, of course, a name is required to form the abstraction of a procedure parameter.

If you want an expression to be first evaluated (simplified, expanded, etc.) and then turned into a procedure, then use unapply:

HIG:= unapply(int(cos(T), T), T);

(*footnote) There is a minor exception: Trivial arithmetic and some very trivial algebra will be done via a process referred to in the Maple documentation as automatic simplification. An example is that A^0 will be replaced by 1.

@fzfbrd I don't understand why you're getting that error message. It seems to think that you are giving the command

evalf(Int(CrssOfVds, Vdson..Charge_Vds), numeric)

which would be erroneous.

Try using restart, and change ArrayInterpolation to CurveFitting:-ArrayInterpolation.

@tomleslie The reason for the phenomenon that you observed is that the garbage collection runs multithreaded even if the primary code doesn't. You can turn off this feature (so that you can properly time test your code) by setting kernelopts(gcmaxthreads= 1).

I know that you must be excited about your new computer and fully utilizing all of its cores, but please don't be so quick to yell "Bug!" so vehemently.

Note that cos is not "threadsafe" (see ?index,threadsafe), so results are unpredictable.

Please run the following command:

kernelopts(numcpus);

If the result isn't 20, just report that result. If the result is 20, then please run the following test code and report the results. You should have 20 seconds with which to observe whether you're getting nearly 100% CPU utilization.

Waste:= proc(N)
local st:= time();
     while time() - st < N do end do;
     kernelopts(numactivethreads)
end proc:

CodeTools:-Usage(Threads:-Map[tasksize= 1](Waste, [20$20]));

The expected results are a cpu time a little over 400, a real time a little over 20, and a list of 20 20s.

Please upload a worksheet (as an alternative to copy-and-paste). Use the green uparrow, which is the last item on the second row of the toolbar in the MaplePrimes editor.

@acer 

Yes, I agree with Acer 100%. I did know that the minima from different fitmethods weren't directly comparable (however, the minima from different methods using one fitmethod are comparable), but I was being lazy and ad hoc in my minimum-selection process. So I knew that I'd have to look at the plots also.

A more formal approach would be to take all the minimal parameter combinations returned and measure them with a single objective function that makes sense for the application. This occasionally produces a lower value than the point returned as the minimum for that objective. How can that be? No known method of minimizing a nonconvex function can guarantee that it has found the global minimum; only local minima can be guaranteed.

There are several other reasonable selection approaches. All that I can think of involve some degree of hueristics.

@hasselhof 

I recommend that you download the DirectSearch package and read its extensive help files in addition to reading this. Depending on your Maple version, you may need to convert the help files to the new format, which is very easy to do.

DirectSearch:-DataFit offers nine ways to measure the residuals. These are the fitmethods. For example, lms is Least Mean Squares---the most traditional way---and lad is Least Absolute Deviations---probably the most intuitive way. Each of these leads to an objective function that is to be minimized. DirectSearch as a whole offers four algorithms for approximating the minimum of a function. These are the methods. That's a total of 9 x 4 = 36 methods. Using other options to DataFit, I could get even more.

The output of DataFit is a three-element list. The first element is the minimal achieved value of the objective function. The second element is, of course, the list of parameter values at which that minimum is achieved. The third element (which has no significance here) is the number of times the objective function was evaluated. It's simply an efficiency measure.

So, how does one choose one of the 36 results? There are several approaches to this. From those results with the smallest minima, I choose the one with the best-looking plot, i.e., the plot with the closest fit to the data. So, you may ask How can the plot be visibly deviant and still have low residuals? That's because some of the fitmethods ignore some of the points that that fitmethod considers to be outliers.

@jaypantone If the third argument to userinfo is 'NoName', then no function name will be printed.

@smith_alpha No, you haven't expressed it very clearly; in particular, your use of the word "manually" has been confusing. And the Answers provided here by Tom Leslie, Kitonum, and me address the issue of how to sort a list, not how to create that list in the first place. Furthermore, Tom's Answer requires that f initially be a table. Your f is indeed a table in your original posing of this Question, but it won't necessarily be a table when you generate it programmatically.

As I've told you before (in another thread), the most efficient way to create a list in a for loop is to create it as a Vector first. Now sort can be used on a Vector just as well as on a list. So, there's no point in making the list at all---just sort the Vector.

@Kitonum It should be noted that when the sublists have varying lengths, this default sort produces perhaps unexpected results---results that I think many people wouldn't consider properly sorted:

sort([[z,o,o], [c,a,t], [m,a,p,l,e]]);

However, if you view the sublists as being positive integers with their elements being the "digits" (such as the output produced by convert(..., base, ...)), then this default sort is okay.

It should also be noted that you have implicitly converted f to a list and that sort won't work with the original format of f.

@smith_alpha You plan to manually enter ~10^4 sublists into a worksheet rather than, say, reading them from a file or generating them programmatically? Why?

@smith_alpha 

If we're only talking about manual input, then that input is necessarily small, and thus efficiency differences are insignificant. If you feel that entering an explicit list is "rather inconvenient" then go ahead and do it the way that you've been doing:

f[1]:= ...;
f[2]:= ...;

etc.

And then immediately after that, convert it to a list with

f:= convert(f, list);

And be aware that before you do the conversion, it isn't a list.

But I'm still surprised that you find it "rather inconvenient". I personally have no problem entering a single list of many hundreds of entries (usually copy-and-pasted from somewhere) across multiple lines. Note that you can use Shift-Enter to continue any input on the next line.