Mathematica 10.3 Release

Posted 6 years ago
19873 Views
|
24 Replies
|
31 Total Likes
|
24 Replies
Sort By:
Posted 6 years ago
 Opening an older notebook, Mathematica 10.3.0 -- thank you all over there for the work with it -- says it will convert it to new default styling. The result isa thouroghly commented code - what the heck? Only half of the code is visible now, the rest let us know that e.g. in German a SparseArray can be denoted as dünnbelegtes Feld ... how can this be undone and banned that it never never happens again? If this feature should make any sense, then I want to see the comments in Italian to learn it a little bit .... oh no Santa Maria.
Posted 6 years ago
 Udo, perhaps uncheck the "Show Code Captions" checkbox in the first panel of the preferences?
Posted 6 years ago
 Note that I have no idea if this is the issue... but it's the only thing I can find that may relate to your issue.
Posted 6 years ago
 It was the issue, many thanks, David. By the way, I can have code captions e.g. in French, in Russian as well as in Chinese language flavours, even in Portuguese, but not yet in Italian :-)
Posted 6 years ago
 Liking all the improvements, when trying to break new speed records in the calculating digits of the MRB constant, I was disappointed in the speed of V10.3. Has anyone else noticed a slowdown? For the following example I calulate 10,000 and 20,000 digits using the following code (*Fastest (at MRB's end) as of 24 dEC 2014.*) prec = 10000;(*Number of required decimals.*)ClearSystemCache[]; T0 = SessionTime[]; expM[pre_] := Module[{a, d, s, k, bb, c, n, end, iprec, xvals, x, pc, cores = 16, tsize = 2^7, chunksize, start = 1, ll, ctab, pr = Floor[1.005 pre]}, chunksize = cores*tsize; n = Floor[1.32 pr]; end = Ceiling[n/chunksize]; Print["Iterations required: ", n]; Print["end ", end]; Print[end*chunksize]; d = Cos[n ArcCos[3]]; {b, c, s} = {SetPrecision[-1, 1.1*n], -d, 0}; iprec = Ceiling[pr/27]; Do[xvals = Flatten[ParallelTable[Table[ll = start + j*tsize + l; h = Log[ll]/ll; x = N[Exp[h], iprec]; pc = iprec; While[pc < pr, pc = Min[3 pc, pr]; x = SetPrecision[x, pc]; y = x^ll - ll; x = x (1 - 2 y/((ll + 1) y + 2 ll ll));];(*N[Exp[Log[ll]/ll], pr]*)x, {l, 0, tsize - 1}], {j, 0, cores - 1}, Method -> "EvaluationsPerKernel" -> 4]]; ctab = ParallelTable[Table[c = b - c; ll = start + l - 2; b *= 2 (ll + n) (ll - n)/((ll + 1) (2 ll + 1)); c, {l, chunksize}], Method -> "EvaluationsPerKernel" -> 2]; s += ctab.(xvals - 1); start += chunksize; Print["done iter ", k*chunksize, " ", SessionTime[] - T0];, {k, 0, end - 1}]; N[-s/d, pr]]; t2 = Timing[MRBtest2 = expM[prec];]; MRBtest2 I tested V9.0,10.0,10,1,10,2, and 10.3, with each one running without any of the others being open, and recorded the best out of the first three tries: 10,000 digits (prec=10000) V9.0 11.9373778 sec V10.0 10.9894860 sec V10.1 10.4070760 sec V10.2 10.7357446 sec V10.3 28.4373030 sec 20,000 digits (prec=20000) V9.0 55.6419174 sec V10.0 49.0587499 sec V10.1 48.2027381 sec V10.2 48.2796596 sec V10.3 111.9064210 sec Version 10.1 seemed to be the fastest, but I've found that 10.2 catches up to 10.1 in larger calculations. However, it looks like 10.3 is a lost cause for this program! The one command program, Timing[N[Sum[(-1)^n (n^(1/n) - 1), {n, 1, Infinity}, Method -> "AlternatingSigns"], 3000]] is just a little slower in 10.3. It could be that about each and every command is just a little bit slower in 10.3 than in those other recent releases.
Posted 6 years ago
 I cannot replicate the slowdown timings. You might want to check that the parallel kernels are actually launching and running.
Posted 6 years ago
 I can replicate the slowdown on OS X, M10.3, 4-core i7 processor (MacBook Pro). It's also good to note that Timing doesn't measure time used by the parallel kernels (AbsoluteTiming does). I didn't try to isolate the slowdown ...
Posted 6 years ago
 Thanks. We have now replicated the slowdown and a bug report has been filed.
Posted 6 years ago
 I didn't pay much attention to this thread originally, but now I see the parallelization performance problem come up in other contexts. Is there any chance this will get fixed somehow before the next major Mathematica version (10.4 or 11)?
Posted 6 years ago
 @Daniel Lichtblau I found a small error in the documentation of ImagePartition. In the "Details and Options" section of the help. In the online version it says: Hold[TransmogrifyPrivateMakeItSo[Evaluate[SelectChildren[][[1]]]]] In the desktop version it shows a red error box. Something went wrong during the inclusion of the new UpTo command in the documentation.
Posted 6 years ago
 You can report documentation problems online at the bottom of each page. In my experience, most things I report do tend to get corrected eventually, so I believe someone at WRI does read these reports.
Posted 6 years ago
 I didn't know about that button, thanks for pointing out!
Posted 6 years ago
 Sorry, at the bottom of what page?
Posted 6 years ago
 At the bottom of any Documentation page e.g.: https://reference.wolfram.com/language/ref/ImagePartition.html there is a button Give Feedback.
Posted 6 years ago
 Thanks a lot. I was looking for it in the Online Help.-Tomas
Posted 6 years ago
 Is anyone else having a delay in the 10.0.3 showing up in their registered products? For some reason my available download is still 10.0.2 for all OS types. I have a full (desktop) Mathematica home license.
Posted 6 years ago
 Hi Lenny, Did you pay for the 10.3 upgrade. The 10.x upgrades are not for free (only the 10.2x in your case). If you did I would contact wolfram support.
Posted 6 years ago
 No I have not paid for any "minor" upgrades. I thought that you only had to pay for major updates EG Mathematica 9 to 10 (Which I did pay for the upgrade). I was under the assumption that after paying for Mathematica 10 I would get all 10.xx updates for free. Looking at my account I do not see any option to actually pay for minor updates.
Posted 6 years ago
 Going to the actual Wolfram store and choosing upgrade allows me to enter my activation key which does give me the option to upgrade to Mathematica 10.3. That clears that up :)
Posted 6 years ago
 Hi,Might I ask whether the bug I remarked in my post"Graphs with multiple edges and problems with edges layouts and colouring"has been solved in the new v10.3?My understanding is that the posted issue is clearly a bug.From the documentation in the Help, it can be understood that everything valid for an edge of a graph is also valid for all edges; there is no documented warning for any exception. So it may be considered a bug since some features either work or not depending on varying conditions and this is not documented. I would need the full feature available and if the answer is affirmative I would upgrade. P.S.Is there any way to insert links to other posts?
Posted 6 years ago
 No, unfortunately it hasn't.In general, it doesn't seem to be possible to assign different properties to multiple edges running between the same vertices (regardless of what properties we're looking at, edge style, edge weight, custom properties or something else).Given the design of Graph, I really wonder how this will get fixed without major breaking changes. In Mathematica edges are referred to by their endpoints. There is no way to distinguish parallel edges when referring to them this way. Which edge is SetProperty[{g, 1<->2}, ...] going to change? But let us trust in the resourcefulness of Wolfram developers.Related:http://mathematica.stackexchange.com/questions/74125/color-edges-of-a-multigraph-when-there-are-parallel-edges-using-graph-and-edgehttp://mathematica.stackexchange.com/questions/92014/issues-adding-properties-to-multigraphhttp://mathematica.stackexchange.com/questions/92360/graphdistance-gives-incorrect-result-in-weighted-multigraphYou can link to other posts the same way as linking to any other website. Just paste the URL or use the link button in the toolbar.
Posted 6 years ago
 Szabolcs, thanks for your reply.Yes, it seems that Wolfram has made a sound mistake on the very roots of the definition of the Mathaematica Graph tool.However, I gather from the appreciated, and smart, reply by Jaebum Jung inhttp://community.wolfram.com/groups/-/m/t/603839?ppauth=qNrI6umOthat there would be a way out to the issue without need to expect a redefinition of the foundations of the concept.In that direction, I wonder whether WRI could (or actually should) provide a free patch under the form of a package including a set of routines for the missing properties of the graphs with duplicated edges. After all, it is a latent or hidden vicious of the product, rather than an inadvertent mistake on a lateral or minor thing made by the designers.For example, along with the available standard set of edges provided by EdgeIndex (which 'ignores' the duplicated edges), a possible solution could be a standard package providing another internal or parallel an different index associated to the positions of the whole edges in the EdgesList). Solving the problem depicted in the image below (part of the notebook I attached in the link above) There is no distinction between the first "M" \[DirectedEdge] "V" (in 'edgesRed') and the last "M" \[DirectedEdge] "V" (in 'edgesPurple'). They carry the same name because they connect the same pair of vertices but they are in different contexts and are different objects. (* edge indices of 'MVPQGraph' *) ei = EdgeIndex[MVPQGraph, #] & /@ EdgeList[MVPQGraph] {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 3, 4, 13, 7, 10, 5} (* position edge indices *) pei = Flatten[Position[EdgeList[MVPQGraph], #] & /@ EdgeList[MVPQGraph]] {1, 2, 3, 11, 4, 12, 5, 16, 6, 7, 14, 8, 9, 10, 15, 3, 11, 4, 12, 13, 7, 14, 10, 15, 5, 16} The sophisticated solution proposed by Jaebum seems to set the way. I havent explored it in depth yet, but, in any a case it is too tricky for being of any use for the common Mathematica user or even for the advanced: I guess the Mathematica is a tool not an end for most of us.It is my view in case it be of any use for the Community.Martin.
 In version 10.3.1 Wolfram research seems to have fixed the regression I noticed while calculating digits of the MRB constant. V10.3.1 is actually a little faster than the pre-10.3 versions in the program I was using.For the following example I calulate 10,000 and 20,000 digits using the following code (*Fastest (at MRB's end) as of 24 dEC 2014.*) prec = 10000;(*Number of required decimals.*)ClearSystemCache[]; T0 = SessionTime[]; expM[pre_] := Module[{a, d, s, k, bb, c, n, end, iprec, xvals, x, pc, cores = 16, tsize = 2^7, chunksize, start = 1, ll, ctab, pr = Floor[1.005 pre]}, chunksize = cores*tsize; n = Floor[1.32 pr]; end = Ceiling[n/chunksize]; Print["Iterations required: ", n]; Print["end ", end]; Print[end*chunksize]; d = Cos[n ArcCos[3]]; {b, c, s} = {SetPrecision[-1, 1.1*n], -d, 0}; iprec = Ceiling[pr/27]; Do[xvals = Flatten[ParallelTable[Table[ll = start + j*tsize + l; h = Log[ll]/ll; x = N[Exp[h], iprec]; pc = iprec; While[pc < pr, pc = Min[3 pc, pr]; x = SetPrecision[x, pc]; y = x^ll - ll; x = x (1 - 2 y/((ll + 1) y + 2 ll ll));];(*N[Exp[Log[ll]/ll], pr]*)x, {l, 0, tsize - 1}], {j, 0, cores - 1}, Method -> "EvaluationsPerKernel" -> 4]]; ctab = ParallelTable[Table[c = b - c; ll = start + l - 2; b *= 2 (ll + n) (ll - n)/((ll + 1) (2 ll + 1)); c, {l, chunksize}], Method -> "EvaluationsPerKernel" -> 2]; s += ctab.(xvals - 1); start += chunksize; Print["done iter ", k*chunksize, " ", SessionTime[] - T0];, {k, 0, end - 1}]; N[-s/d, pr]]; t2 = Timing[MRBtest2 = expM[prec];]; MRBtest2 I tested V9.0,10.0,10,1,10,2, 10.3 and now 10.3.1, with each one running without any of the others being open, and recorded the best out of the first three tries:10,000 digits (prec=10000) V9.0 11.9373778 sec V10.0 10.9894860 sec V10.1 10.4070760 sec V10.2 10.7357446 sec V10.3 28.4373030 sec V10.3.1 10.070777 20,000 digits (prec=20000) V9.0 55.6419174 sec V10.0 49.0587499 sec V10.1 48.2027381 sec V10.2 48.2796596 sec V10.3 111.9064210 sec v10.3.1 44.6207533