More /.{I->-1} craziness
in [Mathematica]
|
Prev: Persistent assumption
Next: Financial Data - Currencies
From: Bill Rowe on 10 Jan 2010 03:28 On 1/8/10 at 4:15 AM, fateman(a)cs.berkeley.edu (Richard Fateman) wrote: >Bill Rowe said ... >"Again, the choice is either understand this behavior and live with >it or find different software. There isn't any other productive >choice." >Well, reporting something as a bug and hoping it will be fixed is >another choice. Reporting a behavior that works as designed as a bug and hoping it will be "fixed" seems very unproductive to me. What is there to "fix" if the program performs as designed? >And writing a version of the facility that does the >right thing is another choice. (Any takers?) It seems to me, the effort to do this for replacement rules and ensure the result doesn't cause other problems is far greater than the effort needed to understand the current design and use it to get your desired result. >Either of these could be "productive". This is highly debatable. >Are Mathematica design decisions sacred or something? Of course Mathematica design decisions are not sacred. But it is highly desirable new versions of Mathematica run code written for earlier versions. Altering design decisions almost certainly means the new version will not run some code written for earlier versions. So, altering design decisions is not something that should be done lightly. I don't believe the existence of users who have not yet taken the time to understand the current design is sufficient cause to change the current design. Nor do I think you have made a strong enough case to warrant a design change in this case. But on this second point, I am not the one who needs to be convinced. It is someone at WRI who could actually implement a change and their management.
From: Noqsi on 10 Jan 2010 03:29 On Jan 8, 2:15 am, Richard Fateman <fate...(a)cs.berkeley.edu> wrote: > Noqsi wrote: > > > Mathematica has a tool that can do what you want here: > > > Reduce[a == Exp[I x] - Exp[-I x] && Exp[I x] == s, {a}, {x}] > > s != 0 && a == (-1 + s^2)/s > > > It's a bit fussier than perhaps you'd like, but that's mathematics for > > you ;-) > > Reduce is a really neat program in Mathematica, one that I especially > admire since it was improved to work on more than polynomials. > Unfortunately, it won't work for I->-I, maybe because that is based on a > decision involving constants represented differently from expressions > that construct them. It's more that I==-I makes no sense. > (David Bailey already pointed this out. Do people > get instantaneous unfiltered feed from this newsgroup??) No. > > but also.. > Bill Rowe said ... > "Again, the choice is either understand this behavior and live > with it or find different software. There isn't any other > productive choice." > > Well, reporting something as a bug and hoping it will be fixed is > another choice. But nobody with sense thinks it's a bug. Remember that nearly all of the expressions evaluated by Mathematica are also generated by Mathematica, not by human users. Reading human intent into such expressions would be a grave mistake. Fundamental facilities like Replace have to perform predictably and regularly to make it possible for the developers of Mathematica to avoid creating bugs. > And writing a version of the facility that does the right thing is > another choice. (Any takers?) You cannot even define with adequate rigor what you mean by the "right thing". How, *in general*, should Mathematica make *mathematical* sense of a command to replace a constant with a different constant? > > Either of these could be "productive". > > Are Mathematica design decisions sacred or something? The design of fundamental functionality like Replace is severely constrained by the architecture of the system. Balsa wood is a useful material, but you cannot use it to make the base structure of a skyscraper.
From: Richard Fateman on 11 Jan 2010 05:27 Bill Rowe wrote: > On 1/8/10 at 4:15 AM, fateman(a)cs.berkeley.edu (Richard Fateman) > wrote: > >> Bill Rowe said ... >> "Again, the choice is either understand this behavior and live with >> it or find different software. There isn't any other productive >> choice." > >> Well, reporting something as a bug and hoping it will be fixed is >> another choice. > > Reporting a behavior that works as designed as a bug and hoping > it will be "fixed" seems very unproductive to me. When one first reports a behavior that one believes is a bug, the natural hope is that it will be fixed. To think otherwise is kind of pessimistic, perhaps depressing. That's probably what motivated the original poster (not me.) > What is there > to "fix" if the program performs as designed? 1. There are many many changes, some incompatible, to programs that worked as designed in earlier versions of Mathematica. The design was apparently deemed unsatisfactory. 2. All programs perform as programmed. Absent any different design document, one could say that all programs operate as designed. After all, the performance of the program is completely designed by the program text, and it operates entirely according to the design. This is the Peewee Herman argument ("I meant to do that"). > >> And writing a version of the facility that does the >> right thing is another choice. (Any takers?) > > It seems to me, the effort to do this for replacement rules and > ensure the result doesn't cause other problems is far greater > than the effort needed to understand the current design and use > it to get your desired result. You don't seem to understand "version of the facility". No one would be forced to use such a version, and therefore one could always use the original version so as to be compatible with previous design (mistakes, features, whatever). > >> Either of these could be "productive". > > This is highly debatable. Apparently :) > >> Are Mathematica design decisions sacred or something? > > Of course Mathematica design decisions are not sacred. Yet you say proposing changes would be "unproductive", quoting from your message above. But it is > highly desirable new versions of Mathematica run code written > for earlier versions. Of course, but that is not enforced by WRI. Why should you enforce it? Your view would make it impossible to improve anything e.g. new integration results, which would be incompatible with previous versions, which might (for example) depend on certainly integration problems NOT being done by the Integrate program. > Altering design decisions almost certainly > means the new version will not run some code written for earlier > versions. Not necessarily. Sometimes the change will return all results that were previously computed, but will provide functionality over a new domain too, as Integrate. One could have a situation in which all code written for the previous version (that worked) will continue to work. A possible incompatibility would be one where previously the code said "error, cannot compute this" and now it returns an answer. While it may have its place in the world of software, being compatible with all previous design decisions (and bugs!) is not a very attractive plan for a software system such as Mathematica. > So, altering design decisions is not something that > should be done lightly. That's why it should be discussed! Not dismissed out of hand. > > I don't believe the existence of users who have not yet taken > the time to understand the current design is sufficient cause to > change the current design. Again, you insist that I am proposing changing the current design. 1. I think the current design is wrong. (or woefully underdocumented) 2. I think a better facility can be designed and implemented. > Nor do I think you have made a strong > enough case to warrant a design change in this case. There are certainly arguments that this particular rule/replacement facility "works" for writing certain low-level programs and that any change which would alter the results or slow down the computation should be avoided, at least for these pre-existing programs. There are also clear arguments that a different facility should be presented to the (less sophisticated) user, e.g. original poster. > > But on this second point, I am not the one who needs to be > convinced. It is someone at WRI who could actually implement a > change and their management. I disagree. All you have to do is use your experience, skill, and imagination, to think about what a GOOD substitution facility should do as to not confuse someone who merely knows mathematics, and does not have an interest in learning the subtleties of FullForm, Reduce, Eliminate, .... Your ideas could then be implemented in a newly designed additional facility. RJF
From: Richard Fateman on 11 Jan 2010 05:27 Noqsi wrote: > > > It's more that I==-I makes no sense. That's not what anyone said. I -> -I means change the sign of all imaginary quantities. Rules do not necessarily represent value-preserving transformations. Sometimes people write epsilon^2 -> 0 By which they do NOT mean epsilon^2==0 and hence epsilon==0. What they mean is to discard powers of epsilon greater than one. This rule, by the way, also would not work, but epsilon^N_ ->0 with the condition N>1 might... A better way might be to compute a Series in epsilon. > >> Well, reporting something as a bug and hoping it will be fixed is >> another choice. > > But nobody with sense thinks it's a bug. I'm rubber you're glue. Everything you say sticks to you. > > Remember that nearly all of the expressions evaluated by Mathematica > are also generated by Mathematica, not by human users. Reading human > intent into such expressions would be a grave mistake. Fundamental > facilities like Replace have to perform predictably and regularly to > make it possible for the developers of Mathematica to avoid creating > bugs. You totally miss the point. If a human writes a rule I->-I, then the system can try to figure it out. Mathematica itself presumably would not automagically write such a rule, and so it would not be an issue. How to fix it for HumansOnly? Suggest to humans that they use BetterRules[I->-I] which would perhaps produce a different rule, e.g. Complex[a_,b_]->Complex[a,-b]. No big deal. > >> And writing a version of the facility that does the right thing is >> another choice. (Any takers?) > > You cannot even define with adequate rigor what you mean by the "right > thing". I think I can. I'm just being generous to people like you who might have suggestions about what you might like. How, *in general*, should Mathematica make *mathematical* > sense of a command to replace a constant with a different constant? Instead of protesting, I suggest you think about what someone might want, for even 60 seconds. As I pointed out above, rules are not used solely for value-preserving transformations, and so replacing 1 by 2 can make perfect sense. Note that Mathematica is perfectly happy to do f[1]/. 1->2. {by the way, f[1]/.1->2 results in the fairly nonsensical 10.f[1]->2, but that's a parsing problem.} > >> Either of these could be "productive". >> >> Are Mathematica design decisions sacred or something? > > The design of fundamental functionality like Replace is severely > constrained by the architecture of the system. Balsa wood is a useful > material, but you cannot use it to make the base structure of a > skyscraper. A more apt analogy may be that if a system is built with one size and shape of rectangular Lego bricks, you can make large stable rectangular structures, but it is impossible to construct (say) a smooth sloping ramp. Introducing another Lego shape can vastly expand the types of structures that can be easily built. People who insist on the perfection and purity of the original Lego brick can continue to use only those bricks, and their buildings will be just fine, as long as they need not comply with ADA. (They can't build wheelchair ramps for their disabled Lego-persons.) RJF > >
From: DrMajorBob on 11 Jan 2010 18:53
WRI has blithely broken user code in the past, so Bill's argument that they shouldn't in THIS case rings hollow. Bobby On Mon, 11 Jan 2010 04:27:30 -0600, Richard Fateman <fateman(a)cs.berkeley.edu> wrote: > Bill Rowe wrote: >> On 1/8/10 at 4:15 AM, fateman(a)cs.berkeley.edu (Richard Fateman) >> wrote: >> >>> Bill Rowe said ... >>> "Again, the choice is either understand this behavior and live with >>> it or find different software. There isn't any other productive >>> choice." >> >>> Well, reporting something as a bug and hoping it will be fixed is >>> another choice. >> >> Reporting a behavior that works as designed as a bug and hoping >> it will be "fixed" seems very unproductive to me. > > When one first reports a behavior that one believes is a bug, the > natural hope is that it will be fixed. To think otherwise is kind of > pessimistic, perhaps depressing. That's probably what motivated the > original poster (not me.) > >> What is there >> to "fix" if the program performs as designed? > > 1. There are many many changes, some incompatible, to programs that > worked as designed in earlier versions of Mathematica. The design was > apparently deemed unsatisfactory. > 2. All programs perform as programmed. Absent any different design > document, one could say that all programs operate as designed. After > all, the performance of the program is completely designed by the > program text, and it operates entirely according to the design. > This is the Peewee Herman argument ("I meant to do that"). >> >>> And writing a version of the facility that does the >>> right thing is another choice. (Any takers?) >> >> It seems to me, the effort to do this for replacement rules and >> ensure the result doesn't cause other problems is far greater >> than the effort needed to understand the current design and use >> it to get your desired result. > > You don't seem to understand "version of the facility". No one would be > forced to use such a version, and therefore one could always use the > original version so as to be compatible with previous design (mistakes, > features, whatever). >> >>> Either of these could be "productive". >> >> This is highly debatable. > > Apparently :) > >> >>> Are Mathematica design decisions sacred or something? >> >> Of course Mathematica design decisions are not sacred. > > Yet you say proposing changes would be "unproductive", quoting from your > message above. > > But it is >> highly desirable new versions of Mathematica run code written >> for earlier versions. > > Of course, but that is not enforced by WRI. Why should you enforce it? > Your view would make it impossible to improve anything e.g. new > integration results, which would be incompatible with previous versions, > which might (for example) depend on certainly integration problems NOT > being done by the Integrate program. > >> Altering design decisions almost certainly >> means the new version will not run some code written for earlier >> versions. > > Not necessarily. Sometimes the change will return all results that were > previously computed, but will provide functionality over a new domain > too, as Integrate. > > One could have a situation in which all code written for the previous > version (that worked) will continue to work. > > A possible incompatibility would be one where previously the code said > "error, cannot compute this" and now it returns an answer. > > While it may have its place in the world of software, being compatible > with all previous design decisions (and bugs!) is not a very attractive > plan for a software system such as Mathematica. > > > > >> So, altering design decisions is not something that >> should be done lightly. > > That's why it should be discussed! Not dismissed out of hand. > >> >> I don't believe the existence of users who have not yet taken >> the time to understand the current design is sufficient cause to >> change the current design. > > Again, you insist that I am proposing changing the current design. > 1. I think the current design is wrong. (or woefully underdocumented) > 2. I think a better facility can be designed and implemented. > >> Nor do I think you have made a strong >> enough case to warrant a design change in this case. > > There are certainly arguments that this particular rule/replacement > facility "works" for writing certain low-level programs and that any > change which would alter the results or slow down the computation should > be avoided, at least for these pre-existing programs. There are > also clear arguments that a different facility should be presented > to the (less sophisticated) user, e.g. original poster. > >> >> But on this second point, I am not the one who needs to be >> convinced. It is someone at WRI who could actually implement a >> change and their management. > > I disagree. All you have to do is use your experience, skill, and > imagination, to think about what a GOOD substitution facility should do > as to not confuse someone who merely knows mathematics, and does not > have an interest in learning the subtleties of FullForm, Reduce, > Eliminate, .... Your ideas could then be implemented in a newly > designed additional facility. > > RJF > > > -- DrMajorBob(a)yahoo.com |