I have no attachment to the name Type. Indeed, I don't like that it's capitalized, but type was already taken (it being itself a type as well as a built-in procedure). I struggled to come up with a good name. I considered `` (the empty symbol).

Aha, how about eval?

@vv You begin your Answer with a discussion of whether it is interesting. To me, it is interesting if there's any hope of generalization and automation. The domain of generalization would be systems of linear equations that include floor, ceil, and frac. So, do you see any hope for it? I'm not asking you to write the algorithm, just whether you've gotten a sense that it's possible.

@ It's okay: Now that you have given your reasons, it does seem that you have excercised "due diligence" (appropriate to your education level) before concluding that Maple was wrong. And, yes, it was clear to me that you did not intend that to be a strict mathematical proof. And I wasn't criticizing it! I did say that it "does provide some evidence...", not that it doesn't provide evidence.

It turns out that all three expressions are valid solution branches. (I'll try to define that in another post.) And the pair given by Maple is a complete solution set^[1] (meaning that given any numeric (real or complex) value of k, the set's evaluation at that value will be the set of all values of x that satisfy the equation for that k). Nonetheless, given any pair of these three expressions, there are some values of k for which the two aren't equal. (The branches are cut in different places.) That is what is is tellling you. 

So, now I am concerned about your instructor: Why do they say that the solution is wrong? Someone who claims that a parameterized solution (k is the parameter in this case) is wrong should be able to provide a witness, that is, a specific numeric value of k for which the solution is wrong. Please ask them why they think it's wrong, saying that I asked you to ask. I'm willing to consider any argument, even "the format that Maple displays the result is ugly."

^[1]As long as we do the sensible thing about the k=0 divide-by-zero case, that is, return the empty set. And Maple will do this part also if you include the parametric option to solve.

What makes you say that the solutions given by Maple are wrong? As a math educator, I am just curious about your reasoning on that.

What you have labeled "Proof" does give some evidence that your proposed solution is a correct solution. But you don't show any evidence that Maple's proposed solutions are not also correct. You may substitute them into the original equation just as you did with your proposed solution. Try it.

It is true that Maple often arranges expressions in ways that are distasteful to a human reader. This seems especially common with combinations of square roots and minus signs. That alone doesn't make them wrong.

Thank you for the very useful procedure. Vote up. However, it can be massively simplified to

# Type for a variable expression, e.g. x=5.
TypeTools:-AddType('varexpr', 'And'('name','Non'('constant'))='algebraic'):

# Type for a function expression, e.g. f(x)=x^2.
TypeTools:-AddType('funcexpr', 'function'('And'('name','Non'('constant')))='algebraic'):

# Identity type (not 'identical'). Ought to be built-in!
# It saves a lot of redundancy in procedure headers!
TypeTools:-AddType('Type', type): 

# Procedure to assign variable and function expressions.
my_assign:= proc(u::{Type,list,rtable,set}({varexpr, funcexpr}), $)
   if u::'indexable' then thisproc~(u); return
   else assign(`if`(u::'varexpr', u, op(0,lhs(u))= unapply((rhs,op@lhs)(u))))
   fi
end proc: 

I believe that this is functionally equivalent to yours^[1]. Certainly, all the examples run identically. One problem I see with the lengthy code is that it makes it seem as if Maple coding is more difficult than it actually is.

Please let me know if you have any questions about how such simplification is achieved, or why any of the numerous parts that I removed were redundant.

^[1]Except that yours didn't allow mixed containers (containers of both varexpr and funcexpr) whereas mine does, because I thought that that was just an oversight on your part. Not sure. 

@Carl Love I just realized that it was incorrect of me to attribute the original algorithm to Kitonum. After rereading the whole thread, I see that Kitonum actually was just making a correction to the OP's code. So, I apologize for that.

@Carl Love 

This boggles me: If I just declare a to be a constant via the official, documented method for declaring constants (see ?constant),

constants:= constants, a;

then, as far as int is concerned, how is a any different from any other official constant, say, gamma? Yet

int(exp(a*exp(I*x)), x= -Pi..Pi) still returns 0, while
int(exp(gamma*exp(I*x)), x= -Pi..Pi) returns 2*Pi.

Somewhere there is knowledge stored about gamma. For example, Maple knows (at the symbolic level?) that it's positive:

signum(gamma) returns 1, whereas signum(a) returns unevaluated. So, where is that knowledge stored?

@bliengme 

All Matrix/Vector arithmetic can be done with the familiar binary infix symbol operators: +, -, *, ., /, ^. (Note the distinction between commutative (or scalar) multiplication, *, and noncommutative Matrix/Vector multiplication, `.`.) There is no need to use any package (such as LinearAlgebra) to define Matrices and Vectors or to do arithmetic on them.

Your Reply makes me think that you're now wondering So what's the purpose of multiply and Multiply? 

