Does anyone know if there's a good tabular format for I/O in both Mathematica and python? I'm working on a little framework for working with python sessions at the ProcessObjectlevel, and one quick way to improve performance is to dump to a temporary file rather than passing it through the system buffers when object sizes get too large. I've been using JSON as my serialization format, but for big tables of data (1000x1000 matrices) it's brutally slow to import.

What I mean by that: it takes ~4.81675 seconds to generate that matrix and export to file on the python side, then import from that file on the Mathematica side.

4.54162 seconds of that are on the Mathematica import

Wow but if I use "RawJSON" it only takes .317285 seconds

I think I have a fix for my issue

With Version 11.2 the graphics in the tutorial of Drawing Tool have disappeared !

Compare Version 11.0 :

with 11.2 :

Otherwise I have several problems when editing graphics with Drawing Tool.

Any information somewhere ?

@andre I'd report this were I you, with a mention of what OS you're using.

@J.M. Done ! By the way my OS is Windows 7 64 bits

Discovered something amazing about Mathematica integrate when I compared different versions against same test. But before I show what I found, I'd like to ask if any one knows if Integrate was re-written or had major changes in version 10 compared to version 9?

I googled this and not able to find something about major change in Integrate in version 10 compared to 9. So this is very strange result. In version 10 and 11, integrate average CPU time used and also average leaf size of the anti-derivatives generated in much larger than in version 9 and earlier. This for me indicate some regression. Here are the plots just generated. If someone can shed light on this, it will be interesting to learn why this happened.

Both CPU time and leaf size increased. But overall passing result did not really change much between 9 and 10 to count for this. If 10 would have solved 100% vs. 9 solving say 70% then OK, this would have been a good trade off:

May be the algorithms used internally changed in integrate after version 9?

Actually version 9 scored better when looking at quality of result of integrate. It has higher A graded ones than 10 and 100. The same grading is used for all versions.

fyi, updated report can be found at same link I posted before. I still need to add more stats and post the actual Latex output of all the integrals run. This uses RUBI CAS test suite (lite version) which contains 15,000 integrals. 12000.org/my_notes/CAS_integration_tests/index.htm

@Nasser I don't have much thought on the leaf/CPU increase between 9 to 10, but I just want to say that I've found your integration comparison analysis very helpful. Do you have any opinion as to if integration is best done through a heavily rule-based approach like RUBI, or if the Risch algorithm can be just as good or better?

Does anybody know any really good reason why 0. + x should not simplify to x ? Compare this to 0+x, which does evaluate to x. I am sure a long time ago I tried to argue with the WRI folks and the only thing I remember was something abou keeping information about numerical accuracy (since x is unkown). But why on earth, if there is already 0. ? Also, compare to maxima (apt-get install maxima):

This is related to my answer.

Perhaps because in MMA, if a floating point is encountered, it tends to transform all other things to floats. If 0. + x simplified to just x, in the case of x = 1, there would be a question of what to evaluate first. Should we first substitute the value for x and then get a floating result of 1., or should we first eliminate the 0 and then get a result of the integer 1.

@RolfMertig here is related post on this 0. thing not simplifying mathematica.stackexchange.com/questions/34967/…

@CoryWalker "Do you have any opinion as to if integration is best done through a heavily rule-based approach like RUBI, or if the Risch algorithm can be just as good or better" this is a $64,000 Question. Originally, integrators were actually written using rule base, table look up, or pattern matching, which solves many of the common integrals found in calculus books. But to fully answer your question will be something I could not really do. This is a good question to post at sci.math.symbolic

As far as I know, FriCAS has the most complete Risch algorithm, and it can solve some integrals which mathematica and rubi could not. For example, here is one: Integrate[(E^(x/(2 + x^2))*(2 + 2*x + 3*x^2 - x^3 + 2*x^4))/(2*x + x^3),x] this was solved only by Fricas, since it uses Risch and has special case extensions. Rubi does not have a rule for this one.

Mathematics also has implementation of Risch, so it looks like Fricas has implementations of additional special cases, or extensions to Risch in this case which allowed it to solve this one.