Just been watching presentation by SW on periscope but could not see the screen. There was mention of better database connection (?) and he gave an example of accessing their bug database. He then mentioned connection to sparkle and mongo. It was all a bit vague without seeing the screen. Can anyone point me in the direction of where I may find this functionality in 11.2?
@MikeHoneychurch I thought all database functionality was in database link, but JDBCDriverNames[] yields nothing relating to Mongo. Theoretically you should be able to any basic Java-based connection driver: see this for those details
I have found 260 integrals in the CAS integration tests, where the anti-derivative size blows up in 11.2 compared to version 9. Each one of these generate in 11.2 at least leaf count 5 times or more than in version 9. Same integral. Should I post these on this forum asking if someone can identify common cause in addition to reporting them to WRI or just report these to WRI?
many blow up by more than 5 times. Such as 50 times as large, or 100 times as large. I just picked the ones which are at least 5 times are large. This regression is very strange to me. Something changed after version 9 in integrate.
@C.E. Ok, sure. I thought it will be useful for the community also. But I am trying to decide how to do this. Here is the current report FYI 12000.org/my_notes/CAS_integration_tests/reports/separate/… the problem is there are so many of them. May I should select few of them, which really blow up by factor of 50 or more. For now, I have to go sleep. School tomorrow. Will try to post this after that.
@Nasser You could just say something like "Take for instance this integral: .... in Mathematica 9 it had a leaft count of foo, but Mathematica 11 it has a leaf count of bar. I have found many such examples, which I have posted to website."
@Rumplestillskin No, it's not. As mentioned in this document, "When you select "DifferenceOrder"->Automatic, the code will automatically attempt to choose the optimal order method for the integration."
@JasonB. I don't think they changed it ... did they? But they redefined mint to be int64_t from stdint.h, which is still 64-bit, just like the previous long was. But now it is ultimately equivalent to long long (which is how my compiler typedef's int64_t). That caused me some inconvenience because the compiler considers long and long long to be distinct types, even though they have exactly the same underlying representation.
@JasonB. C and C++ try to be general and platform-independent, so the standard does not define the size or even the representation of these types.
@JasonB. Right now on OS X long and long long have the exact same representation. It's safe to long long *a; reinterpret_cast<long *>(a) in C++. But you still need to cast because of the quirk that the language considers them distinct types.
On 64-bit Windows, long would be 32-bit (!) and long long is 64-bit.
I asked if C++11 is okay for LTemplate because it makes it much easier to make it resistant to thes kinds of changes and platform-differences. I'm in the process of cleaning it up now. But I'm using new C++ features which I'm not yet comfortable with, so it takes a while.
@JasonB. I pushed it to the types branch. Let me know if anything is wrong. Probably there are still problems. I need to test a lot more before it goes on the master branch.
I haven't tested on Windows and 32-bit Linux at all yet.
I have been looking into TracePrint[MersennePrimeExponentQ[n]], funny that internally there are two list of Mersenne prime exponents, the first 45 (out of 49 known) in "LanguageNumbersDump$MersennePrimeExponents" used by MersennePrimeExponent and also the last 4 known (45th -49th) in "LanguageNumbersDump$provMersennePrimeExponents" used in MersennePrimeExponentQ but not in MersennePrimeExponent.
Why would they separate the list of known Mersenne Prime Exponents in two lists instead of a single one?
Never mind, the reason is that not all primes between the 45th and 49th have been eliminated as candidates (mersenne.org/primes).
So in that case Mathematica will claculate it, a task likely to last several months crunching "brute force" Language`NumbersDump`mersennePrimeExponentQ[n]
I'm wondering whether there's any way to access the components of a symbolic vector if I use syntax similar to Integrate[Norm[x], x \[Element] Ball[{0, 0, 0, 0, 0}]]
in particular, if I want to limit my integration to z > 0, I could write Integrate[Norm[{x,y,z}] Boole[z>0], {x,y,z} \[Element] Ball[{0, 0, 0}]]
but writing Integrate[Norm[r] Boole[r[[3]]>0], r \[Element] Ball[{0, 0, 0}]] gives an error to the effect of 3 being greater than the length of r
…sorry, replace the above instances of Ball with Sphere—I'm using v10, so Sphere describes just the (n-1)-dimensional spherical shell
in any case, based on this, it makes intuitive sense that r should only have two elements, as the surface is parametrized by two coordinates. I can't figure out, though, how to determine what these two coordinates actually are
I guess I probably just have a general misunderstanding of how "symbolic vectors" work
thoughts / advice?
r . {0,0,1} seems like an okay hack, but it seems like there should be a better way
@JulianWolf - not sure of the specifics of your problem, but start with syntax that works, and build from there: Integrate[Norm[{x, y, z}], {x, y, z} \[Element] Ball[{0, 0, 0}, 1]]
