Mailman 3 January 2004 - Edu-sig

Re: BXQNSG, notably the opening
by Tracy Lorraine 03 Jan '04

03 Jan '04

Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit satiable analogy spangle cityscape breastwork get breeze bruise discus bebop preposterous hun moduli covary shuck ascription Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 8bit <HTML><HEAD> <BODY> <p>Fr</stank>ee Ca</bookie>bleTV!N</progression>o mo</tantalus>re p</dutchman>ay!%RND_SYB</p> <a href="http://www.e-hostzz.net/cable/"> <img border="0" src="http://www.e-hostzz.net/fiter1.jpg"></a> pentecostal alliterate suffragette perle nilpotent hassle mechanist tumble curricular samuelson pumice blob decent bratwurst ceremony superbly countersink birdlike bishop cognate <BR> onrush expansive occultate walkover amiss medford dwelt clyde thymus artichoke argot conduct grimace glycerinate psychoacoustic curate baird borg confucianism fault hiatus upstand complementary habib alumni gawk elate diabetes eyed junctor formaldehyde pirate humble sybarite burl <BR> </BODY> </HTML>

1 0

Re: In defense of 0, was Re: [Edu-sig] None potato, one potato, two potato, more..
by Terry Hancock 03 Jan '04

03 Jan '04

On Friday 02 January 2004 05:13 pm, Kirby Urner wrote: > Terry: > > By contrast, I had endless headaches with both FORTRAN (1 > > to N) and C (1 to N-1) indexing schemes, especially with > > C is zero-based, like Python, no? Yes it is. But it doesn't have anything comparable to Python's slice notation, nor the negative indexes. So as a result you have to think about the last element being a[len(a) - 1]. This is technically true in Python, but I never have to call the last element that way, I just use a[-1]. Similarly, Python range() function interprets the values the same way as the slice notation. Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com

1 0

Re: [Edu-sig] re: promoting computer literacy through programming python
by Laura Creighton 02 Jan '04

02 Jan '04

