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?
Last edited by DeltaV on Fri Nov 12, 2010 7:45 am, edited 1 time in total.
the 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"
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.
32 bits for ~$300 instead of the standard version's 64 bits for >$2000
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.
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.
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.
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?
I wish they'd fix known issues before adding new features.
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.
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.
That is wishful thinking and completely different to how I understand how such things work - which is that major version numbers are incremented for:
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 reality, it costs money to fix bugs and software companies don't earn any money doing it. Customers generally only pay for new features. The cynical business case for bug fixing is only those that cause sufficient pain that might drive enough customers away.
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.
I read that book too. The part about cellular fluid dynamics on a hexagonal grid was especially interesting. Would like to explore that further, but right now I need to cleanly scoop a sphere out of a cylinder.
