@acer 
Thanks a lot for your fruitful help.
I tested tou .mw file and it works beond my expectations.

 

@tomleslie 

I am going to implement these two solutions and look what happens on my machine.

Thanks again

@tomleslie 

It works perfectly well

@tomleslie 

Thanks for the suggestion.


To make it more concrete ...

The unknown is a function r(x) which represents tjhe radius of a revolution object at abscissa. r(x) verifies a nonlinear first order ODE and I'm interested in the radius of curvarure of "solution shap" in some range of x. Assessing this radius by divided differences is not accurate, hence the idea to work with a piecewise solution.

@tomleslie 

Thank you for the information.

I had already used the work-around you refet to but the result is less nice.

Thanks again

@ecterrab 

I will have a look at this package.
Thanks for this alternative solution.

@acer 

You wrote “We haven't been told the precise nature of the expressions that may be present…”

The  ODE system I am concerned with describes  the motion of N masses inside a closed box submitted to an outer acceleration. Within this box they are connectors that link each mass to another one or to the box. A connector between masses i  and j delivers a force on these two masses which depends of the displacements (x) and velocities (v) of the masses i and j (think to some generalization of a spring or a linear damper).
This force can be “simple” (an ideal spring) or more complex and highly nonlinear. A common situation concerns forces that come from experimental measurements: in this case the connector is pointwise defined and a continuous representation of it is obtained by piecewise reconstruction (often piecewise linear).
Then some expressions can be piecewise functions.

For each mass these  two ODEs are written (the upper arrow represents all the x or v variables)

diff(x[i](t), t) = v[i](t),   
F[i](t, (t),  (t))*diff(v[n](t), t) =         

 where the summation is extended to all masses j connected to mass i.


Maybe this will give you some ideas about the general problem.

Now a last point:  I use a Maple code written a few years ago and this code is “frozen” in the sense that it has been approved for simulating very critical phenomena. Modifying this code for it returns the “indets” of the system before the ODE system is constructed is technically simple. But it is incredibly complicated in terms of red tape.  One output of the code is the ODE system itself, so the idea to identify the “indets” from this output in order to prevent any modification (even light) of the code.

In any case I want to thank you for all the work you have been doing.

@Kitonum 
@Thomas Richard 
@tomleslie 

indets(eq, {name, function(name)})     (Kitonum)
and
indets(eq,function(name))  (Thomas Richard)

work both of them amazing well, all of this in a single instruction !

Who should I plebiscite for the first idea?
 

@Kitonum 
@Thomas Richard 
@tomleslie 

 Our mutual responses must have crossed, I will watch your latest messages carefully.

@Kitonum 
@Thomas Richard 
@tomleslie 

***** Ouups,  I cannot find my reply to tomleslie ... probably an operating error of my own

First, I must thank you all for the time you spent to give me answers or hints.
Some of your answers, if not solving my “more complicated” problem have given me some ideas to deal with it.

Maybe you will be interested by these two examples where my "method" (not at all one hundred percent sure of its robustness !!!) returns the expected answers

Case 1
eq :=  F *diff(x(t), t$n)  - G

Where n is an integer >=1 and F and G are arbitrary functions of x(t) and its successive derivatives up to order n-1 (at most), it seems that this piece of code returns the desired answer “x(t)”

INDEP  := indets(eq, name):     # should contain t  only
DEP      := convert(indets(eq, function), list):
OpDEP :=  op~(1, DEP):
zip((u,v) -> if member(u, INDEP) then v end if, OpDEP, DEP)

# result is x(t)

----------------------------------------------------------------------------------------------------------------------

Case 2
 eq := {
               diff(x(t), t) - v(t),   
               F(t, x(t),  v(t))*diff(v(t), t) - G(t, x(t), v(t))
           }

the « generalization » below seems to work well