The command multiply---as well as the entire linalg package that it comes from---are deprecated. That means that they are no longer intended to be used and they have been replaced with better commands. The reason that they still exist in Maple is so that old code that uses them will continue to run.

The LinearAlgebra package has numerous commands with the spelled-out names of arithmetic operations like Multiply. These commands are indeed for performing the arithmetic operations indicated by their names. The only reason to use such a command is if you want to use options, which cannot be included when using a binary infix symbol (because there's literally no place to type the option). The options are described on the commands' help pages. For example, the most-commonly-used option is (I expect) inplace, which means that the result overwrites one of the operands. There is no need to use options unless you're trying to write highly optimized code. Thus there's no reason for a beginning Maple user to pay any attention to the commands with names like Multiply.

Suggestion to Maplesoft: There are too many top-level commands in LinearAlgebra, which makes it unwieldy for even an experienced user to find what they're looking for. All of these not-commonly-used Matrix/Vector arithmetic commands should be bundled into a subpackage.

@Carl Love  So, now that I've read more of the package's help pages, I submit the following replacement for my procedure E__n in the Answer above. I think that it combines all of the good points of Tom's, Acer's, and my own approaches discussed in this thread so far:

restart:
ScientificConstants:-AddConstant(
   `Marc's constant`, symbol= 'E__n', 'derive'= 'h' * 'c' * 'R'[infinity]
);
E__n:= n-> evalf(ScientificConstants:-Constant('E__n', 'units')/(-n^2));

(The constant just needs a better name than `Marc's constant`, which Marc can decide on.)

Note that this procedure tacitly uses the constants to the full precision that they are known modulo the value of Digits at execution time.

@tomleslie You're right, Tom: Introducing evalindets was a bit of overkill, and I was hesitant to do it. Your code still accomplishes my top goals:

• elimination of magic numbers,
• replacing them with widely recognized symbols,
• using them to (at least) the precision that they are known,
• simplification of the units.

If I had had more familiarity with the package, I would've used Constant(..., 'units'), as you did. So I read more of the package's help and wrote a much simpler procedure (posted as a Reply to my Answer) that I think accomplishes all of our goals discussed in this thread.

@acer Thanks, Acer. I considered writing it such that the execution-time value of Digits rather than the definition-time value would be used, but I decided in favor of the (slightly) better execution speed of using the definition-time value. But I certainly see the benefits of doing it your way.

This was my first usage of ScientificConstants, and I found the format that the information is returned is awkward. The return value of GetConstant should be type set(name=anything) or something similar, and the units should be real Units, not simply products of symbols.

It looks like the package has a facility for adding constants, and the constant h*c*R could be added as a "derived constant" (using the terminology from the package's help page).

I figured out the meaning of the constants in the OP's original E__n by Googling them in the form "1.097 x 10^7", etc. I guessed that the 2nd procedure, eV, was simply a units conversion factor, so I simply checked that in Maple.

@waseem Thank you for the pages. So, they just use infinity = 8 for the upper boundary point of eta. In that case, the system can be easily solved with Maple's built-in BVP solver. As I said, this and related BVP systems dealing with nanofluids have been discussed and solved numerous times here on MaplePrimes.

Can you post the whole paper? Or just give me reasonable default values for all parameters?

Before you go through a lot of effort to produce this Fortran code, you should exhaust the possibilities of solving the ODEs in Maple first. Then, if that's not fast enough, do the Fortran. Since you've never posted to MaplePrimes before, it seems unlikely that you've exhausted the possibilities for solution entirely within Maple. We have several regular contributors who are expert in efficient numerical solution of ODE systems. 

Consider these two flowcharts for your project:

Method A:

1. Write some crappy Maple code.
2. Translate it to "optimized" Fortran.
3. Run Fortran code.
4. Does it need to be modified? If yes, go back to 1.

Method B:

1. Write some good Maple code.
2. Run it.
3. Does it need to be modified? If yes, go back to 1.
4. Optimize Maple code. Go to 2.
5. Is it fast enough? If yes, you're done; if no, go to 6.
6. Translate to optimized Fortran.

Method B requires much less effort on the part of the programmer and will produce faster code.

@Kitonum Your plots B and C are transposed. In other words, the xs and ys are exchanged with each other. It is only because of the coincidence that x and y are relatively close that this error was not more obvious.

That x = y - sqrt(y-1) and x = y + sqrt(y-1) are better approximations as y -> infinity can be seen by taking the result of your solve command immediately above and dividing the numerator and denominator through by y^2. Of course, this means that the terms of the radicand are divided by y^4. Then the asymptotic function is obtained by discarding any remaining terms that have any power of y in the denominator.

This does not mean that the result that you got from asympt is wrong, because asymptotic terms are not unique. For example, clearly sqrt(y) and sqrt(y-1) are asymptotic to each other because the infinite limit of their ratio is 1.

@Kitonum Closer asymptotic curves are x = y+sqrt(y-1) and x = y-sqrt(y-1).