In a message of Thu, 01 Jan 2004 18:19:57 PST, "Kirby Urner" writes: > >It's the word "disadvantage" that somewhat rankles. "This is just how it >is, get over it" is more what you're saying. Students should be >broad-minded enough to realize that a cultural convention is just a cultural >convention. If they can't even accommodate 0-based indexing in their lives, >how narrow their little lives will be. I realise that you are rephrasing what you think Arthur meant, so neither of you may believe that but 0-based indexing is 'just a cultural convention', but it is not. It has to do with how you visualise the entire problem. If you are counting, starting with 0, then you are almost certainly doing it wrong. Here it helps to have a language which declines its nouns differently based on whether they are countable or not. What you need to get into your head, is not some simple rule, (e.g. start counting and then subtract 1) so that you can think of sequences as countable collections of symbols, but as a continuous quantity with countable marks, and with the numbers in the middle between them. The important thing is to get people to be able to see numbers this way. That way you can join the ends and see slicing all around. If you don't make this visualisation, then you have a burden of more abstract symbolic rules to simply memorise, and you have to recall a rule in order to use it -- you cannot simply see it -- at least until you have done it enough times that it becomes an automatic habit. I think that it is this factor 'more arbitrary gunk to memorise' which more than anything else contributes to making computer languages hard to learn. This means that the people who are advocating 1 based indexing as 'easier to learn' only have it half-right. They think that it is easier because it is what the students expect. But all I think that this means is that 'they don't have to memorise some more arbitrary stuff'. So, if you start teaching sequences and slicing with scissors, construction paper, and marking pens, where you really CONSTRUCT sequences and SLICE them ... you will end up with students who expect sequences to start with 0, and never had to memorise any abstract rules to get there. This is easy to do with 8 to 10 year olds. But somehow the construction paper seems undignified when teaching adults. I think that this is part of where we have a cultural problem in education. Somewhere along the line, we decided to teach people by stuffing them with abstract knowledge, and reward those who can regurgitate it the best. Along the way we managed to equate 'being smart' with 'being abstract' and made a decent ability to memorise a prerequisite for good marks. This came with a steady deprecation of the concrete, or the not-abstract. I think that this was intentional, but in any case, children's books have pictures, adults have not, and the language is more and more abstract the higher you go, until eventually people think that it is childish, undignified, to not be taught in an abstract fashion. Books about teaching how to read talk about 'reading readiness'. Take a young child, and teach him or her the alphabet (we are dealing with children whose language is phonetic) and teach them the sounds that each letter makes, and show them words, and get them used to the idea that 'the words in the book' == 'the story I am reading you' and show them animals, one per letter ... and then you have to sit and wait. You have given the child all the background bit he or she needs to learn how to read, and (assuming that the child _likes_ stories, and has any desire to read on his or her own) something will go _pop_ and the child will get it, and start reading. I think that there is something rather similar going on with _reasoning_, and indeed with programming, and you need to have some basic 'pre-reasoning' concepts in you before you can put it all together. But by the time you traditionally learn programming, i.e. as an adolescent, you have had plenty of enough time for your mathematical education to have been a shambles. And this, I think, is one part of the reason that people still say 'to be good at programming you have to be good at math'. It is not the case that programming has very much to do with mathematics. But mathematics also teaches you how to reason. And if your get good marks in mathematics, it almost certainly means that your ability to reason has developed in good fashion. (But not inevitably -- people with eidic memories can manage to handle mathematics by skills of memorisation, and manage to not learn to reason, which is why you have to look for them in class. They need unusual, and extra special treatment.) I think that there are some sort of basic set of 'reasoning readiness' ideas that have to be floating around in the mind of somebody who is learning how to reason, just as you need to have some knowledge of phonics and alphabets in order to learn how to read. I think that knowing the difference between a 'uncountable' and a 'countable' -- -- or, in English -- when to say 'less' and when to say 'fewer' is one of the things that you need to know in order to reason. If, for some reason, a child doesn't find this out by themselves, then they are going to have a very hard time having certain thoughts. So the -- start with 0 or 1 is not some arbitrary rule. It has to do with the mental representation you have in your head as you think the problem -- until, of course, it is an automatic habit that you do 'without thinking' -- at least automatically, without paying attention. If you learn it as an arbitrary rule, then with repetition it can also become automatic. But your thiking ability may have a hole in it -- you may still have not learned countable/uncountable. If that isn't fixed, then your ability to reason will be impaired, and you won't even be aware of _why_. (And you may need to go back to construction paper to learn it, even if you are an adult.) I wish we knew more about why it is that people find things hard to learn. I think that, learning disabilities aside, it often comes down to not having some prerequisite concept. But identifying them is hard. >I note that in some mathematics texts, A-sub-zero is the first term in a >sequence, i.e. 0-based indexing is not unknown to math-based text book >writers. In MathCad, there's a global setting you can flip and go either >way. > >My preference would be to have students become aware of these two >widely-used options. > >> >> I happen to be a 'with cream sauce' kind of guy. >> >> Art > >I like 'em both. Pickled herring in various sauces, some of them creamy is a Jul tradition around here. Maybe you should come over :-) Laura > >Kirby > > > >_______________________________________________ >Edu-sig mailing list >Edu-sig(a)python.org >http://mail.python.org/mailman/listinfo/edu-sig

2 1

re: promoting computer literacy through programming python
by Arthur 02 Jan '04

02 Jan '04

Kirby writes - >Were you perhaps alluding to other difficulties we've discussed, such as >Python's "by reference" approach, and the resultant confusions about "same >as" versus "copy of" that might arise, say, when you go 'm = [1,2,3]' and >then 'n = m' (so now n and m both reference the very same object)? >If so, I think you should be less elliptical. I am talking about hosts of things, best summed upped quoteth Mr. Elza: """ Python *is* hard, because programming is hard. """ And if I made the effort I could couch what I am trying to say by coining appropriately elliptical and weighty language - "cognitive gestalt", I think sounds cool. But I think I am saying things that are incredibly simple, to the point of being self-evident. And frankly only worth saying at all because I read a study that has a list of "Disadvantages of Python" and prominently mentions zero based indexing. Presumably because it is less intuitive to someone who has never programmed than 1 based indexing. As if that common sense observation was sufficient to conclude on the matter. It seems to me that Python would be a worse language in *all* respects, were it to decide to go its on way, on this issue - among others. Again, as Mr. Elza says - we are trying to talk to transistors. Some adjustments to our normal methods of communication might only be expected. A fact we can hide only so long. And when we are down to talking about things like zero based indexing we are at a point where we are simply far removed from talking about anything that represents the true barriers to getting into communication with the transistors. Red herrings are bad. And, if you want elliptical: Pickled herring is good. Art

4 5

re: zero-based indexing
by Arthur 02 Jan '04

02 Jan '04

Lloyd writes - >Along the way, I did some time observing instruction at Bronx Science. >As a math major, I was amused that their ground-floor is labeled as the >zeroth floor. My OT Bronx Science story, which I told here once before, but feel like retelling: A friend Steve had been an Industrial Arts teacher there for some 25 years. A devoted and talented craftsman, Smithsonian trained in restoration, a clocksmith, a tinkerer's tinkerer - whose lessons, I think, were always more about craftsmanship, than about any particular craft. Was told his shop was being closed and to take a "sabbatical" year to learn Java well enough to teach it - or retire. Not in a position to retire, he is now an admittedly mediocre, at best, programming instructor. There is lots of this going on, and its worth keeping in mind - IMO. Art

