Perl: the Markov chain saw PerlMonks

### Comment on

 Need Help??
Good topic, lots of interesting responses...here are mine :)

1) Yes, geometry should teach you how to reason logically from assumptions to conclusions. This could be achieved other ways, but geometry has the advantage of direct presentation via visuals and kinesthetics, as well as the traditional verbal means. Algebra "puzzles" and Murder Mysteries are not as directly accessible by everyone (especially by the teachers, who, it can be argued, need the most help).

2) Learning to program, and practicing programming, can both help and hinder this goal. It can help by forcing you to focus on the critical details of a problem. It can hinder because there are myriad details to handle that are related to programming and implementation, not to the problem. [An interesting topic to explore would be a measure of the level (high or low) of a language, insomuch as its statements relate to the problem, and not to programming or computers or even people.] It can also hinder because it is possible to write programs that are nearly correct, that either give an answer close enough, or for the inputs tried, or most of the time, but fail for some inputs, or have other subtle errors -- the programmer may think s/he understands the problem, but has failed on some fundamental point (or just tripped over the syntax).

3) The more I learn, across disciplines seemingly unrelated and irreconcilable, the more I realize that everything connects to everything else. The obvious links, like between math and physics, are expected. But who expected fractals to predict tree branching and mountain formation? The less obvious links bring a smile with them -- such as Fibonacci patterns in sunflowers, or chaotic neuron firings indicating a healthy brain.

4) Until you understand the fundamentals (such as the rules of proof in geometry), you will have a hard time making real progress in a subject area. As an example, I liked the way Feynman explained light reflection from a glass window.

The traditional argument was that light was reflected from both the front surface and the back, because of the abrupt transitions between the indices of refraction (air to glass, then glass to air), as if the light were reflected by the boundary itself, and not the material.

Feynman (in the Red Books) starts from a fundamental principle of light: it has a frequency. Since light is a wave (in this context, anyway), it is not a localized phenomenon, and cannot be reflected by a highly localized (and somewhat imaginary) boundary. Instead, suppose it is reflected from each "layer" within the glass, and also transmitted by each layer, and is more accurately described as a superposition of these two states. The resulting reflection and transmission ratios are determined by the number of wavelengths that "fit" in glass at the angle of propagation. The reflections that do not "fit" cancel out, and in the ideal case the result is the same as if assuming light is reflected off the air-glass boundaries. But in less ordinary situations, such as variations in the index of refraction through the material, this new approach makes predictions that match experiments, and is less cumbersome to manipulate than the old way. [I don't think Feynman came up with this - but his was the first and best explanation I've seen to date.]

5) I wish someone had taught me the fundamentals of problem solving directly, instead of having to discover them gradually on my own, with fits and starts and backtracking. There is merit in rediscovery, but I always feel like I've missed something...;)

-QM
--
Quantum Mechanics: The dreams stuff is made of

In reply to Re: Programming & real life by QM
in thread Programming & real life by nothingmuch

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

• Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
• Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
• Read Where should I post X? if you're not absolutely sure you're posting in the right place.
• Posts may use any of the Perl Monks Approved HTML tags:
a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
• You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
 For: Use: & & < < > > [ [ ] ]
• Link using PerlMonks shortcuts! What shortcuts can I use for linking?

Create A New User
Chatterbox?
 [tobyink]: *in your grep block [tobyink]: You can use grep { \$_ =~ /.*\$in.*/; } @my_modules but why not stick to grep(/.*\$in.*/, @my_modules)? (The latter is faster.) [shmem]: Lady_Aleena, in the first example grep evaluates the result from grep and if true, returns \$_. In the second, it always returns \$_ [shmem]: ..the result from the pattern match [Lady_Aleena]: tobyink, I did after I failed to get the BLOCK to work. I can't seem to get my brain around grep BLOCK, though I'm okay with grep EXPR. [shmem]: so in the second example grep returns all true elements of the list passed [Lady_Aleena]: Okay, so grep BLOCK is not like map BLOCK where something might need to be returned at the end. [tobyink]: grep { \$_ =~ /.*\$in.*/; } @my_modules should work just fine. The problem is that you were adding on ;\$_ at the end of the block. Why were you doing that? [Lady_Aleena]: tobyink, I was thinking map. [tobyink]: Something does need to be returned at the end… not \$_ though. You need to return (something that will be evaluated as) a boolean.

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (7)
As of 2017-05-27 07:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
Voting Booth?
My favorite model of computation is ...

Results (192 votes). Check out past polls.