Mathematica skill level snippet(s)
Virgil Stokes
the programming skill level for some of my students (3rd year
undergraduates in Engineering and Physics). Knowledge of their skills in
Mathematica can be very important for the design of student projects
that require Mathematica.
I would appreciate suggestions for small segments of Mathematica code
(or perhaps a single segment of increasing complexity) that could be
used to at least get an idea of their skills in Mathematica. You can
assume they would be using Mathematica 7.
All suggestions, examples, comments, etc. will be welcomed :-)
--V. Stokes
Leonid Shifrin
For general programming, I would pick some of the simpler problems from
sources like the following:
and ask the students to solve them in Mathematica.
For Mathematica specifically, in "Introduction to programming with
Mathematica" by Paul Wellin et al, there is a number of good and relatively
simple problems in the exercise sections. Perhaps other introductory
Mathematica books which I am not familiar with may also have some good
exercises. Some problems from the exercise sections of Michael Trott's
programming guidebook (or examples in the main text) may also do.
>From what comes straight to my mind, some recursive or rule-based (or plain
procedural) implementations of things like factorial, Fibonacci numbers,
GCD, sorting, merge sort, select according to some criteria, binary search,
or some problems like computing primes (sieve of eratosthenes etc),
frequencies of say characters in a string, testing a string for a
palindrome, and the like should give a good idea of students' ability. I
only mentioned programming problems since they are field - independent to a
large degree. For computational ones I would guess that any good multi-step
calculus problem done (say both analytically and numerically) entirely in
Mathematica will do what you need. One thing I would definitely do is to
separate programming and computational assignments and test these skills as
independently as possible.
But I have a strong feeling that most of the students will ordinarily have
the biggest
difficulty simply with getting the syntax right and being able to
explain/correct the unusual output (I certainly had this difficulty for
quite a long time myself). I am not even sure that this has so much to do
with the programming proper - rather with the (relatively complex for a
newbie) evaluation process and symbolic nature of Mathematica. Perhaps,
tests like "predict the output" or "what is broken in this example", or "get
this to work" will be at least as useful as programming assigments proper
(in Michael Trott's programming guidebook there are a number of such
examples, although perhaps many of them are too advanced for the average
student).
It also depends on how much of the core Mathematica programming language you
would like the students to use. If the projects are such that the procedural
subset of Mathematica is enough, and its value in this context is mostly in
a large number of ready-to-use built-in functions, it is one thing. If
patterns, rules and functional programming will be needed, it is another
story. If performance can be important / critical, this is yet another one.
I know that some people end up creating a simplified framework of some kind
on top of Mathematica (sort of an API) to "isolate" their students from the
core Mathematica language, since mastering it may take a course on its own,
and may not be directly relevant to the domain they are learning through
Mathematica (I personally don't like this option. If students are eager to
learn and are good in some other programming language, I would rather give
them a brief introduction to Mathematica at the beginning, and let them use
as much of the power of the language as they can. But I acknowledge that
often the "framework" way may be the right choice).
Hope this helps.
Regards,
Leonid
Nasser M. Abbasi
"Virgil Stokes" <v...@it.uu.se> wrote in message
news:hd0t9u$82o$1...@smc.vnet.net...
I took a computational physics course at UCI (univ. of California, Irvine)
where we used Mathematica for everything. The exams, homeworks, quizzes,
everything was done using Mathematica.
I noticed many students had a hard time at the start since many did not know
Mathematica at all. But I think by the end of the course, most did well. I
also struggled in this course, but more from the physics part, not the
programming part, but that also to some extent ;)
I think if the students do not know any Mathematica, it would be a bit hard,
so may be you need to spend 2 weeks just on introducting mathematica before
anything the actual course starts.
Here is link to the course if you are interested to see the level of
difficultly. Here you see examples of problems we had to solve in
Mathemtica. May be you can use the first few homeworks as examples?
--Nasser
Kevin J. McCann
they need to know in order to get the project done; so, unless they are
complete beginners, I don't think you need to worry too much as long as
you are around to answer questions. If they are complete beginners, then
a couple of hours of lecture followed by hands-on assignments should get
them there in short order.
Kevin
AES
wrote:
Think of the problem in terms of **vocabulary**? How many words of the
Mathematica vocabulary do they know? -- or do you want them to know
and be able to use?
Maybe break this down into categories, e.g.:
* What David Park calls "set pieces" (Plot, ListPlot, Table) and the
options they should know for each.
* Standard functions and list operators [Sin, Cos, Total]
* Arcane symbols: =, ==, :=, ->
* Ways of formatting input and output, graphics operators or options.
* Ways of constructing Functions, Blocks, Modules, arguments.
and decide what you want them know in each category, and to what level
of detail? Then put just the names of these (not definitions) in a
handout?
[Side question: How many total words and symbols are there in the
**full** Mathematica vocabulary? If you made a glossary of **every**
single documented term (symbol name, function, option, operator,
non-alphameric symbol, etc, etc in Mathematica 7), how many terms would
be in it?]
[I'm guessing maybe 3000 or 4000? Or even more?]
Nasser M. Abbasi
"AES" <sie...@stanford.edu> wrote in message
news:hd3n4j$a2k$1...@smc.vnet.net...
>
> [Side question: How many total words and symbols are there in the
> **full** Mathematica vocabulary? If you made a glossary of **every**
> single documented term (symbol name, function, option, operator,
> non-alphameric symbol, etc, etc in Mathematica 7), how many terms would
> be in it?]
>
> [I'm guessing maybe 3000 or 4000? Or even more?]
>
For version 7, Length[Names[�System`*�]] results in 3429
I made a list for few version in my Mathematica versions table, click on the
links in the last column to see the symbols.
http://12000.org/my_notes/compare_mathematica/index.htm
My theory is this: A Mathematica expert is someone have used more than 50%
of these symbols. I am still working on my 5% :)
--Nasser
AES
"Nasser M. Abbasi" <n...@12000.org> wrote:
> > [Side question: How many total words and symbols are there in the
> > **full** Mathematica vocabulary?
> >
> > [I'm guessing maybe 3000 or 4000? Or even more?]
> For version 7, Length[Names[�System`*�]] results in 3429
>
> <http://12000.org/my_notes/compare_mathematica/index.htm>
>
> My theory is this: A Mathematica expert is someone have used more than 50%
> of these symbols. I am still working on my 5% :)
Fascinating results -- I'm very impressed that you've done this.
Lurking behind my original question is, admittedly, my continuing
concern that Wolfram, in its continuing attempt to make Mathematica into
a single app that does absolutely everything for everyone, is instead
creating a monster that has become increasing difficult for more and
more of its potential audience to use.
If you view Mathematica as a "second language" that its potential users
must learn to use and communicate in, the vocabulary size of Mathematica
then becomes one metric for measuring this.
I'm no expert on vocabulary sizes myself, and recognize that it's a
complex subject; but one readable essay on the subject seems to be:
<http://www1.harenet.ne.jp/~waring/papers/cup.html>
A few snippets from this essay (very heavily excerpted) are appended
below. There's a great deal more it; but I suggest that comparing it to
Mathematica's vocabulary size, and thinking about Mathematica as a
second language that users have to learn, ***and then use with absolute
precision***, is an instructive exercise.
----------
VOCABULARY SIZE, TEXT COVERAGE AND WORD LISTS
Paul Nation and Robert Waring
How much vocabulary does a second language learner need?
There are three ways of answering this question. One way is to ask "How
many words are there in the target language?" Another way is to ask "How
many words do native speakers know?" A third way is to ask "How many
words are needed to do the things that a language user needs to do?" We
will look at answers to each of these questions.
How many words are there in English?
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 and there is likely
to be very large variation between individuals.
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. Large numbers of second language learners do achieve
vocabulary sizes that are like those of educated native speakers, but
they are not the norm.
How many words are needed to do the things a language user needs to do?
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. It is possible to make use of a
smaller number, around 2,000 to 3,000 for productive use in speaking and
writing. Hazenburg and Hulstijn (1996) however suggest a figure nearer
to 10,000 for Dutch as a second language.
---------------
Bill Rowe
>Lurking behind my original question is, admittedly, my continuing
>concern that Wolfram, in its continuing attempt to make Mathematica
>into a single app that does absolutely everything for everyone, is
>instead creating a monster that has become increasing difficult for
>more and more of its potential audience to use.
>If you view Mathematica as a "second language" that its potential
>users must learn to use and communicate in, the vocabulary size of
>Mathematica then becomes one metric for measuring this.
It is reasonable to view Mathematica as a "language" with a
vocabulary and syntax to be learned. But. the total number of
symbols really isn't a good metric of what must be learned to
use Mathematica effectively. This metric probably is a
reasonable metric only if you assume starting with very little
knowledge of mathematics.
Most of the things in Mathematica's vocabulary have a one to one
correspondence with the something in mathematics. The naming
convention used in Mathematica makes this correspondence fairly
obvious. So, for someone who already has a good grasp of
Mathematics, the vocabulary to be learned in order to use
Mathematica effectively is much smaller than the total list of
symbols available.
The key here is the intended audience for Mathematica. I don't
see the primary purpose of Mathematica as being teaching mathematics.
One other point. Like mathematics, it is not necessary to learn
everything in Mathematica before making effective use of Mathematica.
DrMajorBob
even 10% of the word families in a second language. Even native speakers
typically don't know half.
That likely applies (approximately) to Mathematica as well, so you haven't
demonstrated a problem with the size of Mathematica.
It's also MUCH smaller than any spoken language... although admittedly,
the meaning of a Mathematica "word" can be quite involved.
We learn whatever subset we need, and that's a continual but manageable
effort.
Bobby
On Mon, 09 Nov 2009 04:47:04 -0600, AES <sie...@stanford.edu> wrote:
> In article <hd6bbm$odf$1...@smc.vnet.net>,
> "Nasser M. Abbasi" <n...@12000.org> wrote:
>
>> > [Side question: How many total words and symbols are there in the
>> > **full** Mathematica vocabulary?
>> >
>> > [I'm guessing maybe 3000 or 4000? Or even more?]
>
>> For version 7, Length[Names[“System`*”]] results in 3429
>>
>> <http://12000.org/my_notes/compare_mathematica/index.htm>
>>
>> My theory is this: A Mathematica expert is someone have used more than
>> 50%
>> of these symbols. I am still working on my 5% :)
>
>
> Fascinating results -- I'm very impressed that you've done this.
>
> Lurking behind my original question is, admittedly, my continuing
> concern that Wolfram, in its continuing attempt to make Mathematica into
> a single app that does absolutely everything for everyone, is instead
> creating a monster that has become increasing difficult for more and
> more of its potential audience to use.
>
> If you view Mathematica as a "second language" that its potential users
> must learn to use and communicate in, the vocabulary size of Mathematica
> then becomes one metric for measuring this.
>
> I'm no expert on vocabulary sizes myself, and recognize that it's a
> complex subject; but one readable essay on the subject seems to be:
>
> <http://www1.harenet.ne.jp/~waring/papers/cup.html>
>
> A few snippets from this essay (very heavily excerpted) are appended
> below. There's a great deal more it; but I suggest that comparing it to
> Mathematica's vocabulary size, and thinking about Mathematica as a
John Fultz
>
>
> "AES" <sie...@stanford.edu> wrote in message
> news:hd3n4j$a2k$1...@smc.vnet.net...
>
>>
>> single documented term (symbol name, function, option, operator,
>> non-alphameric symbol, etc, etc in Mathematica 7), how many terms would
>> be in it?]
>>
>>
>
>
> I made a list for few version in my Mathematica versions table, click on
> the
> links in the last column to see the symbols.
>
>
> My theory is this: A Mathematica expert is someone have used more than 50%
> of these symbols. I am still working on my 5% :)
>
It's probably considerably less than 50%, actually. Mathematica has really
quite a number of functions which are either fairly domain-specific or syntactic
sugar (i.e. a function which accomplishes something the language can already do
without much difficulty, but allows for simpler expression). And, of course,
these functions are far from equal in complexity...compare, for example, the
complexity of IdentityMatrix to Import (the latter of which I'm *still* looking
up in the docs all the time for various tidbits).
I'm really just guessing here, but I suspect my own usage of these kernel
symbols is below 25%. Dan Lichtblau's is probably higher than mine, but I doubt
he's at 50% either.
The fact that we make such productive use of Mathematica nonetheless, I think,
is a mark in its favor. You really can come in with a certain domain knowledge,
plus a core body of functionality (mostly related to pattern and list
processing) and be incredibly productive.
Stephen Wolfram wrote a blog post which included a ListPlot of the function
count from Mathematica's inception to version 7.
http://blog.wolfram.com/2008/11/18/surprise-mathematica-70-released-today/
The plot is about a third of the way through the post. Note the number here is
significantly below your number because you're counting all System` symbols,
whereas he was counting System` *functions*.
Sincerely,
John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc.
Nasser M. Abbasi
From: "John Fultz" <jfu...@wolfram.com>
"Stephen Wolfram wrote a blog post which included a ListPlot of the function
count from Mathematica's inception to version 7.
http://blog.wolfram.com/2008/11/18/surprise-mathematica-70-released-today/
The plot is about a third of the way through the post. Note the number here is
significantly below your number because you're counting all System` symbols,
whereas he was counting System` *functions*.
"
Yes, I know about this blog (it is one of the references already on my
page), and I actually remember spending sometime trying to find how did Dr
Wolfram would have counted the number of functions, but I could not figure
it out (the command used to generate the plot was not shown in the blog.)
Do you know how to find how many of the Symbols are actually Functions such
as Sin,Cos etc.. vs. say function options or other type of symbols? Since
the Head of a Function is a Symbol itself I can't just look at the Head of
each symbol to find out?
In[6]:= Head[Sin]
Out[6]= Symbol
In[7]:= Head[Joined]
Out[7]= Symbol
If I filter by attribute, which I think may be the way to do it, then which
set of attributes to use? Listable? gives only 264
Length[Select[Names["System`*"], MemberQ[Attributes[#1], Listable] & ]]
264
So, need more attributes which all apply to functions, then get a unique
list out, then count it? But I do not know what all the attributes should
be.
If you know _please_ let me know, and I will add this information to the
table.
thanks
--Nasser
fd
> From: "John Fultz" <jfu...@wolfram.com>
>
> "Stephen Wolfram wrote a blog post which included a ListPlot of the function
> count from Mathematica's inception to version 7.
>
I believe that any user of a complex software (like MS word for
example) will use just a fraction of the functionalities in it - a
knowledge which generally increases with time. From my experience it
is usually easier to do things in Mathematica than in any other
program. Compare with SPSS, which I tried to use a while ago: I had to
navigate through many menus with heaps of functionalities, and very
difficult to reproduce steps. Mathematica has some it functions not
well documented for sure, like GeoPosition for example, what I
understand as it is quite recently incorporated.
What I'm not quite happy with is when some options are given as
strings (for e.g. the ColorFunction option in DensityPlot[Sin[x y],
{x, 0, 3}, {y, 0, 3}, ColorFunction -> "BlueGreenYellow"] ), this
confuses me a bit as I can't know all the options available apart from
looking in the documentation (how could I know there is also an
ColorFunction->"Rainbow"? Is there a general way of finding all
possible names a option my have?).
David Park
not always the shortcut version. And there is ColorData[] and
ColorData["Gradients"] // Column
But a casual user of Mathematica might not know about that. Options in
String form are probably a reasonable solution for many special facilities
and keeps the 'official' list of Mathematica symbols from ballooning. It
would help if they were better documented.
1) I think Bill Rowe made a good point that much of Mathematica mirrors
mathematics so one is not learning an entirely new subject.
2) I for one think the Mathematica documentation is fairly good and allows
one to drill down to special topics. Of course, it can always be improved in
places and extended but I think WRI has made a tremendous effort with the
documentation.
3) Nevertheless, there is so much to Mathematica such as learning basic
syntax, the core commands, functional commands, plotting, use of options,
equation solving, color specification, etc., that I am dubious about
advanced students taking on advanced topics with only a brief introduction
to Mathematica. I suspect they may only do well in a limited way, such as
modifying a basic scheme already set out for them. (I may be biased in this
view because of my own limitations.)
4) It would be far better if students heading for a technical career started
learning Mathematica in high school and didn't have to struggle with the
basics when they got to college.
5) It will help if Mathematica gets more "settled down". Version 6 was
really jarring to many users - and yet, I for one, really appreciate the new
capabilities that came with it.
David Park
djm...@comcast.net
http://home.comcast.net/~djmpark/
Drago Ganic
I think there is no way except enumerating the symbols. Unfortunatly
Mathematica is lacking some attributes (like Command, Option etc.) or some
other mechanism (e.g. system tables) for providing those kind of
information.
BR,
Drago
"Nasser M. Abbasi" <n...@12000.org> wrote in message
news:hdbhn2$jol$1...@smc.vnet.net...
Vince Virgilio
[snip]
> What I'm not quite happy with is when some options are given as
> strings (for e.g. the ColorFunction option in DensityPlot[Sin[x y],
> {x, 0, 3}, {y, 0, 3}, ColorFunction -> "BlueGreenYellow"] ), this
> confuses me a bit as I can't know all the options available apart from
[snip]
"documentation" is precisely where all available options should be
listed [*]. Fun as it might be, Mathematica should not assume or
tacitly rely on users spelunking to find approved options (not
obsolete, deprecated, or experimental).
Vince Virgilio
[*] This applies as well to default option values. For example,
PlotStyle's spec as Automatic in Plot[] would benefit from some
elaboration.
DrMajorBob
Why would we want to know what Automatic means, for goodness sake!
Bobby
On Thu, 12 Nov 2009 05:00:13 -0600, Vince Virgilio <blue...@gmail.com>
wrote:
John Fultz
messages are written very systematically. I suspect, for example, the vast
majority of usage messages (if not every single one) which begin with
"<symbol> " (*i.e. followed by a space *)
are options or other free names which aren't functions. On the other hand,
every usage message that begins with...
"<symbol>[" is guaranteed to be a function. But many symbols map to operator.
For example, see the usage message for Plus, which is why searching for messages
which *don't* match "<symbol> " is better than searching for symbols which match
"<symbol>[".
I did start to write a solution to do this, but there's a bit of HoldPattern
magic and such that needs to be done and I was too busy to spend time getting it
to work (I did have something kind of working, actually, but then accidentally
quit my session w/o saving, and gave up because of the ten million other things
on my to-do list).
Sincerely,
John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc.
Vincent N. Virgilio
I hope there's not a conflated design decision lurking behind Mathematica's
ubiquitous Automatic. There's a bright line between automatic
algorithmics/aesthetics and Automatic options. Sure, the two overlap, so the
line has some width. PlotStyle in Plot probably doesn't always have the same
Automatic value. Still, this is about engineering good software, not
perfecting a mathematical edifice [* soapbox], so WRI can approximate. They
can and should specify usual, common, or frequent values for Automatic
options and similar elements. There are examples which demonstrate that they
already understand this; viz, the documentation of MeshFunctions clearly
lists default values across host functions.
Vince Virgilio
[* soapbox]
The mantra "everything is an expression" in Mathematica is about as helpful
as "everything is an atom" is in the physical universe, or "everything is an
utterance" is in linguistics. It's a beautiful observation that more can
enjoy than benefit from in economic time. WRI should not overuse it.
Certainly not to present Mathematica as so plastic that it defies
documentation.
Perhaps it's time to start making some "hard decisions" and evolve the
Mathematica language from compiler-level abstract syntax tree mechanisms
into something more human, with more convenient system-supported idioms; now
there are at most a few. More constraints, perhaps, but likely also more
efficiencies. As it stands, Mathematica is a strange mix of ultra high-level
semantic terminals (NDSolve) and their low-level grammatical glue.
WRI probably needed this scaffolding to get so far, but eventually
scaffolding is taken down. This might be a timely suggestion, since Stephen
Wolfram's personal to-do list for Mathematica will probably complete in the
next couple of major releases (
http://blog.wolfram.com/2009/11/06/a-remarkable-year-ahead-for-mathematica/).
Plenty
of time for linguistic evolution and ramp-up, no?
M.Roellig
> I did start to write a solution to do this, but there's a bit of HoldPattern
> magic and such that needs to be done and I was too busy to spend time getting it
> to work (I did have something kind of working, actually, but then accidentally
> quit my session w/o saving, and gave up because of the ten million other things
> on my to-do list).
If there only was an autosave feature ;-)
(Sorry, but I could not resist)
Markus
P.S. BTW I agree to those that find the documentation helpful. It
takes some time
to dig into it, but one finds surprising stuff. Of course it can
always be better but
compared to other software docs it's quite ok. However, it is not
always easy to
find the information that one may need at the moment.
fd
I think I got late for the discussion (as usual)...
There is an Auto Save feature in Mathematica, but I had to turn it off
because it was slowing down things and work with dynamic evaluation
was almost impossible...
Most of the complains about documentation, from my part, are when it
is too brief and does not contain many examples. In the ColorFunction
case I mention above, for example, the documentation gives you how to
retrieve all available options, but it is concealed - personally I
would show emphasize this a lot more, but the Mathematica developers
surely have a different set of personal preferences, so I do not
complain about it.
AES
> Most of the complains about documentation, from my part, are when it
> is too brief and does not contain many examples. In the ColorFunction
> case I mention above, for example, the documentation gives you how to
> retrieve all available options, but it is concealed - personally I
> would show emphasize this a lot more, but the Mathematica developers
> surely have a different set of personal preferences, so I do not
> complain about it.
I certainly recall a while back wanting to try our a variety of
different ColorFunctions so I could find an optimal choice for a series
of plots I was making, and finding the whole topic very complex and
arcane, and the process of finding or creating demos of different
functions very much of a hassle.
John Fultz
>>
>>
>> I did start to write a solution to do this, but there's a bit of
>> HoldPattern magic and such that needs to be done and I was too busy to
>> spend time getting it to work (I did have something kind of working,
>> actually, but then accidentally quit my session w/o saving, and gave up
>> because of the ten million other things on my to-do list).
>>
> If there only was an autosave feature ;-)
>
> (Sorry, but I could not resist)
>
> Markus
>
> P.S. BTW I agree to those that find the documentation helpful. It takes
> some time to dig into it, but one finds surprising stuff. Of course it
> can always be better but compared to other software docs it's quite ok.
> However, it is not always easy to find the information that one may need
> at the moment.
I don't know of any auto-save feature which would have saved me from
myself...i.e., bypassing both opportunities to save during the session and a
request to save at the end of a session (every auto-save feature I've seen
throws away info after you intentionally decline to save a document).
FWIW, we do have a naively implemented auto-save feature (and have had for many,
many years). It's not turned on by default for good reason, as was pointed out
by another response to this message.
I certainly understand why there is sometimes frustration about stuff not coming
out of the Wolfram feature pipe fast enough. I think that, sometimes, people
leap to the conclusion that we're not listening, or are being stubborn. On the
contrary, as I think many people around here do understand, we take many of our
cues for features from comments on this list. I don't know of any software
product where as many developers are as plugged into the user community (largely
through this forum) as ours is. However, we try to make a practice of not
shipping features until we can make them a fully integrated and highly usable
part of the system. That's sometimes very difficult and time-consuming.
There's evidence of why we should do this in the archives of this group. For
example, after frequent complaints about copy/paste (particularly of code into
posts on this forum), we completely revised the feature in version 6. It was
something like a full year after we shipped this feature before anybody
noticed...presumably because everybody had been trained by experience to avoid
it. Negative reinforcement is really strong and hard to break. I've had
several experiences like that which cause me to realize that people have a very
long memory about stuff that's broken. Better to not ship it than to ship it
broken, is the conclusion I've reached.
So, whatever your pet feature is, if enough people on this forum have talked it
up, we're probably working on it or at least have plans for it. In some cases,
we're even designing features based on MathGroup posts for which no feature was
ever explicitly proposed (when the same shortcoming comes up again and again,
maybe we can design a feature to overcome it). I, for one, rarely respond to
these things, though, because I hate making promises I don't know if I can keep
(e.g., about when such a feature can ship), and because I'm pretty much the
wrongest person in the company to do a marketing/spin-job response.
David Park
1) Color is a complicated phenomenon and it takes some skill and practice to
learn how to use it. Basically how to use the Color Schemes palette, Blend,
Lighter and Darker, how ..Data.. things work, and how to use Functions and
Rescale and ColorFunctionScaling to do specific color design. Color is
usually ancillary to some user's work. It is a skill users should learn
before they get to college so they won't have to wrestle with it while
working on their real problems. It's like spelling and grammar. It's just
another example of why Mathematica won't truly come into its own until
people routinely receive early training.
2) Mathematica is still a relatively new product. Twenty years is nothing.
It will be a lot easier once a wider core of things gets settled down. We
have to hope that this will happen, that WRI will make it a prime
consideration, and the problems of a morphing instrument will diminish. In
the meantime we suffer from being early users. But look on the bright side.
You also get to be a pioneer. WRI doesn't know how to use Mathematica.
Nobody knows. It's like saying Edison knew how to make movies.
From: AES [mailto:sie...@stanford.edu]
In article <hdqb2s$6mn$1...@smc.vnet.net>, fd <fdi...@gmail.com> wrote:
> Most of the complains about documentation, from my part, are when it
> is too brief and does not contain many examples. In the ColorFunction
> case I mention above, for example, the documentation gives you how to
> retrieve all available options, but it is concealed - personally I
> would show emphasize this a lot more, but the Mathematica developers
> surely have a different set of personal preferences, so I do not
> complain about it.
I certainly recall a while back wanting to try our a variety of