5-w-x-y-z<=0

I'm pretty sure the inequality constraints always have to be written as

expr<=0

When you do something "interactively" this means no-one on this site can follow your logic, so no-one is likely to be able to help. If you want help, provide the information originally requested!

###########################################################

Your original post says that you have " 5 dif equations and five unknows"

You don't have five differential equations, You have three differential equations, each of which is off the form

diff(Q(t),t)=some expression

so these can't be independent - correct?

You also have two (non-linear) algebraic equations.

If I list the indeterminates in your equations, using

`union`(seq(indets([eqs][j], name) union indets([eqs][j], function), j = 1 .. 5))

I get

{A, T__1i, T__2i, c__p, d, g, h, h__2, k, m__1, m__2, t, Q(t), T__1(t), T__1s(t), T__2(t), T__2s(t), diff(Q(t), t)}

Now which of these am I suppose to assume are the five unknowns?

What are the 'values' of the other 13 indeterminates? Am I supposed to guess?

You have to appreciate two things:

One

Just because you have 12 equations in 12 unknowns does not mean that a solution exists - they may be inconsistent. (or you may have a typo in one or more equations)

Two

Even if a solution exists, there is no guarantee that it will be found in an optimisation process. As Wikipedia says " Solving ...... non-convex problems can be computationally intractable " !!!

############################################################

Some explanation of the results presented in the worksheet I posted previously.

The DirectSearch:SolveEquations command returns a list of four quantitiies: the meaning of these quatities is

1. The fourth entry is just the number of 'function evaluations' which has been performed. Think of this as the number of different points (ie values of [x₁,.....x₁₂] ) which have been tested on the way to the reported solution
2. The third entry in the output list, is just the 'best' solution point which DirectSearch could obtain
3. The second entry is a vector of the 12 'residuals'. In other words, if one substitutes the entries obtained in (2) above, into your 12 equations, it contains the resulting function values. Since f[j]=0, for all j, then ideally, all of these values will be very close to zero
4. The first entry in the output list is just the sum of the squares of the residuals reported in (3) above - so again a value 'close' to zero would indicate a 'really good' solution. Given the values described in (3) above this entry is a bit superfluous, but it permits the user to perform a crude eyeball check. For example, in your case this value is ~2400: you have 12 equations, so 'on average', the squared residual per equation is ~200, and thus the 'average' residual per equation is ~14. You can compare the actual residuals (see [3] above) with this 'average' to see which equations are being accurately(?) solved, and which are causing problems. In your system, the residuals for equations 1-7 are pretty good, equations 8-9 are pretty poor, and 10-12, somewhere in-between.

You should be aware of how DirectSearch:-SolveEquations works: it is essentially an optimiser. It takes your equations f([x₁..x₁₂])=0, squares them, and adds them to get F([x₁..z₁₂])= add( f[k](x₁..x₁₂])^2 ). The minimum value of this constructed function ought to be zero. DirectSearch:-SolveEquations() uses more-or-less standard optimisation techniques to search for this solution. Note that this values corresponds with bullet (4) in the above list

Note that unless your problem is strictly 'convex' (check convex optimisation on Wikipedia), there is no known method which 'guarantees' a solution

I have no idea why the values in the result vector  (bullet (3) in the above list) *seem* to be 'decreasing' - this *might* be some artefact of the algorithms used by DirectSearch, so I tried the same problem renaming the variables from [x₁..x₁₂] to [z₁₂..z₁], so reversing the index order, then rerunning the problem, which now returned

z[1] = 49.4929430848557
z[2] = 63.2933299441490,
z[3] = -72.3695015952656,
z[4] = 46.8034931399247,
z[5] = 58.9793236486942,
z[6] = -43.1778740546326,
z[7] = -65697.0687518207,
z[8] = -65659.5314038567,
z[9] = -65738.8898574269,
z[10] = -42548.0521958052,
z[11] = -42610.0747365823,
z[12] = -42605.7615573425

with a combined square residual of ~4000, so an average squared residual per equation of ~330, or a residual per equation of ~18. This isn't too far away from the previous attempt where the average residual was ~14.

Although the actual variable values are very different, they are now 'increasing' rather than 'decreasing'. This suggests that it is not an algorithmic artefact.

