[Date Index]
[Thread Index]
[Author Index]
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**
| |