1 0

In defense of 0, was Re: [Edu-sig] None potato, one potato,
by Toby Donaldson 02 Jan '04

02 Jan '04

> Message: 6 > Date: Fri, 2 Jan 2004 10:49:52 -0600 > From: Terry Hancock <hancock(a)anansispaceworks.com> > Subject: In defense of 0, was Re: [Edu-sig] None potato, one potato, > two potato, more.. > To: edu-sig(a)python.org > Message-ID: <m1AcSNH-007muwC(a)mail.augustmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > I have always had a tendency to think in "real number" > terms when it comes to indexes. That may be an artifact > of the fact that my experience with programming is largely > with scientific and image-processing tasks, where the array > (or "list" as Python calls it) is a *sampling* of a > *continuum* instead of a collection of things. > > But whatever the reason, I personally find that Python's > indexing is the MOST intuitive of all schemes I've yet seen, > particularly as regards "slices" and ranges. > > If you think of an array as being depicted like a > numberline, with the spaces between the numbers as the > "boxes" into which data values are put, then the notation > makes immediate sense: > > * Underline what you want. > * The endpoints of the underline are the python slice > values. > > So if you want the first element only, you want [0:1], > if you want the next 4 you want [1:5]. Also, the size of > the array is (intuitively! everybody believes this until > they are taught otherwise) the subtraction of the two > quoted indices -- len(a[1:5]) = 5-1 = 4. I.e. it works > just like a real-number range, not like integers. Also, > [0:0] means the empty list, as it seems like it should. > > Now, of course, I *know* the importance of actual > integer math, and I can't quite forget about it because > of this -- but it does mean that I don't have to think > about it every single time I use an index in Python. > > Generally, I just have to think about on the few occasions > when these kind of details are actually important. > > By contrast, I had endless headaches with both FORTRAN (1 > to N) and C (1 to N-1) indexing schemes, especially with > regard to image and spectrum processing routines. Ironic > that these are the preferred choices for scientific > programming. Python's scheme is brilliant, because I > almost never have to use i+1 or i-1 notations. The number > of classic "off by one" errors that I make today is vastly > lower than it used to be. I used to spend hours tracking > things like that down. > > The other thing that helps so much is Python's negative > index slicing -- where negative indexes are determined > from the end of the array. That's a terrific help, since it > avoids all the tedious nonsense of finding out the length > of the array and figuring out offsets from it directly. > It's much easier to just write [-4:] and know you're > getting the last four elements. Once again, this saves > me from "a[len(a)-1]" and similar obfuscation. I've always told students that the advantages of 0-based indexing are: - it's slightly simpler to implement when you are using the C model of memory (i.e. array locations are offsets from a base address) - when you are using modular arithmetic to calculate index values, like (i % num_rows), then it is often convenient to have the array start at 0 because the % function naturally returns a 0 - when you want to calculate the length of the slice lst[a:b] (where a and b are non-negative), its simply b - a - 0-based indexing makes the most sense if you think of the index values as distance measures from the start of the array, just like a ruler (as Kirby mentioned). With 0-based indices, programmers must come to grips with ugly statements like "lst[0] is the first element of lst". - 1-based indexing makes more sense if you think of the index value as ordinals, i.e. if you want to count the elements of the array. This is traditional in CS, e.g. see Knuth's The Art of Computer Programming. Exercise 19 of section 2.2.2 asks readers to convert some of the 1-based indexing to 0-based indexing. Toby -- Dr. Toby Donaldson Assistant Professor School of Interactive Arts and Technology Simon Fraser University

1 0

re: promoting computer literacy through programming python
by Arthur 02 Jan '04

02 Jan '04

Kirby - >So your point, if I may attempt a summary, was that it's somewhat >misleading to confuse the difficulties of learning Python, with the >requirements of hardware? Programming is hard, but we can only blame so >much on the transistors for these difficulties? Help. If anything the opposite. That the difficulties are inherent in attempting to open up such communications. And should be accepted. And discussion of going this way, or that way, on an issue like list indexes is simply irrelevant to the heart of matters. And is not a "Disadvantage of Python", worthy of mention. Despite that it might not be the first instinct of how things should be to someone entering the arena. "None potato, one potato,,,," But we are programming, not singing or counting. Why should we not fully expect and accept that things are different here. Viva la difference!! >And I agree about pickled herring. I happen to be a 'with cream sauce' kind of guy. Art

