Re: More /.{I->-1} craziness
- To: mathgroup at smc.vnet.net
- Subject: [mg106370] Re: More /.{I->-1} craziness
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Mon, 11 Jan 2010 05:27:30 -0500 (EST)
- References: <hic33e$595$1@smc.vnet.net>
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
- Follow-Ups:
- Re: Re: Re: More /.{I->-1} craziness
- From: DrMajorBob <btreat1@austin.rr.com>
- Re: Re: More /.{I->-1} craziness
- From: DrMajorBob <btreat1@austin.rr.com>
- Re: Re: Re: More /.{I->-1} craziness