Date: May 31, 2013 3:16 AM Author: Andrzej Kozlowski Subject: Re: Applying Mathematica to practical problems 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

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 UTC-6, 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 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.

>