acer

21403 Reputation

29 Badges

15 years, 111 days

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

@tomleslie Yes, replacing vector by Vector in the attachment I gave (listsetvector.mw) shows behaviour that had been recognized and mentioned, more than once before, in the discussion. The prior mention is why I omitted it from the attachment above.

Specifically, it demonstrates that a Vector does not have last-name evaluation -- which is thus seen to neither the cause nor the cure of the central issue. While the default column Vector gets its entries printed vertically and a lowercase vector gets them printed horizontally, both show the name of the assigned parameter.

And so it is evident that having last-name evaluation (or lacking it) is not the cause (or the cure) of the printing issue. It is only tangentially connected to the central issue, and a red herring here.

Upload and attach your actual Worksheet or Document that in which plots:-display fails to do what you want.

Then describe clearly what is wrong with it, if the problem is not a runtime error.

Why do you include text with expressions using apparently incorrect syntax, in your Question and at least one followup response? That adds to the confusion here, I think.

This characterization of the problem -- as being due to lack of last-name evaluation -- is incorrect. That comprises much of this Answer.

The fact that a Vector does not have last-name evaluation is not why it does not print as the OP wants or expects. The list and the set data structures also do not have last-name evaluation, but they do not have the unwanted printing behavior (ie. unwanted by the OP). And a lowercase table-based vector has last-name evaluation, but it too has the key, unwanted part of this printing behaviour.

The printing behavior not wanted by the OP is due neither to the presence nor absence of last-name evaluation on the structure.

restart;

L := [-2+m,3+m];
                      L := [-2 + m, 3 + m]

S := {-2+m,3+m};
                      S := {-2 + m, 3 + m}

v := vector([-2+m,3+m]);
                      v := [-2 + m, 3 + m]

m := 5;
                             m := 5

# absence of last-name evaluation
L;
                             [3, 8]

# absence of last-name evaluation
S;
                             {3, 8}

# last-name evaluation
v;
                               v

print(v);
                        [-2 + m, 3 + m]

v[1], v[2];
                              3, 8

listsetecwtorv.m

A Vector (capitalized V) also does not have last-name evaluation. But it does have the printing behaviour unwanted by the OP. Hence that quality neither causes the problem not does its absence avoid it. Your characterization that last-name evaluation is the factor of primary concern here is quite wrong and muddled.

@taro The third argument passed to the collect command acts separately on each of the "coefficients" (by which I mean, coefficients of the collected expressions, ie. coefficient subexpressions).

Take your expression,

restart;
c := I__11*I__22 - I__11*X__2 - I__12*I__21 - I__22*X__1 + X__1*X__2;

    c := I__11 I__22 - I__11 X__2 - I__12 I__21
         - I__22 X__1 + X__1 X__2

Let's pass just some dummy name K as the third agument. Look at the resulting separate calls to K, which are now the separate coefficients of the (powers of the) collected I__12 term.

collect(c, [I__12], K);

     K(-I__21) I__12
     + K(I__11 I__22 - I__11 X__2 - I__22 X__1 + X__1 X__2)

When we pass simplify instead of K for that third argument, the simplify acts separately on those coefficients (ie. coefficient subexpressions).

collect(c, [I__12], simplify);

     -I__12 I__21
     + (X__2 - I__22) (X__1 - I__11)

But when you do the following the simplify acts on the whole result of the first call to collect. And that allows the various subterms in the coefficients to affect the overall simplification -- which destroys the desired effect. The simplifications are no longer being done separately on the coefficient subexpressions.

collect(c, [I__12]);

  I__11 I__22 - I__11 X__2 - I__12 I__21 - I__22 X__1 + X__1 X__2

simplify(%);

  (-X__2 + I__22) I__11 + X__1 X__2 - I__22 X__1 - I__12 I__21

@Carl Love Sorry, typo, corrected.

@mmcdara We've been in this vicinity before, I think, discussing procedures that generate names that render as 2D pretty-printed output with subscripts.

Note that the second of these examples renders with the subscript in upright Roman, as opposed to the more usual italic for 2D pretty-printed names. Of course, you can adjust that, or mix and match.

The first two procedures produce the kind of name you've been calling "MathML". 

