The reference you supply involves

a space of functions under a weighted norm

Your original question referred to

wighted norm of a matrix or a vector in maple

Please clarify what you are after

We are calculating two different things - it is up to you to decide which of  us is correctly interpreting your problem - becuase it is still not clear to me!

I have added an execution group which calculates the same thing as Axel (and included Axel's code for comparison) in the attached

intProb2.mw

Up to you to work out which problem you want to solve

Your integrand contains the undetermined quantities E, pi, and 'e'. Note that as you have written them, the quantity pi bears no relation to the well-known constant 3.14159.... - it is just a greek letter 'pi'. Note also that the quantity 'e' bears no relation to the well known constant 2.718....

If you assign values to the quantities 'pi' and 'e', you *may* have a problem with the quantity m[e]. You appear to be using indexed variables just to provide 'inert' subscripts. Sometimes you can get away with this, and sometimes not. It is generally better practice to use the double underscore for an inert subscript, so that there is no possibility of confucion with an indexed variable.

Assuming you can fix the above, these may still a problem with plotting the output of the integration. In order to perform the numeric integration a range for the variable 'E' must be given. This will result in a single value for the integration. So what exactly do yu want to plot? You could evaluate the integral for say E=-1..1, E=-10..10, E=-100..100 etc and plot the resulting points - but is that what you want?

but I thought it might be instructive for you to understand why your questions make it difficult to generate meaningful responses. (That's a polite way of saying that your questions are often nonsense).

So let's take the first part of your question, ie

For example

if   f := 1/2*diff(x,t)^2+x*diff(x,t)+x+diff(x,t);

Now, (rather obviously) in this expression the variable 'x' does not depend on the variable 't'. If you don't believe me then just fire up a new Maple session, type diff(x,t) and I absolutely guarantee that the answer will be '0'. So when you type the expression

f := 1/2*diff(x,t)^2+x*diff(x,t)+x+diff(x,t);

what you intend(?) is

f := 1/2*0^2+x*0+x+0;

Which (rather obviously) means f:=x - cos that is what you wrote - right?

So when you write

f - subs(diff(x,t)=p, f) - (diff(x,t) - p)*(diff(subs(diff(x,t)=p, f), p));

the two things which are known are a) diff(x,t)=0 and b) f:=x, so the above expression evaluates to

