MathGroup Archive 2013

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Applying Mathematica to practical problems

  • To: mathgroup at
  • Subject: [mg130977] Re: Applying Mathematica to practical problems
  • From: Andrzej Kozlowski <akozlowski at>
  • Date: Fri, 31 May 2013 03:37:58 -0400 (EDT)
  • Delivered-to:
  • Delivered-to:
  • Delivered-to:
  • Delivered-to:
  • References: <kmngb2$3rv$> <> <>

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 built-in 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 

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


1`0 == 1


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 at> wrote:

> Changing the topic here.
> On Tuesday, May 28, 2013 1:49:00 AM UTC-6, Richard Fateman wrote:
>> Learning Mathematica (only) exposes a student to a singularly 
>> 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 quirk-free 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 mixed-signal 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 
ad-hoc, 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 error-prone, 
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,000-100,000 times faster than the SPICE approach, so it's a lot 
better for probing high-level 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.

  • Prev by Date: Re: Help needed on how plot a stereographic projection
  • Next by Date: Re: Help needed on how plot a stereographic projection
  • Previous by thread: Applying Mathematica to practical problems
  • Next by thread: Re: Applying Mathematica to practical problems