MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: More /.{I->-1} craziness

  • To: mathgroup at
  • Subject: [mg106410] Re: [mg106370] Re: More /.{I->-1} craziness
  • From: DrMajorBob <btreat1 at>
  • Date: Mon, 11 Jan 2010 18:54:03 -0500 (EST)
  • References: <hic33e$595$> <>
  • Reply-to: drmajorbob at

WRI has blithely broken user code in the past, so Bill's argument that  
they shouldn't in THIS case rings hollow.


On Mon, 11 Jan 2010 04:27:30 -0600, Richard Fateman  
<fateman at> wrote:

> Bill Rowe wrote:
>> On 1/8/10 at 4:15 AM, fateman at (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.

DrMajorBob at

  • Prev by Date: Re: How to Modify Mathematica 7 Documentation Center Default Styles
  • Next by Date: Re: Positions of earliest dates for each month in a list of dates
  • Previous by thread: Re: More /.{I->-1} craziness
  • Next by thread: Re: Re: Re: More /.{I->-1} craziness