DirectSearch:-SolveEquations takes several options which may help produce a desirable solution: for example one can place constraints on the range of each of the independent variables, assuming these are known! Makes things much easier than assuming that each independent variable is 'somewhere' between -infinity and +infinity

I tried this by limiting the range of all variables to +/-1000, and obtained the following

x[1] = 999.999998426941,
x[2] = 991.475499828554,
x[3] = 931.043302424890,
x[4] = 999.999999999078,
x[5] = 927.434827264780,
x[6] = 978.104975030587,
x[7] = 3.93204710142291,
x[8] = 8.72433532116129,
x[9] = 6.35643241084421,
x[10] = 16.0089057423308,
x[11] = 16.1547018146869,
x[12] = 19.6736225514207

with a combined residual of~2.6*10^5, correspond to an 'average residual' of ~147 per equation. Compare this with the value of ~14 per equation without the constraints.

Note also that two of the above values (x[1], x[4]) are on the constraint limit, inplying that a "better" solution might be obtained if the constraint were removed

It i impossible for someone here to debug what you did "interactively". I recommend that you add to your worksheet

1. a list of assignments giving values for all parameters
2. a dsolve() command with appropriate entries for the system to be solved, the initial conditions etc

There are numerous typos in your worksheet

1. You use '.' as a multiplication for scalar quantities. '.' only represents non-commutative multiplication (eg with matrices). I think I fixed all of these
2. You have a spare 'del' symbol in the definition of f[3], which I deleted
3. You use 'sum' rather than 'add': this isn't technically an error, but you should check the help pages to see when each is appropriate
4. You define the final equations using f[n]=... I assume that you mean these to be assignments, as in f[n]:=...  - ie I'm assuming you mean ':=' rather than '='

Even with these changes Maple's inbuilt solver, ie fsolve(( [seq(f[j], j = 1 .. 12)]) fails to produce an answer.

You should appreciate that just because you have 12 equation in 12 unknowns does not mean that the unknowns can be solved for: the equations may be inconsistent.

As a final attempt I used the DirectSearch package. This is not an inbuilt Maple package, but it can be downloaded from the MapleSoft Applications centre. With a little persuasion, mainly increasing the evaluationlimit, as in

DirectSearch:-SolveEquations([seq(f[j], j = 1 .. 12)], evaluationlimit = 1000000) returned the answers

x[1] = 1.08764548236834*10^6,
x[2] = 1.08767876202963*10^6,
x[3] = 1.08761167118000*10^6,
x[4] = -8091.47233775908,
x[5] = -8019.43796225151,
x[6] = -8023.31027732841,
x[7] = -178.263952087937,
x[8] = 40.3809326327434,
x[9] = 46.4303987524650,
x[10] = 264.002108755933,
x[11] = 118.656511961104,
x[12] = 126.128305626286

although I would consider the 'residuals' rather high. Worksheet I ended up with (including results) is attached below. Note that you will not be able to re-run all of this worksheet unless you have the DirectSearch package loaded

eq12prob.mw

I have read this several times - and it is as clear as mud. There are two possibilities

1. I am dumb
2. Your explanation is inadequate

Consider the following problem: you  have a matrix A whose elements are either +1 or -1. You want a matrix B, whose entries are determined by an equation

B[i,j]:=

The only quantities allowed on the rhs of this expression are

1. any values from the matrix A (or any expressions involving them)
2. any preceding values from the matrix B (ie entries of B whose indices are less than i and less than j)

No other quantities are allowed - so don't even think about introducing them.

Either

1. This is possible - in which case do it
2. This is not possible - in which case your matrix B cannot be calculated

Pick one!

Your original code

1. Is restricted to square matrices
2. uses hardware floats
3. takes 89 secs on my machine

My original post sincMat.mw

1. handles non-square matrices
2. uses hardware floats (because I screwed up with the version I posted)
3. takes 4.46 secs on my machine

My second post sincMat2.mw

1. handles non-square matrices
2. uses Maple software floats
3. takes 4.69 secs on my machine

I focussed on the 20X speed-up.

Could I speed my solution up further - yes probably because

