@Lali_miani If you are still using Maple 12 (like many of your previous Questions) then you can do it as follows.

(The elementwise operator `~` did not work in Maple 12. But it is not necessary to use that -- or even to map -- since expressions are taken by solve as equal to zero by default.)

restart;
kernelopts(version);

    Maple 12.02, X86 64 LINUX, Dec 10 2008 Build ID 377066

P:=x->x^4+x^3+a*x^2+sqrt(2)*x+b:

evalc([Re,Im](P(1+I)));

                   1/2           1/2
            [-6 + 2    + b, 2 + 2    + 2 a]

solve(%);

                        1/2
                       2              1/2
             {a = -1 - ----, b = 6 - 2   }
                        2

eval(P(x),%);

                /      1/2\
       4    3   |     2   |  2    1/2          1/2
      x  + x  + |-1 - ----| x  + 2    x + 6 - 2
                \      2  /

solve(%);

                                     1/2                        1/2
 1 + I, 1 - I, -3/2 - 1/2 I + 1/2 I 2   , -3/2 + 1/2 I - 1/2 I 2

There is no attachment.

@John Blacksad While these are even more ways (including using commands explictly), you could also get the characteristic matrix or the eigenvalues more directly. (I don't know whether you were doing an assignment question that required you do each step.)

Download maple_ac2.mw

And here are some ways, using commands explicitly,

Download mapleac3.mw

@Kitonum But my points were not about how the timing mechanism itself was used, and I don't see how you last comment contradicts any of them.

If you're going to identify numerically computed roots then Roots(...,numeric) isn't much worse of a choice than Analytic(...), and for the example you gave it is slightly faster unless you give one a leg up advantage by adjusting working precision in an ad hoc manner. It doesn't make so much sense to compare against Roots as symbolic solver.

Yes, there are indeed cases in which symbolic Roots(...) "goes away" while attempting to verify symbolically, as you showed. That is the give-and-take between it and symbolic solve. The latter has the problem that it can sometimes miss roots, or (more often) deliver some symbolic results which are not actually roots. We'd all love it is the trig engine within solve were able to compute roots: without need for verification, not miss any, and not return non-roots. It seems difficult.

Verification via shake is a partial solution, but a little tricky to do "right".

@Kitonum Your timings are not well done, to the point of being invalid, for several reasons.

1) You didn't include the time cost for identify.
2) The choice of working precision in evalf[12] is ad hoc and problem dependent.
3) If you're going to compare, then compare numeric techniques (or at least the same kind of computation).

More fair and sensible might be,

restart;
Eq:=sin(x)=simplify(convert(sin(Pi/60),radical)):
CodeTools:-Usage(identify(Student:-Calculus1:-Roots(Eq, x=3*Pi/2..5*Pi,numeric)));
memory used=58.85MiB, alloc change=4.00MiB, cpu time=660.00ms, real time=661.00ms, gc time=71.72ms
                [121     179     241     299   ]
                [--- Pi, --- Pi, --- Pi, --- Pi]
                [60      60      60      60    ]
restart;
Eq:=sin(x)=simplify(convert(sin(Pi/60),radical)):
CodeTools:-Usage(identify(evalf([RootFinding:-Analytic(Eq, re=3*Pi/2..5*Pi, im=-1..1)])));
memory used=68.42MiB, alloc change=72.00MiB, cpu time=833.00ms, real time=778.00ms, gc time=147.56ms
                [179     299     241     121   ]
                [--- Pi, --- Pi, --- Pi, --- Pi]
                [60      60      60      60    ]

The Analytic approach does not seem to beat out the numeric Roots approach in terms of performance. There is some variation according to the choices of working precision, but that is ad hoc and makes the comparison pretty pointless unless there is a programmatic scheme for determining that precision.

Moreover, for more general problems there may be additional complex roots which have to be accomodated (either by figuring out a suitable complex band, or sieving out, etc), which adds overhead.

Lastly, the whole approach of using identify is highly suspect unless one also verifies the results symbolically -- which involves additional overhead.

@Christopher2222 As far as I can tell you are just flailing about, trying wrong combinations at random.

Double forward slashes make no sense whatsoever, except it reveals that you don't understand the effect of double backslashes.

Redirecting stderr may work in the CLI's ssystem, but not the GUI's. So trying that in a direct ssystem call may well not be the answer, as mentioned. You seem to have tried the opposite, and it seems weird that you did so. Doing it (properly) a shell script might do better here, but you have to know how to pass arguments properly.

