I find it interesting that it can be difficult to apply relative frequency analysis alone and gain insight on such short (substitution) enciphered messages.

For this example, generating and apply all permutations of maps of the first handful of usually-most-frequent letters would produce a too large number of candidate "decrypted" messages. The best of those may not even have many actual full valid English words in it, so filtering them by dictionary matching  may also be involved.

For short messages, some combination of deduction, inspired guesswork, and relative frequency analysis might be a good all round approach. I notice that, after guessing the encrypted "r" and "w", the next that I obtained by inspired deduction were "AUPMNWB"  which also happen to comprise quite a bit of the most frequent encrypted letters "ABUWNM".

acer

Sure, I could have written,

map([lhs,rhs],[G]);

It seems to me that, when the OP appears to be learning Maple, a little longer and more clear is more helpful.

acer

Sure, I could have written,

map([lhs,rhs],[G]);

It seems to me that, when the OP appears to be learning Maple, a little longer and more clear is more helpful.

acer

> with(StringTools):

> G := CharacterFrequencies("I have the best dog."):
 
> [seq([lhs(x),rhs(x)],x in G)];

[[" ", 4], [".", 1], ["I", 1], ["a", 1], ["b", 1], ["d", 1],
 ["e", 3], ["g", 1], ["h", 2], ["o", 1], ["s", 1], ["t", 2],
 ["v", 1]]

acer

> with(StringTools):

> G := CharacterFrequencies("I have the best dog."):
 
> [seq([lhs(x),rhs(x)],x in G)];

[[" ", 4], [".", 1], ["I", 1], ["a", 1], ["b", 1], ["d", 1],
 ["e", 3], ["g", 1], ["h", 2], ["o", 1], ["s", 1], ["t", 2],
 ["v", 1]]

acer

Right. That's why I used CoefficientVector, as it is the efficienct way to get all coefficients, in order.

And so I used it to construct the data in columns. (I amended with an example showing an extra column, using the angle-bracket notation, without having to use Transpose).

acer

Right. That's why I used CoefficientVector, as it is the efficienct way to get all coefficients, in order.

And so I used it to construct the data in columns. (I amended with an example showing an extra column, using the angle-bracket notation, without having to use Transpose).

acer

For me, issuing evalf(solAC[1]) returns 1.582989180.

You could also do evalf([solAC]), and so on.

> evalf([solAC]);
[1.582989180, 0.7753797235 + 1.370887407 I,
-0.7914541420 + 1.343041826 I, -1.550840342,
-0.7914541420 - 1.343041826 I, 0.7753797235 - 1.370887407 I]

acer

For me, issuing evalf(solAC[1]) returns 1.582989180.

You could also do evalf([solAC]), and so on.

> evalf([solAC]);
[1.582989180, 0.7753797235 + 1.370887407 I,
-0.7914541420 + 1.343041826 I, -1.550840342,
-0.7914541420 - 1.343041826 I, 0.7753797235 - 1.370887407 I]

acer

I didn't notice the comma in the rhs of the original post. That, and the use of round-brackets, threw me off. I suppose now that the OP was actually using a syntax for a vector-valued function (just not Maple syntax). Sorry.

acer

I didn't notice the comma in the rhs of the original post. That, and the use of round-brackets, threw me off. I suppose now that the OP was actually using a syntax for a vector-valued function (just not Maple syntax). Sorry.

acer

Have a look at the help-page ?allvalues

minor point: Above, you use the word "evaluate" when it seems you actually mean evaluate an approximation in floating-point. The same term is also misused here. In Maple, the term "evaluation" means something quite distinct, but not that. The routine evalf does floating-point approximate evaluation. See also ?radnormal if you are interested in treatment of expressions containing radicals of exact symbolic values.

acer

Have a look at the help-page ?allvalues

minor point: Above, you use the word "evaluate" when it seems you actually mean evaluate an approximation in floating-point. The same term is also misused here. In Maple, the term "evaluation" means something quite distinct, but not that. The routine evalf does floating-point approximate evaluation. See also ?radnormal if you are interested in treatment of expressions containing radicals of exact symbolic values.

acer

This is partly related. The `int` routine is not as smart as `D`, for handling operators. It evaluates the procedure at some name (_X, say). But that may not result in what was intended.

For example,

> restart:

> f := proc(x)
>    if is(x>0)=true then x; else Pi; end if;
> end proc:

> int(f, 1..2); # oops
                                      Pi
 
> forget(`int/int`):
> int(f, a..b) assuming a>0, b>a; # oops
                                  Pi (b - a)
 
> D[1](f); # good
                                    D[1](f)
 
> D[1](f)(1); # good
                                    D(f)(1)
 
> evalf(%); # right
                                  1.000000000
 
> D[1](f)(-1); # good
                                   D(f)(-1)
 
> evalf(%); # right
                                      0.

Here's another example,

> restart:

> h := proc(x) sign(x); end proc:

> int(h, -1..0);
                                       1
 
> evalf(Int(h, -1..0));
                                 -1.000000000

acer

Sure, last-name-eval and remember tables are known to be a risky mix.

I'd be mildly surprised if something couldn't be changed to allow it to work better in `int`, though.

There is a remember table in use by `int/int`. That routine has options `remember` and `system`. That means that, while it will remember arguments, it's memory can be cleared during garbage collection. That probably explains why you got slightly different results in some layouts -- because gc was happening and "fixing" things by forgetting some of the undesirable last-name-eval proc name entries from the remember table.

Maple 8 can get examples wrong too. (It's not the case that `int/int` did not have option `remember` in Maple 8. It did.) For example,

> kernelopts(version);
          Maple 8.00, SUN SPARC SOLARIS, Apr 22 2002 Build ID 110847
 
> f := x->2*x:
> int( f, 0..1 );
                                       1
 
> f := x->3*x:
> int( f, 0..1 );
                                       1
 
> restart:
> f := x->3*x:
> int( f, 0..1 );
                                      3/2

acer