Please give input examples along with corresponding expected/acceptable output and runtime in Matlab.

Preferably there would be at least one example that takes more than 2 seconds to run.

@Kitonum I guessed that he was asking the general question about how to call add with any conditional, and the the mod example was just for illustration purposes.

@JLange In the attachment below, GetIds is intended as a command to find the identies of embedded components of the given kind in the current worksheet.

(An obvious improvement would be to allow multiple kinds to be queried at once, for efficiency.)

Download GetECIds.mw

@vv While I don't see any nice way to get Maple to solve even the reduced 2-dimensional problem (once x3 is eliminated), for fun here are Yet More Ways to get some plots out of Maple.

Here's a quick way, using the reduced system (without floor) cited as coming from Mma. I transform a 2-d plot using the isolated formula for x3, since implicitplot3d won't find any data on right on the plane.

restart;
# using the cited solution from Mma
eqs:=(155/2 < x1 and x1 < 78 and 744/7-4*x1*(1/7) < x2 and x2 < 62 or
 72 <= x1 and x1 <= 73 and 102-4*x1*(1/7) < x2 and x2 < 62 or 73 < x1 and x1 <= 147/2 and
 102-4*x1*(1/7) < x2 and x2 <= 726/7-4*x1*(1/7) or 147/2 < x1 and x1 < 74 and 60 <= x2 and
 x2 <= 726/7-4*x1*(1/7) or 74 <= x1 and x1 < 75 and 726/7-4*x1*(1/7) < x2 and x2 < 62 or 
 153/2 < x1 and x1 < 78 and 726/7-4*x1*(1/7) < x2 and x2 < 60 or x1 = 72 and 58 <= x2 and
 x2 < 60 or 72 < x1 and x1 < 74 and 58 <= x2 and x2 <= 708/7-4*x1*(1/7) or 75 <= x1 and 
 x1 < 76 and 102-4*x1*(1/7) < x2 and x2 < 60 or x1 = 74 and 442/7 < x2 and x2 < 64 or
 74 < x1 and x1 < 75 and 738/7-4*x1*(1/7) < x2 and x2 <= 744/7-4*x1*(1/7) or 74 <= x1 and
 x1 < 75 and 708/7-4*x1*(1/7) < x2 and x2 <= 102-4*x1*(1/7) or 151/2 < x1 and x1 < 76 and
 708/7-4*x1*(1/7) < x2 and x2 < 58 or 157/2 < x1 and x1 < 80 and 762/7-4*x1*(1/7) < x2 and
 x2 < 64 or 68 <= x1 and x1 < 137/2 and 56 <= x2 and x2 <= 666/7-4*x1*(1/7) or x1 = 137/2 and
 x2 = 56 or x1 = 70 and 56 < x2 and x2 < 58 or 70 < x1 and x1 <= 71 and 56 <= x2 and x2 < 58 or
 71 < x1 and x1 < 72 and 56 <= x2 and x2 <= 690/7-4*x1*(1/7) or 70 <= x1 and x1 <= 281/4 and
 54 <= x2 and x2 < 55 or 281/4 < x1 and x1 < 72 and 54 <= x2 and x2 <= 666/7-4*x1*(1/7)):

P2d:=plots:-inequal(eqs, x1=0..100, x2=0..100, nolines,
                    view=[default,default]):
P2d;

plottools:-transform((x1,x2)->[x1,x2,1-2*x1*(1/3)-7*x2*(1/6)])(P2d):
plots:-display(%,lightmodel=none,orientation=[80,50,0]);

Working with the original system involving floor, a 2-d implicit plot can be produced using the implicitplot command. It can find the complementary set more robustly (if the ranges and grid size vary) but the resolution seems poor unless it is refined so much that it takes a while to compute. Computing the set as below is quick, but seems prone to miss portions unless the ranges/grid are "just right".

foo:={4*x1+7*x2+6*x3 = 186,
      floor((1/2)*x1)+floor((1/5)*x2)+floor((1/3)*x3) = 18, 
      floor((1/5)*x1)+floor((1/2)*x2)+floor((1/4)*x3) = 21}:

px3:=solve(4*x1+7*x2+6*x3 = 186, {x3}):
new:=remove(`=`,map(rhs-lhs,eval(foo,px3)),0):

# seems tricky to ensure that all the region is found
P2d:=plots:-implicitplot(unapply((`or`(op(map(u->u>0 or u<0,new)))),[x1,x2]),
                         50..100,50..100,grid=[151,151],gridrefine=1):
P2d;

plottools:-transform((x1,x2)->[x1,x2,1-2*x1*(1/3)-7*x2*(1/6)])(P2d):
plots:-display(%,lightmodel=none,orientation=[80,50,0]);

It's a shame that solve knows little about floor/ceil/frac.

Yes. And I've previously asked you, via both Replies and private message, to stop posting duplicates of that question.

Youve already asked the same question, more than once. People have responded with code and answers.

If you dont find the answers adequate then provide more detail in followup comments.

Providing a link to a paper, an image, and code without proper explanation isn't very helpful.

Just because nobody can figure out what exactly you want doesn't justify your spamming this forum repeatedly with duplicate Questions.

@tomleslie And now you have code that, IMO, is not significantly simpler than variants already posted by both Carl and me. There is no evalindets or subsindets, but the constants involve more typing.

