> 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

Note that I didn't write that `solve` certainly needed a comprehensive rewrite for this. I said that such a need is conceivable.

There are a variety of approaches that might be taken, to try to teach `solve` about assumptions. One way might be to inject more use of (a strengthened) `is` into a major rewrite. Another way might be to utilize only a (strong) post-processing filter. Another might involve converting some of the assumptions into additional inequality arguments, and strengthening the part of `solve` that handles such. And so on.

One reason why doing such improvements well is a hard task is that in order to keep the expended effort reasonable it's important to get a handle on the likely success of the various approaches. And it can save so much effort if that can be discovered near the start of the work. But it can be very hard to figure out in advance.

If this advance deduction is not done well enough then a lot of effort can be put into a new scheme which then subsequently hits a practical wall. Limits to the new scheme's practical utility can suddenly appear on the event horizon.

Isn't figuring out the "best" places to put development effort the hardest part of CAS improvement?

acer

Note that I didn't write that `solve` certainly needed a comprehensive rewrite for this. I said that such a need is conceivable.

There are a variety of approaches that might be taken, to try to teach `solve` about assumptions. One way might be to inject more use of (a strengthened) `is` into a major rewrite. Another way might be to utilize only a (strong) post-processing filter. Another might involve converting some of the assumptions into additional inequality arguments, and strengthening the part of `solve` that handles such. And so on.

One reason why doing such improvements well is a hard task is that in order to keep the expended effort reasonable it's important to get a handle on the likely success of the various approaches. And it can save so much effort if that can be discovered near the start of the work. But it can be very hard to figure out in advance.

If this advance deduction is not done well enough then a lot of effort can be put into a new scheme which then subsequently hits a practical wall. Limits to the new scheme's practical utility can suddenly appear on the event horizon.

Isn't figuring out the "best" places to put development effort the hardest part of CAS improvement?

acer

[edited, after further reflection]

It is possible to construct an alternate Matrix Browser that is not implemented within a Maplet.

There are a variety of possibilities about how to do it. I hope to find time to post some prototypes to illustrate what (tricks) I have in mind.

How satisfactory these might be would be subjective -- each individual may put differing value of qualities of a Matrix Browser. Those could include such things as non-locking control, separate floating window occurence, dynamic interaction with data, different tab, and flexible ability to switch on-the-fly between any of the above. And so on.

It also raises these questions: is it better to get an alternative non-Maplet Matrix browser right now, or would it be better to implement a sophisticated "array data" analyzer? (The DataMatic, folks. It slices, it dices...) Or would a few simple context-menu driven pointplots suffice?

acer