mmlsub1 := (x,s) -> nprintf(`#msub(mi(\"%a\"),mi(\"%a\"));`, x, s):
mmlsub2 := (x,s) -> nprintf(`#msub(mi(\"%a\"),mn(\"%a\"));`, x, s):
mmlsub3 := (x,s) -> cat(x,':-`__`',s):

mmlsub1( F, [a,b] );
mmlsub2( F, [a,b] );
mmlsub3( F, [a,b] );

Other variants are possible. Sophisticated handling of more ununusual objects in the subscript is also possible.

@mmcdara Incorrectly describing the double-underscore as a means to "index a symbol by another symbol" is not just incorrect here; it confuses the whole issue.

The double-underscore syntax produces a name which renders as subscripted when pretty-printed, by design. But the central purpose of the double-underscore syntax is that it is not indexing.

The main purpose of the double-underscore syntax is to provide an alternate mechanism for subscripting, without the name depending upon (or being mutable with respect to) the subscript.

The way to get an indexed name is to index into a name, by making an indexed reference to it. The syntax for indexing is available via square brackets.

Subscripting is not the same as indexing.

It happens to be the case that indexed names pretty-print as subscripted names. That is a historical feature of Maple, which works well. But it does not mean that all subscripted names are indexed.

The alternate mechanism for creating names which pretty-print as subscripted -- ie. double-underscore -- was introduced so that people could use expressions that contained both the basename as well as the subscripted names without functional collision or interference, and indeed without any programmatic dependence (eg. relation to the basename, mutability of the subscript, or equivalence to the indexed name which happens to pretty-print similarly). For example, using x alongside the indexed name x[0] in calls to solve, dsolve, etc, is problematic, and so one may safely use x alongside x__0 instead.

Some people have now innappropriately conflated the two mechanisms for subscripting. Some people are now innappropriately expecting that double-underscore subscripted names act as if such names depended programmatically upon their subscripts. That is directly contrary to their very design and intended purpose. 

If you are using Maple 17 (released in the year 2013) then it confuses things to mark your Question as Product = Maple 2017 (released in year 2017).

The Fractals:-LSystem package used in Tom's Answer is present in Maple 2017 and it's understandable that he suggested it since that's how you had originally marked this Question. It was introduced in Maple 2015, and so is not present in older Maple 17.

I have revised the Product marker on this Question.

I have also revised the marker on some of your older Questions (including some marked Product = Maple 2017 and for which your attachments were last saved by you in Maple 17). Apologies to those who notice the blip in the Mapleprimes "Last Action" date field.

What version are comparing against, in which characters appeared larger? Was it 2020.1/2020.0, or some earlier version?

What operating system are you running on?

[There was a glitch in Maple 2020.0, but I cannot tell whether you are seeing the reverse effect of that, based only on the few details you've given so far.]

@dnaviaux The short reponse is that, yes, plots and 2D Math (typeset) equations and much more can be used in Tabulate. And DocumentTools:-Tabulate has its own Help page with examples.

And even Tabulate is just a convenient way to get some of the functionality of DocumentTools:-Layout, which provides pretty broad functionality for generating worksheets (as results) programmatically. One end-goal of that is programmatic construction of nice, typeset reports.

I can put together some nice examples, trying to prototype some of the ideas you mentioned from generating multiple kinds of report from the same data source. But it's Dec 27, there's fresh snow, etc. Perhaps in a day or so...

If you already know LaTeX well then it could be a way to grind out some finer nuances of a typeset report. But I think that it's just another toolset layer, and mostly would make this job involve more effort. If you don't already know LaTeX then I think that using it here would be crazy.

@Carl Love Your surmise about anti-aliasing (in the presence of "too many points") is correct. That was one of the main points of my own Answer, though I suspect I did not make it all clear enough.

However, using implicitplot is unnecessary for the example at hand, is much less efficient than using just the plot command, and has led to some confusion (and at least one mischaracterized explanation -- not yours).

But your explanation is indeed germane, and may well help in other examples that do need implicitplot.

Please don't submit duplicates of this Question.

@snowman In that case you can obtain a smooth curve, computed much more efficiently, by passing an explicit formulation to the `plot` command itself.

That uses adaptive sampling, and doesnt produce more data points than the renderer handles well (ie. avoids antialiasing disabling).

You don't need to go near all this implicitplot mess, here.

@dnaviaux Please don't put the same query in two places. Here is enough.

1 2 3 4 5 6 7 Last Page 3 of 450