https://community.wolfram.com RSS Feed for Wolfram Community showing any discussions tagged with Tuning and Debugging with no replies sorted by most likes. https://community.wolfram.com/groups/-/m/t/1241974 After debugging a large chunk of code, I could identify this [MWE](https://en.wikipedia.org/wiki/Minimal_Working_Example). ClearAll@test test[var_String]:= Block[{association}, association = <|"x"-> <|"key01"-> "ok"|>|>[var]; Lookup[association,"key01",{}] ] If I evaluate: test["x"] test["y"] test["x"] I get an error evaluating the last `test["x"]`. What is very strange, I expected to find an error just in the evaluation of `test["y"]`. The same error does not occur if we change from Block to Module. In the Block case, we have some sort of unexpected scope leak. Looks like a bug in `Lookup`. Tested in Mathematica version 11.3 [Cross post](https://mathematica.stackexchange.com/questions/161616) in Stack Exchange Rodrigo Murta 2017-12-08T21:32:33Z https://community.wolfram.com/groups/-/m/t/1071528 For those who use `NeighborhoodGraph`, be aware: when called with default options, this functions performs much worse than it should. The reason is that it computes a graph layout even if the result is never displayed. Let's see how slow it is on a big graph: g = RandomGraph[BarabasiAlbertGraphDistribution[50000, 3]]; NeighborhoodGraph[g, 1]; // AbsoluteTiming (* {61.2058, Null} *) And now do the same computation using `AdjacencyList`: Subgraph[g, Append[AdjacencyList[g, 1], 1]]; // AbsoluteTiming (* {0.019827, Null} *) **It's 3000 times faster, even though it does the same thing!** Why? Because `NeighborhoodGraph` recomputes the graph layout. Turn this off, and it becomes fast: NeighborhoodGraph[g, 1, GraphLayout -> None]; // AbsoluteTiming (* {0.018846, Null} *) Why does `NeighborhoodGraph` compute the graph layout? I do not know, but it makes no sense at all, given that the result may never be displayed. Mathematica can generally work just fine with graphs that are simply too large to visualize in a reasonable amount of time. But not `NeighborhoodGraph`. What is frustrating is that this problem was reported 4 years ago, and mentioned multiple times on this very site. Yet it is still unfixed in version 11.1. Unfortunately, this is an all too common experience with `Graph`-related functions. Szabolcs Horvát 2017-04-24T18:58:10Z https://community.wolfram.com/groups/-/m/t/323055 Scenario - a series of distances between GPS points. (Some overhead in getting there too). Fold the list for accumulated distances along a path. How costly are units? About 3 orders of magnitude after realizing that 0.0 is converted on every function call. (* series of distances between points, will accumulate the path length *) points = 30000; distances = Table[Quantity[RandomReal[{10., 100.}], "Meters"], {points}]; Timing[ path = FoldList[Plus, 0.0, distances]; ] (* Lets not forget to put the same units on that zero - could be the source of a gotcha *) distances = Table[Quantity[RandomReal[{10., 100.}], "Meters"], {points}]; Timing[ path = FoldList[Plus, Quantity[ 0.0, "Meters"], distances]; ] (* what if I stick to unit-less data? *) rawdistances = Table[RandomReal[{10., 100.}], {points}]; Timing[ path = FoldList[Plus, 0.0, rawdistances]; ] {28.984986, Null} {7.597249, Null} {0.015600, Null} What about Accumulate? (Only 1000 points - far worse) points = 1000; distances = Table[Quantity[RandomReal[{10., 100.}], "Meters"], {points}]; Timing[ path = Accumulate[distances]; ] {23.868153, Null} Douglas Kubler 2014-08-18T15:01:07Z https://community.wolfram.com/groups/-/m/t/1087153 Dear community, I am the main author of an old Quantum Mechanics add-on for Mathematica. We are not updating it anymore because we are creating a totally new Quantum Mechanics package, it will be very likely called qmDirac. The old Quantum Mathematica was very difficult to update, because through the years I wrote a messy source code. Our new qmDirac package is in a very early stage of development, however it would be great for me if you or your students try to use it, and let me know your thoughts and suggestions, this is the link: [http://qmdirac.weebly.com/beta-testers.html][1] Please take into account that the old Quantum Mathematica and the new qmDirac are not compatible, you cannot copy-paste from one to the other, neither use one file with symbols from one with the other, it will not work. As I said, the new qmDirac is in a very early stage, I believe you might find it is slow, or perhaps even wrong, in some calculations; please let us know if that is the case, as well as suggestions for new commands of functionality that you would like to use. And, well, we do not have any real documentation yet, just very few examples, without any explanation, in this link: [http://qmdirac.weebly.com/examples.html][2] Anyway I hope our efforts can be of some help to your research and teaching work. Hope to hear from you or from your students soon in this forum. Jose Mexico [1]: http://qmdirac.weebly.com/beta-testers.html [2]: http://qmdirac.weebly.com/examples.html Jose Gomez 2017-05-08T20:14:25Z https://community.wolfram.com/groups/-/m/t/272658 Notes I was given when the debugger was new. <BR> No promises that the debugger hasn't changed in the years since. ============== <BR> Some notes on the debugger buttons are linked to from the "Details" section of <BR> [http://reference.wolfram.com/mathematica/ref/menuitem/DebuggerControls.html][1] The code the instructions refer to is Module[{a}, Do[ a = {i, Sin[i]}, {i, 100}]] * the debugger is enabled by choosing Evaluation menu > Debugger from the menu bar. * a palette will open * select the code you are interested in examining (e.g., triple click on a variable) * press the "Break at Selection" button in the debugger palette * evaluate your example * note that the evaluation pauses and the "a = ..." block is highlighted. * click "Show Stack" in the debugger palette * this brings up a window showing you what is evaluating * in the stack window click the opener triangle labeled "Local Variables" * here you can see that the variable does not yet have a value * press the "Step" button in the debugger palette * note that "a" now has the value {1, Sin[1]} * press "Step" again * note that "a" now has the value {2, Sin[2]} * press "Continue" on the debugger palette a few times * it will stop each time it hits the "a = ..." breakpoint * click the "Show Breakpoints" button on the debugger palette * delete the breakpoint * press "Continue" on the debugger palette * the evaluation will complete The most common gotcha to the Mathematica debugger is that it works only for code which has been evaluated *after* the debugger has been enabled. You can't evaluate a function, turn on the debugger, then debug code which uses that function. You must first turn on the debugger, then evaluate all function definitions you wish to debug, then you can set working breakpoints and step through code. ============== [1]: http://reference.wolfram.com/mathematica/ref/menuitem/DebuggerControls.html Bruce Miller 2014-06-08T23:21:55Z https://community.wolfram.com/groups/-/m/t/3353494 I just began experimenting with running wolframsrcipt on Macos, so far the startup time is very disappointing. I wrote the following script: #!/usr/local/bin/wolframscript Print["hello"] Running this script takes roughly five seconds, consistently. For instance, here I time the script from bash: ~/bin # time ./hello.wls hello real 0m4.809s user 0m0.173s sys 0m0.049s Here is the version info for my installation of wolframscript: ~/bin # wolframscript -info Wolfram 14.1.0 Kernel for Mac OS X x86 (64-bit) Copyright 1988-2024 Wolfram Research, Inc. Is this typical performance? A five second startup for a trivial script is a deal breaker for me. If anyone can suggest ways to make this faster, or to diagnose the reasons for the slow startup I'd love to explore them. On the other hand, if this is the expected level of performance I'll explore other avenues for my scripting needs. Thank you. David Cabana David Cabana 2025-01-08T19:05:18Z https://community.wolfram.com/groups/-/m/t/2561444 After the installation of 13.1 my standard tests of my paclet revealed that all function using `ListControurPlot3D` changed. I was always aware that in `ListContourPlot3D` the data is somehow transposed if you provide it as an array as can be seen in the following code. And for data with isotropic dimensions (21x21x21) it seems that both versions behave the same. dat = Table[ x^2 + y^2 - z^2, {x, -2, 2, 0.2}, {y, -2, 2, 0.2}, {z, -2, 2, 0.2}]; dat2 = Flatten[ Table[{x, y, z, x^2 + y^2 - z^2}, {x, -2, 2, 0.2}, {y, -2, 2, 0.2}, {z, -2, 2, 0.2}], 2]; Dimensions[dat] opts = Sequence[{Mesh -> None, AxesLabel -> {"x", "y", "z"}, ImageSize -> 200}]; Row[{ ContourPlot3D[ x^2 + y^2 - z^2 == 0, {x, -2, 2}, {y, -2, 2}, {z, -2, 2}, Mesh -> None, AxesLabel -> {"x", "y", "z"}, ImageSize -> 200], ListContourPlot3D[dat, Contours -> {0}, opts], ListContourPlot3D[Transpose[dat, {3, 2, 1}], Contours -> {0}, opts], ListContourPlot3D[dat2, Contours -> {0}, opts] }] 13.0.1 ![enter image description here][1] 13.1 ![enter image description here][2] But now consider the same data but with anisotropic dimensions (11x41x81). It has always been that the dimension index would be {z, y, x}. But with 13.1 it changed to {x, y, z}. Which i get since now this function is actually agreeing with the other 3D plotting functions. However, although the axes indexes / labels are changed the data orientation is not but should have been. This is giving wrong plots. dat = Table[ x^2 + y^2 - z^2, {x, -2, 0, 0.2}, {y, -2, 2, 0.1}, {z, -2, 2, 0.05}]; dat2 = Flatten[ Table[{x, y, z, x^2 + y^2 - z^2}, {x, -2, 0, 0.2}, {y, -2, 2, 0.1}, {z, -2, 2, 0.05}], 2]; Dimensions[dat] opts = Sequence[{Mesh -> None, AxesLabel -> {"x", "y", "z"}, ImageSize -> 200}]; Row[{ ContourPlot3D[ x^2 + y^2 - z^2 == 0, {x, -2, 0}, {y, -2, 2}, {z, -2, 2}, Mesh -> None, AxesLabel -> {"x", "y", "z"}, ImageSize -> 200], ListContourPlot3D[dat, Contours -> {0}, opts], ListContourPlot3D[Transpose[dat, {3, 2, 1}], Contours -> {0}, opts], ListContourPlot3D[dat2, Contours -> {0}, opts] }] 13.0.1 ![enter image description here][3] 13.1 ![enter image description here][4] In my opinion both are actually wrong but in 13.0.1 the data orientation was wrong but consistent with the axes. In 13.1 the axes are correct but the data is not consistent with the axes. My workaround used to be to just Transpose the data, now my workaround is to convert the arrays to coordinate lists {x, y, z, f}. Is this a know issue / bug, or is it by design and am i missing something. [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=1301iso.png&userId=1332602 [2]: https://community.wolfram.com//c/portal/getImageAttachment?filename=131iso.png&userId=1332602 [3]: https://community.wolfram.com//c/portal/getImageAttachment?filename=1301aniso.png&userId=1332602 [4]: https://community.wolfram.com//c/portal/getImageAttachment?filename=131aniso.png&userId=1332602 Martijn Froeling 2022-07-01T09:52:44Z https://community.wolfram.com/groups/-/m/t/2305316 I was hoping to seek the advise of others that may have tackled (or been tackled by) the problem of having a large dataset to query in Mathematica. My situation is that I have a large association (ByteCount 100Gb constructed from sequences in the human genome) that I am using as a hash table because the performance combination of Lookup with Associations is spectacular. Even with the amazing performance mentioned, I still expect the querying of the association to be a bottleneck because of the number of queries to the association that is needed to process multiple datasets of experimental data. My experience with ParallelTable and friends in Mathematica is that you get the best performance benefit if you are transmitting very little data back and forth between kernels. If this condition is not met, then the performance of parallel constructs is often worse that their equivalent serial peers. Questions that come to mind: A. Is there any known way of use parallel constructs to query an association that avoids the need for each parallel kernel to have it's own copy of the association? (I am looking for concurrent hash table functionality in Mathematica.) B. Since I suspect the answer to Question A is "no", does anyone know if the good folks at Wolfram are working to improve the capabilities / performance of parallel functionality in Mathematica? I am not looking for deep insider secrets, but it does seem that attention to this functionality had waned as documentation reveals the last revision for many parallel commands was in 2010. C. Has anyone used an external concurrent hash table in their own projects that they linked back into Mathematica? Would you be willing to share your experience? I appreciate your thoughts and advice. Todd Todd Allen 2021-07-04T21:18:10Z https://community.wolfram.com/groups/-/m/t/977819 I would like to start a discussion on how to best handle errors in Mathematica. You are writing a package that many people will use. They may use your functions interactively, or they may use them inside larger functions they define. There is an error condition in your function—incorrect input, can't solve the problem, unexpected failure, etc. What should your function do? There is already a great post by Leonid about this here: * http://mathematica.stackexchange.com/a/29323/12 I thought it was time to revisit the topic and share some thoughts about how each of us typically handles errors. To get the discussion started, here are some things to think about: - The error should be communicated in a user-friendly manner to interactive users - There should be an easy way to catch and handle the error programmatically - It should be easy to track down where the error occurred in a large code block (e.g. function `X` should associate its messages with `X`) Typical ways used by builtins: - Issue a message and stay unevaluated (e.g. `Integral`) (not friendly to programmatic error handling) - Return `$Failed`, with or without an accompanying message - Return `Failure[...]` (e.g. `Interpreter`) - `Throw` something (not friendly to interactive users) - Some functions are designed in such a way as to never error out, e.g. most `Q` functions, like `OddQ`, will always return `True` or `False` and just return `False` for input that one might consider inappropriate. There are multiple challenges to implementing each, as well as handling each type of error. Szabolcs Horvát 2016-12-10T17:59:32Z https://community.wolfram.com/groups/-/m/t/516227 *Vitaliy Kaurov suggested that I cross post this [StackExchange original][1] here.* I am trying out Mathematica as a prototyping tool. As an initial exercise I have put together a brute force ray tracer, with a view to using Mathematica's built in probability distribution functions to test out some fancy shaders. (My starting point was the F# ray tracer available http://code.msdn.microsoft.com/ParExtSamples.) As this is a first attempt at using Mathematica, other than as a fancy calculator, I would welcome some **guidance or critique on whether this coding style is going to be effective**. (You will detect from the code that I am accustomed to an object-oriented paradigm.) My own observations, in no particular order, are: 1. It's an enjoyable way to work, as a lot of the busy type definitions and additional syntax required by other languages is not needed here; the code is quite compact and the intention fairly readable (IMHO). 2. I have built the ray tracer from scratch, without using the ***built-in graphics primitives*** as that would defeat the learning purpose of the exercise and I would probably not be able to roll my own shaders. As a simple example, addition is not defined for RGBColor, for example. 3. Probably as a consequence, the tracer is very slow, even if I use all the 4 kernels that are available to me. I dare say that the existing code could be speeded up considerably by removing all the type / pattern matching, but the code would be much harder to follow, I think, and certainly much harder to debug. My approach seems to mean that I cannot take advantage of Compile optimization, so far as I can see. If I wanted a fast ray tracer I would write it in C++, but I wonder whether there are any **easy optimizations that I have missed** (and that don't involve mangling what I have to the extent that the prototyping benefits of Mathematica -- easy refactoring -- would be lost). However, I am surprised that even with 4 kernels, the cpu of this 4-core (8-core, if you count hyperthreading) never maxes out. For example, is it worth changing some of the `:=` to `=`? Things would be even slower if I aliased the results by averaging 4 adjacent traces, for example. **Real time ray tracing** seems out of reach. 4. Ray tracing results in a lot of "corner cases" that are dealt with naturally with **IEEE maths**. Unfortunately Mathematica does produce +/-Infinity for +/-1/0, for example, so some of the code should really be extended to treat those cases properly. 5. It would be great if Mathematica had more built-in ***vector algebra*** so that I could write the equations defining the objects and the rays involved and getting Mathematica to calculate the ray intersection points that are at the heart of the ray tracer. As things stand, `Reduce` and `Solve` have not helped me to find better intersection algorithms, producing either nothing at all or something large an unintelligible, depending on how I posed the problem. Anyway, here is what you get after 110s from `raytrace[400, 400, basescene, 6]`: ![Here is what you get after 110s from `raytrace[400, 400, basescene, 6]`][2] ... and here is the code: (* Colour helpers *) black = {0., 0., 0.}; darkgrey = {.25, .25, .25}; grey = {.5, .5, .5}; white = {1., 1., 1.}; background = black; defaultcolor = black; brightness[{r_, g_, b_}] = Mean[{r, g, b}]; scale[k_, c: {r_, g_, b_}] = k * c; zero = {0.,0.,0.}; (* Mainly for reference; pattern matching normally used instead *) ray /: start[ray[s_, d_]] = s; ray /: dir[ray[s_, d_]] = d; camera /: pos[camera[p_, l_]] = p; camera /: lookat[camera[p_, l_]] = l; camera /: forward[camera[p_, l_]] = Normalize[l - p]; camera /: down[camera[p_, l_]] = {0., -1., 0.}; camera /: right[c : camera[p_, l_]] := 1.5 * Normalize[Cross[forward[c], down[c]]]; camera /: up[c : camera[p_, l_]] := 1.5 * Normalize[Cross[forward[c], right[c]]]; light /: pos[light[p_, c_]] = p; light /: color[light[p_, c_]] = c; scene /: things[scene[t_, l_, c_]] = t; scene /: lights[scene[t_, l_, c_]] = l; scene /: camera[scene[t_, l_, c_]] = c; surface /: diffuse[surface[d_, s_, re_, ro_]] = d; surface /: specular[surface[d_, s_, re_, ro_]] = s; surface /: reflect[surface[d_, s_, re_, ro_]] = re; surface /: roughness[surface[d_, s_, re_, ro_]] = ro; intersection /: thing[intersection[t_, r_, d_]] = t; intersection /: ray[intersection[t_, r_, d_]] = r; intersection /: dist[intersection[t_, r_, d_]] = d; miss = intersection[nothing, ray[zero, zero], Infinity]; sceneobject /: surface[sceneobject[s_, i_, n_]] = s; sceneobject /: intersect[sceneobject[s_, i_, n_]] = i; sceneobject /: normal[sceneobject[s_, i_, n_]] = n; sphere /: center[sphere[c_, r_, s_]] = c; sphere /: radius[sphere[c_, r_, s_]] = r; sphere /: surface[sphere[c_, r_, s_]] = s; normal[sphere[center_, _, _], pos_] = Normalize[pos - center]; plane /: normal[plane[n_, o_, s_]] = n; plane /: offset[plane[n_, o_, s_]] = o; plane /: surface[plane[n_, o_, s_]] = s; normal[plane[n_, _, _], _] = n; (* Axis-aligned bounding box *) (* TODO: not yet used; integrate into tracer *) box /: lowerb[box[l_, u_]] := l; box /: upperb[box[l_, u_]] := u; extendby[box[l_, u_], pt_] := box[MapThread[Min, {l, pt}], MapThread[Max, {u, pt}]]; size[box[l_, u_]] := u - l; majoraxis[b : box[l_, u_]] := Ordering[size[b], -1]; (* TODO: This does not work for cases where dir has 0 compnent as Mathematic returns ComplexInfinity, not +/-Infinity for +/-1/0 *) intersectboxQ[b : box[l_, u_], r : ray[start_, dir_]] := Module[ {tl = (l - start) / dir, tu = (u - start) / dir, tmin, tmax}, (* Swap u[i] and l[i] if dir[i] < 0 to avoid erroneous result because 0 == -0 *) tmin = Max[MapThread[Min, {tu, tl}]]; tmax = Min[MapThread[Max, {tu, tl}]]; Not[tmax < 0 && tmin > tmax]; (* Use Not to cover some Infinity comparisons *) (* Which[ tmax < 0, False, (* Intersection at t = tmax, but it's behind us *) tmin > tmax, False, (* No intersection *) True, True (* Interesection at t = tmin *) ]*) ]; intersect[s : sphere[center_, radius_, _], r : ray[start_, dir_], i : intersection[_, _, currentdist_]] := Module[ {eo = center-start, v, dist, disc}, v = eo.dir; dist = If[ v < 0., 0., disc = radius * radius - (eo.eo - v * v); If[ disc < 0., 0., v - Sqrt[disc] ] ]; If[ dist == 0. || dist > currentdist, i, intersection[s, r, dist] ] ]; intersect[p : plane[norm_, offset_, _], r : ray[start_, dir_], i : intersection[_, _, currentdist_]] := Module[ {denom = norm . dir, candidatedist}, If[ denom >= 0., i, candidatedist = (norm . start + offset) / (-denom); If[ candidatedist > currentdist, i, intersection[p, r, candidatedist] ] ] ]; testray[ray_, scene_] := dist[Fold[intersect[#2, ray, #1]&, miss, things[scene]]]; traceray[ray_, scene_, depth_, maxdepth_] := shade[Fold[intersect[#2, ray, #1]&, miss, things[scene]], scene, depth, maxdepth]; shade[miss, _, _, _] := background; shade[intersection[thing_, ray[start_, dir_], dist_], scene_, depth_, maxdepth_] := Module[ {pos = dist * dir + start, n, reflectdir, naturalcolor, reflectedcolor}, n = normal[thing, pos]; reflectdir = dir - 2. * n . dir * n; naturalcolor = defaultcolor + getnaturalcolor[thing, pos, n, reflectdir, scene]; reflectedcolor = If[ depth >= maxdepth, grey, getreflectioncolor[thing, pos + (0.001*reflectdir), n, reflectdir, scene, depth, maxdepth] ]; naturalcolor + reflectedcolor ]; getreflectioncolor[thing_, pos_, n_, rd_, scene_, depth_, maxdepth_] := reflect[surface[thing]][pos] * traceray[ray[pos, rd], scene, depth + 1, maxdepth]; getnaturalcolor[thing_, pos_, n_, rd_, scene_] := Module[ {addlight, normraydir = Normalize[rd], howrough = roughness[surface[thing]]}, SetAttributes[addlight, Listable]; addlight[light[p_, c_]] := Module[ {ldis = p - pos, livec, neatisect, isinshadow, illum, lcolor, spec, scolor}, livec = Normalize[ldis]; neatisect = testray[ray[pos, livec], scene]; isinshadow = neatisect <= Norm[ldis]; If[ isinshadow, defaultcolor, illum = livec . n; lcolor = If[ illum > 0., illum * c, defaultcolor ]; spec = livec . normraydir; scolor = If[ spec > 0., (spec ^ howrough) * c, defaultcolor ]; diffuse[surface[thing]][pos] * lcolor + specular[surface[thing]][pos] * scolor ] ]; defaultcolor + Total[addlight[lights[scene]]] ]; raytrace[screenwidth_ : 64, screenheight_ : 64, scene_ : basescene, maxdepth_ : 1] := Module[ {getpoint}, getpoint[x_, y_, camera_] := With[ {recenterx = (x - screenwidth / 2.) / (2. * screenwidth), recentery = -(y - screenheight / 2.) / (2. * screenheight)}, Normalize[forward[camera] + recenterx * right[camera] + recentery * up[camera]] ]; Image[ParallelArray[traceray[ray[pos[camera[scene]], getpoint[#2-1, #1-1, camera[scene]]], scene, 0, maxdepth]&, {screenheight, screenwidth}]] // AbsoluteTiming ]; (* Harness *) (* surface diffuse, specular reflect, roughness *) uniformsurface[diffuse_, specular_, reflect_, roughness_] = surface[diffuse&, specular&, reflect&, roughness]; shiny = uniformsurface[white, grey, .7, 250.]; matteshiny = uniformsurface[white, darkgrey, .7, 250.]; checkerboard = surface[ If[ OddQ[Floor[#[[3]]] + Floor[#[[1]]]], white, black ]&, white &, If[ OddQ[Floor[#[[3]]] + Floor[#[[1]]]], .1, .7 ]&, 150.]; basescene = scene[{ sphere[{0., 1., -.25}, 1., shiny], sphere[{-.5, 1.3, 1.5}, 0.5, matteshiny], plane[{0., 1., 0.}, 0., checkerboard]}, {light[{-2., 2.5, 0.}, {.5,.45,.41}], light[{2.,4.5,2.},{.99,.95,.8}]}, camera[{2.75, 2.0, 3.75}, {-.6, .5, 0.}]]; ---------- To illustrate where I am going with this, here is an example of how one could generate a mesh for a more complex object (a polysphere): polyspherepoints[rad_Real, divs_Integer] := With[ {u = -(Pi/2.), v = -Pi, du = Pi/divs, dv = (2.*Pi)/divs}, rad * Flatten[Table[{Cos[du*i + u]*Cos[dv*j + v], Sin[du*i + u], Cos[du*i + u]*Sin[dv*j + v]}, {j, 0, divs}, {i, 0, divs}], 1] ]; (* Put the polygon vertices in the right order *) ordervertices[{{a_, b_}, {c_, d_}}] := {a, b, d, c}; orderverticestotriangeles[{{a_, b_}, {c_, d_}}] := {{a, b, d}, {a, c, d}} (* Generate a list of (polyspherepoint) vertice numbers, partition them cyclically, and then into quads, and associate them with Polygons *) polyspheremeshtriangles[rad_Real, divs_Integer] := Normal @ GraphicsComplex[polyspherepoints[rad, divs], Map[Polygon, Map[orderverticestotriangeles, Partition[Partition[Range[(divs+1)^2], divs+1], {2, 2}, 1, 1], {2}], 1]]; polyspheremeshtriangles[rad_Real, divs_Integer] := Normal @ GraphicsComplex[polyspherepoints[rad, divs], Map[Polygon, Map[orderverticestotriangeles, Partition[Partition[Range[(divs+1)^2], divs+1], {2, 2}, 1, 1], {2}], 1]]; (It would have been satisfying to use some of the geometric transform functions built into Mathematica to generate the vertices, but life was too short.) And here is what `Graphics3D @ polyspheremeshtriangles[1., 8]` generates: ![PolySphere, of trianges][3] [1]: http://mathematica.stackexchange.com/questions/48675/is-this-the-most-effective-and-efficient-programming-style-for-prototyping-a-ra [2]: http://i.stack.imgur.com/AZE08.png [3]: http://i.stack.imgur.com/RU6dD.png jr p 2015-06-20T11:53:40Z https://community.wolfram.com/groups/-/m/t/3222475 Running official notebook from https://resources.wolframcloud.com/FunctionRepository/resources/SuiteSparseMatrix/ fails on `ssm = ResourceFunction["SuiteSparseMatrix"]["ash85"]` with the following error ![enter image description here][1] It appears trying to retrieve `ash85` gives an array of shape `(1, 0)` at some point. Can anyone see a simple fix so that I can run this locally? [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshot2024-07-16at1.12.50%E2%80%AFPM.png&userId=1046145 Yaroslav Bulatov 2024-07-16T20:13:38Z https://community.wolfram.com/groups/-/m/t/2940172 I think I may have stumbled across an issue with Mathematica’s built-in ConcaveHullMesh function that doesn’t seem to arise with Jon McLoone's NonConvexHullMesh resource function. The issue is illustrated in the attached notebook. My guess is that it occurs when the point values are modestly large (fairly typical of cartographical coordinate systems) and/or the number of points exceeds some threshold (noting that the function works when I take a small sample from the point dataset). From what I’m seeing, it looks like Jon's resource function may be more robust than the built-in function. Any thoughts or solutions other than what I've already tried would be welcomed. Many thanks, Ian &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/0941c754-35d6-4c37-b6de-464f0b97877d Ian Williams 2023-06-20T16:50:15Z https://community.wolfram.com/groups/-/m/t/2931747 I often ask for help on Wolfram Community, but this time I have some help to give that I hope will be helpful for others having the same problem. I build a paclet and I get an error with Get. ref/message/General/noopen Cannot open PeterBurbery`LittleChildPaclet`Coins`. and many other errors. &[Wolfram Notebook][1] I fix the error with PacletDirectoryLoad["C:\\Users\\Peter\\OneDrive - Marshall University\ \\GitHub\\wolfram-challenges-paclet\\little-child-paclet"] &[Wolfram Notebook][2] This shows how the error is resolved. &[Wolfram Notebook][3] The error appears again when I run PacletDirectoryUnload. I found another way to load a paclet. This sometimes works when other methods fail. Get /@ FileNames["*.wl", "C:\\Users\\Peter\\OneDrive - Marshall \ University\\GitHub\\basic-hypergeometric-functions-paclet\\basic-\ hypergeometric-functions\\Kernel"]; I had to run this twice to get it to work. Here is something that works better. Do[Quiet[ Get /@ FileNames["*.wl", "C:\\Users\\Peter\\OneDrive - Marshall \ University\\GitHub\\basic-hypergeometric-functions-paclet\\basic-\ hypergeometric-functions\\Kernel"];, Get::noopen], 4] [1]: https://www.wolframcloud.com/obj/efb57ee5-1003-483c-900c-b57ba5bc5204 [2]: https://www.wolframcloud.com/obj/7ade610b-76e2-4f56-b459-4859cc83f23b [3]: https://www.wolframcloud.com/obj/a3f953ca-b965-4965-96cb-c019aa73c6b8 Peter Burbery 2023-06-07T00:46:23Z https://community.wolfram.com/groups/-/m/t/2759635 Hi, I have a looped function, which includes a Map operation, that I've optimized for serial computation whose computation time grows roughly proportional to (N^2+N)/2, where N is the length of the loop. The bottle neck happens at the Map operation, so I do DistributeDefinitions[F, ..., from]; ParallelMap[F[...], from, Method->"CoarsestGrained"]; That works fine except every time I do a new ParallelMap the amount of memory the kernels are using grows until Mathematica crashes (and I have 64 GB of RAM...). Sadly, I find the documentation on parallel processing in Mathematica to be the poorest part of the documentation, mostly because the examples are far too simple (they are also all numeric - I'm doing symbolic computations) but also because there is no documentation on "Parallel`Developer`" nor the functions it contains, and no discussion on managing subkernel memory. At the beginning of my program I set HistoryLength = 0; and disable caching (which does not benefit what I'm doing - that's a different discussion). Those two things only effect the main kernel. So would "ParallelEvaluate[$HistoryLength = 0];" set the history length for the subkernels to 0 (if not we need an option somewhere to do it, assuming the subkernels have a history)? I know I could prevent this problem by quitting the subkernels and relaunching them, but that has a huge overhead cost (~ N AbsoluteTiming[LaunchKernels[]]) and would wipe-out any gains from parallel processing. I have tried "ClearKernels[]" but that doesn't fix the memory problem. So, should I change my code to ClearDistributedDefinitions[]; DistributeDefinitions[F, ..., from]; ParallelMap[F[...], from, Method->"CoarsestGrained"]; Is there anything else I should try? Troy Wahl 2023-01-04T19:04:55Z https://community.wolfram.com/groups/-/m/t/2733766 I'm seeing some significant problems with ListContourPlot3D since version 13.1.0 when viewing signed distance fields (SDFs). Version 13.0.1 produces nice output: &[Wolfram Notebook][5] In 13.1.0: ![enter image description here][2] In 13.2.0: ![enter image description here][3] I have tried increasing MaxPlotPoints, but it doesn't help much. The "9999.bin" data file can be found [here][4]. [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=plot_13_0_1.png&userId=2732343 [2]: https://community.wolfram.com//c/portal/getImageAttachment?filename=plot_13_1_0.png&userId=2732343 [3]: https://community.wolfram.com//c/portal/getImageAttachment?filename=plot_13_2_0.png&userId=2732343 [4]: https://1drv.ms/u/s!Apg07cGOQDoehZZQpd7acKkjpJFGiQ?e=B57Yuu [5]: https://www.wolframcloud.com/obj/8eb6bdee-8634-44fc-a774-d24a8d9205f5 Eric Parker 2022-12-16T23:55:11Z https://community.wolfram.com/groups/-/m/t/2599137 I had previously raised [a question][1] regarding ListContourPlot3D but got no response. For some work i need contours (base on discrete data) in combination with Image3D, which i had working previously. No to make this work i need to jump some hoops to make it work. While looking for alternatives i also looked at ArrayPlot3D where i found some strange behavior also. I am aware of all the different axes conventions Mathematica uses for Images, Graphics, Arrays, Matrixes etc. (would be nice to have a nice guide on this topic since its getting confusing), but based on my experience here there are some internal size and dimension flips for these functions that are unintended. &[Wolfram Notebook][2] [1]: https://community.wolfram.com/groups/-/m/t/2561444?p_p_auth=Rh92C58n [2]: https://www.wolframcloud.com/obj/4e1558ce-b542-4337-aa9c-6b54e1130e71 Martijn Froeling 2022-08-16T12:01:48Z https://community.wolfram.com/groups/-/m/t/2309593 *Postscript after writing this post: I thought I found a bug in Echo and Print. But in fact it was my mistake to misunderstand "Row".* In all my programs I use a global variable testLvl with which I can control echo outputs. I.e.: I can write: testLvl = 3; (* ... *) If[testLvl >= 3, Echo[expr1, label1]]; If[testLvl >= 4, Echo[expr2, label2]]; ![enter image description here][1] To shorten this further, I have my own echo routine that essentially includes this query of testLvl: ClearAll[echo]; echo[expr_, label_ : "", lvl0_Integer : 3] := If[testLvl >= lvl0, Echo[expr, Row[{{testLvl, lvl0}, ": ", label}]] , expr]; testLvl = 3; (* ... *) echo[expr1, label1]; echo[expr2, label2, 4]; testLvl = 4; (* ... *) echo[expr1, label1]; echo[expr2, label2, 4]; ![enter image description here][2] In doing so, I ran into the following problem within my echo routine: The label in Echo[expr, label] should be any expression. According to the documentation it does not have to be a String. Therefore, it could be any Row as an example. This works: Echo[E, "1.: E - Label as a String: "]; Echo[E, Row[{2, ".: E", " - Label as a Row: "}]] ![enter image description here][3] If newlines appear in a String label, Echo still works fine (except for the indentation of the expression): Echo[N[E], "3.: N[E]\nLabel as a String:\n"] ![enter image description here][4] But when newlines occur in a non-string label, say a Row label, a problem occurs. **The label is split and the expression appears somewhere in between**: Echo[N[E], Row[{4, ".: N[E]\nLabel as a Row:\n"}]] ![enter image description here][5] I was afraid this is a Print bug. In any case, **Print shows the same (assumed mis-) behavior**: Print[Row[{5, ".: N[E]\nLabel as a Row:\n"}], N[E]] ![enter image description here][6] It occurs when Print outputs not only a pure Row or a sequence of expressions. Otherwise everything is fine: Print[6, ".: N[E]\nLabel as a String:\n", N[E]]; Print[Row[{7, ".: N[E]\nLabel as a String:\n", N[E]}]]; ![enter image description here][7] Print's documentation says that Print[expr1,expr2,...] concatenates the expressions and effectively uses Row. I.e.: Print[Row[{expr1,expr2,...}]] should output the same. This remains true if one of the expressions is itself a Row, but the result seems wrong at first sight: Print[Row[{8, "a.: N[E],\nLabel as a String:", "\n"}], N[E]]; Print[Row[{Row[{8, "b.: N[E],\nLabel as a String:", "\n"}], N[E]}]]; ![enter image description here][8] It wasn't until I was writing this post that **I realized I had misunderstood "Row" in this context**, since Row exhibits the same behavior. The elements of Row are not simply concatenated like in a typewriter, but each part is formatted separately in StandardForm (line wrapping if necessary) and the individual results are concatenated: Row[{Row[{8, "bR.: N[E],\nLabel as a String:", "\n"}], N[E]}] ![enter image description here][9] Going back to my original problem (see example 4 above) you just have to convert the label to a String to fix it. Of course, you can then no longer place arbitrary expressions in the label, but only those that can be meaningfully converted to a string. To solve our newline problem, it is better to use EchoFunction when the label ends with a newline: Echo[N[E], Row[{4, ".: N[E]\nLabel as a Row:\n"}]]; Echo[N[E], ToString@Row[{9, ". = 4.Fixed: N[E]\nLabel as a Row converted to String:\n"}]]; EchoFunction[ Row[{Style[ Row[{10, ". = 4.Fixed: N[E]\nLabel as a Row echoed with \ EchoFunction:"}], "EchoLabel"], "\n", #}] &][N[E]]; ![enter image description here][10] Because it is difficult to determine in the general case whether a label ends with a newline, I make a new function echoNl that brings the expression under the label: ClearAll[echoNl]; echoNl[expr_, label_ : "", lvl0_Integer : 3] := Module[{myLbl}, If[testLvl >= lvl0, myLbl = Row[{{testLvl, lvl0}, ": ", label}]; EchoFunction[Row[{Style[myLbl, "EchoLabel"], "\n", #}] &][expr] , expr] ]; testLvl = 3; (* ... *) echoNl[expr1, label1]; echo[expr2, label2, 4]; testLvl = 4; (* ... *) echoNl[expr1, label1]; echo[expr2, label2, 4]; ![enter image description here][11] **This is my final solution**. [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b01.jpg&userId=890153 [2]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b02.jpg&userId=890153 [3]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b03.jpg&userId=890153 [4]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b04.jpg&userId=890153 [5]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b05.jpg&userId=890153 [6]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b06.jpg&userId=890153 [7]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b07.jpg&userId=890153 [8]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b08.jpg&userId=890153 [9]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b09.jpg&userId=890153 [10]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b10.jpg&userId=890153 [11]: https://community.wolfram.com//c/portal/getImageAttachment?filename=b11.jpg&userId=890153 [12]: https://www.wolframcloud.com/obj/590922d3-982f-4008-95d8-0e755af7bc83 Werner Geiger 2021-07-11T17:39:52Z https://community.wolfram.com/groups/-/m/t/2171196 Am I supposed to do a different command within NetTrain[] to use CUDA or is "TargetDevice"->"GPU" still supposed to work? (CUDA examples evaluate successfully.) The net gets trained but CPU spikes to 56% from a baseline of 1% while the NetTrain is evaluated and GPU does not seem to get used. Gfx: Nvidia 2080Ti CPU: AMD 3950x Wolfram v. 12.2 Never mind: I think it is working now. Renay Oshop 2021-01-23T13:25:47Z https://community.wolfram.com/groups/-/m/t/3635801 I have a few code samples which freeze or crash my kernel on evaluation, can anybody confirm that this isn't a local issue for me? Discrete: AudioGenerator[{"Color", AudioGenerator[TimeSeries[{1}, {1}]]}] Continuous: AudioGenerator[{"Color", AudioGenerator[{"Sawtooth", .4, 5}]}] Joseph Stocke 2026-02-06T21:20:51Z https://community.wolfram.com/groups/-/m/t/3562641 **The problem** I run Mathematica 12 from home via a Win11 VM on Proxmox. This configuration has run fine for years. Recently during an upgrade to Win11 25H2 I went to test to make sure everything was functional with a quick BenchmarkReport[] but it caused the kernel to die at Test 3, FFT. Its a very repeatable failure. Just before upgrading to 25H2 I had changed my processor type for this VM to x86-64-v3 +aes from -v2 + aes. I had issues on another vm where Win11 didnt want to upgrade with v2. I didnt originally run the processor as "host" as I am running dual E5-2699v4 Xeons, Win11 doesnt support by age despite having all the instructions needed. I have used this VM with Win10 and Win11 for years running Mathematica without issue. In the past I would use BenchmarkReport[] as a quick check of functionality after any upgrades or changes. This is the first time its failed. A quick test using ParallelTable[sin[x],{x,0,pi,10^-6}] works fine A quick test of Fourier[{1, 1, 2, 2, 1, 1, 0, 0}] works fine But a simple, Needs["Benchmark`"] BenchmarkReport[] Fails while calculating Step 3, FFT. The kernel simply die with no error message or warning. If I watch carefully with Task Manager it looks like the kernel dies, Mathematica recreates the kernel, then it dies again immediately. I also tried running this command through mathscript with -verbose but it gives me no additional details why its dying. I went back and tested some older notebooks I had. One of the first ones I tried died during a NonLinearModelFit of a PieceWise function with Sin[]s. Piecewise[{ { y0 + ( A1 Sin[ 2 \[Pi] ( x - x1)/t1] Sin[ 2 \[Pi] ( x - x2)/t2] ) + A3 Sin[2 \[Pi] (x - x3)/t3], x >= xon }, {y0, x < xon} }] This had worked in the past but now it dies just like BenchmarkReport, the kernel dies with no errors. **Fixes tried** So, I set the cpu back to v2 + aes for the vm config in proxmox but the kernel still dies. Set the cpu to Host in case its an issue with AES being passed correctly but it still dies I had Ballooning memory on so I turned it off, no change I had NUMA on so I turned it off, no change I uninstalled, reinstalled Mathematica 12.0 but it still fails I installed a demo copy of Mathematica 14.3, BenchmarkReport[] and my notebook run without issue. **System Info** Running a network version of Mathematica 12.0 with MathLM on another VM for the license. License is for 2 instances and 16 kernels. The VM is running under proxmox 8.4.14. The vm was just recently upgraded to Win11 25H2 but I am not sure when I last ran BenchmarkReport[]. I have run BenchmarkReport[] on this vm multiple times with some older flavors of win11 but I cant remember when I last ran it. I had recently installed the virtio drivers for this vm on the previous Win11 version but I hadnt run Mathematica since then. Could be a contributing factor. Proxmox has gone through a recent upgrade with a reboot of the host. I hadnt tried test Mathematica afterwards. Could be a contributing factor. The vm has been tested with cpu set to Host, x86-64-v2+aes, x86-64-v3+aes, numa on and off, ballooning on and off, with 32GB memory configured for the vm. This vm is set to get 2 processors of 8 cores each, The vm is only running microsoft virtual graphic drivers and is only accessed via remote desktop, not SPICE. As far as I can tell Win11 is working as expected. I am considering a fresh install of Win11 if no better ideas surface. The host system is dual E5-2699 v4 with 512GB. The host system runs a mix of vms and containers. **Summary** I know this is probably a very weird edge case of using a VM with such an old version of Mathematica. The kernel dying does seem to fail for more than just Benchmark so its most likely not a single package responsible. The failure is limited to Mathematica 12 as far as I can tell. Just wanted to figure this our before I start embarking on a bunch of calculations. Any thoughts are appreciated. Mike Morrell 2025-10-19T19:10:08Z