kernelopts(version);
         Maple 9.51, IBM INTEL LINUX, Aug 9 2004 Build ID 163356

eliminate({x[5] = x[2] / x[1], x[6] = x[3] / x[2], x[7] = x[1] / x[4],
           x[8] = (2 * x[2] + x[4]) / (2 * x[1] + x[3] + x[4])},
           {x[1], x[2], x[3], x[4], x[8]}):

lprint(%);
[{x[1] = x[7]*x[4], x[8] = (2*x[5]*x[7]+1)/(2*x[7]+x[6]*x[5]*x[7]+1),
  x[2] = x[5]*x[7]*x[4], x[3] = x[6]*x[5]*x[7]*x[4], x[4] = x[4]}, {}]

Between version 9.5.1 and 10.00 the procedure `eliminate/recursive` changed quite a bit.

kernelopts(version);
         Maple 10.00, X86 64 LINUX, May 13 2005 Build ID 190196

eliminate({x[5] = x[2] / x[1], x[6] = x[3] / x[2], x[7] = x[1] / x[4],
           x[8] = (2 * x[2] + x[4]) / (2 * x[1] + x[3] + x[4])},
           {x[1], x[2], x[3], x[4], x[8]});
                           NULL

kernelopts(version);
         Maple 2017.3, X86 64 LINUX, Sep 27 2017, Build ID 1265877

solve({x[5] = x[2] / x[1], x[6] = x[3] / x[2], x[7] = x[1] / x[4],
       x[8] = (2 * x[2] + x[4]) / (2 * x[1] + x[3] + x[4])},
       {x[1], x[2], x[3], x[4], x[8]}):

lprint(%);
{x[1] = x[7]*x[4], x[2] = x[5]*x[7]*x[4], x[3] = x[6]*x[5]*x[7]*x[4],
 x[4] = x[4], x[8] = (2*x[5]*x[7]+1)/(x[5]*x[6]*x[7]+2*x[7]+1)}

The last time that it calls itself on that example in Maple 2017.3, `eliminate/recursive` is passing the empty list {} as the first argument. Perhaps it ought to be doing some additional/modified check before doing that?  I have not studied it recently.

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

You could either convert those inequalities to RealRange (using the convert command).

Or you could call solve without the braces around the second argument. For example,

Download RealRange_solved.mw

I believe that the parametrizing approach that vv has shown is very likely best, for simplicity and overall quality.

But for fun I'll show that another approach, using the range functionality of the usual cartesian parameters.

It's key to note that the surfaces in question can be split up into (at least two) pieces, where each is the plotted surface of a function. I mean function in the usual mathematical sense, where each (x,y) point produces just one z-value. Hence instead of using implicitplot3d and we can just stitch together those various pieces.

I'm going to split each of the sphere and the ellipse into four such pieces. I'm pretty sure that it could be done in just two (using conditionals, or piecewise, or min/max calls in the ranges) but maybe not worth the extra effort.

One of the downsides to having to stitch together various pieces is that often either the seam shows (slightly darker due to miniscule overlap) or very tiny pinhole gaps show under manual rotation. Even the parametric approach shows a slight seam. But here -- with the radicals that come from solving these conics for particular valiables -- any slight amount of numeric error can lead to these effects being noticably worse.

The reason both the parametric and this approach work is that they both generate MESH plotting structures where the (x,y) data points can be arbitrary and irregular. And so they can follow 3d surface edge, smoothly. In contrast the regularly spaced GRID plotting structure can display with ragged edges and gaps where some evenly spaced (x,y) vertex fails to produce a real z-value (because the value there is undefined or imaginary).

Anyway, without much clean-up, and a few small numeric adjustments to keep the radicals behaved: Intersecting_surfaces_a3.mw

I've seen a few requests like this.

A similar weakness appears in the plots:-matrixplot command (when creating surfaces, not using its histogram features), but the alternative in that case is to use plots:-surfdata which allows you to specify the ranges over which to interpret the data. There is no easy alternative for plots:-listcontplot that I'm aware of.

But you can use the plottools:-transform command to rescale. It's a little work to create the transformer, but once you see the construction of trans below you'll see the idea, which is not complicated and straightforward to modify for other examples.

I also have a modified listcontplot which does this automatically. It also allows for interpolated refinement  of the data. I might dig that up.

listcontplot_ranges.mw

You seem to be trying to configure the Maple 2017 Compiler to use a particular version of MSVC++ on Windows 64.

But why? Maple 2017 for 64bit Windows ships with its own bundled C compiler, utilized by its Compiler:-Compile command. (Since Maple 2015 all the 64bit Maple platforms have shipped with it.)

That stock un-reconfigured Compiler:-Compile doesn't complain when applied to your MinVal procedure. Do you have some reason to think that it's not working properly?

Are you sure that your code would run properly even without compiling MinVal? When I try the code (without compiling MinVal) I get an error from Iterator:-SetPartitions that seems unrelated.

Download usedot_tau.mw

Did you accidentally type a space between rod and [i,j] ?

It looks like you might also have accidentally typed extra spaces in several other places, such as between letters in simplify, and right after subs, and so on.

In default 2D Input mode Maple interprets those spaces as meaning multiplication.

Also, you need to call the simplify command with round brackets, as a function call (and not just insert a space).

@Markiyan Hirnyk 

restart;
M:=n->Matrix(n,  (i, j) -> binomial(a*i+b*j, j) ):

seq(print(coeffs(expand(numer(simplify(convert(LinearAlgebra:-Determinant(M(n)),factorial)))),[a,b])),n=1..6);

                          1, 1
                         2, 3, 1
                       6, 11, 6, 1
                    24, 50, 35, 10, 1
                 120, 274, 225, 85, 15, 1
            720, 1764, 1624, 735, 175, 21, 1

