Re: Re: Re: More /.{I->-1} craziness
- To: mathgroup at smc.vnet.net
- Subject: [mg106425] Re: [mg106410] Re: [mg106370] Re: More /.{I->-1} craziness
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Tue, 12 Jan 2010 04:48:52 -0500 (EST)
- References: <hic33e$595$1@smc.vnet.net> <201001111027.FAA23268@smc.vnet.net> <201001112354.SAA21077@smc.vnet.net> <63B7F642-0AB0-4332-9B6A-906A4081B0AD@mimuw.edu.pl>
> (I am not adding myself to their number).
Oops. I meant "I am now adding myself to their number".
On 12 Jan 2010, at 10:38, Andrzej Kozlowski wrote:
> The obvious argument against doing this is that there is no evidence
at all that there is a demand would actually justify any effort in this
direction.
>
> So far I have noticed just two voices in favor, the person who once
wrote a Mathematica parser that has never been used by anyone (as far as
I can tell), you and that seems to be all. Even the OP, after his post
was answer, did not, as far as I can tell, support the idea of adding
new facilities to Mathematica so that he would not need to learn about
FullForm.
> On the other hand, I have seen quite many people writing that they see
no need for anything of this kind (I am not adding myself to their
number).
>
> Obviously no well run company would ever embark on spending resources
on something that may end up being never (or almost never) used.
>
> Andrzej Kozlowski
>
>
> On 12 Jan 2010, at 08:54, DrMajorBob wrote:
>
>> 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
>>
>
- References:
- Re: More /.{I->-1} craziness
- From: Richard Fateman <fateman@cs.berkeley.edu>
- Re: Re: More /.{I->-1} craziness
- From: DrMajorBob <btreat1@austin.rr.com>
- Re: More /.{I->-1} craziness