Mathematica 9 is now available
Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2010

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

Search the Archive

Re: Replacement Rule with Sqrt in denominator. Also Bug in Series

  • To: mathgroup at smc.vnet.net
  • Subject: [mg114733] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • From: Bill Rowe <readnews at sbcglobal.net>
  • Date: Tue, 14 Dec 2010 06:57:22 -0500 (EST)

On 12/13/10 at 3:51 AM, fateman at cs.berkeley.edu (Richard Fateman)
wrote:

>On 12/12/2010 2:41 AM, Bill Rowe wrote:
>>On 12/11/10 at 1:52 AM, fateman at cs.berkeley.edu (Richard Fateman)
>>wrote:

>>Access to the source code of a similar program cannot tell you how
>>easy/difficult something is to implement in Mathematica.

>Sure it can. Not in all cases, but in some cases the requirements of
>a program provide a fairly clear basis on which to design an
>implementation.  There are several open-source pattern match
>programs similar to Mathematica's  (e.g. mine, Kevin McIsaac's
>http://www.reduce-algebra.com/docs/pm.pdf, matheclipse, ...)

>>You've no basis for assuming the code in Mathematica is partitioned
>>in the same manner, uses the same approaches etc as your similar
>>program.

>Actually, you are wrong.  There is a basis for assuming the code is
>similar.  (a) Its behavior (including misfeatures) is predictable
>based on some assumptions of similarity. (b) Sometimes there are not
>really so many reasonable ways of doing something.

Let me clarify. One can always say there is a basis for
assumptions. But, having a basis for assumptions doesn't make
the assumptions valid. In essence, to reason something will be
easy to implement in Mathematica because it is easy to do in a
similar program requires assumptions about how Mathematica is
coded which cannot be validated without access to the source
code for Mathematica. A different set of assumptions leads to
different conclusions about ease of implementation. Arguing
something is easy/hard with out access to the source code is
pointless. There is no way to determine which set of assumptions
is a better match to reality.

My only reason for making any comment in response to a claim
something is/should be easy to change in Mathematica is
invariably those claims are invoked as part of the reasons
someone at WRI should implement something. They are (in effect)
a put down to the developers at WRI who are the ones with access
to the source code and are the only ones that can truly
determine how easy/hard making some change to Mathematica will be.

>>3+4I for the same reason 2.345/.2->1 yields 2.345.

>2.345/.2->1  does not yield 2.345.
>
>It yields 11.725 -> 1

>And for an entirely different reason, which is that Mathematica
>parser requires a space after "/."  when the next token is a number.

Yes, I should have written one of the following:

2.345/. 2->1
2.345/.(2->1)
2.345/.{2->1}

which all yield 2.345 since it is not possible to change part of
a real value using replacement rules. And for the same reason
3+4I/. I->-I has no effect.

>>That is, despite the way it appears on screen, to Mathematica 3+4I is
>>a single entity with no parts. You can replace the entire entity but
>>not part of it.

>Well, is that a good thing or a bad thing?  Does it HAVE to be that
>way?

No it doesn't have to be that way. Mathematica could have been
designed differently. But, it doesn't matter one bit whether I
see the current design as good or bad. Perhaps, at some point
WRI will change this aspect of the design. Until then, it is
what it is. And this behavior certainly isn't a bug or design error.

>>If the brewer's new beer formulation wasn't to my liking, I
>>wouldn't buy it again from him. Instead I would get beer from
>>another brewer.

>It is a harder to change from one software system to another, than
>to choose a different beer, at least in most countries.

So? Harder to do doesn't mean it can't be done.

>Imagine if there were only one brand of beer.

Imagining things that don't match reality doesn't seem useful to me.


>>If WRI becomes totally unresponsive to users, then there is
>>opportunity for competitors to WRI. Eventually, being totally
>>unresponsive to your user base will mean you have no users.

>Really?  Consider industrial monopolies.  Consider totalitarian
>regimes. Consider software operating system "lock-ins".

And since when did WRI become a monopoly? Or comparable to a
totalitarian regime? And as far as operating system "lock-ins" I
use a Mac which arguably is one of the more "locked-in"
operating systems. Yet, I I choose, I could run Windows, Linux
or one of a variety of other flavors of Unix on my Mac. So, the
"lock-in" is really my choice.

>>My experience is software developers react much better to reasoned
>>requests for changes then they do claims behavior that is precisely
>>as they intended is a bug and must be changed.

>Oh, so now you want me to be polite. That costs extra.

I've not asked you to do anything. I merely point out being
polite is more effective at getting the desired response in my
experience. You are free to behave as you choose.

It appears this discussion is unlikely to produce anything
useful at this point. So, I likely won't respond further in this
thread. In fact, I probably should have stopped responding
several posts ago.



  • Prev by Date: Re: Calculate a numerical integral with enough precision
  • Next by Date: Re: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt in denominator
  • Previous by thread: Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • Next by thread: Re: paclet type documentation / cpu usage w. Help Browser