More /.{I->-1} craziness
in [Mathematica]
|
Prev: Persistent assumption
Next: Financial Data - Currencies
From: Richard Fateman on 13 Jan 2010 05:55 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. 1. It is interesting that a response to this message from DrMajorBob appears in my newsreader approximately one minutes before the message itself. So either AK and DMB either have early access to the newgroup or (more probably) are corresponding separately. 2. If you wishes to characterize complaints on the newsgroup as "no evidence at all" then quite a few suggestions should be ignored. > > 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), Talking about "no evidence". What could I hypothesize about you, based on no evidence? I'm afraid SteveC would (correctly) censor it! For your information, the lisp program MockMMA (are we allowed to mention this here??) has been used by a few people for system building projects of various sorts. From a Google search, a note back in 2001 says "It's used in Tilu http://torte.cs.berkeley.edu:8010/tilu . There are about 40 people who have downloaded copies and told me they did so; one person apparently used it as the basis for an NSF small business grant". {Tilu, after running about 250,000 queries, over a few years, was shut down.} > 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. As far as YOU can tell. > 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). Many? Really? On the other hand, you are not counting the ones who wrote to me off the newsgroup, in favor of the idea. > > Obviously no well run company would ever embark on spending resources on > something that may end up being never (or almost never) used. I did not know that you were an expert on business practices. Would you therefore recommend that airlines stop carrying lifeboats on Boeing 747s? They've almost never been used (perhaps never? I think crashes into deep ocean water result in 100% fatalities).
From: David Park on 13 Jan 2010 05:55 I thought WRI messed up because whereas previously all NAMED colors had the head RGBColor, in Version 5 some had that head and others had the Head GrayLevel. But in Version 6 WRI instituted a much more comprehensive color scheme and I think most users are happy with that. David Park djmpark(a)comcast.net http://home.comcast.net/~djmpark/ From: DrMajorBob [mailto:btreat1(a)austin.rr.com] 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.
From: Richard Fateman on 13 Jan 2010 05:56 Bill Rowe wrote: > 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. It seems to be inevitable that people will, with such a complex system as Mathematica, have differences of opinion as to whether some behavior constitutes a bug or not. When WRI declares "this is a feature not a bug", that does not necessarily change peoples' opinions. In fact, WRI has, from time to time, changed its opinion on what is a feature or 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. Especially when the documentation is vague or lacking on what should occur, the difference between a feature and a bug is elusive. > >>> 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. I did not ever suppose that you could actually enforce "compatibility with all past mistakes"; WRI does not enforce it either. I was attempting to state, in a shorthand way, the idea that -- I can understand if WRI wants to be compatible with past mistakes because of an existing code base, and they will presumably act in what they perceive as their own best interests in this regard. Having you act as another voice asking them, or reminding them, to enforce this line of reasoning, (especially given your own admitted lack of influence :) is pointless, and your arguments about what is good or bad should be based on better criteria which would presumably be "what would make Mathematica the best system for your own work [or your estimation of what other people do with it]". For example, if you have a substantial amount of code written for Mathematica, you might be able to say such a change would break X% of my code. (You would have to have an implementation of the proposed change to make this judgment -- but that has been supplied now.). My guess is that X%=0%. On the other hand, the implementation given will slightly slow down ReplaceAll if it were used all the time, and so, as I have now repeatedly suggested, a user-oriented "BetterRules" could be provided. > >> 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 know why a change in the method of computation which results in different answers for some inputs would be more (or less) acceptable in the view of "compatibility with previous behavior" than a change of design which results in different answers. Maybe you are arguing something about simultaneously altering the documentation or some such thing? > >>> 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? I think you are being too defensive. If I say that a neighborhood restaurant has a poor wine list and could be better, there are several solutions. e.g. going elsewhere. not drinking wine there. bringing my own wine. making recommendations for different wine. > Leaving a design you feel is incorrect and > somehow patching it? Patching "it"? Yes, providing another similar but (in my view) more user-friendly facility. Of course some people seem to hold the view that revising ReplaceAll would be a mistake (I can understand that view), but that ReplaceAll is perfect and it is the user's problem if it doesn't do what she expects (I am less sympathetic to that view). and some people seem to think that a different version of ReplaceAll and friends is an abomination and must not be allowed. (I am surprised by this view.) .... snip... > > 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. Yes. One of the goals of the people who have been developing software for "symbolic mathematical computation" starting in the 1960s, was that, to the largest extent possible, the newly discovered and implemented algorithmic underpinnings of constructive mathematics should be merged with the natural notations and usage of practicing mathematicians, scientists, engineers, etc, so these computer systems could be used most widely and most effectively. > While I can there are those > who want something to just work without additional effort on > their part, Yes. I don't see this as happening with anything as > powerful and complex as Mathematica. It is a particular conceit of Stephen Wolfram that he has invented a new and improved notation and method for designating computation, and that if only everyone learned it, mathematics and perhaps all of science would be so much better for it. And I see it echoed here -- why don't we have all high school students learn Mathematica? (Uh, answer: maybe Mathematica is (a) unnecessary, (b) unnecessarily complex, (c) not as powerful as you think, (d) the complexity is not required to provide the power, (e) Have you really examined all the history of introducing computing to lower grades in school? (f) Even if we agree that "algorithms and/or computing" is a good thing to know, is Mathematica the tool?) > 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. You know, there are a few alternatives other than doing mathematics "by hand" va. Mathematica that do not require knowledge of these items, and I hope you and other readers of this note consider that your comment it is an example of your "drinking the {wolfram} kool aid". Is the choice "learn internals of Mathematica" or "don't use computers"? Please think about this. > It simply is not reasonable > to expect good results from a tool if you are unwilling to learn > how to use the tool. One of the attributes of computer software is that it is almost infinitely malleable. When a particular design of a software tool turns out to be ill-suited to a particular task, it is worth considering whether a better alternative or additional tool can be designed. Even if you have learned to use the existing tool, that does not mean you are constrained to use it to the exclusion of others, nor that you are forbidden from designing another, or suggesting that other people help design other tools. RJF
From: DrMajorBob on 14 Jan 2010 05:46 I'm less concerned about the way ReplaceAll works than Richard, and I can see downsides to some of the suggested behavior. It's entirely possible that I might want to substitute I -> -I in the current manner -- leaving instances of -I alone. Changing ReplaceAll as suggested might close off that option (and similar options in other pattern replacement situations). HOWEVER, I'm sympathetic with Richard's frustration about how critique and suggestions are received, as if it were heresy at witch-burning time. Bobby On Wed, 13 Jan 2010 04:56:20 -0600, Richard Fateman <fateman(a)cs.berkeley.edu> wrote: > Bill Rowe wrote: >> 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. > > It seems to be inevitable that people will, with such a complex system > as Mathematica, have differences of opinion as to whether some behavior > constitutes a bug or not. When WRI declares "this is a feature not a > bug", that does not necessarily change peoples' opinions. In fact, > WRI has, from time to time, changed its opinion on what is a feature or > 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. > > Especially when the documentation is vague or lacking on what should > occur, the difference between a feature and a bug is elusive. > >> >>>> 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. > > I did not ever suppose that you could actually enforce "compatibility > with all past mistakes"; WRI does not enforce it either. I was > attempting to state, in a shorthand way, the idea that -- I can > understand if WRI wants to be compatible with past mistakes because of > an existing code base, and they will presumably act in what they > perceive as their own best interests in this regard. Having you act as > another voice asking them, or reminding them, to enforce this line of > reasoning, (especially given your own admitted lack of influence :) is > pointless, and your arguments about what is good or bad should be based > on better criteria which would presumably be "what would make > Mathematica the best system for your own work [or your estimation of > what other people do with it]". > > For example, if you have a substantial amount of code written for > Mathematica, you might be able to say such a change would break X% of my > code. (You would have to have an implementation of the proposed change > to make this judgment -- but that has been supplied now.). My guess is > that X%=0%. On the other hand, the implementation given will slightly > slow down ReplaceAll if it were used all the time, and so, as I have now > repeatedly suggested, a user-oriented "BetterRules" could be provided. > >> >>> 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 know why a change in the method of computation which results in > different answers for some inputs would be more (or less) acceptable in > the view of "compatibility with previous behavior" than a change of > design which results in different answers. Maybe you are arguing > something about simultaneously altering the documentation or some such > thing? >> >>>> 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? > > I think you are being too defensive. If I say that a neighborhood > restaurant has a poor wine list and could be better, there are several > solutions. e.g. going elsewhere. not drinking wine there. bringing my > own wine. making recommendations for different wine. > > > > >> Leaving a design you feel is incorrect and >> somehow patching it? > > Patching "it"? Yes, providing another similar but (in my view) more > user-friendly facility. Of course some people seem to hold the view > that revising ReplaceAll would be a mistake (I can understand that view), > but that ReplaceAll is perfect and it is the user's problem if it > doesn't do what she expects (I am less sympathetic to that view). > and some people seem to think that a different version of ReplaceAll and > friends is an abomination and must not be allowed. (I am surprised by > this view.) > ... snip... > >> >> 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. > > Yes. One of the goals of the people who have been developing software > for "symbolic mathematical computation" starting in the 1960s, was that, > to the largest extent possible, the newly discovered and implemented > algorithmic underpinnings of constructive mathematics should be merged > with the natural notations and usage of practicing mathematicians, > scientists, engineers, etc, so these computer systems could be used most > widely and most effectively. > >> While I can there are those >> who want something to just work without additional effort on >> their part, > > Yes. > > I don't see this as happening with anything as >> powerful and complex as Mathematica. > > It is a particular conceit of Stephen Wolfram that he has invented a new > and improved notation and method for designating computation, and that > if only everyone learned it, mathematics and perhaps all of science > would be so much better for it. And I see it echoed here -- > > why don't we have all high school students learn Mathematica? > > (Uh, answer: maybe Mathematica is (a) unnecessary, (b) unnecessarily > complex, (c) not as powerful as you think, (d) the complexity is not > required to provide the power, (e) Have you really examined all the > history of introducing computing to lower grades in school? (f) Even if > we agree that "algorithms and/or computing" is a good thing to know, is > Mathematica the tool?) > > > > > >> 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. > > You know, there are a few alternatives other than doing mathematics "by > hand" va. Mathematica that do not require knowledge of these items, > and I hope you and other readers of this note consider that your > comment it is an example of your "drinking the {wolfram} kool aid". > > Is the choice "learn internals of Mathematica" or "don't use computers"? > > Please think about this. > > > >> It simply is not reasonable >> to expect good results from a tool if you are unwilling to learn >> how to use the tool. > > One of the attributes of computer software is that it is almost > infinitely malleable. When a particular design of a software tool > turns out to be ill-suited to a particular task, it is worth considering > whether a better alternative or additional tool can be designed. Even if > you have learned to use the existing tool, that does not mean you are > constrained to use it to the exclusion of others, nor that you are > forbidden from designing another, or suggesting that other people help > design other tools. > > RJF > -- DrMajorBob(a)yahoo.com
From: Andrzej Kozlowski on 14 Jan 2010 05:47
On 13 Jan 2010, at 10:55, Richard Fateman wrote: >> >> 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), > > Talking about "no evidence". Well, then, what about this: On 9 Feb 2004, at 16:17, Richard Fateman wrote: > > As far as MockMMA, I really don't > care if people use it. I take pieces of it and use them when > I need a rational function package or a parser. Doesn't that sound like some evidence? > > Many? Really? On the other hand, you are not counting the ones who wrote > to me off the newsgroup, in favor of the idea. It must be a rein of terror that makes them keep it so secret. > Would you > therefore recommend that airlines stop carrying lifeboats on Boeing > 747s? They've almost never been used (perhaps never? I think crashes > into deep ocean water result in 100% fatalities). Oh, I see, lifeboats. I am sure if you could get FAA on your side there would still be some hope that all your efforts may not be wasted. Andrzej Kozlowski |