More /.{I->-1} craziness
in [Mathematica]
|
Prev: Persistent assumption
Next: Financial Data - Currencies
From: DrMajorBob on 12 Jan 2010 04:49 I never said the change was a good idea. I've said some of us learned from the thread, so it was worth (some) discussion. And I DID say that WRI has broken plenty of user code in the past. Ask David Park about colors changing their Head... or anybody (virtually everyone) who had graphics output as side-effects in every one of their notebooks. Anybody who used Show was probably forced to reexamine that code. Et cetera. Bobby On Mon, 11 Jan 2010 19:38:12 -0600, Andrzej Kozlowski <akoz(a)mimuw.edu.pl> wrote: > The obvious argument against doing this is that there is no evidence at > all that there is a demand would actually justify any effort in this > direction. > > So far I have noticed just two voices in favor, the person who once > wrote a Mathematica parser that has never been used by anyone (as far as > I can tell), you and that seems to be all. Even the OP, after his post > was answer, did not, as far as I can tell, support the idea of adding > new facilities to Mathematica so that he would not need to learn about > FullForm. > On the other hand, I have seen quite many people writing that they see > no need for anything of this kind (I am not adding myself to their > number). > > Obviously no well run company would ever embark on spending resources on > something that may end up being never (or almost never) used. > > Andrzej Kozlowski > > > On 12 Jan 2010, at 08:54, DrMajorBob wrote: > >> 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 >> > -- DrMajorBob(a)yahoo.com
From: Bill Rowe on 12 Jan 2010 04:49 On 1/11/10 at 6:54 PM, btreat1(a)austin.rr.com (DrMajorBob) wrote: >WRI has blithely broken user code in the past, so Bill's argument >that they shouldn't in THIS case rings hollow. My point wasn't that WRI should not do things that break existing code. But rather, they should not do this without good reason. For example, the change in the way graphics works between version 5 and 6 certainly caused broke some existing code. But I believe the enhanced capabilities for graphics provided by version 6 more than justified the effect on existing code. OTOH making a change simply so that some subset of new users is less confused and provides no other benefit would not be sufficient reason for WRI to break existing code. On the contrary, I would argue the need not to break existing code out weighs the need to make Mathematica more intuitive for some subset of users. But, as you point out WRI has broken code in the past and will certainly do so in the future. In order to grow Mathematica with more functionality, it is inevitable some changes will break existing code. Additionally, my opinion as to what justifies breaking existing code is just that, my opinion. And that has essentially no impact on what WRI does in the future.
From: Andrzej Kozlowski on 12 Jan 2010 04:50 > (I am not adding myself to their number). Oops. I meant "I am now adding myself to their number". On 12 Jan 2010, at 10:38, Andrzej Kozlowski wrote: > The obvious argument against doing this is that there is no evidence at all that there is a demand would actually justify any effort in this direction. > > So far I have noticed just two voices in favor, the person who once wrote a Mathematica parser that has never been used by anyone (as far as I can tell), you and that seems to be all. Even the OP, after his post was answer, did not, as far as I can tell, support the idea of adding new facilities to Mathematica so that he would not need to learn about FullForm. > On the other hand, I have seen quite many people writing that they see no need for anything of this kind (I am not adding myself to their number). > > Obviously no well run company would ever embark on spending resources on something that may end up being never (or almost never) used. > > Andrzej Kozlowski > > > On 12 Jan 2010, at 08:54, DrMajorBob wrote: > >> 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 >> >
From: Andrzej Kozlowski on 12 Jan 2010 04:51 The obvious argument against doing this is that there is no evidence at all that there is a demand would actually justify any effort in this direction. So far I have noticed just two voices in favor, the person who once wrote a Mathematica parser that has never been used by anyone (as far as I can tell), you and that seems to be all. Even the OP, after his post was answer, did not, as far as I can tell, support the idea of adding new facilities to Mathematica so that he would not need to learn about FullForm. On the other hand, I have seen quite many people writing that they see no need for anything of this kind (I am not adding myself to their number). Obviously no well run company would ever embark on spending resources on something that may end up being never (or almost never) used. Andrzej Kozlowski On 12 Jan 2010, at 08:54, DrMajorBob wrote: > 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 >
From: Bill Rowe on 12 Jan 2010 04:52
On 1/11/10 at 5:27 AM, fateman(a)cs.berkeley.edu (Richard Fateman) wrote: >Bill Rowe wrote: >>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. Which is very reasonably when what is reported as a bug is indeed a bug. But it is not reasonable to expect something reported as a bug to be changed when it is not a bug. Nor is it reasonable to expect WRI to intuit your meaning of bug when it differs from the standard accepted difference. That is, the behavior being discussed is simply not a bug. It is exactly the behavior the documentation indicates should occur. >>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? What??? I have no access to the source code. And if I have any significant influence over WRI, I am not aware of it. In short, I've no capability to enforce my view of how Mathematica should be designed on anyone. >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. Let me just respond here by clearly stating the above is not representative of my view at all. >>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. That type of change sounds more like a change in the method of computation not a change of design. >>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. You clearly state here you think the design "is wrong" and can be better. If you are not suggesting changing the design what are you suggesting? Leaving a design you feel is incorrect and somehow patching it? >>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. Well if you think *I* am the one who needs convincing your prospects for seeing this change are very slim indeed. >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. You appear to be suggesting Mathematica should be written to enable someone to do mathematics without understanding much in the way in which Mathematica works. While I can there are those who want something to just work without additional effort on their part, I don't see this as happening with anything as powerful and complex as Mathematica. Someone who "merely knows" mathematics and has no interest in FullForm, Reduce, Eliminate, ReplacementRule etc would be well advised to do mathematics by hand and not use Mathematica at all. It simply is not reasonable to expect good results from a tool if you are unwilling to learn how to use the tool. |