Suggestions

1. If you want anyone to work on this, post your data in plaintext - something I can cut and paste, because I am not going to retype from your 'picture'
2. Just from reading your code, I'd use add() rather than sum() in the definition of 'fungsikerugian'
3. The error message you report indicates that during the optimisation process Maple was unable to evaluate something using 'hardware floats'. Could be that something, somewhere is undefined: this would be fairly easy to detect if I could execute your code - see(1) above. Could also be that the function is returning something which is outside the range of hardware floats (roughly +/-10^307). One can force the use of 'software floats' in the optimisation process to remove this restriction. But it is usualy best to work out why the hfloat(undefined) error is appearing

    

The following is a list of the meaningless/irrelevant/useless stuff in your worksheet. There is so much of this crap that I cannot evan figure out what you are trying to achieve. I can't fix this, but I can point out the stuff which makes my eyes bleed - most of this you are going to have to fix

1. You define the variable 'f' as the constant value 10⁷ but you then use expressions such as f(1.0), f(2.0), f(5.0), f(10.0), evalf(f(1)), evalf(f(2)), evalf(f(5)), evalf(f(10)) - absolutely all of these are going to evaluate to 10⁷ which probably(?) isn't what you want.
2. You define the variable 'G' as the constant 600, but 'G' is never used anywhere in this worksheet - so why does this definition exist?
3. You define the variable 'pi' as 3.14, but 'pi' is never used anywhere in this worksheet - so why does this definition exist. In addition, if you are referring to the ratio of circumference to diameter, then Maple has an in-built constant for this (accessed as 'Pi').
4. You define the function m() - this is never used anywhere, so why does this definition exist? Even if you mean to use this function somewhere, I think it's definition is "doubtful". Since 'm()' contains 'theta', 'theta' depends on the variable 't', and there are two occurrences of the variable 't' in the definition of m(), which will be handled differently. One of these is as an integration variable, so no explicit value is required. However the other use is 'outside' the integration, so 't' here is an 'unknown' variable. Hence m(x), for a numeric value of 'x', will return an expression containing the unlnown variable 't' - but that is what you want, right?

If you want to get anywhere, yo will have to state your problem much more clearly!!!!

Your code

p := x^4-17001090662707204*x^2+4;
select(u -> is(u>0), [solve(p,explicit)]);
map(evalf, %);

returns

[46099201*sqrt(2)-37639840*sqrt(3), 46099201*sqrt(2)+37639840*sqrt(3)]
[-0.3e-1, 1.303882305*10^8]

In other words, Maple returns exact solutions, but one of the returned solutions is negative - exactly the condition the OP was trying to avoid. Reading/assessing your code, I cannot work out why a negative answer is returned, because it shouldn't happen!!!! - in fact this bothers me so much I think it may be a Maple "bug" - keep reading for one other place where it occurs

When I use Carl's "slick" method

select(type, allvalues~([solve(p)]), positive &under evalf);
map(evalf, %);

it returns

[-46099201*sqrt(2)+37639840*sqrt(3), 46099201*sqrt(2)+37639840*sqrt(3)]
[0.3e-1, 1.303882305*10^8]

ie 'exact' solutions and none are negative - looks absolutely fine to me

The method I proposed, ie

solve({p, x>0});

returns

{x = RootOf(_Z^4-17001090662707204*_Z^2+4, 0. .. 0.625e-1)}, {x = 1.303882305*10^8}

So I get  RootOf() and a float. Note that the RootOf() comes with a range. Now I have never paid too much attention to the case where RootOf () contains a range, but I guess I would assume it is a method of 'isolating' a solution to fulfil other conditions - ie in this case x>0?? Seems as if I am wrong

 If I add the 'explicit' option to my original suggestion, then I can get rid of the RootOf() - but

solve({p, x>0}, explicit);
seq(evalf(rhs(j[])), j in %)

returns

{x = 46099201*sqrt(2)-37639840*sqrt(3)}, {x = 1.303882305*10^8}
-0.3e-1, 1.303882305*10^8

