From: Vince Virgilio on
Fred,


On Jan 4, 6:01 am, Fred Klingener <gigabitbuc...(a)BrockEng.com> wrote:

SNIP

> further mention that that hidden level can be discovered even by an
> "unsophisticated user" as the output of //FullForm would be like
> sharing the secret handshake.
>
> First line in tutorial/Applying TransformationRules:
>
> expr/.lhs->rhs apply a transformation rule to FullForm[expr]

SNIP

True.

However, for what it's worth, FullForm appears straightforwardly in
the Doc Center:

In Doc Center . . .
First section is "Core Language"
First bullet is "Language Overview"
First link is "Symbolic Expressions"
First documented command is "FullForm"

Then a one-liner for ReplaceAll occurs a few lines down. Yes, as you
say, the one-liner needs an edit.

I think this doc structure qualifies Mathematica as sufficiently
"discoverable" [*].

Vince Virgilio

[*] I.e. 3rd bullet, second section, at:
http://accu.org/index.php/journals/1572

From: Richard Fateman on
David Bailey wrote:
> Richard Fateman wrote:
>> Leonid Shifrin wrote:
>> ...
>>
>>> I think that there are not many more objects in Mathematica which are as
>>> tricky as <I> or Infinity in terms of pattern-matching.
>>
>> I agree.
>> That's why it can be fixed.
>>
>> Here's a beginning of a short list for the "we're not just talking
>> syntactic replacement-- version of substitution":
>>
>> If the user says -i --> i, then do Complex[a_,-b_] -> Complex[a,b].
>> If the user says x^2 --> y, then do x^(-2)-> 1/y also.
>>
>> I assume this list can be enlarged somewhat, and could even be left
>> open-ended by user option of some sort. [e.g. should x^2--> y also
>> change x^3 to x*y? or to y^(3/2) or ....]
>>
>> ....
>>
>>> It would perhaps be nice if such
>>> cases were more systematically documented, but they have nothing to do with
>>> bugs,
>> You are right if you mean "bug in Mathematica implementation of
>> intended design" (this is not such a bug).
>>
>> But there is another concept:
>> "bug in Mathematica design, contrary to reasonable mathematical expectation"
>> (this IS such a bug).
>>
> Would you really want to use a system which had been arbitrarily hacked
> by well meaning individuals to create exceptions that suited their taste?

Are you describing Mathematica here? It seems to me that it is an
exception that Head[a+b*I] is Plus, but Head[3+4I] is Complex.

>
> Perhaps the documentation should make it clearer which operations are
> supposed to always perform mathematically valid operations, and which
> are meant to operate on the structure of expressions, oblivious to their
> meaning.

You assume that people read the documentation. This is provably false.

I think this is an important distinction. If you pass an
> expression to Integrate (say), you expect to get the integral of that
> expression back as a result (possibly in symbolic form still involving
> an integral sign) - anything else is a bug.

Or an error message like "division by zero" or "out of memory".

However, other operations -
> such as ReplaceAll - are not *defined* mathematically, they are defined
> structurally, and as I pointed out earlier, can be used to produce
> explicitly invalid expression transformations.
>
This is obviously not the view of the person who initially posted this
question.

> Are you really saying that Mathematica doesn't need structural
> operations?

No.
Just that people want other kinds of operations for substitution. This
should be obvious from the subject line, I -> -I etc.


If it does, why pick on ReplaceAll?

Because this is enshrined in the syntax of the user language, and
APPEARS (falsely, as it turns out) to be a mathematical operation.
RJF

From: Richard Fateman on
Does it bear repeating?

In f[x_]:= ... the x_ is a pattern.

The reality in Mathematica programming is that this is NOT a function
definition, but a replacement rule. Contrary to Andrzej's opinion,
this is not "mathematical" but is made up of exactly the same stuff as
Rules, with pattern matching and replacement.

It is a useful shorthand illusion that you are defining a function.
But it is an illusion. Wolfram, in his earlier SMP, called these
Projections, but I guess that was just to confusing.

Here's a pattern-driven rule that describes how to replace f[something]:
f[x_]:=x+1

In contrast,
Mathematica DOES have functions. To define the (I think appx. same)
function as f above, you can do this:

f=#1+1&

and for people who wonder what this is, you can try it out and/or read
the manual.

And as for when/if these are exactly the same, I think there would have
to be some examination of the role of free and bound variables, the
effect of "return" and other issues that, by and large, also cause
confusion in the Mathematica context, since some ideas borrowed from
well-understood programming concepts were not quite understood by the
initial implementors of Mathematica. I don't know if they have been
patched correctly in the current system.



RJF


Andrzej Kozlowski wrote:
> On 3 Jan 2010, at 17:40, Vince Virgilio wrote:
>.....


I think its not a great exaggeration
> to say that most of applied mathematics consists of evaluation and most
> of pure mathematics of studying the effect of various equivalence
> relations on certain expressions. Neither has much in common with
> general syntactic substitution.

If you believe this then it seems that syntactic substitution would
really be a weak tool in so much of applied mathematics, and you should
be seeking a better tool.

RJF

