Re: Re: More /.{I->-1} craziness
- To: mathgroup at smc.vnet.net
- Subject: [mg106410] Re: [mg106370] Re: More /.{I->-1} craziness
- From: DrMajorBob <btreat1 at austin.rr.com>
- Date: Mon, 11 Jan 2010 18:54:03 -0500 (EST)
- References: <hic33e$595$1@smc.vnet.net> <201001111027.FAA23268@smc.vnet.net>
- Reply-to: drmajorbob at yahoo.com
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 at cs.berkeley.edu> wrote:
> Bill Rowe wrote:
>> On 1/8/10 at 4:15 AM, fateman at 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 at yahoo.com
- Follow-Ups:
- Re: Re: Re: More /.{I->-1} craziness
- From: Andrzej Kozlowski <akoz@mimuw.edu.pl>
- Re: Re: Re: More /.{I->-1} craziness
- References:
- Re: More /.{I->-1} craziness
- From: Richard Fateman <fateman@cs.berkeley.edu>
- Re: More /.{I->-1} craziness