Re: Mathematica daily WTF
- To: mathgroup at smc.vnet.net
- Subject: [mg115316] Re: Mathematica daily WTF
- From: DrMajorBob <btreat1 at austin.rr.com>
- Date: Fri, 7 Jan 2011 04:11:01 -0500 (EST)
I'd try something like:
Clear[echo]
Attributes[echo] = {HoldAll};
echo[s_, place_] /; debug :=
Print[ToString[Unevaluated[s]], " = ", s, " at ", place]
With a module like this:
debug = True;
bookSave[num_]:=Module[{book,dir},
(* some code *)
echo[dir, 1];
echo[book, 2];
echo[num, 3];
(* other code *)
]
The printed output was:
dir$3287 = /Users/keleen/TS/Wings/ at 1
book$3287 = Book1 at 2
1 = 1 at 3
It's annoying that "num" prints as its value, rather than its name.
Unevaluated is still a mystery.
Bobby
On Thu, 06 Jan 2011 01:01:37 -0600, Ingolf Dahl <ingolf.dahl at telia.com>
wrote:
> Andrzej,
> Since you ask for "single examples", I would like to hear your opinion
> about
> my "Debugging code snippet"
>
> ((If[debug, Print["Place1 ", #]]; #) &)@
>
> I have started with the functional identity operator # &@, and then added
> the global variable debug, which if set to True prints out the value of
> the
> variable as side effect. The code snippet can be used to monitor the
> values
> of sub expressions during debugging, without disturbing the flow of the
> program, and it does not necessarily need to be removed afterwards.
> Best regards
>
> Ingolf Dahl
> ingolf.dahl at telia.com
>
> This code snippet can be inserted into d
>> -----Original Message-----
>> From: Andrzej Kozlowski [mailto:akoz at mimuw.edu.pl]
>> Sent: den 3 januari 2011 09:58
>> To: mathgroup at smc.vnet.net
>> Subject: [mg115174] Re: Mathematica daily WTF
>>
>> I don't want to get involved in what is likely to turn out a
>> "linguistic"
> dispute, but I think
>> your ideas about what constitutes "functional" and "procedural" are
> misconceived and do
>> not correspond to what other's mean by these terms. While there is some
> difference between
>> the meaning of "function" in mathematics and in programming, both
>> concepts
> originate from
>> the same source. To quote Thompson's "Haskel. The craft of functional
> programming": "A
>> function is something that we can picture as a box with some inputs and
>> an
> output:..."
>> followed by a picture which is exactly the same that I used to draw in
>> my
> lectures on
>> introductory set theory and analysis for many years before I heard of
> functional
>> programming. In this sense functions are ubiquitous in mathematics and
> science. "Procedural
>> programming", on the other hand, is programming by "change of state" or
> "side-effects", and
>> as the latter expression suggests, is less natural for the human mind
>> even
> if it could be
>> claimed to c!
>> orrespond more closely to what goes on at "machine level". In any case,
>> I
> cannot think of
>> any scientific or mathematical problems that can be more naturally
> formulated in terms of
>> "side-effects" than in terms of "functions". Perhaps they exist and I my
> bias is due to several
>> decades of doing mathematics but I seriously can't think of a single
> example. Can you
>> provide one?
>>
>> Andrzej Kozlowski
>>
>>
>> On 2 Jan 2011, at 10:55, AES wrote:
>>
>> > In article <ifmrvv$pim$1 at smc.vnet.net>,
>> > Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote:
>> >
>> >>
>> >> anyway, it does not matter as far as the point I was making is
> concerned,
>> >> which is that the C-like structure of Mathematica procedural programs
> is
>> >> helpful to people (somewhat) familiar with C or Fortran.
>> >>
>> >
>> > I'd argue it is also extremely helpful to people who _think_
>> physically,
>> > or if you like procedurally, and who are primarily focused on solving
>> > problems that have an inherently procedural character.
>> >
>> > The successive steps (lines, cells, expressions) in a procedural
>> program
>> > will very often state or mimic or reproduce what happens as a function
>> > of time in a dynamic system, or as a function of distance as a wave
>> > propagates, or mimic the flow of control in a complex system, or . . .
>> >
>> > As such, they simplify the process of _coding_ these programs; they
>> > _document_ and make readable what the program is doing, step by step;
>> > they make it easy to _insert later refinements_ inside the procedure
>> > (e.g., tests for current values or for exceptional cases at points
>> > within the procedure).
>> >
>> > All of these things are much more valuable to some of us in our use of
>> > Mathematica than the speed at which the code executes, or the brevity
>> > with which it can be typed. And none of this is to argue that many
>> > basic functions within the language (things like Fourier transforms,
>> > finding matrix eigensolutions, many others) should not be provided and
>> > used as pre-coded non-procedural routines within larger programs.
>> >
>> > I make a lot of use of self-programmed Modules[] in my own
>> programming.
>> > The active or working part of the completed program, where numerical
>> > results get asked fror and results displayed, can be quite briefly
>> > written, mostly just setting input variables, then calling these
>> > modules. But these modules themselves are heavily procedurally coded
>> > internally, and I think that makes a lot of sense.
>> >
>
>
--
DrMajorBob at yahoo.com
- Follow-Ups:
- Re: Mathematica daily WTF
- From: DrMajorBob <btreat1@austin.rr.com>
- Re: Mathematica daily WTF