Re: Approximate Zero Times A Symbol

*To*: mathgroup at smc.vnet.net*Subject*: [mg127143] Re: Approximate Zero Times A Symbol*From*: Richard Fateman <fateman at eecs.berkeley.edu>*Date*: Mon, 2 Jul 2012 05:27:22 -0400 (EDT)*Delivered-to*: l-mathgroup@mail-archive0.wolfram.com*References*: <201206270811.EAA18698@smc.vnet.net> <19783652.3140.1340794328091.JavaMail.root@m06> <jsh3a9$sir$1@smc.vnet.net> <18402214.58885.1341077225203.JavaMail.root@m06> <000501cd56f2$cb6cec40$6246c4c0$@comcast.net> <22401981.60766.1341088322561.JavaMail.root@m06> <000001cd573a$98b2b260$ca181720$@comcast.net>

On 6/30/2012 8:35 PM, djmpark wrote: > You look on Mathematica as a programming language (which it is in a way) but > I look on it as a "piece of paper" on which I can do, write and communicate > mathematics. I don't disagree with that generally, and most computer algebra systems look that way, with a "document" paradigm lurking somewhere. I think where we disagree is to what extent a system that is designed at a particular time by a particular group of people, and is more or less bound to some backward-compatible notions and design guidelines can be expected to do encompass everything and anything that someone else can envision. I think that the best chance for success is for the system to do the mathematically correct thing whenever that can be unequivocally determined. Sometimes called the principle of "no surprises". Even so, such a system cannot do everything for everyone, since there are disagreements about matters in which there are several distinct approaches. Mathematicians, to a surprising extent, deal with ambiguous situations and notations. Context is quite important. In these situations it helps to have a programming language in which each of the competing camps can define particular approaches. In a situation where you'd like to obtain something that does not fall automatically out of the system in the most obvious way, you can argue that the system should do what you want done, or you can do the programming. Arguing that the system should do what you want can best be done if what you want is unequivocally the right thing. That is, mathematical correctness demands it. A good but weaker, argument is that what you want can also make it easier to do the alternatives at that point (one thought is that the programming language should also be nicely designed, and the representation should be elegant, compact, versatile, etc.) A common line of complaint about CAS is that (for some user with a specific notation and computational viewpoint) the CAS does not do exactly what that user expects. Changing the underlying mathematics should be considered if the underlying mathematics is wrong. I don't know about simplifying 0.0* x, but it seems to me your requirement of knowing the coefficient of x is simple enough to program. But maybe I've misunderstood your requirement. > > It is actually pretty good at that because, as an example, one can just use > NumberForm on an expression to obtain nice display, not to speak of all the > other wonderful features. But then it falls apart, out of the blue, because > Mathematica automatically converts 0.0 x to 0.0, but only if it has a set > precision and not a set accuracy. So yes, you can sneak around it by using a > HoldForm and a Rule, or by making a Row construction (but isn't that what > NumberForm was supposed to do?) or a String construction or by generating > the coefficients with a set accuracy and probably other methods. It's the > kind of programming I would rather not do. It chews up time - including the > time spent on: Why did Mathematica do that?. > > So if we have 0.0 x and x is a Symbol why can't Mathematica just leave it > alone? What is the rationale? > > > David Park > djmpark at comcast.net > http://home.comcast.net/~djmpark/index.html > > > > From: Richard Fateman [mailto:fateman at eecs.berkeley.edu] > > > I don't know much about NumberFormat or Sliders, but look at this: > > Coefficient[a*x+b*y, {x,y}] returns {a,b} > Coefficient[ b*y,{ x,y}] returns {0,b} > > I get the feeling that there is something resembling a "thought crime" > that is causing you > problems. That is, confusing the "computation of a value" and the > "display of some > attributes of a value". It is not necessary to change the Accuracy or > Precision of a value to display it. It is not necessary for you to make > Mathematica to (not) simplify 0.0*x to 0.0. > All you have to do is figure out what you want to display, as above. > > NumberForm is essentially a way of taking values and computing some strings > of characters. The string for a number has some relation with the actual > value, > but given a result of {0,b} from Coefficient, presumably you can make > any kind of string you wish, e.g. > > x-coefficient y-coefficient > ---------------------------------------- > |.........0........|..........b........| > ---------------------------------------- > RJF > > > > On 6/30/2012 12:01 PM, djmpark wrote: >> Thanks for your reply Richard. >> >> Basically I was interested in formatting a vector a x + b y to so many >> places and keeping both terms present even when a or b was an >> approximate zero. (My dislike of Dynamic displays that jitter and >> jump.) > ..big snip... >

**Re: How to rectify the error for NDSolve ?**

**Re: Varying a constant in an ODE to Manipulate solution**

**Re: Approximate Zero Times A Symbol**

**Re: Book**