
Re: Applying Mathematica to practical problems
Posted:
May 31, 2013 3:16 AM


I think this is an excellent and quite fascinating account of serious and genuinely useful application of some of Mathematica's vast capabilities, which made me feel that the kind of stuff that the rest of us do is more akin to playing. To my mind, it also should make very clear (to anyone who had any doubts) the complete irrelevance of most of the "criticism" of Mathematica that Richard Fateman has been posting for over 2 decades (not that I expect him to stop doing it or even modify it in anyway).
I don't think the points John's makes needs any further support so I want to address just one issue: Richard's use of the words "erroneous, incorrect, buggy" etc. This has, in fact, already been addressed by John in the first sentence of his reply, but so briefly that I think there is still some room for additional comment. Almost always when RJF uses such words in connection with Mathemtica he is playing a kind of game, well familiar to the veterans of this forum but which could confuse newcomers. The idea is to make ambiguous statements that can be interpreted in at least two ways: one could be called "strong" and the other "weak". The "strong" interpretation is the one you hope will influence people not very familiar with the topic (or with this sort of rhetorical tricks), the weak one is what you turn to when pressed by people who demand precise justification of your claims. When this happens it turns out that the alleged "errors" are not at all what people normally call errors but merely aspect of design that Richard does not like (assuming, of course, that he does not have another hidden motive that goes beyond disliking the working of Mathematica). Thus, Richard whenever he sees a chance to influence someone who he thinks is new to Mathematica, suggest that Mathematica's significance arithmetic is prone to give wrong answers and is unreliable. But when pressed, he has admitted on a number of occasions that:
1. Significance arithmetic, being a (faster) version of interval arithmetic, can be useful when used by people who understand it and that it is used quite reliably by many builtin Mathematica functions such as NSolve (and also Solve). 2. It is easy to switch to fixed precision arithmetic whenever one wants with a simple usage of Block.
In other words: significance arithmetic is a feature that Mathematica offers in addition to standard, fixed precision arithmetic. How can more be worse than less? Of course JRF when pressed, has admitted all this (I can post references but I don't think he will deny it) and his objections actually amount to just two things: the choice of significance arithmetic as the deafult for extended precision computations and the fact that Mathematica treats what are actually intervals as "numbers" instead of just calling them something else ("fuzz balls"). Every time there is a serious discussion of these things, he is forced to concede all these points but then, at the next opportunity, he starts the whole things all over again. In the end, he becomes so careless that he ends up writing comical nonsense like:
> I will say that for scientific computing it is probably a bad feature > to have finite numbers x such that x ==0 and x+1 == x.
Excuse me? I have always assumed that every number system has at least one finite number x such that x+1=x, this follows from the group axiom. Also, by the way, if we are talking about group addition then "x ==0 and x+1 == x" is a not very economical way to express x==0.
More seriously, there are two things are being insinuated here, both of them false. The first is that having "numbers" with unusual properties is somehow "wrong" or even "eccentric" in mathematics. This is, of course, completely false and one can give lots of examples. To take just one: in non standard analysis one has infinitely many "infinitely small numbers" x such that n x <1 for every positive integer n. This is both logically sound and very useful in practical proofs and computations. Exactly the same is true of "fuzz balls".
Another insinuation, equally false, is that an unsuspecting "naive" user of Mathematica could fall into some trap because of this. Naive users of Mathematica practically never use arbitrary precision arithmetic. Users who need it will almost always look into the documentation and realise that they won't be dealing with numbers in the ordinary sense but intervals of variable size. This is why examples of the kind that RJF loves posting never come up naturally. The only time they occur is either then RJF posts them or sometimes when someone discovers low precision numbers and tries things like:
1`0 == 0
True
1`0 == 1
True
But, of course, to be able to enter numbers with no precision you really need to know, well, what it means for a number to have Precision 0. At this point, I suspect, RJF will be tempted to come up with his favourite example of the the kind of thing that awaits an unsuspecting user who for some reason needs to evaluate:
z = 1.11111111111111111111;While[(z = 2*z  z) != 0, Print[z]]
Well, see it for yourself (in Mathematica 9) and decide if anyone would find it so confusing.
Andrzej Kozlowski
On 30 May 2013, at 12:15, John Doty <noqsiaerospace@gmail.com> wrote:
> Changing the topic here. > > On Tuesday, May 28, 2013 1:49:00 AM UTC6, Richard Fateman wrote: > >> Learning Mathematica (only) exposes a student to a singularly erroneous >> model of computation, > > A personal, subjective judgement. However, I would agree that exposing the student to *any* single model of computation, to the exclusion of others, is destructive. > >> Nice that you concede it is eccentric. > > Concede? I praise its eccentricity! It takes me places other tools cannot easily go. > >> Productive perhaps if you do not >> encounter a quirk. > > There is no nontrivial quirkfree software. > >> Especially a hidden quirk that gives the wrong >> answer but no warning. > > Mathematica applied to real problems is pretty good here. > >> And if you are not in a hurry for numerical >> results. > > OK, let's consider how I use Mathematica in mixedsignal chip design. For my video chain chips, I start with two different approches in Mathematica. I have a nonlinear simulation environment that breaks the chip down into blocks, represented by functions, and composes a function representing the effect of a single clock step on the chip state from these functions. I iterate that function to "simulate". Some of the blocks are initially represented as Z transforms, so Mathematica's algebraic capabilities come in handy. The ease of partial evaluation helps with optimization: by evaluating as much of the function as possible before iterating it, special cases like consta nt inputs become very simple and fast. > > I also have a Mathematica model that starts as symbolic Z and Fourier transforms, and models the chip as linear operators. For numerical results, these operators turn into matrices. > > Once I've established the design parameters, I reduce the functional blocks to circuits and simulate with that fine Berkeley product, SPICE, the liguafranca of circuit simulation. You think Mathematica has problems? You've never used SPICE. > > Linguistically, SPICE is an absolute mess. "Grammar" is utterly adhoc, and variable with dialect. "1N914B" is a perfectly good model name for a diode, but "2N2222A" cannot be used to name a transistor model in some dialects. There are a couple of dozen different dialects around, most containing incompatible proprietary extensions. > > For quirky unpredictability, SPICE is much, much worse than Mathematica. SPICE users get used to seeing spurious "trap oscillations", large amounts of energy appearing out of nowhere, and ridiculous time steps. Tuning the numerics to get sane results is an arcane art. As a programming language, SPICE is about as sophisticated as BASIC, but much less regular. Nevertheless, SPICE is very widely used and very productive. In the end, people find that it gets the job done (although many get rather exasperated in the process!. > > But the big problem with SPICE isn't that it's quirky and errorprone, but that it buries the problem in (mostly irrelevant) detail. I'm simulating thousands of transistors, each with ~100 model parameters, with state changing on picosecond time scales. My SPICE chip simulations tend to run at a billion times slower than real time. Data output is voluminous and difficult to analyze (sometimes I read it into Mathematica for reduction). These problems limit the range of questions I can practically ask of SPICE. > > On the other hand, the iterated function approach in Mathematica is 10,000100,000 times faster than the SPICE approach, so it's a lot better for probing highlevel behavior. The linear algebra approach in Mathematica is even faster: bang a few matrices together and it tells me approximately what I'd get from averaging an unlimited number of simulation runs. > > Because SPICE is so slow and detailed it's very difficult to use as a design tool, where the question is "I want this behavior, how do I get it?" It'sbetter for design verification: "I have this circuit, how will it behave?". The linear approach in Mathematica is the quickest for design optimization, but of course it can't probe nonlinear phenomena in "large signal" cases. The iterated function approach in Mathematica is a good compromise to bridge the gap. > > So, when I have two Mathematica models and a SPICE model that agree that the design will meet requirements, and agree with each other where their capabilities overlap, I release the design to the layout contractor. One result is another SPICE model, extracted from the silicon geometry, for verification. This model is extremely complex, with tens of thousands of "parasitic" resistors and capacitors, but I'll run a few test cases through it before releasing the design to the mask aggregator. So, before any silicon is patterned, I get four fairly independent looks at the design from different viewpoints through two radically different tools. > > There are still many things that can go wrong before I have an actual chip powered up and processing video. Some of them involve other software, but they have nothing to do with Mathematica, so I won't go into them here. > > The real world simply doesn't work the way you imagine in this case. The design process involves cross checks between multiple tools and models, so few design errors escape detection. Furthermore, I haven't seen any errors attributable to the "quirks" of Mathematica in this process. I, of course, make and (hopefully) correct errors at a rapid pace. SPICE is rather treacherous. But correct and accurate calculation in Mathematica just isn't a problem in this engineering flow. >

