Mathematica bug
Mathematica bug
A while ago I bought Mathematica Home Edition v7.0.1 (32 bits for ~$300 instead of the standard version's 64 bits for >$2000, supposedly the same functionality otherwise).
My 30 days of support expired before I ran into the brickwall below using RegionPlot3D (Wolfram's attempt at Constructive Solid Geometry, which is commonly included in CAD software). I realize Mathematica is not, and will never be, a CAD program, but they obviously still have some work to do with RegionPlot3D for objects with sharp, curved edges.
Are there any Mathematica experts out there who know of a simple workaround?
My 30 days of support expired before I ran into the brickwall below using RegionPlot3D (Wolfram's attempt at Constructive Solid Geometry, which is commonly included in CAD software). I realize Mathematica is not, and will never be, a CAD program, but they obviously still have some work to do with RegionPlot3D for objects with sharp, curved edges.
Are there any Mathematica experts out there who know of a simple workaround?
Last edited by DeltaV on Fri Nov 12, 2010 7:45 am, edited 1 time in total.
Increase the thickness of the solid:
Have fun with Mathematica, takes some toime to grasp it but is worth the effort in the end.
http://www.mathkb.com/Uwe/Forum.aspx/ma ... lot-pointsthe problem comes from the fact, that the region becomes very thin
compared to the plot range. The numerical algorithm seems to have
problems to decide if the region exists or not.
An easy work around would be make the surface "thick"
Have fun with Mathematica, takes some toime to grasp it but is worth the effort in the end.
Thanks, Giorgio. I'm looking for a sharp edge in this case, however.
I can piece together a cylinder and a spherical cap, I suppose, but then small gaps occur at the joining circle due to different tesselations.
I can also import CAD data, but then I lose the ability to drastically change the (computed) geometry using Manipulate, which is great for parametric design studies in combination with the rest of Mathematica's features.
Sure would be nice to have fully functional, basic CSG, but like I said it's not intended to be a CAD program. If they can get the CSG bugs ironed out it will be a really powerful tool for "what if" analyses of early design concepts.
I can piece together a cylinder and a spherical cap, I suppose, but then small gaps occur at the joining circle due to different tesselations.
I can also import CAD data, but then I lose the ability to drastically change the (computed) geometry using Manipulate, which is great for parametric design studies in combination with the rest of Mathematica's features.
Sure would be nice to have fully functional, basic CSG, but like I said it's not intended to be a CAD program. If they can get the CSG bugs ironed out it will be a really powerful tool for "what if" analyses of early design concepts.
This refers to the CPU design, not the number of bits used by Mathematica for calculations. They would give the same precision, but a 32 bit machine might take longer.32 bits for ~$300 instead of the standard version's 64 bits for >$2000
It's a flaw in the algorithm. For a case like this, a part of the mesh used to define the facets should be a polygonal circle, where the cylinder and sphere intersect.
If Mathematica is like Maxima and I have been led to believe so, then it has a "precision" input parameter. In Maxima, the code statement, sets the calculation precision to 30 decimal digits. Maxima runs OK with fprec set to 200 but I haven't seen an example where the difference between 30 and 200 is detectable in the output. That's because I've never wanted to look at digits of precision beyond 30.
Code: Select all
fprec:30;
Aero
AFAIK, Mathematica is capable of as much precision as needed, automatically determined and not limited by HW. There are some user tweaks that can be made, but that won't help here. The algorithm appears to fail long before any precision limits are reached. I suspect they've made the mesh algorithm so general that it fails for a few specific cases. Testing a sufficient variety of cases would have caught it. The web site now says that if you buy 7.0.1 you'll get 8.0 free when it's released. Maybe 8.0 has the fix, but I bought it before they made this offer, so maybe I'm hosed.
I found quite a few posts complaining about RegionPlot3D function.
Clearly is bugged, and clearly a fix should be delivered to enable paying users to make the most out of their purchase.
Should they release the fix only in version 8.x and not make it available for free to previous users I'll be quite pissed off if I was one of the guys who just spent 300 US$ on this product.
Why don't you send them an e-mail to check about this?
Clearly is bugged, and clearly a fix should be delivered to enable paying users to make the most out of their purchase.
Should they release the fix only in version 8.x and not make it available for free to previous users I'll be quite pissed off if I was one of the guys who just spent 300 US$ on this product.
Why don't you send them an e-mail to check about this?
That is wishful thinking and completely different to how I understand how such things work - which is that major version numbers are incremented for:Giorgio wrote:Indeed. This is not a very proessional behaviour from them.
Moving from a 7.xx release to a 8.xx release should imply that all known 7.xx bugs have been cleared of.
- Major rewrites that break compatability in some way
- Introduction of major new features - for marketing purposes
- Money spinner - partly due to 2. ; but also due to 1. since existing customers must upgrade to keep compatability with other users of latest version
In theory there is no difference between theory and practice, but in practice there is.
Sad, but true. At the very least, one would expect them to clearly point out known issues to their paying customers.
Case in point: the "[[1]]" in the code above is absolutely necessary for it to run without errors in 7.0.1, but is not mentioned anywhere in the standard "Help" documentation. You have to browse through the thousands of demo programs on their website to find it.
Wolfram is not unique in this regard. MathWorks plays a similar game with their MATLAB/Simulink product.
P.S. - I've changed the title of this thread from "Mathematica question" to "Mathematica bug" in the vain hope that it might shame Wolfram into fixing the problem.
Case in point: the "[[1]]" in the code above is absolutely necessary for it to run without errors in 7.0.1, but is not mentioned anywhere in the standard "Help" documentation. You have to browse through the thousands of demo programs on their website to find it.
Wolfram is not unique in this regard. MathWorks plays a similar game with their MATLAB/Simulink product.
P.S. - I've changed the title of this thread from "Mathematica question" to "Mathematica bug" in the vain hope that it might shame Wolfram into fixing the problem.