The matrix operations are far more efficient (by a factor of about 30) if performed in LinearAlgebra:-Modular. The drawback is that the syntax used by that package is difficult to understand. Here's a procedure for it;

FlipBits:= proc(block)
uses LAM= LinearAlgebra:-Modular;
local Block:= LAM:-Mod(2, block, integer[kernelopts(wordsize)/8]);
    LAM:-AddMultiple(
         2,
         LAM:-Create(2, nops(block), 7-3+1, 1, integer[kernelopts(wordsize)/8]),
         Block, 1..-1, 3..7,
         Block, 1..-1, 3..7
    );
    Block
end proc:

To use it:

block:= ListTools:-Reverse~(Bits:-Split~(convert(message, bytes), bits= 8)):
Block:= FlipBits(block):
cblock:= convert(Block, listlist):

with that last line being not needed if you want to stay in Matrix form.

This is also far faster than the subsop method.

@Joe Riel Do you know if using subsop on a long list is just as inefficient as assignments? I would think so, but I haven't been able to confirm it. I made the original message 1000 times longer and compared my code with Kitonum's shorter code. Kitonum's was faster by a little bit.

@ecterrab You said that the Document mode has additional features (over the Worksheet mode). What are some of those features?

Is the Worksheet mode considered to be for more-computational work while the Document mode is for more-expository work?

@Christopher2222 

With some small adjustments, the plots are almost identical. I used Maple's ColorTools to find colors matching the Mathematica plot. I also adjusted the transparency, thickness, labels, and number of subticks on each axis.

I'll agree that Maple's orange is actually red. Maple's green and blue seem okay, although they're different shades than Mathematica's colors corresponding to those names.

restart:
Options:=  
     t= -6..6,
     color= ["Resene Horizon", "Resene YellowSea", "Resene Citron"], #i.e., blue, orange, green
     filled= [transparency= .85], thickness= 4, labels= [``$2],
     axis[1]= [tickmarks= [subticks= 3]], axis[2]= [tickmarks= [subticks= 4]]
:
plot([seq(Statistics:-PDF(Normal(0,i), t), i= [.75, 1, 2])], Options);
plot([seq(Statistics:-PDF(Normal(i,1.5), t), i= [-1, 1, 2])], Options);

Compare with the Mathematica plot:

@Christopher2222 Of course, I have assumed that you've already executed

with(Statistics):
X := RandomVariable(Normal(0, 1));

before executing my command!!!

Markiyan, I wish that you'd stop changing the titles of the Questions in such a banal way. The title "Problem with dsolve" is nearly meaningless when so many problems with dsolve are currently being discussed. You aren't just editing the titles; you're also altering their meaning. I like seeing some reference to the error that the OPs are having. Such a radical change of the title also makes it more difficult for new MaplePrimes users to find their own Questions.

I don't mind titles being corrected for spelling, grammar, and punctuation, and long words being abbreviated.

The title should be such that it improves the searchability of the post for all time. The momentary convenience of having a shorter title doesn't trump that long-range goal. If the all-time index contains several hundred posts titled "Problem with dsolve", it seriously hampers the searchability.

Words such as "problem", "question", and "issue" are meaningless in this context and shouldn't be included in titles.

@Preben Alsholm I changed all the float constants to rationals, changed all the . to *, and got rid of the continuation parameter. The new error message is

Error, (in fproc) unable to store 'Float(undefined)*I' when datatype=sfloat

@billyp245 

You have a line of code

A:= a-> sqrt(1/I1);

where I1 is an expression that depends on (global) a. This global a is "hidden" inside the expression I1. It is not matched with the parameter a that is on the left side of the ->. This is a very common problem in Maple. The solution is a command called unapply, used thus:

A:= unapply(sqrt(1/I1), a);

This defines A as a function, just like the arrow -> does, but it also associates the parameter a with the global a hidden in I1. Once you make this one change, the rest of the worksheet will work.

Here are two ways that you can select the correct (real) amin. The first way, which I recommend in this case, is to include option useassumptions in the solve command:

amin:= solve(D2, a, useassumptions);

This'll produce only the one solution, and it'll get rid of that warning.

I showed the second way in the Reply above:

amin:= solve(D2, a):
amin:= remove(has, [amin], I)[];

Putting your comments in quotes is very clunky. You can switch between text mode and math mode with Ctrl-T and Ctrl-R, respectively. What you type in text mode will not be interpretted as code, and thus there's no need to use quotes.

Why do you want to write a procedure to find the inverse of a floating-point matrix?

Your C^T/Det(A) formula can be easily implemented by

Inv:= proc(A::Matrix(square))
uses LA_D= LinearAlgebra:-Determinant;
     Matrix(op(1,A), (i,j)-> (-1)^(i+j)*LA_D(A[[..i-1, i+1..], [..j-1, j+1..]]))^+/LA_D(A)
end proc:

The reason for the "bad index" error is that you're trying to index A with the undefined names a[k] and b[k]. A matrix's indices must be numbers, not names.

@torabi I think that the existence of a trivial solution will make it much more difficult to find a nontrivial solution---if one exists at all. But I must defer on this point to those members who have more knowledge of the theory of differential equations.

Also, omega being unknown will be a problem unless you can come up with one more boundary condition. If you can make it a nonzero boundary condition, it'll solve the first problem also.

@Christopher2222 When you use the transparency option with a plot command, it is applied to the whole plot. The help page ?plot,options is incorrect where it says "This option specifies the transparency of the plot surface," [emphasis added] because it's applied to the curves also. But when you use filled, the transparency is only set for the shaded region, not the bordering curve, and the value used is 0.4. This is exactly what my code does.

@billyp245 The original equation is degree three in a, so it has three solutions. Only one is real. The real solution can be selected automatically if you wish.

In order to diagnose the problem of it not evaluating the a, I'll need the actual worksheet, which you can easily upload here.

On the other hand, the following code works:

E:= a-> a*h^2/2/m + 1/sqrt(2*Pi*a):
Sol:= solve(D(E)(a), a):
amin:= remove(has, [Sol], I)[]:
simplify(E(amin));

The trivial solution g(x)=0, s(x)=0 (for all x) is a solution to your system for any omega.

@acer So, if we make a dumb intermediate procedure that converts a module to a name, then it works:

ModuleToName:= proc(M::`module`) local N:= M; evaln(N) end proc:
MyPDF:= v-> t-> piecewise(t<0, 0, t<v, 1/v):
Statistics:-Mean(ModuleToName(Statistics:-Distribution(PDF= MyPDF(1))));

@Kitonum My solution (below) attempts to retain all the options from the original plot.