INDEP  := `union`(op~( indets(eq, name))):
DEP      := convert(`union`(op~(indets(eq, function))), list):
OpDEP :=  op~(1, DEP):
zip((u,v) -> if member(u, INDEP) then v end if, OpDEP, DEP)

# result is { v(t), x(t) }

@Thomas Richard 

Thanks for your help,
I have just sent a reply to tomleslie from which I reproduce here this element

It is not fair to complicate the question once an answer has been provided (my apologies)
… but how how can I deal with this problem ?
eq := diff(x(t), t) = x(t) - 1 +  sin(x(t))

I cannot generalize your solution to all possible functions of x(t) (here a sine).

I'm very sorry to ask you for this extra help

@tomleslie 

Efficient but not completely satisfactory ...

The reason is :
 I'm working in a team where several computation codes are developed in different languages. To insure that new versions of them do not “regress” we test them on a bunch of test cases and compare the results to those given by a reference version.

To do this one has developed a global Eclipse-based application that eases code versioning and regression testing. This app uses environment variables, for instance  to inform the code of the  test case to run.
… and I must comply with this framework.

So I would prefer, if it is possible, a solution which suits our requirements

Nevertheless, thank you for your help

@acer 

This message gives a final reply to your "Sorry I don't understand" answer

I think the many difficulties  I encountered came from the version of Maple I used.



Acer, could you please realize this simple test in Maple 2015 and Maple 2016

1. Open a new worksheet (not in document mode)
2. After the “>” prompt write something like
   > MyVar := # here a string with more than 80 characters”
3. Export this worksheet in a text file (choose mpl, maple text, or whichever other format you want ; lets us name it  ExportFormat).
   Let MyTextFile the name of the text file you have created
4. Now click on Open in the menu bar, choose MyTextFile and (let us call it OpenFormat) one format among the ones Maple proposes.
5. Execute the worksheet.

I did it for all the (ExportFormat, OpenFormat) combinations.
Regardless what it is,  the operation (5) above generates an error when executed with Maple 2015 on a Windows 7 machine.

I did not test all of these combinations in Maple 2016 but, (Mapletext, MapleText), or (mpl, mpl) lead to a no-execution error in stage (5)

The condition “more than 80” characters is important : if the line contains less than 80 characters operation (5) works well in Maple 2015.
If not, operation (4) generates a 2 lines worksheet beginning with a “>” : the first one conatins 79 characters and the second one the rest of the original line. Generally the caesura appears at some place that generates an execution error (for example here between the twos “ right to :=)



 

@acer

I apologized, I probably expressed myself poorly ...

I understood what you have said in your previous answers; but the problem for me is now “how can I generate plain text files from existing mw files in order to deal with them in the future ?”.

(I am not going to develop something from scratch by writing code within an editor, but to convert an existing set of procedures into plain text files this same editor can read)

I had prepare a reply with a more detailed explanation of the issue I face with ... but I have found the way to avoid it.

I need to Export my worksheet with the option "Maple text"  : then if I open the text file after having selected "Maple Text" again I retrieve the content of the original worksheet
(other export & open options generate spurious line breaks and execution errors).

Sorry for the disagreement.

Thank you agai for all the informations you provided me.

@rstellian 

The command  X := RandomVariable(DiscreteUniform(i-x, i+x)): generates a discrete uniform  random variable with possible values

i-x, ....i-1, i, i+1, .... x+i

Then the probability of each event is not 1/2x but 1/(2x+1).

I hadn't understood it was what you wanted !
(see kitonum answer)


If you really want to discard the central element i you can :

1/ build your own mass function (I already did it for continuous random variables but never for discrete ones ; so I am not sure it works correctly)

2/ build X this way  (probably a little bit simple)
  Xp :=  RandomVariable(DiscreteUniform(i+1, i+x)):
  Xn :=  RandomVariable(DiscreteUniform(i-x, i-1)):
  C := RandomVariable(Benoulli(0.5)):                   
  X := Xn*(1-C) + Xp*C
 
Now the random variable X  seems to fit your requirements