1. sin(x)/x is the same as sin(-x)/(-x) so I am doing twice as many of these evaluations as necessary.
2. a consequence of (1) above is that when I perform the 'elementwise row multiplications', I am doing twice as many as necessary.

However I'd have to write a reasonable amount of code to handle the book-keeping issue of odd/even numbers of rows/columns and frankly I couldn.'t be bothered! Getting the original 2000% speed-up was significant, picking up maybe another 25% or so ...... you'd have to be paying me!

Probably by realising thart the Maclaurin series for erf(x) is the Taylor series for erf(x) expanded around x=0.

The you have to look up the the Maple help for Taylor series - as in ?Taylo at the Maple prompt. Then follow instructions. Takes about 2secs to come up with an answer!

I loaded a (slightly) wrong version of my original code becuae I was checking against vv's solution and used an evalhf() command where I had intended to use evalf(). The following does not require the use of hardware floats and runs about the same time as my original post

sincMat2.mw

I tried the method of ignoring the Fourier transform part and just solving your original equation 'equ' for y(t) directly using dsolve/numeric. My difficulty with this. were the warning messages

Warning, cannot evaluate the solution further right of 2.0367764, probably a singularity
Warning, cannot evaluate the solution further left of -1.4642164, probably a singularity

So you can solve for y(t) directly between t=-1.4642164 and t=2.0367764, but outside this region.........

dsolve/numeric does not like parameters with no defined numeric values.

In your worksheet, the following are not defined

R, k, m, omega, thetal

First Option
Depends very much on what caused this file to become corrupted. But Maple produces "backup" files during each session (unless you have disabled this feature??). These backup file get deleted when your worksheet is "successfully" saved.

Always worth checking the directory where your worsheet is saved, to see if there is a file with the same name, and extension '.BAK',  '.bak', '.Bak' whatever - can't remember

If it exists ( a bit unlikely, I admit), then you can restore it from the Maple toolbar using

File -> Recent Documents -> Restore Backup

then select appropriate file.

Second Option

Upload the damaged file here (big green up-arrow). Depending on how badly damaged it is, someone here might be able to recover something

Maole's exportplot() command supports the following formats

Raster Graphics formats: GIF, JPEG, TIFF
Vector Graphics formats: BYU, DXF, COLLADA, JVX, OBJ, OFF, PLY, POV, STL, VTK, WMF

So - no FITS :-(

Best I can suggest is that you use soe kind of graphics converter. As in find a grphics package which will import one of the above and export FITS

For example, trusty ole GIMP appears to have a FITS plugin

I've been running Maple 18, 2015, and 2016 for about the last 5 yrs on a desktop with a 26" desktop monitor, using its native resolution of 2560x1440 with no real problems. Default zoom is set to 100%, all input/output font styles are set to 12pt and I have no problem with legibility - other than two cases  (see later).

The default plot size is a *little* small, legible,but small. I usually fix this (when necessary) just by clicking on the plot and grabbing/moving the corner handles. Maybe I will try Carl's suggestion of setting up a default plot size (presumably it is in pixels) using the plots:-setoptions(size) command

The two cases where I have a *real* problem are

1. when using the interatctive debugger, there seems to be no way to chnage the font sizes in the debugger window - so buttons, command-line entry, and output window are all too small, and cannot be resized. I have reported this problem to Maple, but (so far) no solution. This annoys the hell out of me, becuase it makes using the debugger extremely painful - literally, cos my eyes hurt after about 15mins
2. Code edit regions: not something I use often, because my workflow is usually to develop procedures interactively, then transfer to a decent text editor (EMACS/NotePad++ depending on my mood). Save as an 'mpl' file, then just have a stack of read statements in the worksheet to load the mpl files. If I could make the text in code edit regions more legible, I might use them more.

If you can't explain the algorithm, then I sure as hell can't code it. I have added some code to my original which performs *part* of what you might want. I am reluctant to extend this code to handle edge/corner cases until you can confirm that this is the algorithm you want. See attaxhed

matProb.mw

The mere fact that you can implement your algorithm "by inspection" means that it cannot be difficult. Try answering the following question.

You have a matrix 'A' whose entries are +1, or -1. You need to define a matrix 'B' whose entries depend on those of matrix 'A'. What is the expression for the entry B[i,j] in terms of entries in the matrix 'A'