From: David Bailey on
Fred Klingener wrote:
> On Jan 3, 3:37 am, DrMajorBob <btre...(a)austin.rr.com> wrote:
>> I think the way we enter and understand InputForm is syntax; FullForm is
>> the way they're stored internally.
>>
>> So Mathematica's pattern matching isn't what I'd call syntactical...
>> unless you mean "syntactical on a hidden (though discoverable) level".
>>
>> Bobby
> ...
>
> I studied the doc center entries for a few things like Replace,
> ReplaceAll, etc. as well as tutorial/ApplyingTransformationRules, and
> I was unable to find a single entry that might give what we're calling
> an "unsophisticated user" a hint that the lhs to be acted on is
> anything other than that displayed on the notebook screen.
>
> I wouldn't describe myself as "unsophisticated," but my expectations
> are conditioned and contaminated by almost 50 years of technical
> computing. As a result, I've been a slow learner of the grand
> structure of Mathematica, and I've spent my share of time astonished
> by the way Mathematica works and confused by the lack of rewards to be
> gained by RTFM.
>
> A mention in the docs of replacement happening on Bobby's "syntactical
> on a hidden (though discoverable) level" would be sufficiently
> frightening to drive some users back to the hand calculator, but
> further mention that that hidden level can be discovered even by an
> "unsophisticated user" as the output of //FullForm would be like
> sharing the secret handshake.
>
> First line in tutorial/Applying TransformationRules:
>
> expr/.lhs->rhs apply a transformation rule to FullForm[expr]
>
> unless you don't want to share the secret handshake.
>
> Cheers,
> Fred
>
>
>
If you can, get hold of one of those brick-like Mathematica books -
preferably version 5. The organisation of the book helps quite a bit -
there is a flow to it that you never find with the help system, plus you
can put book markers in it, etc. Failing that, you could print off the
virtual book. Graphics has changed a bit since version 5, but almost all
of the underlying concepts are unchanged.

Flow is important. For example, I encountered someone who wanted to
execute a program contained in more than one notebook. If he had read
through the book, roughly in order, he would almost certainly have
realised that the two notebooks would typically use the same kernel.
However, because he had not mastered the frontend/kernel concept, he
browsed the help system until he came across SelectionMove and
SelectionEvaluate.... The end result was not pretty!


David Bailey
http://www.dbaileyconsultancy.co.uk

From: E. Martin-Serrano on
Hi,

It is well known that there are many books about syntax (and semantics) and
programming languages available in English. (of course, most of you know
that). But, for others interested in the subject, the following are good
sources to find any reference.

Lambda Calculus: http://en.wikipedia.org/wiki/Lambda_calculus (Close to the
Mathematica underlaying form.)

BNF grammars : http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form (The
simplest form; only context-free syntax)

Affix-grammars: http://en.wikipedia.org/wiki/Affix_grammar (Augmented BNF to
include context sensitive syntax and semantics)

Two-Level grammars: http://en.wikipedia.org/wiki/Two-level_grammar
(Meta-grammars and hyper-grammars togheter o more sophisticated form of
Affix Grammrs used to describe Algol 68)

Petri nets: http://en.wikipedia.org/wiki/Petri_net (enriched finite state
machine grammars to include devices to trigger state transitions)

Phrase structured grammars: http://en.wikipedia.org/wiki/Chomsky_hierarchy
(seminal work in the field)

And many others.


E. Martin-Serrano




-----Original Message-----
From: Andrzej Kozlowski [mailto:akoz(a)mimuw.edu.pl]
Sent: Monday, January 04, 2010 11:58 AM
Subject: Re: Re: More /.{I->-1} craziness


On 3 Jan 2010, at 17:41, Leonid Shifrin wrote:

> Hi Richard,
>
> Below I describe rather extensively my view on the issues you raised. J=
ust
> to make myself clear, it is not my intention to get involved in an endles=
s
> debate on these topics. I try to adhere to DRY (don't repeat yourself)
> principle whenever I feel appropriate, so I detail my view on these subje=
cts
> below with the intention to do it only once. But I will certainly appreci=
ate
> your feedback.
>
> On Sat, Jan 2, 2010 at 9:06 AM, R Fateman <fateman(a)cs.berkeley.edu> wrote=
:
>
>> Leonid Shifrin wrote:
>>
>>> Regarding this issue, I think I entirely agree with what David Bailey a=
nd
>>> other people said: I don't consider replacement rules as a mathematical=
tool
>>> for end users, but rather as an inner layer of Mathematica, which is al=
so
>>> exposed for flexibility / convenience and intended primarily to be used=
by
>>> the more advanced users.
>>>
>>
>> Unfortunately many users or potential users are not as sophisticated in
>> their understanding of the distinction between the underlying mechanisms=
of
>> a syntax-driven
>> transformation system. They simply take the marketing blurbs about "A
>> system for doing mathematics" as a description suggesting that --hey, I=
do
>> mathematics too. They don't really know what "syntax" means and they do=
n't
>> think they need to know, because syntax is not part of their mathematics
>> education.
>>
>
> Well, if these people don't understand the importance of syntax for doing
> any formal sicence, regardless of whether it is done by a human or a
> computer, and somehow believe that some software is able to completely
> automate this problem away without any further efforts on their side - =
too
> bad for them and their current and future employers. Every tool used blin=
dly
> will eventually produce nonsense. Mathematica is a research tool. I view =
it
> as a tool for explorations, tests, verifications and sometimes discoverie=
s,
> but not a substitute for domain knowledge, intuition, right questions to =
ask
> and anticipation for possible correct answers.


I would add this: if someone does not know what syntax is he should take
some time off and read almost any introductory on mathematical logic. Need
not be written by anyone who has anything to do with computer science and
can be in fact pretty old.
The first example form my shelf: Yuri Manin "Lecture on Mathematical Logic"
vol 1., Chapter I, Section 2, Language of propositions: alphabet, syntax and
interpretation. (1974, in Russian but there is no shortage of equivalent
English texts).


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Prev: Persistent assumption
Next: Financial Data - Currencies