seq(print(seq(Stirling1(j,i),i=1..j)),j=2..7);

                          -1, 1
                         2, -3, 1
                      -6, 11, -6, 1
                   24, -50, 35, -10, 1
              -120, 274, -225, 85, -15, 1
          720, -1764, 1624, -735, 175, -21, 1

That OEIS sequence represents the concatenation of rows of a "triangle" of the Stirling1(i,j) numbers. That's why I wrote above of offsetting into the triangular collection in the OEIS sequence (because that can get one the sequence of Stirling(i,j) for a fixed `i`.)

lprint([seq(seq(Stirling1(i,j),j=0..i),i=0..9)]);

[1, 0, 1, 0, -1, 1, 0, 2, -3, 1, 0, -6, 11, -6, 1, 0, 24, -50, 35, -10,
 1, 0, -120, 274, -225, 85, -15, 1, 0, 720, -1764, 1624, -735, 175, -21,
 1, 0, -5040, 13068, -13132, 6769, -1960, 322, -28, 1, 0, 40320, -109584,
 118124, -67284, 22449, -4536, 546, -36, 1]

It is not difficult to find a formula using Stirling1(i,j) which matches the determinants M(i), including the powers of a and b and the signs and the factorial in the denominator. I did it at home this morning (soon after you posted this), but if you need me to give it in full it'd have to wait until when I get home again.

But such a formula is no proof of its correctness. Perhaps it may give someone inspiration (for the proof of that formula, not that formula itself).

[edited] Here is the unproven formula I arrived before, as a sum of n+1 terms involving Stirling1 calls. It takes a while to compute S(7) and higher.

Download Det_Stirling1.mw

[edited] And for anyone curious about using the coefficients to query the OEIS package (available from the maplecloud for installation directly from within Maple 2017, or installable directly from within Maple 2017 itself using the cloud tab): OEIS.mw

You can set the use of piticks and decimalticks without having to construct all the tickmarks explicitly.

pi_decimal.mw

Those warnings are emitted by the Maple interface (whether it is the cmaple commandline interface or the Standard Java GUI), and not by the Maple kernel (computational engine).

If you don't want to see such parser warnings (while still seeing kernel and Library warnings) you can set,

interface(warnlevel=2):

I'm not sure what else to say. The commandline interface (aka CLI or TTY interface) and the Java GUI have their own separate parsing mechanisms, with a few differences.

One example of such differences includes that business you mentioned in your previous thread about trailing backslash as a continuation character. That was historically there to support the CLI and the plaintext `read`. In the GUI you can insert an additional line of code using Shift-Enter, without triggering execution of the line with just Enter. But in the CLI and text-based `read` that doesn't make physical sense. So in order to allow multiple line input (without typing just Enter and triggering execution) the CLI and test-based `read` support the trailing backslash as an indicator of statement continuation.

This warning you cite here is another difference in the interfaces.

You've already bothered to escape the backslash, with your posted version using "\\".

Now be consistent and handle the newline the same way, as an escape sequence. (...and similarly for the tab, if you want)

There's no need to use an extra blank space (which you might need to subsequently erase or deal with) at the end of a line which might otherwise end with a backslash (which Maple treats as a line continuation marker).

process_file := proc()
local str;

str:="\n\t\\begin{align*}\n\tA =& B \\\\\n\t=& 3\n\t\\end{align*}\n ";

FileTools[Text][WriteString]("output.txt", str);
FileTools[Text][Close]("output.txt");

end proc:

Also, if it helps you keep things more understandable (say, when dealing with longer strings), you can break it up by formatting it as follows. Here I'll also add in a few spaces you had originally, to indent like your original (though of course you could also replace all escaped tabs with spaces if you prefer that.)

process_file := proc()
local str;
  
str:="\n"
     "\t\\begin{align*}\n"
     "\t  A =& B \\\\\n"
     "\t    =& 3\n"
     "\t\\end{align*}\n ";

FileTools[Text][WriteString]("output.txt", str);
FileTools[Text][Close]("output.txt");

end proc:

And if you are building up the rhs of the assignment statement (for str) programmatically you could use the cat command on a comma-separated sequence of substrings.

This is much cruder than _Maxim_'s suggestion, but happens to work here.

restart;

eu := -2*n^2*B^2+2*n*B^2*p-2*n*B^2*p^2+n*B^2-B^2*p+B^2*p^3+n*c*d:                          

algsubs(p^2=freeze(p^2-p+n)+p-n,
        expand(algsubs(p^3=freeze(p^3-p+n)+p-n,
                       expand(eu))));

                       2                2
                   -2 B  n freeze/R0 + B  freeze/R1 + c d n

collect(%,[freeze(p^2-p+n),freeze(p^3-p+n)]);

                       2                2
                   -2 B  n freeze/R0 + B  freeze/R1 + c d n

thaw(%);

                       2   2             2   3
                 -2 n B  (p  + n - p) + B  (p  + n - p) + n c d

Some of those apparent numbers in the input Matrix are not really numbers. But rather, they are just names that just look like the numbers, and so do not resolve mathematically. Some of the apparent zeroes in the input Matrix are lime that.

I've seen others have the same problem when using the Matrix palette, in particular with Maple 2017.

I suggest you manually delete the entries in the Matrix input, and then re-enter them.

Or use the `<<..>>` or Matrix commands instead of the palette to enter your Matrices. 

I don't really understand what rule you might be thinking of, for including terms like z^w .

But is this the kind of thing you mean? (It is not guaranteed to always produce "difference parametric coefficients", but most of the time it does.)

Download param_poly.mw