x-subs(0=p, x) -(0-p)*(diff(subs(0=p, x), p)

Since trying to substute for '0' is obviously nonsense (at least it is to me!), the terms -subs(0=p, x) will not perform any substitution, but simplt return the second argument, ie 'x'. In other words the above expresiion will become

x-x -(0-p)*diff(x, p)

Now in this expression it is obvious that 'x' does not depend on 'p' so diff(x,p) is identically zero. (Try firing up up enw MAple worksheet and typing diff(x,p); if you don't believe me). So the above expression evaluates to

0-(0-p)*0

whihc is certailny 0, but I suspect that this is not what you want. Now I didn't get any part of this analysis wrong - so which whic part of your question was wrong? I respectfully suggest you think about it very carefully

In all my responses in this thread I stated that this situation could/would arise through Maple operating correctly.

In none of my responses did I suggest that this was a bug

1. Solve an ODE with no BC/IC which will therefore introduce a constant (at least one) called  _C1
2. incluce this solution is a second ODE, and make sure it is is differentiated so that the _C1 constant "disappears"
3. Solve the second ODE with no BC/IC| whihc will therefore introduce a constant (at least one) called _C1
4. Are the constants _C1 from stage1 and stage3 above identical - NO. They are both named as _C1 but should be considered as different values
5. Since the name _C1 occurs in both solutions, but these constants _C1 in the two solutions are actually different in the "general case", combining these two solutions could get a bit "evil"
6. And I haven't seen a "real" example either - but I fell into this hole many years ago
7. In my opinion, this is NOT a Maple BUG - just a trap for the unwary. After all, if I gave you two equations both of which contained the name '_C1', you would probably assume that  '_C1' would be identical in these two equations - but in the sequence (1)-(5) above, you would be wrong

Worjks for me - I guess it might be a version issue. Which Maple version are you running so I can verify?

In my post on this issue I copy/pasted the output of showstat(`convert/elsymfun`) , mainly to explain the modified procedure whihc the OP seemd to want. The out put of the showstat(`convert/elsymfun`) in my original post has now been deleted, and replaced with

[deleted as violation of Mapleprimes terms of use: copyright violation]

I am honestly shocked by this. My understanding of the 'showstat()' function is that it enables users to examine the way certain commands are implemented. An obvious corollary of this capability is that a user might read the functionality, and then decide to copy+modify it somewhat for a partivular purpose - which is what I did.

I have no idea what I have done "wrong". I pasted the output of a Maple command to a Maple-controlled website!??

To the moderator/bot who deleted this entry - can you provide a list of Maple commands whose output cannot be reported on this site?

How recent does Word have to be?

I tried exactly this approach with Word2010 incorporating the DesignScience/MathType addon, and I couldn't persuade anything to accept MathMl

The OP did not post his particular problem, so there is a level of guesswork in follows. Hold that thought.

It is possible to construct a couple of executions for the solution of smple ODEs, where an integration constant _C1 will occur in both solutions, but actuallly these two occurrences of _C1 bear no relationship to each other - they are certainly not equal. Consider the following "toy" example where the first execution group solves two ODEs where these are essentially considered as two completely separate problems. The integration constant _C1 occurs twice, but actually the two constant represented by _C1 should be considered as distinct (and certainly not equal). The second execution group solves the same two ODEs, but does so simultaneously, and as a result two integration constants occur

The "toy" example

restart;
#
# Solve separately
#
   de1:=diff(y(x),x)=1;
   sol1:=dsolve(de1);
   de2:= diff(u(x),x)*diff(rhs(sol1),x)=1;
   sol2:=dsolve(de2);
   sol2-sol1;
#
# Solve simultaneosly
#
  sol3:=dsolve( { de1,de2});
  sol3[1]-sol3[2];

Can I criticise Maple for the behaviour of the first executioin group above. I don't think so.

Maple's simplicification/evaluation rules mean that on evaluation of de2, any reference to the parameter _C1 in the expression 'sol1' will disappear. Hence when solving 'de2' there is absolutely no reason why the parameter _C1 should not reappear as an integration constant. However this output usage of _C1, in dsolve(de2) bears no relation to the fact that de2 used _C1 as an input parameter. As a consequnce, the _C1 which occurs in sol1 actually bears no relationship to the _C1 which occurs in sol2 - and this is where things can get "evil" - after all, if you manage to generate two expressions, both of which contain yhr variable _C1, then this quantity must be he ame in both expressions, right? Regrettably. NO.

Hence the solutions/wokaround I proposed ptreviously

I don't disagree with your main point, but the workarounds are fairly simple. Either

1. something like) the one I posted earlier, or
2. I'm pretty sure that (most of the time)  if you have two systems of differential equations where the solutions of the first system are fed into the second,  you can just solve both systems simultaneously with a single (p)dsolve() command. In this case there will be no confusion over constants. In fact this is probably(?) the preferred method

As I see it the BIG danger, is if one carries out the operation described in your original post, and don't notice the problem, because it isn't going to be obvious

Variable Separation Constants

If one has a PDE, involving u(x,t) and its various derivatives etc, then often one can look for a solution of the form u(x,t)=X(x)*T(t., By substituting this into the original equation, it is sometimes possible to rearrange the original to a form where the LHS contains only X(x), its derivatives wrt x, and x, while the RHS contains only T(t), its derivatives wrt t and t. Since the two sides of such an equation depend on two independent variables, the only way equality between them can be assured is if each side is equal to a constant. known as the separation constant.

As a general rule (and I don't know if this is universally true) in Maple, separation constants are lower case, (_c1, _c2,...) and integration constants are upper case (_C1, _C2...)

See the second example (Laplace equation in spherical coordinates:) at ?pdsolve, where the solution contains both "upper case" and "lower case" constants

reading the manual - that's how I work things out

You can run the code I came up with using the link in my original post.

1. It *seems* to produce the same graph as in your original post
2. It only uses fairly simple manipulations on the original data - no need for "add-on" packages.
3. The answer it generates for X=12 is 0.7224561404

For future reference, you can upload code here by using the big green up-arrow icon, in the Mapleprimes toolbar

Simplest solution is probably to use a simple rootfinding  "halt" event. NB you cannot use this with method=lsode, but I'm assuming that so long as dsolve() provides an answer, you are not really mothered about the method used - so just let Maple use its default. See the attached

haltIVP.mw

I don't understand your second point: rho is a constant in your worksheet - so rho(r) is meaningless.

Sorry - missed the bit about document mode (probably because I never use it anyway).

Can confirm that in document mode,

code works in  Maple18, Maple 2015, Maple 2016, but errors in Maple 2017.

Interestingly(?), I'm not convinced that "Document Mode" is the problem!

1. if I use 2-D Input in "worksheet" mode, the error occurs
2. if I use 1-D math input in "document" mode (a strange combination I know, but possible), the error does not occur

So my conclusion would be that it is not a "Document Mode" issue, but a "2-D Input" issue.

Furthermore, using 2-D math in document mode, if I restrict the "RealDomain" command, by deleting with(RealDomain), and changing your last line to

use RealDomain in Seq(1/a, a=1..2) end use;

then this also "works"