I believe each different number of points interacts differently with the aliasing and the number of pixels used. There is no direct relationship such that quality increases with numpoints. For example, the following plot has only 67 points, and I think that it has better quality than the default 200.

P:= plot(sin(x), x= 0..2*Pi, view= [DEFAULT, -1.05..1.05],
    thickness= 2, color= brown, numpoints= 67
):

op([1,1,1,1], P); #Verify that it really used 67 points.
                               67
print(P);

How many points does Mathematica use for the plot shown above? Maple uses 200 by default.

Can you show an example of this?

How about posting a link to the file? (You don't need to explicitly put the contents of the file in the post.)

For what it's worth, the bug is not manifested in M17.

(This comment is not relevant to the Asker's present question; it refers to their previous question about this same piece of code.)

You misunderstood my answer to your previous question about this piece of code. There is no need (and no reason) to do this:

f:=()->zeta1;
U1:=tau->add(c[p]*(tau-f())^(p),p=0..Term1-1);

If you just leave it the way you had it,

U1:=tau->add(c[p]*(tau-zeta1)^(p),p=0..Term1-1);

then it will work fine. The value of zeta1 will be used when you invoke U1.

But you still need to fix the problem of Term1 not having a definite value.

@Christopher2222 It is automatic simplification, as acer pointed out. I had mistakenly mixed up sqrt and `^` in my test (even though I had already made a mental note that the action of procedure sqrt was irrelevant to this issue). Since it is automatic, it can't be prevented by overloading. The best that can be done is to reverse the simplification, encapsulate the radicand with ``() or some such, put the radical in the denominator, and adjust the other factors---a lot more work.

There's nothing to fear from unprotect. It can't cause any problem that can't be corrected by restart. It does not allow overwriting of the value of the name stored in the library.

@Christopher2222 It is automatic simplification, as acer pointed out. I had mistakenly mixed up sqrt and `^` in my test (even though I had already made a mental note that the action of procedure sqrt was irrelevant to this issue). Since it is automatic, it can't be prevented by overloading. The best that can be done is to reverse the simplification, encapsulate the radicand with ``() or some such, put the radical in the denominator, and adjust the other factors---a lot more work.

There's nothing to fear from unprotect. It can't cause any problem that can't be corrected by restart. It does not allow overwriting of the value of the name stored in the library.

Is there something missing from your post? You ended with

Is there a sim

As to why the numeric one often has its denominator rationalized: I think it is because it makes long division easier. Which long division would you rather do, 1/1.4142 or 1.4142/2? You can do the latter in your head.

@Joe Riel I was just about to expand on my Answer, but I needed to let the dog out (literally), and you caught it. I was going to say that the desired command was probably zip, assuming that the x's and y's are separate to start with, since the Asker expressed skepticism about the data structure anyway. If they are already in pairs, then certainly the f@op (or equivalent) is better than doing a "strip then zip".

@Joe Riel I was just about to expand on my Answer, but I needed to let the dog out (literally), and you caught it. I was going to say that the desired command was probably zip, assuming that the x's and y's are separate to start with, since the Asker expressed skepticism about the data structure anyway. If they are already in pairs, then certainly the f@op (or equivalent) is better than doing a "strip then zip".

@Joe Riel Sigh. I'm never satisfied with using satisfies with a predicate that is pure (albeit parametrized) syntactic type checking. It always leaves me feeling there's gotta be a smoother way.

@Joe Riel Sigh. I'm never satisfied with using satisfies with a predicate that is pure (albeit parametrized) syntactic type checking. It always leaves me feeling there's gotta be a smoother way.

Acer wrote:

> depnames := indets(expr,And(And(name,Non(constant)),
> 'satisfies'(u->depends(expr,u))));

It seems like such a fundamental concept that it's surprising that there isn't a more primitive typespec for that. I suspect that in the majority of cases where one calls indets(expr, name) that the above is what one really wants. I've found a few bugs in library code that probably would've been avoided if there had been a primitive typespec for the concept. (One I recall involved fsolve(Int(..., [x=..., y=...]), ...) where it complained about x and y not being solved for. That's fixed in Maple 17.) There are the types ?type,dependent and ?type,freeof, but they are types which are applied to an expression, not to the names within the expression.

Acer wrote:

> depnames := indets(expr,And(And(name,Non(constant)),
> 'satisfies'(u->depends(expr,u))));

It seems like such a fundamental concept that it's surprising that there isn't a more primitive typespec for that. I suspect that in the majority of cases where one calls indets(expr, name) that the above is what one really wants. I've found a few bugs in library code that probably would've been avoided if there had been a primitive typespec for the concept. (One I recall involved fsolve(Int(..., [x=..., y=...]), ...) where it complained about x and y not being solved for. That's fixed in Maple 17.) There are the types ?type,dependent and ?type,freeof, but they are types which are applied to an expression, not to the names within the expression.