@Thomas Richard I feel that another example is useful here, for two reasons:

1) Units:-Split does not first combine units.
2) convert(..,unit_free,t) also allows the unit to be assigned to unevaluated name t.

Download units_split.mw

Note that with the combine, Split merely returns the expression, and 1 (one) for the unit. (Maple 2024.0)

Of course, for the OP's original example no extra combine(..,units) or simplify call is needed.

Note that in general that combining also has the effect of turning the result into the base units for the current system, eg. m=meter for SI in the original example. Neither Split alone nor convert(...,unit_free) will affect the units in these (...no addition):

@salim-barzani See the following attachment, which behaves like dharr's f12, which he ran using Maple 2023.

f12_dharr_ac_2021.2.mw

I converted one expression to `diff` to enable a key substitution to work in Maple 2021, since you have that version.

@salim-barzani 

Please stop posting multiple wholly separate Question threads for the same items.

Such duplicates get flagged as such and may be deleted.

[edit] You can use the Branch button at the bottom of this Question to create a new related Question thread with cross-reference links, so that the content and details are not split.

I have deleted a duplicate of this.

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