Re: Applying Mathematica to practical problems
- To: mathgroup at smc.vnet.net
- Subject: [mg130977] Re: Applying Mathematica to practical problems
- From: Andrzej Kozlowski <akozlowski at gmail.com>
- Date: Fri, 31 May 2013 03:37:58 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-outx@smc.vnet.net
- Delivered-to: mathgroup-newsendx@smc.vnet.net
- References: <kmngb2$3rv$1@smc.vnet.net> <20130519095011.606CD6A14@smc.vnet.net> <20130530101525.2281869F1@smc.vnet.net>
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 at 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.
>
- References:
- Re: Work on Basic Mathematica Stephen!
- From: paulmchale7@gmail.com
- Applying Mathematica to practical problems
- From: John Doty <noqsiaerospace@gmail.com>
- Re: Work on Basic Mathematica Stephen!