You might as well ask how to solve int(f(x)*g(x), x= 0..16).

Your first equation is cubic in x[i+1], and your second equation is quadratic in y[i+1]. That means that there are six possibilities for [x[1], y[1], z[1]], 36 possibilities for [x[2], y[2], z[2]], etc. We need to use a selection criterion for the roots, such as using the greatest real roots for each.

@alpha041 You'll need to upload your worksheet for me to diagnose it.

@alpha041 What do you want to do if the same edge appears on both paths, but with different weights?

Your error probably arises from mixing lists and sets. If you emulated my code, then Path1 and Path2 are lists, so you can't use union on them. Simply change the code to

GraphTheory:-Graph({Path1[], Path2[]});

Let me know if that doesn't work.

@Muhammad Ali 

I don't know if it can be done with Statistics:-SurfacePlot, which crudely forms the data into a 3 x 441 GRID. If your data is to be made into a GRID, it should clearly be a 21x21 GRID. See ?plot,structure for the definitions of GRID and MESH. Statistics:-SurfacePlot is not smart enough to detect that there is a third dimension of organization hidden in your 2d data.

@Muhammad Ali 

map and seq are built-in, but zip is library code. Check out showstat(zip). So, zip(f, K, M) either uses a seq or a for loop, depending on the types of K and M.

When dealing with one container instead of two (so that zip doesn't apply), I'd use map(f, L) if the container L already exists. I'd use a seq if the container does not exist. But the difference in timing is very subtle and small, and could be influenced by a variety of other factors.

@taro 

a &* b is the same as `&*`(a,b). The quotes are necessary in the prefix form. Actually, this works for almost all infix operators, not just the neutral ones: a + b is the same as `+`(a,b).

Your code works for me, unchanged. Do you get an empty plot or nothing at all?

@Mörre Noseshine Apparently the constant N[A] uses the unit 'mole'. I don't know why that is. The system 'CGS' does not contain a unit for "amount of substance", which is the dimension whose standard unit is 'mole'. Using the AddSystem command to add 'mole' to the system 'CGS' in the way that I showed corrects the problem. Be happy for that.

The concepts of a Units environment and a Units system are othogonal. 'CGS' is not an alternative to Natural; rather, 'CGS' is an alternative to 'SI', which is the default system that is loaded for either environment Natural or environment Standard. Having a Units environment loaded tells Maple to automatically convert and cancel units upon entry. The Units system tells it what units to convert to. If I were writing it, then every system would have a unit for every fundamental dimension. Perhaps MapleSoft had a reason for not doing it that way, or perhaps it should be considered a bug.

@Mörre Noseshine I'll need to see the full code that led to the error with evalf(84000/Constant(N[A])). Are you trying to use the ScientificConstants package?

@Mörre Noseshine Wow, I guess they never added 'mole' to the 'CGS' system! Well, you'll have to add it yourself, like this:

restart:
with(Units:-Natural): #or with(Units:-Standard):
Units:-AddSystem('CGS', Units:-GetSystem('CGS'), 'mole');
Units:-UseSystem('CGS');

@rit What you have listed is the Hessian of f, which is the Jacobian of the gradient of f, as Acer said. The Hessian can be thought of as the second derivative of a function f:R^n -> R.

@lutfi Your "some weird reason" was probably that you did not include option allsolutions to solve.

@abscissa 

Yes. For example:

J1:= eval(J, [a= 1, b= 2, c= 3, d= 4, e= 5, f= 6, g= 7, h= 8, s= 9, t= 10, u= 11, v= 12]);

You may use the same command to provide numeric values for the parameters also.

@Mörre Noseshine On this site, you can vote up for Questions, Answers, and Posts, but there is no equivalent to StackExchange's ability to accept one Answer as the answer.