Either disable ffmpeg logging using a low logging level option, or log to a file, as suggested. You seem to have tried the opposite, and it seems weird that you did so.

I cannot tell how you tried to specify an output, since you didn't show explicitly.

I suggest that if you cannot get a simple example to work then you might not be a suitable individual for trying to cobble together a package for accessing ffmpeg from escaped shell commands.

@Adam Ledger Your last attachment is hardly (if at all) more useful than what came before.

It doesn't contain the data except as marked-up 2D Input, which is no better than the 2D Output on which I previously commented. And there is no attached data file (even zipped).

And you've omitted the portion of the data that contains the DataFields, which is what your piecewise conditional references! So, yet again, you have not provided anything to reproduce the problem or re-run the example.

You've posted nine separate messages in this thread and -- despite several requests -- given us little to work with concretely. Good luck.

@Christopher2222 

So far what you're describing is not a path or environment issue, and neither is it a problem with need for extra quoting of filenames.

The ssystem in the GUI is different from that in the GUI. Yet, if I call ffmpeg from the ssystem in the GUI then (even without any stderr redirection) I can get it to work.

It helps to use a sensible example. If I pass a suitable value for ffmpeg's loglevel option, and specify an output target, then it works ok for me so far. I had to read and understand parts of the ffmpeg manual.

As someone else mentioned, passing arguments to a shell script (in which there is additonal control to manage ssystem quirks, stderr, etc) looks like a decent idea. Logging to a file -- even temporarily -- might also make a few aspects more manageable.

@dharr Well, Code Edit Regions behave differently, eg. navigation and evaluation work differently.

So switching to CERs may not be acceptable to all, as a means of getting good visual cues on code editing.

I find that working fast and efficiently, with multiple execution groups, using keyboard only, is *much* more difficult with CERs instead.

@Adam Ledger If the extension you need isn't allowed explicitly then... notice that .zip is allowed.

You can zip anything else, no?

@Adam Ledger And the final results shown are different, in your last uploaded Document. Some instances involving "VAGRANTASP\\Adam" in the previous Document's output are no longer there.

But we cannot tell for sure what different effect has been made, because you still haven't bothered to upload a data file that contains a representative example that reproduces the problem.

@Carl Love Use of those mixes of options to solve -- as well as a further real option, which also sometimes has effects that are not documented -- is one of the things that Calculus1:-Roots tries internally (using environment variables to control those options).

But Calculus1:-Roots also does more, including some checks that solutions are valid. In the recent past some version's solve would sometimes emit too many results, some of which weren't actual solutions. The trig case was one of the offenders. It still happens now and then when using solve and trig equations, though less often.

In addition, the call to solve which you've given does not work for this particular example in Maple 2018 and earlier. But this example works using Calculus1:-Roots at least as far back as Maple 11.

This is why I consider Calculus1:-Roots to be still the best choice for this particular class of problem (univariate, trig involved, real root required, and not too complicated). I have examples where it still does better than solve, even with the user trying all the special options combinations. I have less examples of the opposite. (I've looked at many examples.)

I agree that RealDomain:-solve is often not the best choice. It tries to "solve over the reals", in a sometimes stricter sense than merely restricting final results to the reals. That's not so tenable or practical in Maple.

@Adam Ledger I am not sure that you understood my point. It seems to me that your output shows that the string in the imported data is actually "VAGRANTASP\\Adam" . It ought to be easy enough to make a few checks to see whether that is the case.

You could simply lprint the imported data (before any processing) and look.

And if it is the case, then your predicate ought to use that same string in its test. It looks like it is not doing so. It looks to me as if your original predicate is using a string that doesn't actually contain a backslash character.

I could be mistaken, as you've only shown awkward 2D Input (which is not helpful here, as it adds another layer of possible error). And you haven't bothered to upload the actual data, so we only get to see the pretty-printed output.

@Zeineb I already knew some ways to demonstrate that it's true, thanks. I was simply suggesting that you could consider it, if you were wary that I'd taken off the sqrt on this example.

It wasn't clear whether you wanted a programmatic means.

@zjervoj97 So, why didn't you supply those ranges as arguments to fsolve?

My Answer's last example already showed how you could supply a complex box as domain, and supplying real ranges is done similarly and even more easily. All you had to do was type in the ranges that you knew.

You didn't mention the restriction when you originally asked the question here.