Factorial2 and rough fix some misc bugs

[rocky]

@TiagoCavalcanteTrindade This was a lot messier than I had imagined. And our system of setting the method of evaluation needs to be redone. And there were bugs outside of just the Factorial2 code.

Fixes #683

[TiagoCavalcante]

@rocky I was thinking in add a test that checks if the double factorial of an even negative shows a message, so when SymPy/MPMath implement it we could remove the dead code.

[rocky]

First of all we shouldn't be testing errors in the doctest thing. Those are should be in unit tests. It's just that we haven't figured out or coded in a routine how to match against errors in the unit test stuff yet.

And there is kind of a general principle here that is becoming annoying at least to me. We keep piling more stuff on rather than fix more basic stuff. So that means that when the basic stuff gets fixed, there is a bigger backlog to do.

(To be concrete here: moving stuff that doesn't belong to doctest out of it. Reoganizing the docs and the module structure itself not to be such a pig with long lists of functions and 6K lines of code modules)

As for the specific unit test here. The problem is that in this framework we don't have a way to say that you'll get an error message if say scipy is not installed but if it is installed you are okay. Or that if you get an error message this is what it will be.

[TiagoCavalcante]

First of all we shouldn't be testing errors in the doctest thing. Those are should be in unit tests. It's just that we haven't figured out or coded in a routine how to match against errors in the unit test stuff yet.

Ok.

And there is kind of a general principle here that is becoming annoying at least to me. We keep piling more stuff on rather than fix more basic stuff. So that means that when the basic stuff gets fixed, there is a bigger backlog to do.

Ok, after finishing the arrows (which probably won't look so good in Asymptote) and the subsections, I'll give it a look. Just a question: should I stop adding new functions? (I was thinking on complete Threshold, add some polyhedrons, and Cone).

As for the specific unit test here. The problem is that in this framework we don't have a way to say that you'll get an error message if say scipy is not installed but if it is installed you are okay. Or that if you get an error message this is what it will be.

Ok, dead code is better than no code, so I guess a bit of dead code won't hurt.

[rocky]

First of all we shouldn't be testing errors in the doctest thing. Those are should be in unit tests. It's just that we haven't figured out or coded in a routine how to match against errors in the unit test stuff yet.

Ok.

And there is kind of a general principle here that is becoming annoying at least to me. We keep piling more stuff on rather than fix more basic stuff. So that means that when the basic stuff gets fixed, there is a bigger backlog to do.

Ok, after finishing the arrows (which probably won't look so good in Asymptote) and the subsections, I'll give it a look. Just a question: should I stop adding new methods?

This is a great question really really hard to answer. If the thing you are adding is something that you know a lot about and feel is clean then great!

But what I have come to appreciate more is that if you just dive into a new area where you know nothing about, it is possible that this is one of the many places that haven't been gone over in quite a while. If you are adding to a 6K file like strings then that is likely to be dirty and change. (And in fact one of your PR's will conflict with the one where I split up strings.py to smaller module under the string directory).

On the other hand if you are working in an area no one has under control (or had before you started) like Django or machine learning as a pymathics module, then go wild!

[TiagoCavalcante]

This is a great question really really hard to answer. If the thing you are adding is something that you know a lot about and feel is clean then great!

But what I have come to appreciate more is that if you just dive into a new area where you know nothing about, it is possible that this is one of the many places that haven't been gone over in quite a while. If you are adding to a 6K file like strings then that is likely to be dirty and change. (And in fact one of your PR's will conflict with the one where I split up strings.py to smaller module under the string directory).

On the other hand if you are working in an area no one has under control (or had before you started) like Django or machine learning as a pymathics module, then go wild!

Ok, so I guess is better I remove some 2015 libraries from Mathics Django and try to improve the UX.

[rocky]

This is a great question really really hard to answer. If the thing you are adding is something that you know a lot about and feel is clean then great!
But what I have come to appreciate more is that if you just dive into a new area where you know nothing about, it is possible that this is one of the many places that haven't been gone over in quite a while. If you are adding to a 6K file like strings then that is likely to be dirty and change. (And in fact one of your PR's will conflict with the one where I split up strings.py to smaller module under the string directory).
On the other hand if you are working in an area no one has under control (or had before you started) like Django or machine learning as a pymathics module, then go wild!

Ok, so I guess is better I remove some 2015 libraries from Mathics Django and try to improve the UX.