So I (like you), get a negative solution from solve(), despite the including the inequality x>0. Noiw I have no idea why both you and I get answers which are downright wrong (a Maple bug??) and Carl gets a solution which is correct!!!

My head hurts:-(

when you mix container types of the same 'size', what is the type of the returned value. A simple test with sets and lists, shows that

[1,2,3]*~{4,5,6} returns the list [4, 10, 18]

so maybe the returned type is the same as the first argument? Errrr no, because

{4,5,6}*~[1,2,3] also returns the list [4, 10, 18]

In a similar vein, elementwise multiplication of an Array() and a Matrix() always returns an Array. Try the following

M:=Matrix([[1,-1],[-1,1]]);
A:=Array(1..2,1..2,[[2,2],[3,3]]);
M*~A;
whattype(%);# it's an Array
A*~M;
whattype(%);# it's still an Array

And if you haven't had enough 'quirkiness', consider the elementwise multiplication of a 2*2 Matrix by a 2*2 Array, wher the Array indices are not 1..2, 1..2 - as in

M:=Matrix([[1,-1],[-1,1]]);
A:=Array(-1..0,0..1,[[2,2],[3,3]]);
M*~A;

This fails with the error message

Error, dimension bounds must be the same for all container objects in an elementwise operation

So not only must the dimensions of the container objects match, but the dimension bounds must match!

So to summarise, in an elementwise operation

1. the dimensions of the container objects must match
2. the dimension bounds of the container object must match
3. in a mixed-type operation the returned data type is the 'more general' of the two argument types. (I may be wrong but I think of Matrices as  Arrays with additional restrictions, and similarly sets are lists with restrictions)

So bearing in mind (3) above, try to guess the returned type of the elementwise multiplication of a set by a row vector (or a row vector by a set)!

Extending Preben's example somewhat, and initially using lists and listlists

[-1, 1]*~[2, 2] returns [-2, 2] : as expected

[-1, 1]*~[[2, 2],[3, 3]] returns [[-2,  -2], [3, 3]]: did you expect that?

What is being performed is [ -1*[2,2], 1*[3,3]], ie the first element in the left-side "container" multiplies the corresponding element in the right-side "container" (and so on).

You appear to think that [-1, 1]*~[[2, 2],[3, 3]] should be interpreted as

[[-1, 1]*~ [2, 2], [-1, 1]*~[3, 3]] and return [[2, -2], [3, -3]]

So on the basis that an element in the left-side container is processed with the corresponding element in the right-side container, reconsider your original example. The left-side container has four entries (the matrix elements) and the right-side container has two entries (the two 2x2 matrices) - so this is never going to work!

One "interesting" case is if the left-side container is a 2*2 matrix and the right-side container is a list of four 2*2 matrices - because at first sight this "might" work - although the result "ought" to be the scalar multiplication of each of the four matrices in the right-side container, by a "corresponding" element in the left-side container. However as Preben has already noted - this doesn't work. However the Error message is informative, ie

Error, number of dimensions must be the same for all container objects in an elementwise operation

The left-side container has 2 "dimensions", because it is a 2x2 matrix. The right-side container only has 1 "dimension", because it is a 1x4 list

Since you do not specify your actual problem, I can only speak in generalities - not specificis.

LPsolve accepts a number of optional arguments. If I assume that you have a strictly integer programming problem, then you would need to include the optional argument assume=integer in the LPsolve() command (see the help page)

Constraints can be included in the LPsolve command as either a set or list (see the help page). So for your example constraints, " i not equal to j, i is not equal to 1, etc" then I would write something like { i<>j, i<>1}.

So my LPsolve() command would end up something like

LPSolve( functionIWantToMinimize, { i<>j, i<>1}, assume=integer)

Obviously, since you do not post your specific problem, I cannot guarantee that the above will work! You may have more variables. Some variables may be continuous; you may have other constraints; the function to be minimised may be non-convex;, the variable ranges may be restricted in some way etc, etc.

If you need a more precise answer, post a more precise problem - such as

1. the function you want to minimize
2. the free variables and their types ( ie integer, continuous, whatever)
3. the constraints - such as i<>j
4. allowable ranges on the variables - might be -infinity to +infinity, but if any of you variables are restricted to (say) -10..10 then this is seriously valuable info for LPSolve~(), and the odds of a successful solution will go up (a lot!)

1. Load code I can run using the big green up-arrow in the MaplePrimes toolbar
2. There is no chance that I (or anyone else here) will retype your code in order to figure out the problem
3. The possibility that someone here could figure out your problem simply by reading your code (because they can't edit/execute) is very low - and I personally wouldn't even bother trying
4. You have to help us to help you!

Well I'm running 64-bit Windows Home Premium and 64-bit Maple2016.1, and I don't see the problem.

Can only suggest that you use Thomas Richard's suggestion. I assume that this 'workaround' succeeds because (by default) routines in the Optimization package use hardware floating point arithmetic. By setting Digits=16, one essentially forces the use of Maple's software floats

I,ve just tried the example

restart;
with(Optimization);
LPSolve(-4*x-5*y, {0 <= x, 0 <= y, x+2*y <= 6, 5*x+4*y <= 20});

in Maple18, Maple2015, and Maple2016 on Win7 64-bit and obtained the answer

[-19., [x = 2.66666666666667, y = 1.66666666666667]]

in all of them.

Make sure your code begins with a 'restart' command. If that doesn't work, list exact versions for Maple and Windows

Never used these commands before, and you do not provide any executable code (just pictures - and trust me, I am not going to retype), so I have to guess. My first thought would be to comply with the requirement for the naming of configuration coordinates and their associated conjugate momenta, as specified on the help page for  hamilton_eqs() - as in (emphasis added)

Some useful conventions were adopted to represent the p's and q's. All p's and q's must appear as pn or qn where n is a positive integer, as in p1, p2, and the time dependence need not be explicit, as in pn or qn instead of pn(t) or qn(t). The Hamilton equations will be automatically returned using pn(t) or qn(t).

Now the above would be my first attempt - and I'd try quite hard to make it work. Only if this failed would I then move on to Maple's variational calculus package (see ?VariationalCalculus).

It is generally considered unhelpful when posters complain that Maple lacks certain functionality - particularly when the required functionality is readily available to anyone who can use the built-in help

The DETools package contains the commands hamilton_eqs() and generate_ic() which would seem to do exactly what you want - so I guess they would be a good starting point (assuming analytic solutions are possible!?)

The geom3d() package contains a test for collinearity of points, which is relatively trivial to add to the code posted previouly, as in

getEq:= proc( L1::listlist )
                        local expr;
                        uses geom3d:
                     #
                     # generate deom3d "points"
                     #
                        seq( point(p||j, L1[j]), j=1..3);
                        if      AreCollinear(p1,p2,p3)
                       then printf( "%a Points are Collinear\n\n", L1);
                               return
                       else
                            #
                            # Generate geom3d plane
                            #
                               plane(p, [p1,p2,p3], [x,y,z]);
                            #
                            # get plane equation, reduce common factors,
                            # and sort to required order
                            #
                               expr:=sort( primpart(lhs(Equation(p))));
                            #
                            # ensure lead coefficient of sorted plane
                            # equation is positive
                            #
                               return expr*signum(lcoeff(expr))=0;
                      fi;
             end proc:
map(getEq, L);

1. I have no idea what sub-matrix you are trying to extract, however
2. the LinearAlgebra:-SubMatrix() command will extract almost any submatrix if given the appropriate arguments

Your original code works - sort of - so what is the problem?

If I strip out all the crap which isn't actually used, and reformat to produce moderately readable code, I get the following

lensCode.mw

Now exactly what is wrong with this? - if I don't know what is wrong, I can't fix it!

The new expression has four maxima - two of which would be considered as local maxima, and two 'global'. The only method I have found whihc locates all of these is the to use the DIrectSearch package (not part of standard Maple). See the attached, which also includes Preben's suggestion (for completeness)

findmax.mw