@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.

@sand15 

I did not intend the version in my first Reply as any kind of workaround. I added it because it shine a dim light on what might be going wrong internally. (Anyone who really wants to diagnose exactly how it goes wrong can enjoy debugging the object-oriented Statistics package here.) This happens to be what I tried first, while looking at the bug you've shown.

In the case that N is unassigned, both the effect of assumptions about s on the CDF result as well as the introduction of Psi calls, seem to hint that there may be some symbolic summation going on. That lead me to want to try controlling the summation manually.

Contrary to what you've writtten above, the inert option to the CDF command is documented. Supplying that option to CDF, with N unassigned, returned an inert Sum call that looked much better.

So then I applied the value command to that to see whether that would go amok, doing symbolic summation, but all that happened was the Sum became an unevaluated active sum call. This hints that CDF must be going about it somewhat differently.

Apart from the explicit value of 1 for s>3 I don't see why the Maple 2015 symbolic result is significantly better. I'd be interested in hearing why you think it might be so. (The extra value of 1 for the condition s>3 could be added programmatically, if one really needed it for visual insight.)  The expression I obtained does evaluate to 1 for s>3. I gave this as the result in my Answer.

There is often a distinction between doing the CDF computation symbolically for the purpose of further symbolic computation, and doing it for the purpose of getting insight from nature of the exact formula. If you think that a result such as vv showed is incorrect then it would help if you were more clear about which of those ways you found it lacking (I guess it is the second).

@Carl Love For a variety of situations the GUI holds a semantic "parsed meaning" of 2D Input. The need for that is somewhat related to the specifics of interoperability and communication between the kernel and the interface.

My main reason for not using 2D Input mode has always been that it is not WYSIWYH (What You See Is What You Have).

More specifically, there are many ways in which distinct statements and expressions get displayed the same, and there is no reliable/foolproof and easy way for me to ascertain the parsed meaning exactly.

Not pretty.

Download uglierbinomialcdf.mw

@Simwar That's a bug in the parsing of 2D Input.

In your 2D Input example the x appearing in the operator n->n>=x is being mis-parsed as the global name rather than a lexical (which should scope to the first parameter when run).

If you don't want to utilize a Code Edit Region, but wish to avoid the above 2D Input bug, then you can enter the definition of the procedure in an Execution Group, in 1D Maple Notation (plain text).

Download satisfies_scoping.mw

I have submitted a bug report.

See here which would be a suitable place for him to ask his question yet again. Also see here and here.

This member has a habit of re-posting essentially the same code and not explaining what he wants to get from it.

@Markiyan Hirnyk Yes, it is true that the documentation of the solve command is significantly behind its actual capabilities. But what I showed works too, and not just by chance as can be confirmed by thorough examination of the source.

The real option can quite often also (but not always, naturally) be used to good effect for a univariate trigonometric equation, sometimes when combined with the explicit and the allsolutions options. It is a good addition to one's arsenal for handling some classes of problem.

Here are two other ways to handle this particular example.

Download realsolvemore.mw

I consider RealDomain:-solve to be an approach which is in general weaker than the conglomeration of other approaches using :-solve (but not always -- there are exceptions to everything), because its implementation and fundamental design are not strong.

Perhaps the most important thing to note is that there is currently no command which can handle all the examples of exact symbolic real-solving currently handled by at least one method.