From: AES on
In article <i073p5$kn0$1(a)smc.vnet.net>,
Bill Rowe <readnews(a)sbcglobal.net> wrote:

> Sure, it might be reasonable to think the way the OP indicated.
> But to do so will clearly get in the way of using Mathematica
> efficiently. It is understanding what Mathematica actually does
> that is important here.

Quite true.

But if what Mathematica actually does differs, in some unexpected or
arcane (or hidden) way, from what reasonable, or reasonably experienced,
users might expect it to do -- and there certainly are some examples of
this in Mathematica -- that's of some importance also.

Situations where this happens generally don't mean that Mathematica has
to change its behavior -- that's not a realistic expectation in most
cases. But they do indicate that Wolfram might want to improve its
documentation in those particular cases.

From: Bill Rowe on
On 6/28/10 at 2:28 AM, siegman(a)stanford.edu (AES) wrote:

>In article <i073p5$kn0$1(a)smc.vnet.net>,
>Bill Rowe <readnews(a)sbcglobal.net> wrote:

>>Sure, it might be reasonable to think the way the OP indicated. But
>>to do so will clearly get in the way of using Mathematica
>>efficiently. It is understanding what Mathematica actually does
>>that is important here.

>Quite true.

>But if what Mathematica actually does differs, in some unexpected or
>arcane (or hidden) way, from what reasonable, or reasonably
>experienced, users might expect it to do -- and there certainly are
>some examples of this in Mathematica -- that's of some importance
>also.

If someone reasonably experienced in using Mathematica
encounters behavior they do not expect, then they gain more
experience with Mathematica and hopefully learn more about
Mathematica. What else could happen?

>Situations where this happens generally don't mean that Mathematica
>has to change its behavior -- that's not a realistic expectation in
>most cases. But they do indicate that Wolfram might want to improve
>its documentation in those particular cases.

I am not sure what outcome you are looking for here. Someone
such as myself with lots of experience with Mathematica wouldn't
look at the documentation prior to encountering your
hypothesized arcane characteristic. And given the size of the
documentation, the motivation for reading documentation is
either an unexpected result or trying to use some aspect of
Mathematica one is not experienced with. So, better
documentation will not prevent one from getting unexpected results.

My approach when I do encounter unexpected results is to first
verify I have done what I intended to do. This is usually the
source of my problems. If I have verified things are as I
intended and still get unexpected results, I use tools such as
Trace and FullForm in combination with the documentation for the
functions I am using to understand what is going on. So far,
this approach has always led to my understanding of why things
work the way they do. And it seems to me this is all I can
expect of the documentation.


From: AES on
In article <i0cjk9$88h$1(a)smc.vnet.net>,
Bill Rowe <readnews(a)sbcglobal.net> wrote:

> I am not sure what outcome you are looking for here.

Something like the following:

* Wolfram identifies, from user test panels that they set up, or from
monitoring particularly frequent queries or complaints in user forums
like this one, those "gotchas" in Mathematica that are particularly
likely to be encountered by novice or unsophisticated or unsuspecting
users, or particularly likely to cause serious damage.

("Particularly frequent" might be defined as the top 1% of all such
encounters.)

* And Wolfram then attempts to forestall these damaging encounters, or
attempts to assist users in recovering from them as quickly as possible,
by, as appropriate:

--Adding brief warnings about those specific gotchas in prominent
locations in the ref/ or elementary tutorial/ documentation that one
would go to if one encountered such a gotcha.

