The procedure LineOnSphere() requires the addition of the command 'uses LinearAlgebra', (and maybe plots) as in

LineOnSphere := proc (A1::(Vector[column](3)), A2::(Vector[column](3)), R)
                                        uses LinearAlgebra, plots;
                                        local a, b, t;
                                        a := Normalize(A1, 2);
                                        b := Normalize(A2, 2);
                                        spacecurve(R*Normalize(a+t*(b-a), 2), t = 0 .. 1, thickness = 1, color = black)
                              end proc

Any time you have a procedure which calls commands from a package it is good practice to have a 'uses' statement within the procedure.

maple( 'd:=3; g:=1; fsolve(d*x^2-g)' )

works

I'm pretty sure that with setmaple(), you have to issue this command for each variable that requires 'setting' in Maple - I could be wrong, but then I find driving Maple from Matlab a bit of a black art!

I can come up with a couple of solutions for your original problem.

Both

maple( 'a:=10; fsolve(a*x^2-1)')

and

maple('fsolve', 'eval( a*x^2-1, a=10)')

work for me

After a little checking it seems as if the context menu->Insert Row option appeared in Maple 2016 - so I assume that you are using an earlier version?

I can't find any "menu-based" way in Maple 2015 (for example) to add extra piecewise conditions when you are using the combination of 2D-math and expression palettes. Hence possible solutions are

1. Type the command, as in "piecewise( x<1, f(x), x<2, g(x), x<3, h(x))" using either 1D or 2D input modes
2. Upgrade to Maple 2016 (or a leter version)

So far as I can tell, the polyhedralSets package was introduced in Maple 2015.

It is therefore available in this, and all subsequent, releases, ie

Maple 2015

Maple 2016

Maple 2017

Currently, Maple 2017 is the latest version

If you want to render spaces as insignificant, then switch to using Maple's 1D input mode. This is a more familiar environment for those with a programmimg background. You will,  of course, then find that the "sematic analyser used in modern computer languages" requires a specific token/symbol to represent the mathematical operation of multiplication

I am not a "software architect" before I retired, I designed hardware for a living.

However I do understand that some people at Maple had to decide how to resolve the ambiguity between function application and multiplication, which is inevitable in expressions such as a(x+1). Your view seems to be that this syntax should always represent multiplication. That would be absolutely fine with me. However, out of idle curiosity, what syntax would you then define for function application?

The PolyhedralSets package was introduced in Maple 2015, the major release right after Maple 18.

None of Maple's system architect are/were "confused"

No-one responding here to your queries is/or has been in the slightest "confused"

In fact only one person seems to suffering from confusion (or its aftereffects)

Maybe you should think about that?

On the other hand if you believe "I am right and the rest of the world is wrong", then you may want to contemplate DA

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

delta2 values are not fixed.

My code defines the horizontal range of the plot as being from delta2=0.02 to delta2=0.1 - just like the x-axis range of the figure in your original post

If I were to write the expression a(x+1) - what do you think I mean?? Be careful, because even I (as the author) know that it is ambiguous

Do you interpret this as the function a() supplied with the argument x+1, or is it the symbol 'a' multiplied by x+1. There is simply no way to tell: either interpretation is 'valid' and humans will generally pick the appropriate interpretation, based on context. However such context-based interpretation is not available to computer math packages. The distinction between the two possible interpretations somehow has to made 'obvious'.

Maple achieves this distinction in different ways depending on whether you decide to use 1D input or 2D input.

In 1D input, the simple product requires the user to type a*(x+1), and the function application requires a(x+1)

In 2D input, the  simple product requires the user to type a (x+1) and the function application requires a(x+1)

Note that whichever input mode is applied, the user is required to enter expressions in such a way that the inherent ambiguity is removed

Strangely enough, I am aware of the limitations of the numpoints option, including whether their spacing is adaptive or not. But as a quick, dirty solution........?

of the 'symbolic' option are described in the help pages.

For this example they (more-or less) correspond to those you are specifying with your 'assuming'  condition.

I'm not sure if this is the reason for our different results, but I'm running 64-bit WIndows 7, not 64-bit Windows 10

otherwise you just add to the confusiion. Your statement

This seems to be a bug for win64-bit, because a Linux and Mac software solves the problem. The NLPSolve can solve the problem on my setup without any problems which is odd because the problem isnt Non-linear. 

is completely incorrect.

My original post, and all of my subsequent posts correctly solve the problem on 64-bit Windows (as it happen WIndows 7), using LPSolve(). These correct solutions are obtained for Maple 18.02, Maple2015.2, Maple2016.2 and Maple 2017.3.

So with this OS and these Maple versions - exactly what doesn't work!!!!! THINK CAREFULLY before responding

see the attached

binPack2.mw

The problem with reconciling the definition of the fourth set of constraints, and the reported equations which "arise" from this definition is much more difficult. We seem to agree that the definition and the "resultant" equations are incompatible - so which is "correct"?

Implementation of any particular algorithm within Maple is relatively trivial - but if you cannot determine what the algorithm is, then Maple isn't going to help very much. Can only suggest that you perform a "deep dive" into this problem in order to understand/generate a valid algorithm, rather than (blindly) using one which is obviously inconsistent.