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