Re: Re: More /.{I->-1} craziness
- To: mathgroup at smc.vnet.net
- Subject: [mg106474] Re: [mg106447] Re: More /.{I->-1} craziness
- From: DrMajorBob <btreat1 at austin.rr.com>
- Date: Thu, 14 Jan 2010 05:46:25 -0500 (EST)
- References: <hihgor$fhm$1@smc.vnet.net> <201001131056.FAA06769@smc.vnet.net>
- Reply-to: drmajorbob at yahoo.com
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 at cs.berkeley.edu> wrote:
> Bill Rowe wrote:
>> On 1/11/10 at 5:27 AM, fateman at 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 at yahoo.com
- References:
- Re: More /.{I->-1} craziness
- From: Richard Fateman <fateman@cs.berkeley.edu>
- Re: More /.{I->-1} craziness