@nrebman1 Please post your worksheets here if you have ongoing problems with your (essentially same) example.

@Østerbro If you use the "Contect" link on my member page here then I'll get an email and be able to respond to you via email.

I cannot use the Contect mechanism from this site to contact you because I'm unable to view your member page here (possibly due to special characters in your member handle for this site.)

@John Fredsted I believe that deletion as spam is yet another ability which is key on reputation. (...a higher cutoff, I suspect, since if the spammer's reputation/activity is low enough then deletion as spam may disable the spamming account.)

@rostam Your response to me, about using even 10^7 points, indicates that you've misunderstood me.

What I mean is that there may be a cutoff in the number of data points below which antialiasing is enabled in the Java renderer. Not above. Compare,

plot(10*sqrt(3)/sqrt(120*Pi^2+19*x), x=0..10, view=0..1,
     adaptive=false, numpoints=2000, thickness=0);

plot(10*sqrt(3)/sqrt(120*Pi^2+19*x), x=0..10, view=0..1,
     adaptive=false, numpoints=200, thickness=0);

So the key thing may be that, at present, better quality comes from not using a very high number of points for such curves.

I have a suspicion that potentially "expensive" smoothing techniques for line smoothing in java/jogl/jwhatever may not being done when there are too many points. If that surmise is correct then the global cutoff has clearly been set too low, or is being misapplied. (It's possible that some distinction is made to handle simultaneous rendering of multiple curves, and that in the interest of not exceeding a reasonable global total an over-strict cutoff is applied to single curves. I'm guessing about how it could be mis-coded.) OTOH, if this is any kind of java/jogl renderer limitation (which I doubt) the GUI could still resample downwards before passing to the renderer. Another possibility is that antialiasing is not being done following downsamplling.

The behavior is wrong, and the lower point-number case demonstrates that better rendering is possible: that's the important thing. I thought that most of the 2D plot rendering smoothness issues were resolved a few releases ago. It's a shame. 2D plot rendering of single curves should use the highest quality that the renderer provides, with speed being no problem, up to a really high point-number (above which the GUI could downwards resample very quickly). And it should be less easy for the user to try something reasonable (like ramping the number of points way up) and end up with low quality rendering.

Like several other editing aspects, being able to edit other's posts is keyed on the level of the member's reputation, I believe.

acer

Do you see an abrupt change in quality when numpoints becomes smaller or greater than 1999 (or some value around that)?

acer

@Østerbro Attached is an edited version of your File.mw Document, in which units appear within the object.

I have been extending the object's functionality, and while I'm not yet finished or 100% satisfied it may be that you find this of some use.

Filemodif2.mw

I put the code that defines the package (which defines the object) into the Startup Code region of the Document, merely for convenience. Soon I hope to have it in an .mla, useful perhaps to others. For now you could use it in Startup Code as I do here, or the Document's body as you did before, or a Code Edit region, or LibraryTools:-Save it to your own .mla.

I've learned a few lessons about objects which I eventually hope to share with full comments in the code (eg, sequence return from static `*` and `+`), and found a few bugs (eg, static Re and Im), etc. And I have a number of aspects still to deal with (eg. evalc of product of a name and an object, better float contagion, etc).

And I've had to make some choices. I'm trying to be pretty agressive with automatic simplification of the object data. As it stands now unassigned names get pulled out of the object to make a product of terms. It might possibly be more ideal to have unassigned terms remain in the object, say, in the modulus. But I have not yet found a good way to get assuming to work with that. If I can't subs or evalat to replace names in the object (let alone temporary assumed names) then what's the use of not pulling them outside it?

Do you mean linewraps that are an effect of the displayed width of the TextArea Component?

acer

@torabi Why do you use lowercase pi instead of Pi?

It looks like you are trying to use LinearAlgebra:-Transpose. Either load the LinearAlgebra package (using the with command) before using the short command name Transpose, or use the explicit long name LinearAlgebra:-Transpose, or simply raise it to the power %T.

In at least one instance `.` was being used to multiply a nonnumeric scalar expression by a Matrix (it was somescalar . T if I recall...).  Use `*` there instead, if you want the multiplication to be distributed across the Matrix. I changed it.

Are you trying to apply that integration across all entries of S?

Is Y supposed to have a numeric value?

maple2modif.mw

It could also be pointed out that the zero-detection (tests whether an entry is zero) could be done with a call to the Testzero command, instead of merely using evalb (which is done above, implicitly via if M[...] <> 0 then constructs). That would allow the reduced procedure to handle better other coefficient domains without inadvertant and invalid use of a "hidden zero" as pivot. By default it would allow coverage for polynomials with rational coefficients, and using it would allow for easy adjustment for other domains.

Additionally, in order to keep expression swell down while reducing the addition and multiplication steps could use the Normalizer command. Apart from benefitting the size of the final result that could also help unburden the work done while zero-testing. And then a simple strengthening assignment to Normalizer could cover both reducing stage simplification as well as zero-testing, leaving Testzero to use Normalizer just as it does by default.

@Carl Love I don't think that the three elementary procedures are correct. Given the way that `reduced` is trying to use them, they are wrongly implemented.

For example, use `perm` to interchange a row with itself (should get identity, but instead get something with a zero-row). Either `reduced` should avoid calling `perm` when i=j or `perm` itself should handle that case properly.

Also, considering the way that `addition` and `multiplikation` get used in `reduced`, their last parameters are mistyped as integer.

@Østerbro Ok, I have it now. I see two things to deal with: a problem in the static `*` procedure, and the Units Formatting mechanism. I will endeavor to accomodate both.

@Østerbro That download link does not work for me. Please try again (just insert a link to your comment, not the entire contents inlined). I suggest a simple name with no special Danish characters, such as file.mw with only one period in the filename (your above had two). You can test that it worked, using the Preview to test the download link, before posting any new comment.

I don't really understand why you have used the 2D Input that looks like & (ampersand) before the typeset angle symbol. Was that deliberate, because you knew it wasn't the way it's intended to be used, but just wanted to convey the computation flow you want?

I think that I can enhance it, to work with units...

@Østerbro I cannot read that tiny font, and have little wish to type it all in by hand. Please attach a worksheet/document. Thanks.

I am whipping the module object into better shape, and will augment if I can figure out exactly what more you want or need here.

@vv I think your original 1st and 2nd example can be covered by correcting the lhs/rhs thing, and robustifying the `is` call used to `ormap` to avoid problems with FAIL (from `is`).

And then, yes, the 3rd example would return unevaluated for me, which as you say is at least not a wrong result. I'll think about that 3rd one too. As you say, the solution is easy for a person, but how it may misstep in the code may be another thing...