Thanks! Here's something that occurred to me the other day that I think will help the UI. While we have reduced the use of MathML for stuff it doesn't need there is still more to do: Booleans and Integers. A reason it is good not to wrap this in MathML is that MathML on cached cell data re-evaluates things and it really doesn't need to be done here.

[TiagoCavalcante]

While we have reduced the use of MathML for stuff it doesn't need there is still more to do: Booleans and Integers.

Yes.

A reason it is good not to wrap this in MathML is that MathML on cached cell data re-evaluates things and it really doesn't need to be done here.

Yes, and here MathML disturbs, it doesn't break the numbers, resulting in a horizontal overflow for big numbers. I'll think about how linebreak the numbers without confuse the user.

I was also thinking about in the future replace MathJax with KaTex.

[rocky]

While we have reduced the use of MathML for stuff it doesn't need there is still more to do: Booleans and Integers.

Yes.

A reason it is good not to wrap this in MathML is that MathML on cached cell data re-evaluates things and it really doesn't need to be done here.

Yes, and here MathML disturbs, it doesn't break the numbers, resulting in a horizontal overflow for big numbers. I'll think about how linebreak the numbers without confuse the user.

I was also thinking about in the future replace MathJax with KaTex.

You are the expert here - so whatever you decide is probably best.

One other thing related to front-end stuff. It would be nice to split out the mathics.js and graphics3d.js stuff into its own package. That way you can use it in Flask if you decide to go that route. And maybe it can be used in Jupyter (or other kinds of JS-based front ends).

[TiagoCavalcante]

It would be nice to split out the mathics.js and graphics3d.js stuff into its own package.

Yes, we just need to decide how to get the package.

About graphics3d.js, I guess it's going to be amazing to have it's own module: "Very easy and fast 3d graphics in your browser". Also in its own module would be easier to minify (and convert to ES5 for who want to support old browsers).

[TiagoCavalcante]

@rocky I have been thinking about this and a <script src="https://raw.githubusercontent.com/Mathics3/graphics3d.js/master/build/index.js"></script> would be the best.

[rocky]

@rocky I have been thinking about this and a <script src="https://raw.githubusercontent.com/Mathics3/graphics3d.js/master/build/index.js"></script> would be the best.

Seems like a reasonable place to start. You should be able to create repositories in the Mathics3 space.

[TiagoCavalcante]

You should be able to create repositories in the Mathics3 space.

@rocky ok.

I'll finish what I'm doing, then solve the subsections problem, and then do it.

[rocky]

Actually, we'd want this installed locally in Mathics-Django as well because you don't want to count on github or the internet to have Mathics-Dango running.

That's why I like something like npm. And a npm package can get the right version of threejs which is also important.
And Mathics-Django just needs to do an npm install.

There may be other things like npm, but using a packager seems better.

[rocky]

Of course there is a git repository for the package, but a <script> tag with a URL is not really a packaging mechanism.

[TiagoCavalcante]

Actually, we'd want this installed locally in Mathics-Django as well because you don't want to count on github or the internet to have Mathics-Dango running.

@rocky yes, you're right. I just think that one more dependency (npm) isn't good. What do you think of git submodules?

[rocky]

I have used git submodules in the past. That too is not a packaging mechanism. It is a git mechanism for gluing together git.

I think we want this packaged if it is to be used in other projects which may or may not use git.

Here's the bigger picture. Initially this is a Mathics thing going to three.js However as part of making this a separate project is documenting the JSON structures (the input to mathics.js/graphics3d.js). This is nothing more than documenting reasonable JSON structures for WL graphics as well.

And once the JSON structures are documented, then you could swap out the three.js for some other graphics library. Or swap out Mathics for Mathematica if someone wants to do that.

[TiagoCavalcante]

I have used git submodules in the past. That too is not a packaging mechanism. It is a git mechanism for gluing together git.

I think we want this packaged if it is to be used in other projects which may or may not use git.

Yes, makes sense. We using git submodules will do someone thing "they don't update the npm version as they don't use it". Also, I guess almost everyone has Node.js.

Here's the bigger picture. Initially this is a Mathics thing going to three.js However as part of making this a separate project is documenting the JSON structures (the input to mathics.js/graphics3d.js). This is nothing more than documenting reasonable JSON structures for WL graphics as well.

Yup, I thought in use JSDocs.

And once the JSON structures are documented, then you could swap out the three.js for some other graphics library. Or swap out Mathics for Mathematica if someone wants to do that.

I thought in pure WebGL (or if it ever be released: WebGPU). I guess switching between libraries is replace 6 by half a dozen.