You should include fclose(fileName). I think this will preclude the need for Threads[Sleep]. Even if it doesn't completely eliminate the need for Sleep, you should include it anyway.

You should include fclose(fileName). I think this will preclude the need for Threads[Sleep]. Even if it doesn't completely eliminate the need for Sleep, you should include it anyway.

@Christopher2222 Is a Mathematica plot an accessible data structure the way that a Maple PLOT is? something that can be assigned to a variable? taken apart with the equivalent of op? Does it even have something like op?

@Christopher2222 Is a Mathematica plot an accessible data structure the way that a Maple PLOT is? something that can be assigned to a variable? taken apart with the equivalent of op? Does it even have something like op?

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);

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".