("Prominent location" is operationally described as "On the first screen
that opens when you go to this documentation".)

--Or, adding a small number of user-enable-able or disable-able warning
flags that will be displayed if the user issues a command that may raise
one of these gotchas.

Mathematica has, what, about 5000 commands in its vocabulary? Maybe 50
of those commands account for 90% of the gotchas that occur? Adding
maybe 50 such warnings or warning flags wouldn't be a good idea?

From: Bill Rowe on
On 6/30/10 at 1:49 AM, siegman(a)stanford.edu (AES) wrote:

>In article <i0cjk9$88h$1(a)smc.vnet.net>,
>Bill Rowe <readnews(a)sbcglobal.net> wrote:

>>I am not sure what outcome you are looking for here.

>Something like the following:

>* Wolfram identifies, from user test panels that they set up, or
>from monitoring particularly frequent queries or complaints in user
>forums like this one, those "gotchas" in Mathematica that are
>particularly likely to be encountered by novice or unsophisticated
>or unsuspecting users, or particularly likely to cause serious
>damage.

Given postings from Daniel Lichtblau, John Fultz and others at
Wolfram, I am sure this happens at least on an informal basis.

>("Particularly frequent" might be defined as the top 1% of all such
>encounters.)

>* And Wolfram then attempts to forestall these damaging encounters,
>or attempts to assist users in recovering from them as quickly as
>possible, by, as appropriate:

>--Adding brief warnings about those specific gotchas in prominent
>locations in the ref/ or elementary tutorial/ documentation that one
>would go to if one encountered such a gotcha.

>("Prominent location" is operationally described as "On the first
>screen that opens when you go to this documentation".)

Clearer documentation is always better. But given the size of
the current documentation this likely won't prevent new users
from experiencing the "gotchas" you are describing. Also, keep
in mind several of the things that new users seem to trip over
are things like thinking in terms of positive reals when
Mathematica is designed to treat everything as complex. Issues
like this are really related more to mathematics itself rather
than Mathematica.

>--Or, adding a small number of user-enable-able or disable-able
>warning flags that will be displayed if the user issues a command
>that may raise one of these gotchas.

>Mathematica has, what, about 5000 commands in its vocabulary?

Less. Using a tool documented in one of Roman Maeder's books, I
get a total of 3442 symbols in the System context of version 7.0
for Mac OS X x86 (64-bit) (February 19, 2009). Some of these of
course are constants such as E. Additionally, 580 of these
currently have no documentation that is returned by doing
?symbol. So, it seems there is much closer to 3000 things to be
covered in the documentation.

>Maybe 50 of those commands account for 90% of the gotchas that occur?
>Adding maybe 50 such warnings or warning flags wouldn't be a good idea?

I am not so sure this would be a good idea. Some of the things
being labeled "gotchas" are fairly fundamental. Adding overhead
to these things quite likely will impact performance. Also,
given the rather fundamental nature of some of these things,
there may well be other unintended consequences to other parts
of Mathematica. So, changing even a small number of these is
likely to entail quite a bit of effort to verify other problems
aren't introduced as a consequence of the change.


From: AES on
In article <i0i1lh$hqv$1(a)smc.vnet.net>,
Bill Rowe <readnews(a)sbcglobal.net> wrote:

> >Mathematica has, what, about 5000 commands in its vocabulary?
>
> Less. Using a tool documented in one of Roman Maeder's books, I
> get a total of 3442 symbols in the System context of version 7.0
> for Mac OS X x86 (64-bit) (February 19, 2009). Some of these of
> course are constants such as E. Additionally, 580 of these
> currently have no documentation that is returned by doing
> ?symbol. So, it seems there is much closer to 3000 things to be
> covered in the documentation.

Interesting data. Does this include all the named Options (or any
other "reserved words") that are defined or used with commands?

Mathematica is of course, among other things, a "second language", with
a vocabulary that has to be learned. The vocabulary size that one has
to learn to be fluent, or even minimally productive in Mathematica seems
to me a topic worth considering.

(And, for an engineer like me, having at least 3442 identified symbols
IS "about 5000"!)

A special aspect of Mathematica as a language is that just knowing its
vocabulary is a long way from enough. That vocabulary has to be used or
"spoken" with absolute accuracy: absolutely perfect spelling, absolutely
perfect perfect word order, absolutely perfect punctuation (defined by
some very complex and arcane rules), absolutely perfect choice of words
used -- to be of any use at all. There's no such thing as "pidgin
Mathematica".

(And to illustrate this point, for purists the first word in your quoted
excerpt above would have to be "fewer" rather than "less" -- right?
"Fewer" for countables, "less" for uncountables.)

I'm no expert on vocabulary science, but the excerpts from an online
article given below (very heavily trimmed, lots of cautionary text and
discussion removed) give some interesting data on that topic, and how
Mathematica might compare to other "second languages".



------------

VOCABULARY SIZE, TEXT COVERAGE AND WORD LISTS

Paul Nation and Robert Waring

How many words are there in English?

Two separate studies (Dupuy, 1974; Goulden, Nation and Read, 1990) have
looked at the vocabulary of Webster's Third International Dictionary
(1963), the largest non-historical dictionary of English when it was
published. When compound words, archaic words, abbreviations, proper
names, alternative spellings and dialect forms are excluded, and when
words are classified into word families consisting of a base word,
inflected forms, and transparent derivations, Webster's 3rd has a
vocabulary of around 54,000 word families. This is a learning goal far
beyond the reaches of second language learners and, as we shall see,
most native speakers.


How many words do native speakers know?

At present the best conservative rule of thumb that we have is that up
to a vocabulary size of around 20,000 word families, we should expect
that native speakers will add roughly 1000 word families a year to their
vocabulary size. That means that a five year old beginning school will
have a vocabulary of around 4000 to 5000 word families. A university
graduate will have a vocabulary of around 20,000 word families (Goulden,
Nation and Read, 1990). These figures are very rough . . .


For adult learners of English as a foreign language, the gap between
their vocabulary size and that of native speakers is usually very large,
with many adult foreign learners of English having a vocabulary size of
much less than 5000 word families in spite of having studied English for
several years.


How many words are needed to do the things a language user needs to do?

The good news for second language learners and second language teachers
is that a small number of the words of English occur very frequently and
if a learner knows these words, that learner will know a very large
proportion of the running words in a written or spoken text.


With a vocabulary size of 2,000 words, a learner knows 80% of the words
in a text

The significance of this information is that although there are well
over 54,000 word families in English, and although educated adult native
speakers know around 20,000 of these word families, a much smaller
number of words, say between 3,000 to 5,000 word families is needed to
provide a basis for comprehension.i


How much vocabulary and how should it be learned?

We are now ready to answer the question "How much vocabulary does a
second language learner need?" Clearly the learner needs to know the
3,000 or so high frequency words of the language. These are an immediate
high priority and there is little sense in focusing on other vocabulary
until these are well learned.


Contact Info:
Rob Waring
Notre Dame Seishin University, 2-16-9 Ifuku-cho, Okayama, Japan 700
Tel 086 252 1155 Fax 255 7663 Home 086 223 0341
Email:Rob Waring

Return to Main menu of papers