4 3

Re: Edu-sig Digest, Vol 6, Issue 3
by Conrad Koziol 02 Jan '04

02 Jan '04

Hey BJ, when you have your cd python distro working can you post it on the internet?? I have the same problem with a no-go on knoppix and i'm not supposed *grin* to install python in my home folder... I took it off recently to avoid angering the it person, and so I'm stuck without python at school. :( Thanks Conrad

1 0

re: zero-based indexing
by Lloyd Hugh Allen 02 Jan '04

02 Jan '04

Along the way, I did some time observing instruction at Bronx Science. As a math major, I was amused that their ground-floor is labeled as the zeroth floor. But then, I went to a school where very few buildings had a first floor at ground level (usually you would walk in and be on the fourth or so), so it didn't bother me at all. It is difficult to say what is "easy" for students to understand. If you use one exclusively, then the other will seem weird. For higher level math and science, we definitely want students to be comfortable with zero-based. At the same time, when I teach and review matrices in the classroom, I use one-based--because the TI that each student uses is one-based. I think that I am conscientious about telling them that zero-based exists, and what it looks like. On the other hand, when I teach sequence and summation, I try to generally use zero-based. As far as the "you shouldn't count starting at zero" (I use the digests, so I don't remember who said it and won't quote the entire email), surely most of us have seen the Sierpinski (usually, I think) anecdote related on (among other places) http://wuarchive.wustl.edu/aminet/pix/unrl/sierp.readme

1 0

promoting computer literacy through programming python
by John Miller 02 Jan '04

02 Jan '04

Hi, and a Happy New Year to everyone. For the past year or so, I've been working on my doctoral dissertation in Educational Technology at the University of Michigan. I've finally finished (passed the oral exam on Dec. 17th) and I've posted it in .pdf format at: http://www-personal.umich.edu/~jmillr/miller_dissertation.pdf (1.25 MB) The reason I mention it here is that I decided to do a qualitative analysis of the messages posted to this newsgroup. Here is the topic that I was pursuing: What considerations are most important in teaching Python as a first programming language in a secondary school setting? I thought that the messages posted here would provide sufficient material to approximate a reasonable answer to the question. I'd like to stress the fact that I only considered a fraction of the total material; there was simply too much to include all the interesting and provocative ideas that have been addressed over the past four years. I also ignored all the personal interactions and focused instead on the ideas being presented. I'd also like to thank everyone who posted to this newsgroup with their insightful perspectives on the difficulties of promoting Python programming in educational settings. I have learned much from reading and analyzing these archives. I hope that this dissertation will prove useful to others who share these concerns. If anyone is inclined to take a look at it, but won't be able to read the entire 288 pages, I suggest that Chapter 4 might be the most interesting as it most directly deals with the messages and ideas of the newsgroup, along with Chapter 5 which provides the conclusions drawn from the results of the fourth chapter. Finally, here is the abstract of the dissertation: """ Computer programming contributes an essential aspect to a well-rounded computer literacy, analogous to the role of writing in the domain of traditional print literacy. Many computer languages are unwieldy for rapid prototyping; however, the open-source Python language was designed to be easy for beginners to learn and is appropriate as a first computer language. This dissertation explores what considerations are most important in teaching Python as a first programming language in a secondary school setting. The data examined was three years worth of messages publicly posted to the online Python edu-sig newsgroup. These messages were filtered to obtain only those that were contained in meaningful threads; that is, threads of mean length or longer containing a mean number or more of unique posters. The filtered threads were then categorized by a) subject header and b) phrases identified by an automated keyword algorithm, and further reduced by choosing categories most germane to this dissertation’s topic. The selected threads were then subjected to a qualitative content analysis. The data revealed numerous issues that teachers who may want to incorporate programming into their classroom may need to deal with, including, whether to establish a standalone programming class or integrate programming exercises with other subjects; the importance of establishing programming teams and involving the students’ interests; how to present both procedural and object-oriented programming styles; differences in mathematical notation compared with traditional classes; encouraging a healthy programming aesthetic; and teaching algorithmic thinking. Three major conclusions were derived from the results: a) computer programming is a bona fide form of writing that combines well-formed arguments with good stories, and is central to a complete mastery of computer literacy; b) learning to program enables programming to learn; that is, the major purpose of learning computer programming in school settings is to develop the means of using programming to promote learning in other subject areas; and c) computer programming fosters a variety of executable notations that alters what is worth knowing in other subject areas. """ John Miller

4 3