@salim-barzani Wholly separate and duplicate Question threads on this may be flagged and/or deleted.

If you want to spawn a related new Question thread on it then you could use the Branch item at the bottom of this body of this Question.

@janhardo 

Now, how about handling a sequence of more than one assumption (passed together simultaneously, in a list)?

@emendes The coeffs command deals with (expanded) polynomials. But things like cos(w) and exp(s+w) are not polynomial in w, and neither is your expression.

The freeze command can turn expressions into names, and thaw reverts that.

So I use freeze here to turn those problematic terms into temporary names, which makes a polynomial (in your given names and the temp names) out of your expression. Then I get the coefficients of x,y,z,w and these temp names. Then I slap it all into a nice list-of-lists while thawing the temp names back to their original expressions.

The same operations as before, but spilt into more steps:

Download acf_ex3.mw

@janhardo Your latest Reply's attachment contains code with the following mistake:

You have,

   "Definite_integral_with_assumption"
        = proc(expression, assumption::nonnegint) ...  end proc

and your FSsimp code is calling that inner procedure and passing it (the FSimp argument) assumption as its second argument. But your usage examples have the passed values for assumption being things other than actual integers. 

If you try your example,
  e3 := Int(exp(-u*x)*x^(1/3), x = 0 .. infinity);
  FSimp(e3, 15, true, 2, false, u::nonnegint );
then FSimp uses u::nonnegint for its own assumption parameter. And that internal procedure receives u::nonnegint as its own second argument, when called by FSimp.

Now, do you understand that the expression
   u::nonnegint
is not itself an integer? Do you understand that the expression u::nonnegint is not itself of type nonnegint?

Why are you putting the specification ::nonnegint on assumption the second parameter of your inner procedure? It doesn't make sense.

ps. You wrote, "...not working is Definite integral with assumption method yet" [emphasis mine]. But that example did in fact work in the edited attachment I gave in my previous Reply. You've broken it with this new coding mistake.

Please add your followup queries here (eg. about using or subistituting with these values in a loop), instead of spawning wholly separate new Question threads on it.

You want more than 190 edges, for an undirected graph with 20 vertices?

(Of course, a seg-fault is a bug.)

@janhardo There were several basic coding mistakes.

Your integration-with-assumptions procedure was written by you to expect the assumption as second argument, but your code forgot to pass that second argument -- which made it error out.

Also you had the FSimp parameter-specification assumption::algebraic but that type doesn't include u<=0. (now edited in attachment with highlights in red)

Also that method's procedure was only printing its result and returning NULL, instead of actually returning the result (now edited in attachment, but not highlighted).

The algebraic and simplifcation methods were classifed and also utilized with their method numbers mixed up/reversed, by you. That's why your other example was not working. (now edited in attachment with highlights in green)

FSimp-integration-assuming_Mprimes_17-7-2024_ac.mw

ps. I have not changed the basic structure of your approach, even though I think it is misguided. I've only made edits to make it work within your approach.

@Ariathm [edited] The only reason that I used kappa->infinity was because you wrote about that elsewhere in this thread.

It now seems that you don't want kappa=infinity. That was not clear to me. Thanks for followup indicating some aspect of an underlying physical problem.

@nm As you have indicated, this problematic behavior is a regression bug from Maple 2023.2 to Maple 2024.

Elision of very large output used to work fine (for many releases) with typesetting=standard (which was the cross-platform default up until & including Maple 2016).

You've used the terms "mathematically" (incorrect) and "present", but not defined those.

So what precisely is the mathematical meaning of using a structural test here? The has command is a structural query.

Consider the two Maple expressions, I*(a^(1/2))^k and I*a^(k/2), for unassigned and unspecified k. The subexpression a^(1/2) is present structurally in only one of them. For which would you consider a^(1/2) as being mathematically "present"?

ps. Your or of two has calls can be made into a single call,
   has(%,{a^(1/2),a^(-1/2)})
as is documented in the second bullest point of the has Help page.

@Ariathm In a followup comment you wrote, "...because kappa approaches to infinity".

So, given the form of your p__3, why not take kappa=infinity (and implying J=1), so that r=1?

[edit] That is the primary issue in your original Question (with kappa->infinity followup). One can get there by either considering the original form of p__3, or the the form of the RootOf form as dharr solved. After that, numerical regression is very easy.

Download testacc.mw

[edit] It is largely irrelevant here whether you use NonlinearFit or LinearFit for this simplified objective form (which is obviously linear in C__10 and C__01); the resulting rational polynomial solutions from them will correspond when expanded, and the computational time here is very small regardless.

@janhardo Your call,

   FSimp(e3, 15,2, 0 <= u)

does not make sense, given the parameter specification of that section's version of FSimp.

That problematic call is passing 0<=u for the sort_by_complexity parameter of FSimp, which is likely not what you intended. You likely intended it for the assumption parameter, but you omitted arguments for some earlier positional parameters and so it was misplaced.

That parameter specification of FSimp using positional parameters is poor, ie. it's confusing and awkward enough that it even confused its own author. Why not use keyword parameters for options?

Does the GUI lock up for this large output with typesetting=standard, and without any timelimit call?

@Andiguys I you run solve without assumptions you get a parametric result showing conditions under which the simpler forms of the inequality (with isolated target name) attain.

You might figure out whether the conditions for those agree with your assumptions. If not then a single sign/direction of the the simpler isolated inequality might not hold for your given assumptions. I don't know what you'd want in such a case.

Please attach your actual code to reproduce in full.