Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- To: mathgroup at smc.vnet.net
- Subject: [mg114733] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- From: Bill Rowe <readnews at sbcglobal.net>
- Date: Tue, 14 Dec 2010 06:57:22 -0500 (EST)
On 12/13/10 at 3:51 AM, fateman at cs.berkeley.edu (Richard Fateman) wrote: >On 12/12/2010 2:41 AM, Bill Rowe wrote: >>On 12/11/10 at 1:52 AM, fateman at cs.berkeley.edu (Richard Fateman) >>wrote: >>Access to the source code of a similar program cannot tell you how >>easy/difficult something is to implement in Mathematica. >Sure it can. Not in all cases, but in some cases the requirements of >a program provide a fairly clear basis on which to design an >implementation. There are several open-source pattern match >programs similar to Mathematica's (e.g. mine, Kevin McIsaac's >http://www.reduce-algebra.com/docs/pm.pdf, matheclipse, ...) >>You've no basis for assuming the code in Mathematica is partitioned >>in the same manner, uses the same approaches etc as your similar >>program. >Actually, you are wrong. There is a basis for assuming the code is >similar. (a) Its behavior (including misfeatures) is predictable >based on some assumptions of similarity. (b) Sometimes there are not >really so many reasonable ways of doing something. Let me clarify. One can always say there is a basis for assumptions. But, having a basis for assumptions doesn't make the assumptions valid. In essence, to reason something will be easy to implement in Mathematica because it is easy to do in a similar program requires assumptions about how Mathematica is coded which cannot be validated without access to the source code for Mathematica. A different set of assumptions leads to different conclusions about ease of implementation. Arguing something is easy/hard with out access to the source code is pointless. There is no way to determine which set of assumptions is a better match to reality. My only reason for making any comment in response to a claim something is/should be easy to change in Mathematica is invariably those claims are invoked as part of the reasons someone at WRI should implement something. They are (in effect) a put down to the developers at WRI who are the ones with access to the source code and are the only ones that can truly determine how easy/hard making some change to Mathematica will be. >>3+4I for the same reason 2.345/.2->1 yields 2.345. >2.345/.2->1 does not yield 2.345. > >It yields 11.725 -> 1 >And for an entirely different reason, which is that Mathematica >parser requires a space after "/." when the next token is a number. Yes, I should have written one of the following: 2.345/. 2->1 2.345/.(2->1) 2.345/.{2->1} which all yield 2.345 since it is not possible to change part of a real value using replacement rules. And for the same reason 3+4I/. I->-I has no effect. >>That is, despite the way it appears on screen, to Mathematica 3+4I is >>a single entity with no parts. You can replace the entire entity but >>not part of it. >Well, is that a good thing or a bad thing? Does it HAVE to be that >way? No it doesn't have to be that way. Mathematica could have been designed differently. But, it doesn't matter one bit whether I see the current design as good or bad. Perhaps, at some point WRI will change this aspect of the design. Until then, it is what it is. And this behavior certainly isn't a bug or design error. >>If the brewer's new beer formulation wasn't to my liking, I >>wouldn't buy it again from him. Instead I would get beer from >>another brewer. >It is a harder to change from one software system to another, than >to choose a different beer, at least in most countries. So? Harder to do doesn't mean it can't be done. >Imagine if there were only one brand of beer. Imagining things that don't match reality doesn't seem useful to me. >>If WRI becomes totally unresponsive to users, then there is >>opportunity for competitors to WRI. Eventually, being totally >>unresponsive to your user base will mean you have no users. >Really? Consider industrial monopolies. Consider totalitarian >regimes. Consider software operating system "lock-ins". And since when did WRI become a monopoly? Or comparable to a totalitarian regime? And as far as operating system "lock-ins" I use a Mac which arguably is one of the more "locked-in" operating systems. Yet, I I choose, I could run Windows, Linux or one of a variety of other flavors of Unix on my Mac. So, the "lock-in" is really my choice. >>My experience is software developers react much better to reasoned >>requests for changes then they do claims behavior that is precisely >>as they intended is a bug and must be changed. >Oh, so now you want me to be polite. That costs extra. I've not asked you to do anything. I merely point out being polite is more effective at getting the desired response in my experience. You are free to behave as you choose. It appears this discussion is unlikely to produce anything useful at this point. So, I likely won't respond further in this thread. In fact, I probably should have stopped responding several posts ago.