Also, while the float values of the constants resolve reasonably in this example, in general there may be benefit to delaying the evalf call until later. Hence my 2nd variant in response to Carl.

You did ask what was wrong with it. So I gave my opinion.

Just because some aspects are subtle doesn't mean they are necessarily overkill.

@tomleslie One thing I consider inferior about it is that Maple will call evalf and simplify each and every time your procedure En will get used.

A central part of my and Carl's commentary is about how the units can be simplied, just once, in advance of even creating the procedure.

But it's worthwhile that you mention calling Constant(...,units), if only for completeness. 

Who deleted the original full question and attachment? That is so very unhelpful and rude.

Perhaps the GUI's context-menu driven Matrix/Array/rtable browser cannot handle 500000 columns of data.

You have floating-point 2-dimensional data, yes? In a float[8] rtable, I hope.

How about using the ImageTools package to scale that down to a manageable pixel-width (number of columns).

@Carl Love I find using the ScientificConstants package is awkward at best, for anything other than the most simplistic usage of immediately calling GetValue and GetConstant on all the Constant calls separately, at the start, and assigning the results to some names for use in the worksheet.

But if one wants to leave the Constant calls in, while doing further symbolic manipulation which could result in simplifications, etc, I find it hard going. I don't understand why there isn't any single command that can replace a Constant call by its numeric value (or its derived formula) multiplied by its units. I don't think any new user is going to enjoy being shown something like,

   evalindets(expr, specfunc(Constant), GetValue*GetUnit)

or even this (whose result works nicer with evalf, though really it doubles up the units concept in context),

   evalindets(expr, specfunc(Constant), u->u*GetUnit(u))

Having to use evalindets (or subsindets) at all seems like a tough introduction. Why couldn't GetValue (or GetValue alongside GetUnit) map across an expression or formula containing several Constant calls?

@samen I'm not really sure what you're trying to do.

My guess is that you have some exact formula, and that you'd like to plot the difference between that and the Matrix produced by calling your p procedure at a given value.

If that's right, then one way is to generate a Matrix where the values of the Matrx at indices (i,j) represent the value of the exact formula. I'm assuming that your original values for a and b are supposed to be the end-points of the range for t the variable in the exact formula. (You haven't given an indication of what the second dimension in the plot is supposed to represent. I treat it as a dummy.) 

error_plot_acer.mw

It would be really helpful if, in future, you could explain in much more detail what you're trying to do. It may be obvious to you, but it isn't to me.

@Carl Love Good eye. I did not pay attention to the particular values of the constants.

While your mechanism above is elegant, please forgive me if I offer a slight revision -- both to walk the member through some of the ScientificConstants usage, as well as provide a version that allows combining the constants' values at higher Digits.

(Even more involved would be to use ScientificErrorAnalysis for combining values and errors.)

Download SC.mw

Does not the .mw file attachment in this question (posted by member enigm50) contain only the null character? If so then there's no hope of recovering anything from that file.

To the member eggoodaire, if you have a partially corrupted .mw file with something in it then please attach it here, and we could investigate what other content might be recovered from it.

@countzero You are missing the point. The reason that 2*x+2*y doesn't appear to factor is that the Maple kernel automatically simplifies 2*(x+y) back to the original.

Note the unevaluation quotes cannot be used to delay evaluation and prevent this automatic simplification.

'2 * (a + b)';        

                       2 a + 2 b

See section 3.4 of the Programming Guide (and other parts of Chapter 3), for some discussion of that.

Your second example has the additional common factors a and b, which prevents the automatic simplification.

factor( 2*a*b*m[1]+4*a*b*m[2] );

                  2 a b (m[1] + 2 m[2])

Supplying a third optional argument for the content command won't help with the original example (and it's not what allows you to exclude use of ``() here).

content( 2*m[1] + 4*m[2], [m[1], m[2]], 'pp' ) * pp;

                    2 m[1] + 4 m[2]

Here's a bit more on ways to display your example without automatic simplification, and ways to "undo" the effect.

Download auto.mw

You asked two "Finally" questions above. Some comments:

1) The following different behaviour from active sum makes me suspect that I cannot easily modify the CDF procedure (on the fly) to recover the old behavior just from issuing CDF(X,s) . The cause of the bug appears to reside somewhere below sum.

restart;

kernelopts(version);

  Maple 2018.1, X86 64 LINUX, Jun 8 2018, Build ID 1321769

sum(binomial(3,i)*(1/2)^i*(1/2)^(3-i), i = 0 .. floor(s));

                               1

while,

restart;

kernelopts(version);

  Maple 2015.2, X86 64 LINUX, Dec 20 2015, Build ID 1097895

sum(binomial(3,i)*(1/2)^i*(1/2)^(3-i), i = 0 .. floor(s));

        floor(s)                              
         -----
          \                       i    (3 - i)
           )                   /1\  /1\       
          /     binomial(3, i) |-|  |-|       
         -----                 \2/  \2/       
         i = 0

The following quirk/idiosyncrasy of sum allows the piecewise inert Sum form returned by CDF(X, s, inert) to not get hit by the same bug, when I apply value to the inert Sum. This explains why the workaround in my Answer doesn't encounter the bug.

Download sum_pw.mw

2) Yes, the behavior from CDF(X,s) that we've discussed is surely a bug in Maple 2018.