Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1998
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 1998

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

Search the Archive

Re: Re: declaring integers

  • To: mathgroup at smc.vnet.net
  • Subject: [mg13181] Re: [mg13063] Re: declaring integers
  • From: David Withoff <withoff>
  • Date: Mon, 13 Jul 1998 07:42:29 -0400
  • Sender: owner-wri-mathgroup at wolfram.com

> On Tue, 7 Jul 1998, David Withoff wrote:
> 
> > My first question is about the connection you mentioned between declaring
> > variable types and whether or not Mathematica is considered a functional
> > language, a procedural language, or something else.  I don't understand
> > what you mean by that.  These seem like orthogonal issues to me.
> 
> What I meant is that, in a functional language, using Scheme as a
> description
> 
>   (foo a (bar b)) 
> 
> Results in a procedure object, named foo, which consists of machine code,
> being executed, with two values "on the stack" or wherever paramaters are
> passed. That code takes the two values, does something, and puts a value
> "on the stack" and exits. If it is enclosed in another form, then that
> form takes the value on the stack and keeps going. That's a complete
> description of "foo".
> 
> It so happens in this example, that the second value came to be "on the
> stack" because of another piece of code, which is part of the bar object,
> being executed.
> 
> But "foo" doesn't know that! It just takes values and foos them.
> 
> As we discussed in e-mail, 
> 
> Plus[Times[2,a],a,b] --> Plus[Times[3,a],b]
> 
> Which means that Plus knows that Times[] was enclosed. 
> 
> The distinction is that, for my "foo" example, it makes sense to talk
> about those values "on the stack." In that, they are a certain size, or
> are in a floating-point register. Or, in a language like scheme, they
> could be many different types, where the type is marked in some "magic"
> way.
> 
> In the Plus[Times[]] example, one can't really talk about the value being
> added. What type is Times[3,a]? It's a symbolic expression. It doesn't
> correspond to a piece of computer code with a MUL instruction. It would
> have some particular numerical type if we gave "a" a numerical value,
> perhaps, but I can't tell you whether the CPU will do a MUL or an FMUL
> instruction to compute it.

The answer to "What type is Times[3,a]?" can be determined if sufficient
information about "a" is available, even if "a" is never given a value.
If the computer is told that "a" is a positive real number, for
example, then the computer can determine that Times[3,a] is also a
positive real number, which would be useful information if one wanted
to know if Integrate[Exp[Times[3,a] x],{x,0,Infinity}] was a convergent
integral, or if Sqrt[Times[3,a]^2] was equal to Times[3,a].

The whole point of a symbolic manipulation system is to provide for
working with expressions where one doesn't know if a result might be
computed using a MUL or an FMUL instruction, or what sort of register
the result might be stored in if the symbols were given values.

One way to address the problem of needing to determine the type of
symbolic expressions is to throw the problem away, by considering it an
error when symbols don't have values.  That's where this aspect of
Scheme comes in. Certainly Mathematica can be used that way.  There is
no requirement that Mathematica symbols be valueless.  If symbolic
manipulation is to be done, however, then that problem obviously must
be faced more directly.  

Regarding the rest of your message, I enjoyed your description of your
struggles to learn a new programming language.  I am sure that just
about everyone can sympathize with that experience, especially when the
learning is affected by details borrowed from another language.

For your specific example:

> I found myself with a list of anonymous functions which I wanted to apply
> to a given argument, in order to end up with a list of the results.
> 
> E.g. {Sin[#1]&, Cos[#1]&,.....}[3.14]  --> 
> 
>      { 0.0, -1.0, .....} was my goal.

here are some of the ways to do that in Mathematica:

In[1]:= Through[{Sin[#1]&, Cos[#1]&}[3.14]]

Out[1]= {0.00159265, -0.999999}

In[2]:= Map[#[3.14] &, {Sin[#1]&, Cos[#1]&}]

Out[2]= {0.00159265, -0.999999}

In[3]:= Table[{Sin[#1]&, Cos[#1]&}[[k]][3.14], {k,2}]

Out[3]= {0.00159265, -0.999999}

and so forth.  Facilities for handling this sort of task in Lisp are
sufficiently similar to corresponding facilities in Mathematica that I
suspect that any reasonable way of doing this in Lisp could be
translated almost directly into Mathematica.

When I got too

> I give up trying to do it all anonymously and end up with
> 
> apply1 := Function[arg, Apply[#1, List[arg]]&]
> 
> then I use it
> 
> extraplist = Map[Apply[fit90clip[#1, #2, 0.0]&, #1]&, lin3ft];
> t0ex0 = Map[apply1[0.0], extraplist];
> 
> Hooray! this does what I want.

I started wondering what lin3ft and fit90clip were, since it seems that
this is equivalent to

    t0ex0 = Apply[fit90clip[#1, #2, 0.0][0.0] &, lin3ft, {1}]

assuming that lin3ft is a list of pairs (data points perhaps?) and
fit90clip takes arguments fit90clip[arg1, arg2, arg3][arg4].  If those
assumptions aren't correct, I would be curious to know what you were
trying to do here.

> I don't have Dybvig's book, but the fact that it is the first example
> doesn't surprise me. It certainly doesn't represent how apply is actually
> *used*. (apply + '(2 2)) is not "proper quoting." It's just a verbose way
> to write (+ 2 2).  I can't think of a single *useful* way to use quote on
> the second argument of apply, outside of a textbook example. 
>   
> Just as in Mathematica Apply[Plus, {2,2}] is just a toy example--no one
> would do this, because it is just Plus[2,2]. NOTE, however, that this
> simple example only works because {2,2} is an input form for for
> List[2,2].

Actually, this construction is very common in Mathematica.  For example:

In[1]:= Apply[Plus, {1, 2, 3, 4, 5}]

Out[1]= 15

to compute the sum of a list of numbers, or

In[2]:= Mean[data_List] := Apply[Plus, data]/Length[data]

In[3]:= Mean[{1, 2, 3, 4, 5}]

Out[3]= 3

to compute the mean of a list of numbers.

> I'm not trying to identify complaints about Mathematica (although I have
> them :-)), just trying to explain that differences between Mathematica and
> other languages can cause trouble for someone with expectations based on
> those other languages.

Good.  I can agree with all of that.  I'm just surprised that the two
languages in question are Lisp and Mathematica.  These languages look
so similar to me that I had assumed, apparently incorrectly, that
Mathematica would seem fairly natural to someone who already knew Lisp.
I learned Lisp before I saw Mathematica (before Mathematica existed),
and quite the opposite of causing trouble, I found that background to
be very helpful in learning Mathematica.  I can imagine the transistion
from Fortran or C to Mathematica would be harder, but Lisp?  I wouldn't
have anticipated that that would be a problem.

I wish that I could have been there, or that some experienced
Mathematica programmer could have been there, to look over your
shoulder or offer advice when you were learning Mathematica.  If you
have occasion to try programming Mathematica again, or for anyone else
learning to use the system, there are a number of resources to help in
that process, such as contacting technical support, finding an expert
to help you out, reading the documentation, investigating one of the
dozens of tutorial books, and asking questions in this newsgroup.  A
certain amount of struggle is an unavoidable part of learning almost
anything, but these resources can save a lot of time, and can help
clear up puzzlement before it degenerates beyond simple frustration.

Dave Withoff
Wolfram Research


  • Prev by Date: Re: Integrate Bug?
  • Next by Date: Gradient Option in FindMinimum
  • Previous by thread: Re: Re: declaring integers
  • Next by thread: Re: Re: Re: declaring integers