MathGroup Archive 2010

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

Search the Archive

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

  • To: mathgroup at smc.vnet.net
  • Subject: [mg106447] Re: More /.{I->-1} craziness
  • From: Richard Fateman <fateman at cs.berkeley.edu>
  • Date: Wed, 13 Jan 2010 05:56:20 -0500 (EST)
  • References: <hihgor$fhm$1@smc.vnet.net>

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


  • Prev by Date: Re: Re: Re: Re: Radicals simplify
  • Next by Date: Re: Re: Manipulating FinancialData[]
  • Previous by thread: Re: More /.{I->-1} craziness
  • Next by thread: Re: Re: More /.{I->-1} craziness