@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.

One good idea is for you to provide code the can be used to reproduce the problem.

You could also attach a worksheet to your Question. Platform details might help.

Form the Help page for Topic solve,ineq

   In general, variables and parameters will automatically be assumed
   to be real-valued in the context of one or more inequalities.

@TechnicalSupport This item is not really about incorporating functionality.

This is about fixing a regression in quite usual functionality. In Maple 2015.2 the following works:

   plots:-matrixplot(<<1,2,3>|<3,4,7>|<4,5,8>>, heights=histogram, color=red);

But in Maple 2016.2 (and on to Maple 2020.1) the data contructed in the COLOR substructure is invalid (the number of entries are wrong, and some of the floats are indexed...)

The primary and central fix should be to restore the proper construction of the COLOR substructure. The fix should not consist primarily of applying options as a final step (eg. using plots:-display, say with _rest, and with or without overrideoption.)

If anyone's interested: the GUI sometimes renders 3D plots as all black when the color data it receives from the kernel is invalid. The CommandLine Interface (CLI) throws an error when running this problematic example in a terminal shell with the default plot-device.

@Anthrazit Your image shows the Help page of the substring command.

Your Post was (only) about the SubString command from the StringTools package. The Help page for that command states,

    All of the StringTools package commands treat strings as (null-terminated)
    sequences of 8-bit (ASCII) characters.  Thus, there is no support for multibyte
    character encodings, such as unicode encodings.

@Anthrazit One of the paragraphs specifically mentions that the command (and the StringTools package) only supports 8-bit ASCII interpretation.