@mmcdara Thanks, but I had already run in the debugger, and already knew exactly how many times f() gets evaluated in these cases. The debugger cannot help much more than that, here.

An issue with these mixed cases (positive and negative coefficients) is inconsistency between cases and between what happens after wrapping in uneval quotes (relatively speaking). Some amount of automatic simplification occurs. 

The debugger can only show what happens when the evaluation occurs, and that happens only *after* any automatic simplification occurs.

@Preben Alsholm As far as I know (so far) that too is a result of some automatic simplification.

See also the cited example,  f()+f()+f()-f()

The behavior is more complicated in these mixed cases. [edited] Earlier I wrote, "...affected by the order of terms in the sum" but I am not sure. See later comments below.

@mmcdara In general, symbolic integration for expressions containing floating-point coefficients is a not a great idea. This general problem relates to broader areas of symbolic computation, and not just integration in statistics or DEs.

You have omitted to show how M and L figure in your conditions, following "such that".

The wrong use of the `assume` command and the handling of names inside procedure S is the main cause of the problem.

Using the deprecated linalg package, setting Digits to 2, and use of `%` inside procedure S are also poor choices.

@Kitonum The conjugate is there. I suspect that the later assumptions were one way for the OP to deal with it.

If that subterm were not conjugated then it could be done more directly (ie. without substitutions or supplying extensions to factor) as,

   simplify(evala(Expr), symbolic)

or,

   simplify(radnormal(Expr), symbolic)

or even,

   simplify(expand(rationalize(Expr)), symbolic)

@Kitonum Did you omit the conjugate term in entering your version of the expression?

@lime I know you are trying to optimize performance time. That's why I suggested reducing the accuracy tolerance. But no accuracy value optimizes all possible examples, so fishing for a value that works for some unknown integrand is difficult.

Also, it may well be that the computation of the integrand could be sped up. But that's really hard to do without knowing what it is. Is it evalhf'able?

Specifying some methods can save time by avoiding unnecessary checks for discontinuties. (Another way is using so-called operator form.)

This is a complicated and general query, without the integrand being known.

[edit] I expect that you've already tried exact integration.

There is often very little difference between properly using evalf(Sum(...)) and add(evalf(...) for a small finite number of terms. I doubt that by itself would help in a significant way.

I'd suggest instead to focus first on the performance of individual calls to numerically compute the integrand -- especially under evalhf, but also more generally. And, as originally mentioned, loosening the tolerance,  and forcing a method or using operator form.

It usually helps to explicitly supply the integrand. You can upload and attach a link to a worksheet here by using the green up-arrow in the Mapleprimes editor.

Some performance improvement might be attained by passing options such as, say,
    epsilon=1e-4, method=_d01ajc
to the Int call.

This Answer makes claims about the original results from the OP. But actually it is this Answer which is wrong.

I don't understand why some people upvoted this Answer.

There is no justification provided for throwing away additional digits of precision in the data. If one keeps the full digits provided and accomodates the numeric error (eg. roundoff, loss or precision) then by raising the working precision the original plot is explained.

Conversion to rational without the exact option will throw away information here, without justification. Conversion to rationals is not actually necessary here, if Digits is raised adequately. But too low a wokring precision for such rational conversion gets highly inaccurate and wrong results for this example.

prec_examp.mw

@Jean-Michel Collard Please provide the real (wall clock) timings for both Maple 2020 as Maple 2021, for both the CUDA and non-CUDA timings separately.

I understand that English is not the native language of all members here, and that is perfectly OK.

But your query, "So what can't I get a better ratio with/without CUDA?" is not clear, or well formed, as an English sentence.

I can think of at least three reasonable -- but quite different -- interpretations of that string of words.

And some good answers may depend on what you already know about parallelized and otherwise optimized implementations of the DGEMM function across different architectures and platforms.

So, could you please explain precisely what you want to ask?

Moreover, you have missed some key details. You gave the ratios for both Maple 2020 and Maple 2021, but you gave the numerator and denominator only for Maple 2021. So we cannot tell whether both or just one of the timings changed for your machine.

(Presumably you are running both Maple versions now to get this data fresh, for this comparison -- and not using data from possibly an older revision of your GPU driver.)

This is very similar to this Question you asked in July, 2019. Query and solution are much the same.

And the techniques that work can also be learned from Answers to additional previous Questions you have posted. The Answers here (July 2019), and here (Oct 2020) are very close in essence. And those here (July 2019), and here (Jan, 2021) are also close enough.

Perhaps you went back to those earlier duplicates and related questions of yours, and did not see how this current example could be handled similarly.

If that is the case then is there something more we could do to help in your understanding of how these commands work?

It is not clear what you are trying to ask.

The error message indicates that the GUI plot renderer had received a plot structure that it thinks contains an invalid substructure.

That is pretty much all we can tell from the message itself.

So we need to be able to re-execute, to reproduce the problem, so as to examine the internals of the problematic plotting structure.

Please show not just your procedures, but also the examples of calling them. (Word description is not as helpful.)

You could just upload and attach your .mw file.  Platform/OS details can be helpful.