From Jason Cunliffe" <jasonic@nomadics.org  Wed Oct  2 04:28:12 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Tue, 1 Oct 2002 23:28:12 -0400
Subject: [Edu-sig] Flightdeck
Message-ID: <000501c269c3$bd5e2c80$6501a8c0@vaio>

http://openlight.com/fdui/

<quote>
Flightdeck-UI is a project that seeks to utilize the ideas in aircraft controls
and instruments design for creating general purpose user interfaces. The project
has been initiated by Open Light Software Inc. It uses the Python programming
language, and also requires Tkinter (see Downloads below for details). The
current release provides a set of modules for creating flightdeck-style user
interface elements, along with a demonstration program.

The demonstration program allows you to monitor a variety of parameters on your
system. By default, it is configured to sample the output of the free command,
and display the percentage of used memory. The program uses the Python commands
module, and thus follows that module's platform limitations (i.e. Unix only).
The library modules, however, should work on any platform that supports Python
and Tkinter.
</quote>

Flightdeck-UI - a Cockpit on your Desktop
George Belotsky
http://openlight.com/fdui/fdui-whitepaper-html/book1.html

./Jason



From ajs@ix.netcom.com  Wed Oct  2 13:43:51 2002
From: ajs@ix.netcom.com (Arthur)
Date: Wed, 2 Oct 2002 08:43:51 -0400
Subject: [Edu-sig] Re: Still working on rational numbers PEP?
Message-ID: <000701c26a11$622bc860$9865fea9@arthur>

Kirby wrties :

>In Python, we might go:

>   >>> rat(0.5555)
>1111r2000
>   >>> rat(0.5555)/1r2
>1111r1000

>The main objection to my proposal, I think, is that it seems
>to return us to the bad old days (like now), when / can do
>different things depending on the types of the operands.

To me, in a limited sense only,  the good old days.  I think there is some
consistency, at least, in my view of things.  As with my thinking on copy()
as a built_in, I like to see important conceptual ideas laid as clearly on
the table as possible.  I can only talk from my own experience.  1/2 = 0 is
how I learned that numerical typing not only exists but acutally *matters*.
Surely 1/2 = .500 is *easier*. Its simply less educational.  And if Python
was somehow unique in the fact that numerical typing mattered, I guess one
could argue about the importance of the lesson.

Truly not looking to open old wounds.  But I do think my position is not
totally off the wall.

Again I do understand that Guido is in the trade-off game, and it is silly
for me to question his decisions on some of these things when I admit to not
understanding all the trade-offs involved in a decision.  Even if I
understand 80%, the 20% I don't might be the ones that put a close decision
over some top.

That being said, the fact that Python's bad old days behavior in respect to
"/" did not meet the expectations of a  novice that Python should behave
like a calculator, I felt strongly and feel strongly, should not be a
concern. Destroying some expectations, clearly and cleanly and early on, is
a good thing, IMO.

And with that said, my real feelings are that *now* is the best old days.
The *option* to change the default "/" behavior is beautiful.  For PyGeo,
for example, I will probably avail myself of it. But because programming
education is *not* my prime focus.  Wonder why these kinds of toggles aren't
a longer term alternative to these kinds of issues?

Art




From wilson@visi.com  Wed Oct  2 19:03:36 2002
From: wilson@visi.com (Tim Wilson)
Date: Wed, 2 Oct 2002 13:03:36 -0500
Subject: [Edu-sig] handling money and floats with beginners
Message-ID: <20021002180336.GA22232@isis.visi.com>

Hi everyone,

I'm struggling a bit with explaining how important it is to handle
floating point numbers correctly when doing calculations with money. My
latest assignment (http://isd197.org/sibley/cs/icp/loancalc_html)
involves calculating and printing a load payment schedule and I want my
students to do things "the right way."

My assignment instructions include a link to the Floating Point
Arithmetic section of the python tutorial, but it's not quite enough.

Does anyone have any code snippets that illustrate the problem clearly
and are understandable by novices? My instructions say that the simplest
approach is to do money-related calculations in pennies. Is that really
the best approach for beginners? I didn't address this issue very well
last year and I'd like to do a better job this time around.

-Tim

-- 
Tim Wilson      |   Visit Sibley online:   | Check out:
Henry Sibley HS |  http://www.isd197.org   | http://www.zope.com
W. St. Paul, MN |                          | http://slashdot.org
wilson@visi.com |  <dtml-var pithy_quote>  | http://linux.com


From engelbert.gruber@ssg.co.at  Thu Oct  3 09:15:11 2002
From: engelbert.gruber@ssg.co.at (engelbert.gruber@ssg.co.at)
Date: Thu, 3 Oct 2002 10:15:11 +0200 (CEST)
Subject: [Edu-sig] handling money and floats with beginners
In-Reply-To: <20021002180336.GA22232@isis.visi.com>
Message-ID: <Pine.LNX.4.33.0210030958510.6822-100000@b52.b.ssg.co.at>

On Wed, 2 Oct 2002, Tim Wilson wrote:

> Hi everyone,
>
> I'm struggling a bit with explaining how important it is to handle
> floating point numbers correctly when doing calculations with money. My
> latest assignment (http://isd197.org/sibley/cs/icp/loancalc_html)
> involves calculating and printing a load payment schedule and I want my
> students to do things "the right way."
>
> My assignment instructions include a link to the Floating Point
> Arithmetic section of the python tutorial, but it's not quite enough.
>
> Does anyone have any code snippets that illustrate the problem clearly
> and are understandable by novices? My instructions say that the simplest
> approach is to do money-related calculations in pennies. Is that really
> the best approach for beginners? I didn't address this issue very well
> last year and I'd like to do a better job this time around.

1. since switching to euros some software must cope with with 1/100 cent.

2. ::
    >>> r=10e+15
    >>> "%20f" % r
    '10000000000000000.000000'
    >>> r+=1
    >>> "%20f" % r
    '10000000000000000.000000'
    # incrementing by one is not possible
    >>> r+=100
    >>> "%20f" % r
    '10000000000000100.000000'
    >>> r+=1
    >>> "%20f" % r
    '10000000000000100.000000'
    >>> r+=2
    >>> "%20f" % r
    '10000000000000102.000000'
    # by two works

3. use mpz or as in the old days bcd-coding

4. in my school days we had to do calculations on date::
   19871093 * 2 = 39742186
   39742186 * 3 = 119226558
  119226558 * 4 = 476906232
  476906232 / 2 = 238453116
  238453116 / 3 = 79484372
   79484372 / 4 = 19871093

  but going up to 10. now my son had the same kind of calcualtions
  but going up to 13, which exceeded the calcualtors precision.

cheers
-- 
 BINGO: professionally create virtual services
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+



From ajs@ix.netcom.com  Fri Oct  4 14:31:33 2002
From: ajs@ix.netcom.com (Arthur)
Date: Fri, 4 Oct 2002 09:31:33 -0400
Subject: [Edu-sig] Fw: [Visualpython-users] Re: strange output
Message-ID: <001101c26baa$5d8cb4f0$9865fea9@arthur>

Doing my morning rounds of annoying posts.

Thought I'd forward this up to edu-sig.

Bruce Sherwood, FWIW, was an influential advocate of the change in the "/"
operator (in that Guido referred to his position and classroom experience a
number of times in the course of the debate).  Bruce says without ambiguity
that his position is based on the fact that his students where thrown by the
fact that Python did not behave as a calculator.  Of course Bruce is a
physics instructor, with *no* particular interest in conveyuing programming
ideas to his students,  Even basic ones.  Except to the extent it effects
their ability to use one particular library - VPython.  Which by the way he
had very little to do with creating - at least in terms of actually writing
code.

All of which to me speaks to the better use of language in conducting
discussions around these points.  As far as I am aware nobody interested in
Python as an introductory *programming* language ever raised a serious
objection to the "/" operator behavior as it stood.  It concerned me that
the potential for a conflict of interests between different classes of
"novices" was never addressed in the debate.  Novices were newbies, were
non-programmers.  But the distinction of one's with an eye toward truly
learning programming, and ones with no interest in getting below the top
surface of scripting a little ditty or two, were discussed as if they were
somehow one class of folk.


----- Original Message -----
From: "Arthur" <ajs@ix.netcom.com>
To: "Bruce Sherwood" <basherwo@unity.ncsu.edu>; "vpusers"
<visualpython-users@lists.sourceforge.net>
Sent: Friday, October 04, 2002 9:13 AM
Subject: Re: [Visualpython-users] Re: strange output


> I think it worth supplementing Bruce's analysis with the solution to what
> was trying to be accomplished by
>
> rininitial = ball.pos
>
> I believe either:
>
> rinitial = ball.pos[:]
>
> or
>
> rinitial =copy(ball.pos)
>
> would get one to where one is trying to go.
>
> [:] returns a complete "slice" of the list.
> copy, of course, a copy of the list.
>
> In either case rinitial is no longer an additional name for ball.pos, but
an
> object independant of it, which will not be modified upon the modification
> of ball.pos.
>
> I think I have this right.  Corrections welcome.
>
> Art
> ----- Original Message -----
> From: "Bruce Sherwood" <basherwo@unity.ncsu.edu>
> To: "vpusers" <visualpython-users@lists.sourceforge.net>
> Sent: Friday, October 04, 2002 8:16 AM
> Subject: [Visualpython-users] Re: strange output
>
>
> > A VPython user sent me a small program that behaved oddly, and I thought
I
> > should share my analysis, since it involves an aspect of Python that is
> > subtle and may be missed in early study of the language. Fortunately it
> > rarely bites students writing computational physics programs!
> >
> > Early in the program the user said "rinitial = ball.pos" which means
> "assign
> > an additional name to ball.pos, so that in the future one can refer to
the
> > ball's position either by the label (name) ball.pos or the label (name)
> > rinitial". You can have lots of names pasted onto the same thing. The
> puzzle
> > for the user was that later in the program (after moving the ball
around),
> > printing rinitial showed the new value of ball.pos, not the initial
value.
> >
> > This multiple labeling has consequences only with "mutable" objects such
> as
> > lists -- objects whose values can be changed in situ. For example, if
you
> > say "a = 5" and then "b = a", and then say "a = 7", b will still have
the
> > value 5. When you assign 7 to a, you create a new object ("7") and
attach
> > the label "a" to it, so b continues to be a label for the object "5".
> >
> > But with "rinitial = ball.pos", you can actually change ball.pos without
> > creating a new object. For example, you might say "ball.pos.y = 7" in
> which
> > case the 2nd element in the ball.pos list has changed (without affecting
> the
> > other two elements). Since rinitial is a label for ball.pos, printing
> > rinitial shows you the new value of ball.pos.
> >
> > A list such as [1,2,3] is mutable. The Visual vectors are mutable. A
> 'tuple'
> > such as (1,2,3) is not mutable. Constants such as 3 or pi or a string
such
> > as 'cat' are not mutable.
> >
> > Needless to say, it took me a while to pay attention to "mutability" as
an
> > important property of Python objects!
> >
> > Bruce
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Visualpython-users mailing list
> > Visualpython-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
>




From michael.williams@st-annes.oxford.ac.uk  Fri Oct  4 14:45:36 2002
From: michael.williams@st-annes.oxford.ac.uk (Michael Williams)
Date: Fri, 4 Oct 2002 14:45:36 +0100 (BST)
Subject: [Edu-sig] Fw: [Visualpython-users] Re: strange output
Message-ID: <E17xSlt-00088g-00@wing5.herald.ox.ac.uk>

In message <001101c26baa$5d8cb4f0$9865fea9@arthur> "Arthur" <ajs@ix.netcom.com> writes:
> All of which to me speaks to the better use of language in conducting
> discussions around these points.  As far as I am aware nobody interested in
> Python as an introductory *programming* language ever raised a serious
> objection to the "/" operator behavior as it stood.  It concerned me that
> the potential for a conflict of interests between different classes of
> "novices" was never addressed in the debate.  Novices were newbies, were
> non-programmers.  But the distinction of one's with an eye toward truly
> learning programming, and ones with no interest in getting below the top
> surface of scripting a little ditty or two, were discussed as if they were
> somehow one class of folk.

FWIW, here at the University of Oxford we're beginning a teaching course using
Python as the principal language (replacing Pascal). We chose to go to the
trouble of making future/true division the default behaviour for exactly the 
reasons described in the PEP. I didn't raise an objection to the / behaviour
at the time because I wasn't using Python. I'm glad it's changing though.

The course is a *programming* course (not a physics course, although it is for
physics undergrads). You can read the handbook and my dissertaion discussing
Python's relative merits here:

http://users.ox.ac.uk/~sann1276/python/
-- 
Michael


From BestEng@cs.com  Fri Oct  4 16:06:23 2002
From: BestEng@cs.com (Tienzen (Jeh-Tween) Gong)
Date: Fri, 4 Oct 2002 15:06:23
Subject: [Edu-sig] Enter into it, we can
Message-ID: <200210042201.g94M1LD367996@logs-mtc-tg.proxy.aol.com>

If Walt Disney were ignored,
We would have been denied of a wonderful universe, the cartoon world.

If Shakespeare were ignored,
We would have been denied of a towering light tower in our literary universe.

A small, tiny hint is all that scientists need
To come up a wonderful idea,
To theorize a beautiful universe.

The Intelligence Machine is much more than a hint.

Many, many of us would have roamed in a beautiful intelligence universe,

Many, many of us would have ascended to a towering height, ...

Today, no conclave nor any peer Council can block
The flow of ideas anymore.

We ignore it; it will deny us a wonderful universe.
Yet, enter into a new brave world together, we can.
And we will.

For a small hint,
     Visit www.iewu.org/brain.htm
For a new brave universe,
     See www.iewu.org/Thinking.htm

From: Tienzen (Jeh-Tween) Gong
      P.O. Box 4794
      Diamond Bar, CA 91765
      email: jehtween@cs.com

If you   (   edu-sig@python.org    )do not wish to receive any future News Brief, please 
forward this email to:
          RemoveNews@cs.com




From ajs@ix.netcom.com  Fri Oct  4 23:49:16 2002
From: ajs@ix.netcom.com (Arthur)
Date: Fri, 4 Oct 2002 18:49:16 -0400
Subject: [Edu-sig] re: Enter into it, we can
Message-ID: <003c01c26bf8$9734b330$9865fea9@arthur>

Is this perhaps the newest of the new, new paradigms?




From ajs@ix.netcom.com  Sat Oct  5 00:20:37 2002
From: ajs@ix.netcom.com (Arthur)
Date: Fri, 4 Oct 2002 19:20:37 -0400
Subject: [Edu-sig] Fw: [Visualpython-users] Re: strange output
Message-ID: <004601c26bfc$dcf1cd00$9865fea9@arthur>

>The course is a *programming* course (not a physics course, although it is
for
>physics undergrads). You can read the handbook and my dissertaion
discussing
>Python's relative merits here:

I read excerpts of the handbook and dissertation - both of which are
interesting.

But I don't agree with your take on "/".  Or necessarily disagree.  1/2=.5
*is* more intutive to someone who has not programmed before.  Common sense
would allow us to conclude that is true in the absence of any study of the
issue.  Just as I think common sense allows us to conclude that list[1] is
more intutively the first item in the list, rather than the second.

You toss off the issue of numeric typing is a few sentences of the handbook,
and it comes into play in the creation of Numeric arrays.

The problem is that I don't think you will know to what extent your students
actually grasp the significance of the numeric typing issue.  One can get
far enough without understanding it.  It only becomes an issue when it
becomes an issue.
For example perhaps while doing a

a[1] = .5

to an array that was initially as an int array, not so much consciously as
by a=array([1,2,3}).

Not something that one does everyday.

The interesting study might be to see if your students acutally *get* the
significance and pitfalls of the underlying numeric typing system.

Seems to me that for a physics student, it is particularly important that
they do.  For example, to be aware of the pitfalls that can arise in
comparing values for equality.

So I still ask whether it is necessarily true that the more intutive
behavior is the behavior we should prefer in all cases.  It is perhaps
unintuitive to suggest not.  But I am suggesting it.

Art





From michael.williams@st-annes.oxford.ac.uk  Mon Oct  7 11:04:44 2002
From: michael.williams@st-annes.oxford.ac.uk (Michael Williams)
Date: Mon, 7 Oct 2002 11:04:44 +0100 (BST)
Subject: [Edu-sig] Types and true division (was Re: strange output)
Message-ID: <E17yUkm-0002aS-00@wing3.herald.ox.ac.uk>

In message <004601c26bfc$dcf1cd00$9865fea9@arthur> "Arthur" <ajs@ix.netcom.com> writes:
> >The course is a *programming* course (not a physics course, although it is
> for
> >physics undergrads). You can read the handbook and my dissertaion
> discussing
> >Python's relative merits here:
> 
> I read excerpts of the handbook and dissertation - both of which are
> interesting.
> 
> But I don't agree with your take on "/".  Or necessarily disagree.  1/2=.5
> *is* more intutive to someone who has not programmed before.  Common sense
> would allow us to conclude that is true in the absence of any study of the
> issue.  Just as I think common sense allows us to conclude that list[1] is
> more intutively the first item in the list, rather than the second.

Indeed.

> You toss off the issue of numeric typing is a few sentences of the handbook,
> and it comes into play in the creation of Numeric arrays.

Correct.

> The problem is that I don't think you will know to what extent your students
> actually grasp the significance of the numeric typing issue.  One can get
> far enough without understanding it.  It only becomes an issue when it
> becomes an issue.

The whole reason we're using Python is that we can get away without explaining
everything the first time around, and come back to stuff like this in a 
second year course. Numeric typing is important, yes, but when you've got two
days to teach students programming, you've got to be selective.

> For example perhaps while doing a
> 
> a[1] = .5
> 
> to an array that was initially as an int array, not so much consciously as
> by a=array([1,2,3}).
> 
> Not something that one does everyday.

This actually came up in onse student's program -- so you are correct that it
is a real problem.
 
> The interesting study might be to see if your students acutally *get* the
> significance and pitfalls of the underlying numeric typing system.

I would imagine not. ;-)

> Seems to me that for a physics student, it is particularly important that
> they do.  For example, to be aware of the pitfalls that can arise in
> comparing values for equality.

As I say above, unfortunately we have to be *very* selective. It was decided
it was worth spending more time on procedural concepts like control flow, and
some time on graphing, simply because those two very quickly give an immediate
and tangible return on a student's investment of their time.

We have a real problem with student retention; programming becomes an elective
in the second year. I agree with you entirely that typing and the internal
representation system of a computer is *crucial* to a physicist's understanding.
Whether it's the *most crucial* is another matter ;->

> So I still ask whether it is necessarily true that the more intutive
> behavior is the behavior we should prefer in all cases.  It is perhaps
> unintuitive to suggest not.  But I am suggesting it.

This argument was pretty much done to death around the time of the PEP on 
comp.lang.python.

By the way, the versions of both my handbook and dissertation on
<http://users.ox.ac.uk/~sann1276/> are not final versions. In particular, our
first batch of "real" first years (not trial volunteers) arrive next week, and 
we're putting a lot of finishing touches to it.

For example, after you reminded me of the problem with truncation of floats
when stored in arrays of ints I added a little bit on this. Thanks for your
comments. I'll be posting to this list and other relevant ones when there is
something a bit more final to look at (which had better be within the next 
few days, otherwise I'm in trouble!)

Cheers,
-- 
Michael


From ajs@ix.netcom.com  Mon Oct  7 14:35:06 2002
From: ajs@ix.netcom.com (Arthur)
Date: Mon, 7 Oct 2002 09:35:06 -0400
Subject: [Edu-sig] Types and true division (was Re: strange output)
Message-ID: <00f201c26e06$59e4c820$9865fea9@arthur>

Morning rounds.

Michael writes:

>The course is a *programming* course (not a physics course, although it is
for
>physics undergrads).

and Micahel writes:

> Numeric typing is important, yes, but when you've got two
>days to teach students programming, you've got to be selective.

2 days.

Maybe I am irretrievable scarred by the fact that my undergardauate degree
is in English literature.  But I can't help feeling the discussion is in
harm of being misdirected when you emphasize in one post that you are
teaching *programming* and don't mention that whatever it is you are
teaching you are teaching in a 2 day course.

I am of recent vintage allowing myself to call what I am capable of doing:
*programming*.  3 or 4 years of fairly intense effort. With allowances for
native intelligence issues and aptitudes, for the natural decay of brain
cells (I'm not 20), and with an additional fudge factor for the long-term
effects of some of my late 1960's and early 1970's recreational ingestions -
maybe someone else could get there is a 1 1/2 or 2..

The issue then remains at least to some extent one of constituencies.  I am
not sure how much I would like to see Python try to configure itself as the
perfect solution to the 2 day programming course. Because the concept itself
is a little bizarre, IMO.

I came across this quote in the book "The Cognitive Computer", by Roger C.
Schank - an artificial intelligence researher, I believe of some note:

"""
There is one very good reason to learn programming, but it has nothing to do
with preparing for high-tech carerrs or with making sure one is computer
literate in order to avoid being cynically manipulated by the computers of
the future.  The real value of learning to program can only be understood if
we look at learning to program as an exercise of the intellect, as a kind of
moden-day Latin that we learn to sharpen our minds.

"""

I was once asked on a Python list in a course of one these contentious
debates, in a not very friendly tone,  who it was I thought I was
representing with my comments. I guess I would  at least like to *think* I
am representing anyone coming to the study of Pythion with that kind of
attitude and and those kinds of goals.  Might not be *the* constituency, but
certainly *a* constituency.

Art







From urnerk@qwest.net  Thu Oct 10 01:50:42 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Wed, 09 Oct 2002 17:50:42 -0700
Subject: [Edu-sig] Types and true division (was Re: strange output)
In-Reply-To: <00f201c26e06$59e4c820$9865fea9@arthur>
Message-ID: <5.1.1.6.0.20021009174205.03bcc640@pop.ptld.qwest.net>

At 09:35 AM 10/7/2002 -0400, Arthur wrote:
>Morning rounds.
>
>Michael writes:
>
> >The course is a *programming* course (not a physics course, although it is
>for
> >physics undergrads).
>
>and Micahel writes:
>
> > Numeric typing is important, yes, but when you've got two
> >days to teach students programming, you've got to be selective.
>
>2 days.

I noticed that too.  It's a *programming* course -- AND you've got two
days to teach students programming.  Interesting incongruity.

http://www.amk.ca/python/writing/warts.html is a useful document re
beefs of pro programmers re Python, some of which are being addressed.
I personally don't think the primary reason for changing the behavior
of / was that it confused newbies.

Kirby





From guido@python.org  Thu Oct 10 02:23:47 2002
From: guido@python.org (Guido van Rossum)
Date: Wed, 09 Oct 2002 21:23:47 -0400
Subject: [Edu-sig] Types and true division (was Re: strange output)
In-Reply-To: Your message of "Wed, 09 Oct 2002 17:50:42 PDT."
 <5.1.1.6.0.20021009174205.03bcc640@pop.ptld.qwest.net>
References: <5.1.1.6.0.20021009174205.03bcc640@pop.ptld.qwest.net>
Message-ID: <200210100123.g9A1Nl105139@pcp02138704pcs.reston01.va.comcast.net>

> I personally don't think the primary reason for changing the behavior
> of / was that it confused newbies.

Correct, it has nothing to do with that (even though newbie confusion
led me to first see the problem).  It has to do with substitutability
of equal values with different types.  When a==A and b==B, then a+b
should be == A+B, at least within reasonable precision.  (Floating point
doesn't even guarantee a+(b+c)==(a+b)+c, but it usually gets something
pretty close -- just realize that "pretty close" is not a transitive
property. :-)

Art needn't bother to reply. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)


From ajs@ix.netcom.com  Thu Oct 10 02:47:04 2002
From: ajs@ix.netcom.com (Arthur)
Date: Wed, 9 Oct 2002 21:47:04 -0400
Subject: [Edu-sig] re:  Types and true division (was Re: strange output)
Message-ID: <000801c27000$47476f50$9865fea9@arthur>

Kirby writes -

>I personally don't think the primary reason for changing >the behavior of /
was that it confused newbies.

Maybe you are correct.  And there certainly are good arguments for the
change that are not related to that fact that it was not what folks who
hadn't gotten to chapter 3 of the tutorial were expecting.

But I've gone this far, might as well finish my thought.

The most activist advocates of the change seemed to have been folk like
Bruce Sherwood who was questioning Python's, let's say, saleability for
purposes like his physics class and Randy Pausch, because the behavior did
not play nice with his toy.  I am not making up the fact that Guido
mentioned Sherwood's classroom experience prominently and at key points
during the debate. And it is clear that Pausch saw it as a *big* issue and
that Guido quite well heard his position.

But I was and remain confused.  Confused why Guido needed documentary
evidence that non-programmers would be surprised by 1/2 = 0.  Common sense.
Not sure how much of Sherwood's and Pausch's grant money went done the tubes
making that discovery.

But there is reality reality and there is emotional reality.

So I won't claim to be in touch with reality reality.  My own emotional
reality (now the guy is talking about *emotions*) is that Guido has, when it
comes to issues of Python and education, been more in tune to the needs and
analysis of folks who don't take Python very seriously (like them) rather
than folks who do (like me).

Certainly I had nor have no reason to believe that Guido, in the weighing of
pros and cons,  took at all seriously the possiblity that the div operator
change might be *harmful* to folks looking to Python as an introduction to
programming. Despite the fact that someone who had been through the
experience was trying to say he thought it would - me.  I can tell you that
Bruce Sherwood *still*  understands little about Python.  And Randy Pausch's
true interest in Python and education is well indicated, in my mind, but the
level of his participation on this list.

And with that, hopefully I will find myself able to go silent on the issue
of "/".

Copy of course being a whole other story.

Art






From guido@python.org  Thu Oct 10 12:59:31 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 10 Oct 2002 07:59:31 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
In-Reply-To: Your message of "Wed, 09 Oct 2002 21:47:04 EDT."
 <000801c27000$47476f50$9865fea9@arthur>
References: <000801c27000$47476f50$9865fea9@arthur>
Message-ID: <200210101159.g9ABxV006652@pcp02138704pcs.reston01.va.comcast.net>

> Certainly I had nor have no reason to believe that Guido, in the
> weighing of pros and cons, took at all seriously the possiblity that
> the div operator change might be *harmful* to folks looking to
> Python as an introduction to programming.

If we take this argument seriously, perhaps Python would become a
better language if we crippled it some more.  Let's limit the maximum
size of lists to 32767, and the maximum size of dicts to 32768.  Let's
make multiplication undefined when the result is larger than 2**33.
Let's truncate all identifiers to 6 characters.  Let's make keywords
(but not identifiers) case-insensitive.  Let the program die with a
core dump upon division by zero.

Seriously, Art, it sounds like you struggled with a problem and are
proud that you overcame it, and now you want others to have the same
experience.

I'll tell you what.  The school of hard knocks sucks.  There are
plenty of *interesting* problems in programming to break your head on,
there's no need to surrect artificial barriers.  Save some brain cells
to think about an efficient sorting algorithm or a generational
garbage collector (never mind that Python comes with these built-in as
well).

> Despite the fact that someone who had been through the experience
> was trying to say he thought it would - me.  I can tell you that
> Bruce Sherwood *still* understands little about Python.  And Randy
> Pausch's true interest in Python and education is well indicated, in
> my mind, but the level of his participation on this list.

Bullshit.

> And with that, hopefully I will find myself able to go silent on the
> issue of "/".

I dare you.

> Copy of course being a whole other story.

"I came here for an argument."

"Oh, I'm sorry, this is abuse."

'Nuff said.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From michael.williams@st-annes.oxford.ac.uk  Thu Oct 10 13:13:51 2002
From: michael.williams@st-annes.oxford.ac.uk (Michael Williams)
Date: Thu, 10 Oct 2002 13:13:51 +0100 (BST)
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
Message-ID: <E17zcCN-0007lT-00@wing3.herald.ox.ac.uk>

In message <200210101159.g9ABxV006652@pcp02138704pcs.reston01.va.comcast.net> Guido van Rossum <guido@python.org> writes:
> > Certainly I had nor have no reason to believe that Guido, in the
> > weighing of pros and cons, took at all seriously the possiblity that
> > the div operator change might be *harmful* to folks looking to
> > Python as an introduction to programming.
> 
> If we take this argument seriously, perhaps Python would become a
> better language if we crippled it some more.  Let's limit the maximum
> size of lists to 32767, and the maximum size of dicts to 32768.  Let's
> make multiplication undefined when the result is larger than 2**33.
> Let's truncate all identifiers to 6 characters.  Let's make keywords
> (but not identifiers) case-insensitive.  Let the program die with a
> core dump upon division by zero.
> 
> Seriously, Art, it sounds like you struggled with a problem and are
> proud that you overcame it, and now you want others to have the same
> experience.
> 
> I'll tell you what.  The school of hard knocks sucks.  There are
> plenty of *interesting* problems in programming to break your head on,
> there's no need to surrect artificial barriers.  Save some brain cells
> to think about an efficient sorting algorithm or a generational
> garbage collector (never mind that Python comes with these built-in as
> well).

I couldn't agree more. The removal of barriers that are nothing more than
arbitrary in the modern era of programming languages is a key reason for what
is looking like its successful adoption at one of the most prestigious
educational institutions in the UK. And crucially, in preference to C.

We don't have to waste time teaching specific language/arcitechture features
and can concentrate on the algorithms, which is what people who use programming
as a means rather than an end are interested in.
-- 
Michael


From ajs@ix.netcom.com  Thu Oct 10 14:34:09 2002
From: ajs@ix.netcom.com (Arthur)
Date: Thu, 10 Oct 2002 09:34:09 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
References: <000801c27000$47476f50$9865fea9@arthur>  <200210101159.g9ABxV006652@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <001101c27061$c8dde880$9865fea9@arthur>

>
> Seriously, Art, it sounds like you struggled with a problem and are
> proud that you overcame it, and now you want others to have the same
> experience.

Actually I haven't overcome it.  I understand barely enough about numeric
typing to get by for what I do.  I am still lost in most of the
conversations about the intricacies.
>
> I'll tell you what.  The school of hard knocks sucks.  There are
> plenty of *interesting* problems in programming to break your head on,
> there's no need to surrect artificial barriers.  Save some brain cells
> to think about an efficient sorting algorithm or a generational
> garbage collector (never mind that Python comes with these built-in as
> well).
>
Well we do have a difference of perspective I think.  Seems to me anybody in
the least bit serious about learning to program getting "stuck" on 1/2 = 0
isn't going too far beyond that anyway.

Maybe I am missing your point.  To me this isn't a *problem* of programming,
it is just programming.

> > Despite the fact that someone who had been through the experience
> > was trying to say he thought it would - me.  I can tell you that
> > Bruce Sherwood *still* understands little about Python.  And Randy
> > Pausch's true interest in Python and education is well indicated, in
> > my mind, but the level of his participation on this list.
>
> Bullshit.

Can you say more?  Does Bruce Sherwood know much about Python?  Was he even
a qualified newbie when he look up the mantle of an "expert" on how Python
should be configured  Seems to me that all experiemnts need a control.  Even
if doing an "experiment" in one's head, one needs to understand the
implications of the control group side.

No Sherwood did and does *not* understand Python well enough to be in a
position to open his mouth in an informed way on anything connected to
Python.  Though he does leave the field open for folks like me to get vocal.
I promise you I can Python the guy under the table.

I have said enough of what I think I about Randy Pausch's project.  Probably
that is where our violent disagrement lies.

The fact that I see nothing "technical" in the issues involved in our
different takes, and am willing to contend with you as an equal on the
subject, seems to make you a bit meshuga.

>
> > And with that, hopefully I will find myself able to go silent on the
> > issue of "/".
>
> I dare you.

Got me.

>
> > Copy of course being a whole other story.
>
> "I came here for an argument."
>
> "Oh, I'm sorry, this is abuse."
>
> 'Nuff said.

I think you notoriously do not take disagreement well.  I phrased and have
been trying to phrase things as carefully as I can to try *not* to sound
abusive  - while at the same time allowing myself to express my thoughts
clearly on issues relevant to the subject line of this list  Recently, at
least, I have *absolutely nothing* to apologize for.

Art




From gritsch@iue.tuwien.ac.at  Thu Oct 10 15:06:06 2002
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Thu, 10 Oct 2002 16:06:06 +0200
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
References: <000801c27000$47476f50$9865fea9@arthur>  <200210101159.g9ABxV006652@pcp02138704pcs.reston01.va.comcast.net> <001101c27061$c8dde880$9865fea9@arthur>
Message-ID: <3DA5894E.6080208@iue.tuwien.ac.at>

Arthur wrote:
> 
> No Sherwood did and does *not* understand Python well enough to be in a
> position to open his mouth in an informed way on anything connected to
> Python.  Though he does leave the field open for folks like me to get vocal.
> I promise you I can Python the guy under the table.

Arthur, you are provoking other people with your disgusting statements 
all the time.  In my opinion you are an embarrassment for the otherwise 
in general very friendly and polite Python community.

> I think you notoriously do not take disagreement well.

I think Guido is very open for other opinions.  Write a PEP and make 
your point clear.  Then things can be discussed and enhanced on a common 
ground.  But you always talk importantly about things you don't really 
understand very deeply.  I fact, you can not even write an example of 
your thoughts using Python.

You are just poisoning the whole atmosphere.

> I phrased and have been trying to phrase things as carefully as I can
> to try *not* to sound abusive

bla, bla.  I wonder who agrees with you on that point.

Personally I get too upset reading your postings so I just added a 
filter to my email reader which deletes all emailes stemming from your 
address.

trying-to-stay-out-of-this-conversation-as-long-as-I-could'ly yrs
Markus



From ajs@ix.netcom.com  Thu Oct 10 15:08:51 2002
From: ajs@ix.netcom.com (Arthur)
Date: Thu, 10 Oct 2002 10:08:51 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
Message-ID: <000501c27066$9f8d2e00$9865fea9@arthur>

>I couldn't agree more. The removal of barriers that are nothing more than
>arbitrary in the modern era of programming languages is a key reason for
what
>is looking like its successful adoption at one of the most prestigious
>educational institutions in the UK. And crucially, in preference to C.

In the world.  Don't be modest.

But I will stick to my guns that we have a legimate disagreement.

I wouldn't be here if I didn't think Python does an all in all brilliant job
of addressing these issues.  But like in all things, there comes a point of
dimishing returns, then negative returns.  Where is that point?

If the underlying numeric typing system were in fact to disappear with some
kind of actual unification implementation, obviously there becomes nothing
to discuss.

The phrase "premature optimization" comes to mind again here.

You readily admit that you are not getting across important and fundamental
issues regarding numerics in Python that a physics student *needs* to know.
I contend those issues are getting too deeply submerged, without losing
*any* of their fundamental importance.

Now all I am asking, because alll I am in a position to ask, is that we
acknowledge ourselves to have an honest disagreement.

Art






From guido@python.org  Thu Oct 10 15:36:49 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 10 Oct 2002 10:36:49 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
In-Reply-To: Your message of "Thu, 10 Oct 2002 09:34:09 EDT."
 <001101c27061$c8dde880$9865fea9@arthur>
References: <000801c27000$47476f50$9865fea9@arthur> <200210101159.g9ABxV006652@pcp02138704pcs.reston01.va.comcast.net>
 <001101c27061$c8dde880$9865fea9@arthur>
Message-ID: <200210101436.g9AEan830932@odiug.zope.com>

Indeed, Art, I'm sick and tired of you.

You did not respond to my explanation of the division change using the
substitutibility rule.  It's a technical issue, whether or not you
understand it.

As to whether Sherwood and Pausch understand Python or not, I'm not
particularly interested in a repetition of "is not" / "is too" ad
infinitum.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From ajs@ix.netcom.com  Thu Oct 10 15:39:32 2002
From: ajs@ix.netcom.com (Arthur)
Date: Thu, 10 Oct 2002 10:39:32 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
References: <000801c27000$47476f50$9865fea9@arthur>  <200210101159.g9ABxV006652@pcp02138704pcs.reston01.va.comcast.net> <001101c27061$c8dde880$9865fea9@arthur> <3DA5894E.6080208@iue.tuwien.ac.at>
Message-ID: <000601c2706a$d9efc950$9865fea9@arthur>

Perhaps I do take all this *much* too seriously.

But, I keep thinking that's what we are here for

Bruce Sherwood actually criticized Python's old div operator behavior in the
scant documentation to VPython.  Some editing of that documentation - I am
stating facts as I understand them - was the bulk of his contribution to the
substance of the project.

 Does criticism of the language in which you freely chose to implement
something, rightly belong in the documentation of that something

Incredibly, I perceive myself as being defensive on behalf of Python.  That
probably sounds funny to you.

I am definitely clumsy, though.

No question.

Art

----- Original Message -----
From: "Markus Gritsch" <gritsch@iue.tuwien.ac.at>
To: "Arthur" <ajs@ix.netcom.com>; <edu-sig@python.org>
Sent: Thursday, October 10, 2002 10:06 AM
Subject: Re: [Edu-sig] re: Types and true division (was Re: strange output)


> Arthur wrote:
> >
> > No Sherwood did and does *not* understand Python well enough to be in a
> > position to open his mouth in an informed way on anything connected to
> > Python.  Though he does leave the field open for folks like me to get
vocal.
> > I promise you I can Python the guy under the table.
>
> Arthur, you are provoking other people with your disgusting statements
> all the time.  In my opinion you are an embarrassment for the otherwise
> in general very friendly and polite Python community.
>
> > I think you notoriously do not take disagreement well.
>
> I think Guido is very open for other opinions.  Write a PEP and make
> your point clear.  Then things can be discussed and enhanced on a common
> ground.  But you always talk importantly about things you don't really
> understand very deeply.  I fact, you can not even write an example of
> your thoughts using Python.
>
> You are just poisoning the whole atmosphere.
>
> > I phrased and have been trying to phrase things as carefully as I can
> > to try *not* to sound abusive
>
> bla, bla.  I wonder who agrees with you on that point.
>
> Personally I get too upset reading your postings so I just added a
> filter to my email reader which deletes all emailes stemming from your
> address.
>
> trying-to-stay-out-of-this-conversation-as-long-as-I-could'ly yrs
> Markus
>




From ajs@ix.netcom.com  Thu Oct 10 16:01:27 2002
From: ajs@ix.netcom.com (Arthur)
Date: Thu, 10 Oct 2002 11:01:27 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
Message-ID: <000d01c2706d$fbc568c0$9865fea9@arthur>

>Indeed, Art, I'm sick and tired of you.

And I, believe or not, truly wish that weren't so.

>You did not respond to my explanation of the division change using the
>substitutibility rule.  It's a technical issue, whether or not you
>understand it.

I did, in effect.  By stating on a number of occasions that I understand
that the issue goes beyond the first take of the non-programmer.

Have you responding in any serious way to my point about a potentially
harmeful side effect.  In the year over which this has been discussed.

Is my point that fundamenatlly unworthy of reply?  The form of your replies
and non-replies indicates a position that it is.

I respectfully disagree.

Did *you* learn to program with Python?

Art




From guido@python.org  Thu Oct 10 16:17:48 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 10 Oct 2002 11:17:48 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
In-Reply-To: Your message of "Thu, 10 Oct 2002 11:01:27 EDT."
 <000d01c2706d$fbc568c0$9865fea9@arthur>
References: <000d01c2706d$fbc568c0$9865fea9@arthur>
Message-ID: <200210101517.g9AFHmP07054@odiug.zope.com>

> >Indeed, Art, I'm sick and tired of you.
> 
> And I, believe or not, truly wish that weren't so.

That makes two of us.

> >You did not respond to my explanation of the division change using
> >the substitutibility rule.  It's a technical issue, whether or not
> >you understand it.
> 
> I did, in effect.  By stating on a number of occasions that I
> understand that the issue goes beyond the first take of the
> non-programmer.

But do you understand the issue of substitutability?

> Have you responding in any serious way to my point about a
> potentially harmeful side effect.  In the year over which this has
> been discussed.

And what would that side effect be?  What's the benefit of 1/2==0?

> Is my point that fundamenatlly unworthy of reply?  The form of your
> replies and non-replies indicates a position that it is.

You rarely rise above talking about your emotions on the issue, which
makes it impossible to have a reasonable discussion.

> I respectfully disagree.
> 
> Did *you* learn to program with Python?

Can you rephrase that as a direct question (or comment) instead of
sarcasm?

--Guido van Rossum (home page: http://www.python.org/~guido/)


From ajs@ix.netcom.com  Thu Oct 10 17:14:51 2002
From: ajs@ix.netcom.com (Arthur)
Date: Thu, 10 Oct 2002 12:14:51 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
References: <000d01c2706d$fbc568c0$9865fea9@arthur>  <200210101517.g9AFHmP07054@odiug.zope.com>
Message-ID: <001b01c27078$2fe5c910$9865fea9@arthur>

I appreciate the opportunity to respond further.

But we need to try to understand and find some tolerance for the different
languages with which we speak about these issues.

Understand that I am the first to admit that I have nothing to contribute to
these kinds of conversations from a technical point of view.

But learning to program, and learning to program in particular with Python,
is an experience.

That experience -  and what I've taken (so far) from it -  is one that I am
not only prepared, but it seems, anxious, to talk about.

And like many, I feel that you anticipate that experience amazing well.  The
word "fun" always rightfully crops up in a discussion about the Python
experience.

That I have and have had fun with it is nothing unusual.  But perhaps there
is a little bit unusual with how "ground zero" was my starting point, and
how far I've come.

Only because Python is still young. Others have and I trust and hope many
others will share that experience in the future.

> And what would that side effect be?  What's the benefit >of 1/2==0?

Provides the signal and the reminder of the importance of giving attention
to the underlying numeric typing scheme.  Not a complicated or brilliant
point. But real, experientially, IMO.

Art




From list-python-edu@ccraig.org  Thu Oct 10 18:10:15 2002
From: list-python-edu@ccraig.org (Christopher A. Craig)
Date: 10 Oct 2002 13:10:15 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
In-Reply-To: <001b01c27078$2fe5c910$9865fea9@arthur>
References: <000d01c2706d$fbc568c0$9865fea9@arthur>
 <200210101517.g9AFHmP07054@odiug.zope.com>
 <001b01c27078$2fe5c910$9865fea9@arthur>
Message-ID: <wh65waqky0.fsf@olorin.ts.gatech.edu>

[Arthur] >>> Arthur write:
         >>> Have you responding in any serious way to my point about a
         >>> potentially harmeful side effect.  In the year over which this has
         >>> been discussed.
[Guido]  >> And what would that side effect be?  What's the benefit >of 1/2==0?
[Arthur] > 
         > Provides the signal and the reminder of the importance of giving attention
         > to the underlying numeric typing scheme.  Not a complicated or brilliant
         > point. But real, experientially, IMO.

I can only presume that you also opposed 2**1024 returning a long
rather than raising an error and dictionary iteration for the same
reason.  

With respect to your experience that may be a real point.  With
respect to language design it seems totally inane.  Ceiling tiles
falling on my head might remind me that I need regular building
maintenance and my engine locking up might remind me that I need oil
changes, but that's no reason to design a building so that ceiling
tiles fall more quickly or cars to be less tolerant to operator abuse.

I don't understand how getting what you want instead of an error could
be considered a 'potentially harmful side effect' of a language
change.  It seems like the logical extension of this theory is that we
should make compilers illegal so that people will be spared the agony
of not understanding parallel execution, stack tables, and register
reuse.

-- 
Christopher A. Craig <list-python-edu@ccraig.org>
The memory management on the PowerPC can be used to frighten
small children.  - Linus Torvalds


From urnerk@qwest.net  Thu Oct 10 18:12:50 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Thu, 10 Oct 2002 10:12:50 -0700
Subject: [Edu-sig] re: Types and true division (was Re: strange
 output)
In-Reply-To: <001b01c27078$2fe5c910$9865fea9@arthur>
References: <000d01c2706d$fbc568c0$9865fea9@arthur>
 <200210101517.g9AFHmP07054@odiug.zope.com>
Message-ID: <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>

At 12:14 PM 10/10/2002 -0400, Arthur wrote:

> > And what would that side effect be?  What's the benefit >of 1/2==0?
>
>Provides the signal and the reminder of the importance of giving attention
>to the underlying numeric typing scheme.  Not a complicated or brilliant
>point. But real, experientially, IMO.
>
>Art
>

I don't find this on-the-face-of-it persuasive, as then any
counter-intuitive wrinkle X in any language (any "wart") could
be justified as "reminding the newbie to give attention to X".

Let's just admit that *any* language, out of the box, is going
to contain a number of "gotchas" -- things that regularly confuse
newbies and occasionally even bite a seasoned programmer on the
butt.  Then the question is whether these gotchas are unnecessary
quirks, our essential characteristics that make it *worth a
newbie's while* to bang his or her head against a few times.

In the case of copy(), I'd say we're dealing with an essential
characteristic:  Python uses referents to objects, and to assign
a name is to hand one end of a string to a label (a variable name),
where the other end of the string attaches to a place in memory
which houses the object itself.  When you go x = obj(); y = x,
you're giving another string to y, but both y and x have the
*same* fish on the end of their respective hooks.

Now you're saying:  by including copy() as a built-in, you'd
signify to the newbie that there's something deeply necessary
about having copy() in the picture.  Apparently x = y isn't
going to do the job.  And you're saying, by having 2/3 return
0, you're likewise cluing the newbie to something deep:
number types.

However, it presumes a lot of a newbie that they'd be able to
deduce anything deep from the presence of copy().  Indeed, few
newbies even realize there's a way to dump a list of builtin
functions to the screen, as dir() returns
['__builtins__', '__doc__', '__name__']

You'd have to already know enough to go:
 >>> dir('__builtins__')
which'd then give you a long alphabetized list of 57 functions, many
having to do with strings.  Just seeing copy (and deepcopy?) among
those 57 (now 59) would be unlikely to trigger some involved thought
process about the name/object model in Python.  That's entirely a
retrospective view, i.e. you have to *already know* these basics to
muse to yourself about the importance of copy().

Of course you may be presuming that we're using some tutorial, which
takes us through the built-ins.  But if that's the case, then this
same tutorial could be about drumming home the name/object model,
and the importance of copy() could be leveraged to drum home the
essentiality of *importing* to Python, i.e. "the ability to copy or
clone an object is critical in some situations, yet for generic
objects, this ability must be imported".  In other words, we can
turn your argument around and say *not* including copy() reminds
the newbie that knowing how to import is absolutely critical to
getting full functionality -- the built-in stuff is *not* going to
get you everything you need (no built-in trig either, which all
those physics students will definitely need).

About div, the technical point is that all the operators *except* div,
return very close to equivalent answers, even if the types differ.
In this sense, it matters less for + - and * whether the arguments
are floats, longs or integers.  Since there're no explicit type
declarations in Python (as there are in C, from which the original
div behavior derives), just eyeballing code is *not* necessarily
going to make div's behavior unambiguous, even if you're a pro.
So in this case, I'd say we're dealing with a "gotcha" that it
doesn't pay to beat your head against.  It's still a problem even
after you master it -- when reading others' code (don't always
think about what it's like to read and understand your own).

Going to / and // makes division unambiguous again.  The former
forces a floating point treatment, the latter an integer treatment.

An interesting question, to me, is how a built-in rational number
type might fit into this scheme.  As I understand the current PEP,
we're looking at again altering / such that it returns a rational
type in some circumstances.

My suggestion is that we follow J's example and use lowercase 'r'
(or some other letter) as part of the name of a rational, just as
we use 1e1 to name a float.  Then, have / return a rational if and
only if both arguments are rationals, otherwise stick to the planned
behavior of returning a float.  This would preserve pre-existing code
and make rationals phase in without much disruption.  Plus we're not
going back to "ambiguous results" because the rational result,
though of a different "type", would be essentially equivalent to
the corresponding floating type return value.  In other words 3/2
returns 1.5 or, if a=rat(3) and b=rat(2), then a/b returns 3r2,
and float(3r2) returns 1.5

Kirby





From ajs@ix.netcom.com  Thu Oct 10 18:38:40 2002
From: ajs@ix.netcom.com (Arthur)
Date: Thu, 10 Oct 2002 13:38:40 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
References: <000d01c2706d$fbc568c0$9865fea9@arthur><200210101517.g9AFHmP07054@odiug.zope.com><001b01c27078$2fe5c910$9865fea9@arthur> <wh65waqky0.fsf@olorin.ts.gatech.edu>
Message-ID: <004201c27083$f0b3b110$9865fea9@arthur>

> [Arthur] >>> Arthur write:
>          >>> Have you responding in any serious way to my point about a
>          >>> potentially harmeful side effect.  In the year over which
this has
>          >>> been discussed.
> [Guido]  >> And what would that side effect be?  What's the benefit >of
1/2==0?
> [Arthur] >
>          > Provides the signal and the reminder of the importance of
giving attention
>          > to the underlying numeric typing scheme.  Not a complicated or
brilliant
>          > point. But real, experientially, IMO.
>
> I can only presume that you also opposed 2**1024 returning a long
> rather than raising an error and dictionary iteration for the same
> reason.

No comprenda.  (Isn't it a *little* refreshing to have someone say that so
candidly on these lists?)

But I would say it is a *significant* no comprenda. Apparently I have not
*experienced* the issues you raise as sigifcant - yet.

But I take the point that you disagree with me.

And I believe that Michael Williams is willingly to acknowledge that as much
as he might dislike with my tone of voice, in the end we have little more
than a small disagreement about emphasis.

But if you were prefer to conclude that I am talking total nonsense - your
privilege.

Why do you think Python was let out into the world this fundamentally
broken, if the issue is as obvious as all that?

Art




From Jason Cunliffe" <jasonic@nomadics.org  Thu Oct 10 18:47:02 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Thu, 10 Oct 2002 13:47:02 -0400
Subject: Sensible feedback = was: {Re: [Edu-sig] re: Types and true division (was Re: strange  output)}
References: <000d01c2706d$fbc568c0$9865fea9@arthur> <200210101517.g9AFHmP07054@odiug.zope.com> <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
Message-ID: <005401c27085$0b3cf220$6501a8c0@vaio>

Student Z from from Planet Y has just installed Python over IGSL [Inter Galactic
Subscriber Lines]. They might at first be a little confused...

>>> 1 / 2
0
>>> help(/)
SyntaxError: invalid syntax
>>> help("/")
no Python documentation found for '/'
>>> 1 / 2.0
0.5

Python always has deeply considered, intelligent reasons for doing everything it
does.
So what can we do to make visitors from Planet Y feel more welcome ?

More examples..

>>> /
SyntaxError: invalid syntax
>>> *
SyntaxError: invalid syntax
>>> +
SyntaxError: invalid syntax
>>> -
SyntaxError: invalid syntax

Since typing a command function alone like is obviously not 'pragramming', why
not just return some help about each function? This need not disturb Python's
design philosphy and decisions, but, simply a serious proposal to provide
valuable common sense help at the beginning and when the context is in no doubt.

Are there good Pythonic reasons was this can or should not be done?


./Jason





From ajs@ix.netcom.com  Thu Oct 10 18:54:31 2002
From: ajs@ix.netcom.com (Arthur)
Date: Thu, 10 Oct 2002 13:54:31 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange outp
Message-ID: <005b01c27086$266e3300$9865fea9@arthur>

>But I take the point that you disagree with me.

The more important point actually, is that no where have I argued that my
point is the killer argument that negates the ultimate sensibility of the
change that was decided upon.

I do think it is a point with enough merit to be considered along side the
"it don't work like a calculator" argument - and achieve at least a wash.
And even that is just an opinion.

And the only reason to discuss it, is in the context of diminishing returns
for changes to the language that cater to the out-of-the box expectations of
the non-programmer.  It's simply much more complicated than that -
experientially.

And I am hoping that Guido might include within his purview first hand
reports, rather than second and third  - as these issues arise in the
future.

Where such reports are available.

Art





From dyoo@hkn.eecs.berkeley.edu  Thu Oct 10 19:22:41 2002
From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo)
Date: Thu, 10 Oct 2002 11:22:41 -0700 (PDT)
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
In-Reply-To: <001b01c27078$2fe5c910$9865fea9@arthur>
Message-ID: <Pine.LNX.4.44.0210101051540.25201-100000@hkn.eecs.berkeley.edu>


> Only because Python is still young. Others have and I trust and hope
> many others will share that experience in the future.
>
> > And what would that side effect be?  What's the benefit >of 1/2==0?
>
> Provides the signal and the reminder of the importance of giving
> attention to the underlying numeric typing scheme.

Hello!

This model assumes that the programmer believes that division between
integers is possible.  *grin*


Seriously though, some other languages hold division as a very strict and
dangerous thing.  Standard ML, for example, takes its types darn
seriously: it doesn't even allow division between integers using '/'!

###
- 1.0 / 2.0;
val it = 0.5 : real
- ;
- ;
- 1 / 2;
stdIn:18.3 Error: overloaded variable not defined at type
  symbol: /
  type: int
- ;
- ;
- 1 div 2;
val it = 0 : int
- ;
- ;
- 1.0 div 2.0;
stdIn:23.5-23.8 Error: overloaded variable not defined at type
  symbol: div
  type: real
###

(SML's prompt character is '- ', which is visually confusing...)


ML'ers use a separate DIV operator that explicitely does truncation
between integers.  So that is one potential future that Python could have
turned toward, but all this typing does feel a bit like bondage.  If we
really want to teach typing concepts, I don't think Python's the language
to do this.

Should a programming languages abstract the numeric model of the machine
away from the programmer?  In the case of Python, it looks like the answer
is leaning toward "yes", especially since it already has long integers and
complex numbers (and probably rationals soon!) as basic types that the
programmer can use.


My feeling is that Python division doesn't have to reflect what the
machine is doing underneath.  At long as we explain to folks that Python
is an abstraction on top of the machine, I don't think it will cause
long-term harm.

The big problem is if we just use just Python alone to teach how computers
work: that would be an extraordinarily unbalanced view!  If we want to
show people the real details about computation, then we really should be
doing this in combination with a low-level language like MIPS assembly.
Have you thought about doing something like this?


Best of wishes to you!



From guido@python.org  Thu Oct 10 19:36:03 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 10 Oct 2002 14:36:03 -0400
Subject: [Edu-sig] Re: rationals
In-Reply-To: Your message of "Thu, 10 Oct 2002 10:12:50 PDT."
 <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
References: <000d01c2706d$fbc568c0$9865fea9@arthur> <200210101517.g9AFHmP07054@odiug.zope.com>
 <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
Message-ID: <200210101836.g9AIa3Q14798@odiug.zope.com>

[Kirby]
> Going to / and // makes division unambiguous again.  The former
> forces a floating point treatment, the latter an integer treatment.
> 
> An interesting question, to me, is how a built-in rational number
> type might fit into this scheme.  As I understand the current PEP,
> we're looking at again altering / such that it returns a rational
> type in some circumstances.

That's not my (current) preference.

> My suggestion is that we follow J's example and use lowercase 'r'
> (or some other letter) as part of the name of a rational, just as
> we use 1e1 to name a float.

Right.

> Then, have / return a rational if and
> only if both arguments are rationals, otherwise stick to the planned
> behavior of returning a float.

Exactly.

> This would preserve pre-existing code
> and make rationals phase in without much disruption.  Plus we're not
> going back to "ambiguous results" because the rational result,
> though of a different "type", would be essentially equivalent to
> the corresponding floating type return value.  In other words 3/2
> returns 1.5 or, if a=rat(3) and b=rat(2), then a/b returns 3r2,
> and float(3r2) returns 1.5

Except I don't like the 3r2 notation very much.  In my version it
would become 3/2r, or 3r/2; parsed as 3 / 2r and 3r / 2, respectively.

And I'd also support 1.5r as a way to spell the same value.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@python.org  Thu Oct 10 19:48:14 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 10 Oct 2002 14:48:14 -0400
Subject: Sensible feedback = was: {Re: [Edu-sig] re: Types and true division (was Re: strange output)}
In-Reply-To: Your message of "Thu, 10 Oct 2002 13:47:02 EDT."
 <005401c27085$0b3cf220$6501a8c0@vaio>
References: <000d01c2706d$fbc568c0$9865fea9@arthur> <200210101517.g9AFHmP07054@odiug.zope.com> <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
 <005401c27085$0b3cf220$6501a8c0@vaio>
Message-ID: <200210101848.g9AImE914854@odiug.zope.com>

> Are there good Pythonic reasons was this can or should not be done?

It never occurred to me that you would not have the tutorial handy.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From urnerk@qwest.net  Thu Oct 10 20:41:33 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Thu, 10 Oct 2002 12:41:33 -0700
Subject: [Edu-sig] Re: rationals
In-Reply-To: <200210101836.g9AIa3Q14798@odiug.zope.com>
References: <Your message of "Thu, 10 Oct 2002 10:12:50 PDT." <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
 <000d01c2706d$fbc568c0$9865fea9@arthur>
 <200210101517.g9AFHmP07054@odiug.zope.com>
 <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
Message-ID: <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>

At 02:36 PM 10/10/2002 -0400, Guido van Rossum wrote:

>Except I don't like the 3r2 notation very much.  In my version it
>would become 3/2r, or 3r/2; parsed as 3 / 2r and 3r / 2, respectively.

Not clear if you mean 3r is by itself a rational (=3/1) as in:

   >>> a = 3r
   >>> a/2r
3/2

or would that be 3/2r ?

Entering 3r/2 on a command line looks to me like an invocation
of division between a rational (3r) and an integer (2), and so
would return 1.5 (float), i.e.

   >>> 3r/2
1.5


>And I'd also support 1.5r as a way to spell the same value.

Makes sense.

I get confused when I try to see / used both as an operator, and
as part of the name of a number.  Not sure if that's what you're
doing.

Would you go:

   >>> 1.5 .__rational__()
3/2r
   >>> 3/2r .__float__()
1.5

Perhaps you could do a short dialog in Python along the lines of:

    >>> a = 3r2
    >>> b = 1r2
    >>> a * b
3r4
    >>> float(a*b)
0.75
    >>> a + 2
5r2
    >>> a / 2
3r4

showing how it'd look in your implementation.

Note:  I'm deviating from the policy that rat / int --> float
in the last line.  Not sure if this is a good idea.  Maybe:

    int   / int   --> float     (float//float --> int)
    float / int   --> float     (int//int     --> int)
    rat   / int   --> rat   (?) (rat//rat     --> int)
    rat   / float --> float
    rat   / rat   --> rat

In other words, maybe it makes sense for / to coerce an int or
a long into a rat if the other arg is a rat.  This wouldn't
break code, as rat is a new type that couldn't get created by
old pre-rat code.

Coercion:

rat(3.1)    --> 31/10r   (?)
rat(2)      --> 2r
float(2/3r) --> 0.66666666666666663

rat() or rational()  ?


Kirby





From ajs@ix.netcom.com  Thu Oct 10 20:42:48 2002
From: ajs@ix.netcom.com (Arthur)
Date: Thu, 10 Oct 2002 15:42:48 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
Message-ID: <008101c27095$3746cca0$9865fea9@arthur>

Kirby writes -

>I don't find this on-the-face-of-it persuasive, as then any
>counter-intuitive wrinkle X in any language (any "wart") could
>be justified as "reminding the newbie to give attention to X".

What I am experiencing - that is, from my point of view - I am trying to
talk about something very specific in a very specific way, and mostly,
having my point defeated by talking it to absurdium by resorting to
generalities about mega-design issues.

Perhaps, one of my key points is that nothing can be generalized from this
particular specific, nor do I see myself attempting to advocate any
generalization that can be made.  I honestly don't see one .

The old "/" operator is a gotcha if one choses to see it that way.  I had
told you in a private note some time ago, that I found it a particulary
nasty gotcha when raising to a fractional power. From an experiential point
of view, that tended to be the only time I would *actually* get caught with
my pants down.

But I have the ability to foresee where Bruce's and Michael's students are
most likely to get caught with *their* pants down, under the new operator.
Which are ways even more subtle, IMO, but just as likely to arise as with my
raised to a power issue.  So, on the gotcha score - at best a wash, IMO.

With no generalizations to be made beyond that observation.

Art







From ajs@ix.netcom.com  Thu Oct 10 20:49:45 2002
From: ajs@ix.netcom.com (Arthur)
Date: Thu, 10 Oct 2002 15:49:45 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
References: <Pine.LNX.4.44.0210101051540.25201-100000@hkn.eecs.berkeley.edu>
Message-ID: <008b01c27096$3b221590$9865fea9@arthur>

Danny -

I think your argument holds together perfectly were there in fact an
underlying unification of types in Python.

There is not.

Getting a conscious awareness of the practical issues involved remains a
practical necessity for working in Python - irrespective of the div operator
behavior.

At least if you are doing anything related to numerics.

And thanks for all your help to me and others as we try to contend with
these things.

Art

----- Original Message -----
From: "Danny Yoo" <dyoo@hkn.eecs.berkeley.edu>
To: "Arthur" <ajs@ix.netcom.com>
Cc: <edu-sig@python.org>
Sent: Thursday, October 10, 2002 2:22 PM
Subject: Re: [Edu-sig] re: Types and true division (was Re: strange output)


>
>
> > Only because Python is still young. Others have and I trust and hope
> > many others will share that experience in the future.
> >
> > > And what would that side effect be?  What's the benefit >of 1/2==0?
> >
> > Provides the signal and the reminder of the importance of giving
> > attention to the underlying numeric typing scheme.
>
> Hello!
>
> This model assumes that the programmer believes that division between
> integers is possible.  *grin*
>
>
> Seriously though, some other languages hold division as a very strict and
> dangerous thing.  Standard ML, for example, takes its types darn
> seriously: it doesn't even allow division between integers using '/'!
>
> ###
> - 1.0 / 2.0;
> val it = 0.5 : real
> - ;
> - ;
> - 1 / 2;
> stdIn:18.3 Error: overloaded variable not defined at type
>   symbol: /
>   type: int
> - ;
> - ;
> - 1 div 2;
> val it = 0 : int
> - ;
> - ;
> - 1.0 div 2.0;
> stdIn:23.5-23.8 Error: overloaded variable not defined at type
>   symbol: div
>   type: real
> ###
>
> (SML's prompt character is '- ', which is visually confusing...)
>
>
> ML'ers use a separate DIV operator that explicitely does truncation
> between integers.  So that is one potential future that Python could have
> turned toward, but all this typing does feel a bit like bondage.  If we
> really want to teach typing concepts, I don't think Python's the language
> to do this.
>
> Should a programming languages abstract the numeric model of the machine
> away from the programmer?  In the case of Python, it looks like the answer
> is leaning toward "yes", especially since it already has long integers and
> complex numbers (and probably rationals soon!) as basic types that the
> programmer can use.
>
>
> My feeling is that Python division doesn't have to reflect what the
> machine is doing underneath.  At long as we explain to folks that Python
> is an abstraction on top of the machine, I don't think it will cause
> long-term harm.
>
> The big problem is if we just use just Python alone to teach how computers
> work: that would be an extraordinarily unbalanced view!  If we want to
> show people the real details about computation, then we really should be
> doing this in combination with a low-level language like MIPS assembly.
> Have you thought about doing something like this?
>
>
> Best of wishes to you!
>
>




From guido@python.org  Thu Oct 10 21:24:58 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 10 Oct 2002 16:24:58 -0400
Subject: [Edu-sig] Re: rationals
In-Reply-To: Your message of "Thu, 10 Oct 2002 12:41:33 PDT."
 <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
References: <000d01c2706d$fbc568c0$9865fea9@arthur> <200210101517.g9AFHmP07054@odiug.zope.com> <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
Message-ID: <200210102024.g9AKOwF15892@odiug.zope.com>

> >Except I don't like the 3r2 notation very much.  In my version it
> >would become 3/2r, or 3r/2; parsed as 3 / 2r and 3r / 2, respectively.
> 
> Not clear if you mean 3r is by itself a rational (=3/1)

Yes.

> as in:
> 
>    >>> a = 3r
>    >>> a/2r
> 3/2
> 
> or would that be 3/2r ?

It would probably print that, yes.

> Entering 3r/2 on a command line looks to me like an invocation
> of division between a rational (3r) and an integer (2), and so
> would return 1.5 (float), i.e.
> 
>    >>> 3r/2
> 1.5

Why?  A binary operator involving an int or long and a rational should
return a rational, IMO -- the int or long can always be cast to
rational, and the result is exact.

> >And I'd also support 1.5r as a way to spell the same value.
> 
> Makes sense.
> 
> I get confused when I try to see / used both as an operator, and
> as part of the name of a number.  Not sure if that's what you're
> doing.

You can see it either way and it doesn't make any difference for the
outcome.  Just like we write negative numbers as -3 which is
technically the minus operator applied to the positive constant 3, or
complex constants as 2+1j which is technically a float constant plus
an irrational constant.

> Would you go:
> 
>    >>> 1.5 .__rational__()
> 3/2r

I'm not sure I'd like to add __rational__ to all numeric types to
convert things into rationals.

I'm also not sure that converting arbitrary floats to rationals should
be a standard conversion.

>    >>> 3/2r .__float__()
> 1.5

Definitely, but please write that as float(3/2r).

> Perhaps you could do a short dialog in Python along the lines of:
> 
>     >>> a = 3r2
>     >>> b = 1r2
>     >>> a * b
> 3r4
>     >>> float(a*b)
> 0.75
>     >>> a + 2
> 5r2
>     >>> a / 2
> 3r4
> 
> showing how it'd look in your implementation.

I have no implementation. :-)

But it would look like this:

  >>> a = 3/2r
  >>> b = 1/2r
  >>> a * b
  (3/2r)
  >>> float(a*b)
  0.75
  >>> a + 2
  (5/2r)
  >>> a / 2
  3/4r
  >>> 

(I'm not sure about the parens, but complex uses them in a similar
situation.)

> Note:  I'm deviating from the policy that rat / int --> float
> in the last line.  Not sure if this is a good idea.  Maybe:
> 
>     int   / int   --> float     (float//float --> int)
>     float / int   --> float     (int//int     --> int)
>     rat   / int   --> rat   (?) (rat//rat     --> int)
>     rat   / float --> float
>     rat   / rat   --> rat

Exactly.  int/rat should also be a rat.

> In other words, maybe it makes sense for / to coerce an int or
> a long into a rat if the other arg is a rat.  This wouldn't
> break code, as rat is a new type that couldn't get created by
> old pre-rat code.

Right.

> Coercion:
> 
> rat(3.1)    --> 31/10r   (?)

I don't like this, but maybe it's okay.  It's up to the rat()
constructor though, the float needn't know anything about this.

> rat(2)      --> 2r
> float(2/3r) --> 0.66666666666666663

Right.

> rat() or rational()  ?

I think rat() is good -- after all I shortened 'dictionary' to 'dict'...

--Guido van Rossum (home page: http://www.python.org/~guido/)


From guido@python.org  Thu Oct 10 21:28:56 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 10 Oct 2002 16:28:56 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
In-Reply-To: Your message of "Thu, 10 Oct 2002 15:49:45 EDT."
 <008b01c27096$3b221590$9865fea9@arthur>
References: <Pine.LNX.4.44.0210101051540.25201-100000@hkn.eecs.berkeley.edu>
 <008b01c27096$3b221590$9865fea9@arthur>
Message-ID: <200210102028.g9AKSuO15909@odiug.zope.com>

> I think your argument holds together perfectly were there in fact an
> underlying unification of types in Python.
> 
> There is not.

But there will be in Python 3000.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From DaddyGravity@livingcode.ca  Thu Oct 10 21:43:44 2002
From: DaddyGravity@livingcode.ca (Dethe Elza)
Date: Thu, 10 Oct 2002 13:43:44 -0700
Subject: [Edu-sig] Re: rationals
In-Reply-To: <200210102024.g9AKOwF15892@odiug.zope.com>
Message-ID: <F7C050D0-DC90-11D6-A8C7-0003939B59E8@livingcode.ca>

>> rat() or rational()  ?
>
> I think rat() is good -- after all I shortened 'dictionary' to 
> 'dict'...

I like rat().  I'd like to use a programming language that was infested 
with rat()s.  After all, Pythons eat rat()s, right?

+1

--Dethe



From urnerk@qwest.net  Thu Oct 10 22:26:07 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Thu, 10 Oct 2002 14:26:07 -0700
Subject: [Edu-sig] Re: rationals
In-Reply-To: <F7C050D0-DC90-11D6-A8C7-0003939B59E8@livingcode.ca>
References: <200210102024.g9AKOwF15892@odiug.zope.com>
Message-ID: <5.1.1.6.0.20021010142535.02ce2980@pop.ptld.qwest.net>

At 01:43 PM 10/10/2002 -0700, Dethe Elza wrote:

>I like rat().  I'd like to use a programming language that was infested 
>with rat()s.
>After all, Pythons eat rat()s, right?
>
>+1
>
>--Dethe

Heh.  Yes, rat-infested Python sounds good to me too.

Kirby





From urnerk@qwest.net  Thu Oct 10 22:38:25 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Thu, 10 Oct 2002 14:38:25 -0700
Subject: [Edu-sig] Re: rationals
In-Reply-To: <200210102024.g9AKOwF15892@odiug.zope.com>
References: <Your message of "Thu, 10 Oct 2002 12:41:33 PDT." <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
 <000d01c2706d$fbc568c0$9865fea9@arthur>
 <200210101517.g9AFHmP07054@odiug.zope.com>
 <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
Message-ID: <5.1.1.6.0.20021010142628.02ce16d0@pop.ptld.qwest.net>

>
>I have no implementation. :-)

You mean there's more to it than just imagining what goes
on at the command line?  :-D

>But it would look like this:
>
>   >>> a = 3/2r
>   >>> b = 1/2r
>   >>> a * b
>   (3/2r)
>   >>> float(a*b)
>   0.75
>   >>> a + 2
>   (5/2r)
>   >>> a / 2
>   3/4r
>   >>>

OK, this is clear.  Personally I like 3/2r better than 3r/2.
It's as if the r keeps the / from operating -- as long as we're
in lowest terms, e.g. I assume you'd go:

    >>> 4/8r
(1/2r)

The only thing that nags is using two symbols instead of one to
signify a type.  Complex (1j1) and float (1e1) get away with one
symbol, which is why 3r2 was somewhat appealing (but the r tends
to get lost).

>(I'm not sure about the parens, but complex uses them in a similar
>situation.)
>
> > Note:  I'm deviating from the policy that rat / int --> float
> > in the last line.  Not sure if this is a good idea.  Maybe:
> >
> >     int   / int   --> float     (float//float --> int)
> >     float / int   --> float     (int//int     --> int)
> >     rat   / int   --> rat   (?) (rat//rat     --> int)
> >     rat   / float --> float
> >     rat   / rat   --> rat
>
>Exactly.  int/rat should also be a rat.

Yes, in retrospect this is clear to me.


> > In other words, maybe it makes sense for / to coerce an int or
> > a long into a rat if the other arg is a rat.  This wouldn't
> > break code, as rat is a new type that couldn't get created by
> > old pre-rat code.
>
>Right.
>
> > Coercion:
> >
> > rat(3.1)    --> 31/10r   (?)
>
>I don't like this, but maybe it's okay.  It's up to the rat()
>constructor though, the float needn't know anything about this.

In J, there's number-naming using p and x where 1p2 means
1*math.pi**2 (translating to Python) and 1x3 means 1*math.e**3.
So 1p1 is just math.pi.  x: is the operator for converting to
rational (like rat(n)), and you get the following:

    x: 1p1     NB.  = rat(math.pi)
1285290289249r409120605684

    x: 1x1     NB.  = rat(math.e)
6157974361033r2265392166685

I find that interesting, even if Python chooses not to go there.

> > rat(2)      --> 2r
> > float(2/3r) --> 0.66666666666666663
>
>Right.
>
> > rat() or rational()  ?
>
>I think rat() is good -- after all I shortened 'dictionary' to 'dict'...

rat() sounds good.  I suppose fract() would be another option,
but of course math purists (and I suppose computer scientists)
prefer "rational numbers" to "fractions" as the name of the
number type.

Kirby





From ajs@ix.netcom.com  Fri Oct 11 03:28:16 2002
From: ajs@ix.netcom.com (Arthur)
Date: Thu, 10 Oct 2002 22:28:16 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
References: <NGBBIKAHMDNFPKNEPALEEEIFIOAA.dennis.hamilton@acm.org>
Message-ID: <00a801c270cd$eb0dec40$9865fea9@arthur>

>
> The impugning of the competence or motivation of *anyone* via a list is
> completely non-constructive.  I think Colin Powell's response to Harry
> Belafonte is appropriate in this context (since it is topical at the
> moment).

I agree.  And will forward your comment to Kirby with whom I fight about
politics, as a sideline.

> For those of us on the list, it is a complete distraction.  We are in no
> position to verify or impeach your judgment on the matter.  And it is
> meaningless (though a popular pastime) for us to vote on the subject
and/or
> contribute to perpetuation of the soap opera.

Expressing it and having it heard, when it is felt strongly and securely,
has to be part of what the list is about.

Guido could have ended the conversation with me a year ago by saying
anything that indicated that he actually heard me, and why he thought my
point was either wrong, or overriden by point Y.

He would in fact  preempt my point specifically by saying that Bruce
Sherwood's classroom experience proves otherwise.  I can dig up the exchange
if pressed.  Which only indicates he was not hearing me - at all.  And of
course setting me off further on the Bruce Sherwood issue.


> Furthermore, the elitist stance of requiring some demonstrated level of
> competence before being able to speak is almost completely contrary to the
> focus and theme of this particular list (i.e., CP4E).  Really smart people
> say stupid things.

I made it clear why I think Bruce is fair game.  Putting his criticism of
Python in the documentation of an application he didn't write, then
distributing it.  I personally resent it particularly because I happen to
love the application.  VPython.  Putting the weight of that wonderful code
he didn't write behind his not particularly informed opinion.

You wanna talk bullshit.

I'm sorry - no regrets.

>Someone who has not delved deeply into something can
> have something bright to observe.  No one in this list is clueless and
> everyone deserves credit for being here and willing to participate.  Ad
> hominem observations do *nothing* for honoring the spirit of inquiry or
> creating a welcome environment.  It reduces the conversation to one of
> personalities and argument and nothing concrete.  Think of all the newbies
> who are now concerned that some fellow named Art may have a public
sentiment
> to offer about their qualifications!
>
> I have personal reservations about Python as a language of choice.  I have
> some concern that the compromises that have been made in the general (not
> specifically Pythonese) programming-language appropriation of mathematical
> terminology have been damaging to mathematics and its teaching, so I am
not
> so willing to defend that situation.  (Here, if it is not clear, I am
> disagreeing with you about 1/2=0.)

I happen to be more interested in the teaching of mathematics than I am in
the teaching of programming. And think I have some interesting ideas, that
have been actualized to a decent extent, to help turn the tables and make
programming a good servant to that cause.   Have lectured by invitation to
the math faculties at a few universities on the subject.  To, I think, an
interested response.  Though they don't know what to make of me either.  I
am neither a mathematician nor an educator.  But in the end I am quite sure
nobody felt their time was wasted.

I talk quite specifically about the choice of Python as my implementation
language in those presentations.  The math professor who is sort of
sponsoring me - having found what I had done and appreciating some of what
makes it unique - was a Scheme head.  Though he is  happily exploring Python
as of now.

>
> At the same time I am fascinated by the Edu-sig community and what it is
up
> to.  I have no complaint against Python and I love what people are able to
> accomplish with it.  I am not anti-Python.  I still use it for examples in
> some of my work.  It just doesn't satisfy my requirements for certain
> things, and there are pitfalls that I don't like that may, in the event,
not
> turn out to be very significant.  And my preferences don't tell me
anything
> about Guido at all!  They're my preferences and they are in response to my
> values and my research interests, not someone else's.  Although I tend to
> think of them as the right preferences (it is apparently how we are wired
to
> constantly fall into that), I find it valuable to be reminded that there
is
> no such thing.  There are my preferences, your preferences, and Guido's
> preferences, etc.

> Along those lines, I also have strong preferences about arithmetic and
value
> types and related topics, including copy (e.g., storage models versus
> reference versus value models). I find value in the discussions of actual
> experiences people have had with being stopped, or having difficulty being
> able to comprehend, explain or motivate.  That is very useful.  I collect
> those emails and articles because it is valuable to understand and to be
on
> alert for in things I do.
>
> The bandy-rooster stuff is usually just an invitation for the delete key.
>

Feel free.

You might miss something worth hearing in the morose, though.


> I don't leap from the experiences people have to insisting there is
> something broken that should be fixed or something there that should be
> preserved.  They are separate things.  This list is not a very good place
to
> lobby for either.  I think the PEP mechanism is where that happens, and
then
> there is what the official says.  As the seasoned umpire says of pitched
> strikes and balls, "they aren't anything until I call them."  It is clear
> who the umpire is here.   If you want to play in this game, you get to
play
> by the umpire's rules.  Certain moves get made and the thing to do is play
> it out and see how it works.  Constant revisitation just paralyzes things.
> And mistakes are made, detected and repaired (or not), and then the next
> mistake is made, etc.

> My experience of Guido is that he is extremely gracious and open.

Am I allowed to express that I have had a different expereince, without be
accused of being abusive?

>That is my personal experience.  Whether his last notes are an expression
of
> irritation/impatience with things said on the list, I don't see that as
> evidence of him being particularly thin-skinned.  But I don't think asking
> for evidence concerning the competence of third parties is what it is
about.
> It is about such discussions being bullshit from the get go.  I think
that's
> what there is to take to heart.
>
> And I get that you find Python very valuable and appealing and you want to
> see it widely known and well used.  And sometimes, what there is to do is
> see how it goes and let experience be the teacher.  Reiteration about a
> resolved matter simply doesn't add anything.
>

There is resolved and resolved.

Certainly there is something quite unresolved as between Guido and myself.


> For what it's worth,
>
> -- orcmid
>
> ------------------
> Dennis E. Hamilton
> http://NuovoDoc.com/
> mailto:dennis.hamilton@acm.org
> tel. +1-206-932-6970
> cell +1-206-779-9430
>      The Miser Project: http://miser-theory.info/
>      AIIM DMware: http://DMware.info/
>





From tim.one@comcast.net  Fri Oct 11 05:09:36 2002
From: tim.one@comcast.net (Tim Peters)
Date: Fri, 11 Oct 2002 00:09:36 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
In-Reply-To: <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEMJBKAB.tim.one@comcast.net>

I'm fortunate enough to get to talk with Guido in person several times per
decade <wink>.  We've talked about Python's division many times, and,
indeed, I share the blame for Python's original decision to make 1/2 == 0,
since Guido picked my brain about numerics at the time, and we both thought
"well, it's good enough in C, and rationals didn't work that well in ABC, so
what the heck ...".

In all the conversations I've ever had with him on the topic, neither
Sherwood nor Pausch came up.  Arthur, you've been told that more times than
I can keep track of, but you still bring them up endlessly.  Yes, what they
said caught Guido's attention at the time, but no, they've had nothing to do
with this since then.  Any mention of them now is at best irrelevant.

Kirby has managed to gain an excellent understanding of the real issues with
division in Python (perhaps because he's listening?):

[Kirby Urner]
> ...
> About div, the technical point is that all the operators *except* div,
> return very close to equivalent answers, even if the types differ.
> In this sense, it matters less for + - and * whether the arguments
> are floats, longs or integers.  Since there're no explicit type
> declarations in Python (as there are in C, from which the original
> div behavior derives), just eyeballing code is *not* necessarily
> going to make div's behavior unambiguous, even if you're a pro.
> So in this case, I'd say we're dealing with a "gotcha" that it
> doesn't pay to beat your head against.  It's still a problem even
> after you master it -- when reading others' code (don't always
> think about what it's like to read and understand your own).
>
> Going to / and // makes division unambiguous again.  The former
> forces a floating point treatment, the latter an integer treatment.

In a polymorphic language without explict type declarations, allowing

    z = x / y

to lose catastrophic amounts of information silently was simply a Bad Idea,
and more so for accomplished programmers than for newbies.  Along the way,
we changed Python 2.2 so that x**y no longer raised an exception when x and
y happen to be integers and y < 0, and for exactly the same reasons.  They
have nothing to do with newbies, apart that from giving a bizarre result for
sensible inputs isn't truly helpful to anyone.



From ajs@ix.netcom.com  Fri Oct 11 14:28:01 2002
From: ajs@ix.netcom.com (Arthur)
Date: Fri, 11 Oct 2002 09:28:01 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output
Message-ID: <00d401c2712a$066e1d00$9865fea9@arthur>

Tim writes -

>In all the conversations I've ever had with him on the topic, neither
>Sherwood nor Pausch came up.  Arthur, you've been told that more times than
>I can keep track of, but you still bring them up endlessly.

Is it important to make me seem more irrational and arbritrary than I
already do?

"Arthur, you've been told...."

Unacceptable wording, and unacceptable implications.

I *don't* have private conversations with Guido and am perfectly well
entitled to respond to what is of record.
Which simply, clearer, and undisputably is  not consistent with your private
conversations.

Simply, clearly, and undisputably.

I can't help that.

I have been made the fool enough, thank you.

Art




From list-python@ccraig.org  Fri Oct 11 14:52:12 2002
From: list-python@ccraig.org (Christopher A. Craig)
Date: 11 Oct 2002 09:52:12 -0400
Subject: [Edu-sig] Re: rationals
In-Reply-To: <5.1.1.6.0.20021010142628.02ce16d0@pop.ptld.qwest.net>
References: <Your message of "Thu, 10 Oct 2002 12:41:33 PDT."
 <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
 <000d01c2706d$fbc568c0$9865fea9@arthur>
 <200210101517.g9AFHmP07054@odiug.zope.com>
 <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010142628.02ce16d0@pop.ptld.qwest.net>
Message-ID: <whsmzd5bhv.fsf@olorin.ts.gatech.edu>

"Kirby Urner" <urnerk@qwest.net> writes:

> The only thing that nags is using two symbols instead of one to
> signify a type.  Complex (1j1) and float (1e1) get away with one
> symbol, which is why 3r2 was somewhat appealing (but the r tends
> to get lost).

Technically, you're only using one symbol.  You could specify a
rational with an integral value with just 'r'.

I should have a reference implementation that does this on Sourceforge
by next Tuesday.  

-- 
Christopher A. Craig <list-python@ccraig.org>
"Parity is for farmers." Seymour Cray on his machines lack of parity
"I guess farmers buy a lot of computers." Seymour Cray on including parity


From urnerk@qwest.net  Fri Oct 11 15:19:08 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 07:19:08 -0700
Subject: [Edu-sig] re: Types and true division (was Re: strange
 output
In-Reply-To: <00d401c2712a$066e1d00$9865fea9@arthur>
Message-ID: <5.1.1.6.0.20021011071831.02974ec0@pop.ptld.qwest.net>

At 09:28 AM 10/11/2002 -0400, Arthur wrote:

>Simply, clearly, and undisputably.

You're talking about some remarks in the VPython docs yes?

Kirby





From urnerk@qwest.net  Fri Oct 11 15:21:34 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 07:21:34 -0700
Subject: [Edu-sig] Re: rationals
In-Reply-To: <whsmzd5bhv.fsf@olorin.ts.gatech.edu>
References: <5.1.1.6.0.20021010142628.02ce16d0@pop.ptld.qwest.net>
 <Your message of "Thu, 10 Oct 2002 12:41:33 PDT." <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
 <000d01c2706d$fbc568c0$9865fea9@arthur>
 <200210101517.g9AFHmP07054@odiug.zope.com>
 <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010142628.02ce16d0@pop.ptld.qwest.net>
Message-ID: <5.1.1.6.0.20021011071935.0297aec0@pop.ptld.qwest.net>

At 09:52 AM 10/11/2002 -0400, Christopher A. Craig wrote:
>"Kirby Urner" <urnerk@qwest.net> writes:
>
> > The only thing that nags is using two symbols instead of one to
> > signify a type.  Complex (1j1) and float (1e1) get away with one
> > symbol, which is why 3r2 was somewhat appealing (but the r tends
> > to get lost).
>
>Technically, you're only using one symbol.  You could specify a
>rational with an integral value with just 'r'.

You could, if there's only a numerator, as in 2r.  But 3/2r contains
two symbols signifying type, whereas 3r2 contains only one.  I feel
I can live with either option.  3r/2 I don't really like, but I see
it as an operation rat/int returning 3/2r or (3/2)r or something
(I like the r as the final symbol in the number name, as L used to
be for longs).

Kirby





From tim.one@comcast.net  Fri Oct 11 16:08:30 2002
From: tim.one@comcast.net (Tim Peters)
Date: Fri, 11 Oct 2002 11:08:30 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output
In-Reply-To: <00d401c2712a$066e1d00$9865fea9@arthur>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEOJBKAB.tim.one@comcast.net>

[Tim]
> In all the conversations I've ever had with him on the topic, neither
> Sherwood nor Pausch came up.  Arthur, you've been told that more
> times than I can keep track of, but you still bring them up endlessly.

[Athur]
> Is it important to make me seem more irrational and arbritrary than I
> already do?
>
> "Arthur, you've been told...."
>
> Unacceptable wording, and unacceptable implications.

You've been told that by me more times than I can keep track of:  that was
about us.  I said nothing in that msg I haven't told you before, including
two more attempts at explaining what the division issue is really about (one
quoted from Kirby, in case you hadn't seen it, and another rewording from
me).  You wholly snipped the parts of the msg that addressed the base
question, retaining the tiny mention of Sherwood & Pausch(!).  What's up
with that?  You should broaden your interests beyond them <wink>.

> I *don't* have private conversations with Guido and am perfectly well
> entitled to respond to what is of record.

You should have noticed by now it's a monologue:  what S&P thought or think,
said or say, affirm or deny, is irrelevant to Python's plans.  You've been
told the real reasons for the division change so often and by so many that
you do indeed appear irrational on this specific topic.



From jjposner@snet.net  Fri Oct 11 16:30:29 2002
From: jjposner@snet.net (John Posner)
Date: Fri, 11 Oct 2002 11:30:29 -0400
Subject: [Edu-sig] RE: Rationals
Message-ID: <001601c2713b$23ed5240$c901a8c0@biped>

> 
>     int   / int   --> float
>

Why not this?

      int   / int   --> rat

After all, the definition of "rational" is "int divided by int".

--
John Posner
jjposner@snet.net



From dblank@cs.brynmawr.edu  Fri Oct 11 16:42:19 2002
From: dblank@cs.brynmawr.edu (Douglas S. Blank)
Date: Fri, 11 Oct 2002 11:42:19 -0400
Subject: [Edu-sig] Re: rationals
References: <000d01c2706d$fbc568c0$9865fea9@arthur> <200210101517.g9AFHmP07054@odiug.zope.com> <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>              <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net> <200210102024.g9AKOwF15892@odiug.zope.com>
Message-ID: <3DA6F15B.9000904@cs.brynmawr.edu>

[Apologies if this rational number issue is a dead horse; I've just 
joined the discussions recently. I've included some possible thoughts 
about perception from novice users. -Doug]

Guido van Rossum wrote:

>>rat() or rational()  ?
> 
> 
> I think rat() is good -- after all I shortened 'dictionary' to 'dict'...

You could also use ratio(), but rat() does seem to go with pythons better.

 >     int   / int   --> float     (float//float --> int)
 >     float / int   --> float     (int//int     --> int)
 >     rat   / int   --> rat   (?) (rat//rat     --> int)
 >     rat   / float --> float
 >     rat   / rat   --> rat

At first glance, this table seemed to create an asymmetry. Before the 
introduction of rationals, it seemed that / was a "float" division 
operator and produced only floats regardless of the operands (a good 
thing). And // was an "int" operator and produced only ints.

There are two ways around the apparent assymetry: 1 - result type is 
based on operator, or 2 - is based on a hierarchy of the operands. I see 
now that the proposal is to do both, with the following assumptions.

Method 1. // is the "integer" division operator. If we define a 
"rational" division operator (maybe represented by ///, or maybe not 
defined syntactically) to return rats and only rats, regardless of input 
types:

 >>> int   /// int => rat
 >>> float /// int => rat
 >>> rat   /// int => rat

Method 2. The result type of "/" is based on a hierarchy of the 
"highest" precision type. The heirarchy (apparently) is:

int -> rational -> float

which does match the original table. (Although the hierarchy seems 
arbitrary since rational seems to have higher precision than float). If 
you define a rational division operator, and state this hierarchy, then 
the asymmetry goes away. (Although, I'm not sure where to put imaginary 
and scientific representations).

Further asymmetries are found in examining other operators. For example, 
a beginner might guess:

float * float --> float
int   * int   --> float
float * int   --> float
rat   * int   --> rat
rat   * float --> float
rat   * rat   --> rat

And even worse:

float ** float -> int

(by making the analogy "if / ==> *, then // ==> **"). I am assuming that 
the other operators will be based on hierarchy only (I assume the one 
above). That is:

rat * float --> float
float * int --> float
rat * int   --> rat

As far as interactively displaying rationals goes, the "r" and parens 
seem unnecessary and could lead to confusion. We humans will parse it 
correctly. Although, if you wanted to be able to cut output and paste it 
as input, then you woud want to keep the input and output formats the same.

-Doug

> --Guido van Rossum (home page: http://www.python.org/~guido/)

-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu



From ajs@ix.netcom.com  Fri Oct 11 16:47:18 2002
From: ajs@ix.netcom.com (Arthur)
Date: Fri, 11 Oct 2002 11:47:18 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output
Message-ID: <00e201c2713d$7d489e10$9865fea9@arthur>

Me:

>>Simply, clearly, and undisputably.

Kirby:
>You're talking about some remarks in the VPython docs yes?

To continue a monolgue that I agree is absolutely pointles, but at the same
time can, if one chooses to see it as such, is also absolutely harmless:

No, Kirby.

I am referencing the fact that the original PEP spoke *only* of the newbie
issue.

But more importantly I am referencing the fact that Guido in the course of
the discussion referenced the work of Pausch and Sherwood, quite
specifically and on numerous occassions and in a way that indicated that to
him it provided what amounted to a scientific basis for a conclusion that
the change was necessary and important to be made on behalf of newbies.

I am referencing the fact that after all the contentious debate, the
announcment of the fact that it was a (near) done deal came in the form of
an announcement by Guido that he was sending over a patch to Bruce Sherwood
effectuating the change so that Bruce would no longer need to maintain a
forked Python. Which BTW Sherwood in fact never did, to my knowledge.

I am repeating the fact that in the course of the debate Guido specifically
responded a post of mine by pointing to the Sherwood classroom experience as
*proof* - as in science - that whatever Guido might have thought my point
was, it was groundless

Why clutter up the list with quotes and links. It's all there on the record.

I quite believe Tim that that was not the substance of *his* discussions on
the matter with Guido.

So?

Art





From dblank@cs.brynmawr.edu  Fri Oct 11 17:02:26 2002
From: dblank@cs.brynmawr.edu (Douglas S. Blank)
Date: Fri, 11 Oct 2002 12:02:26 -0400
Subject: [Edu-sig] RE: Rationals
References: <001601c2713b$23ed5240$c901a8c0@biped>
Message-ID: <3DA6F612.4070601@cs.brynmawr.edu>

John Posner wrote:
>>    int   / int   --> float
>>
> 
> 
> Why not this?
> 
>       int   / int   --> rat
> 
> After all, the definition of "rational" is "int divided by int".

Many Scheme implementations do exactly that. In Scheme:

 > (/ 12 23)
12/23
 > (/ 3 33)
1/11

Maybe Python should make a distinction between what it prints, and the 
internal form? For example, maybe internally Python would keep the most 
precise form of an expression, but the display format (integer, float, 
rational) could depend on other aspects (operator, hierarchy, or other 
context-sensitive items).

-Doug

 >
 > --
 > John Posner
 > jjposner@snet.net





-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu



From Jason Cunliffe" <jasonic@nomadics.org  Fri Oct 11 17:13:03 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Fri, 11 Oct 2002 12:13:03 -0400
Subject: [Edu-sig] RE: Rationals
References: <001601c2713b$23ed5240$c901a8c0@biped> <3DA6F612.4070601@cs.brynmawr.edu>
Message-ID: <009a01c27141$13eff0e0$6501a8c0@vaio>

> Maybe Python should make a distinction between what it prints, and the 
> internal form? For example, maybe internally Python would keep the most 
> precise form of an expression, but the display format (integer, float, 
> rational) could depend on other aspects (operator, hierarchy, or other 
> context-sensitive items).

I think that's also what 'Mathematica' does. 
Can anyone confirm or correct this ?

./Jason




From guido@python.org  Fri Oct 11 17:38:30 2002
From: guido@python.org (Guido van Rossum)
Date: Fri, 11 Oct 2002 12:38:30 -0400
Subject: [Edu-sig] RE: Rationals
In-Reply-To: Your message of "Fri, 11 Oct 2002 11:30:29 EDT."
 <001601c2713b$23ed5240$c901a8c0@biped>
References: <001601c2713b$23ed5240$c901a8c0@biped>
Message-ID: <200210111638.g9BGcVi03168@pcp02138704pcs.reston01.va.comcast.net>

We've gone through all this recently on python-dev, and also to some
extent here I believe.  I hope we won't have to go though all of it
again here; the python-dev archives are public.

The name choices are between rat() and rational().  Tim noted that
every rational type that was every used for real was called rat, so
rat it is.

> >     int   / int   --> float
> 
> Why not this?
> 
>       int   / int   --> rat
> 
> After all, the definition of "rational" is "int divided by int".

This is even what PEP 238 suggests.  But I'm not comfortable right now
with it for two reasons:

- People are expecting this to return a float now.

- I don't know how well rationals will work in "common" computations.
  I was bitten badly by this in ABC (read the python-dev archives) and
  while we can avoid the mistakes made there, I'm still not
  comfortable.

I think the following would be fair:

  If fixed-point decimal constants like 2.5 are rationals, 5/2 should
  also be a rational.  If 2.5 is a float, 5/2 should return a float --
  meaning that the only way to get a rational is to use an explicit
  rat() constructor or a literal with an 'r' suffix.  (I think 2.5r
  would make a nice way to input a rational too, in addition to 5r/2
  and 5/2r.)

For extra credit:

- What should "print 1/3" print?  I really don't want this to print
  the string "1/3" or some other way showing the components of the
  rational number.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From urnerk@qwest.net  Fri Oct 11 18:12:57 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 10:12:57 -0700
Subject: [Edu-sig] RE: Rationals
In-Reply-To: <001601c2713b$23ed5240$c901a8c0@biped>
Message-ID: <5.1.1.6.0.20021011100442.027e7d20@pop.ptld.qwest.net>

At 11:30 AM 10/11/2002 -0400, John Posner wrote:
> >
> >     int   / int   --> float
> >
>
>Why not this?
>
>       int   / int   --> rat
>
>After all, the definition of "rational" is "int divided by int".
>
>--
>John Posner
>jjposner@snet.net
>

This conflicts with the current redefinition of div such
that int/int --> float, meaning code currently being redone
to match 2.2 will have to be redone again.

Sometimes people *want* floats from ints, so the compromise
of making at least one int a rat, in order to get a rat,
seems worth making (to me).

Kirby





From guido@python.org  Fri Oct 11 18:15:46 2002
From: guido@python.org (Guido van Rossum)
Date: Fri, 11 Oct 2002 13:15:46 -0400
Subject: [Edu-sig] RE: Rationals
In-Reply-To: Your message of "Fri, 11 Oct 2002 10:12:57 PDT."
 <5.1.1.6.0.20021011100442.027e7d20@pop.ptld.qwest.net>
References: <5.1.1.6.0.20021011100442.027e7d20@pop.ptld.qwest.net>
Message-ID: <200210111715.g9BHFk525855@pcp02138704pcs.reston01.va.comcast.net>

> This conflicts with the current redefinition of div such
> that int/int --> float, meaning code currently being redone
> to match 2.2 will have to be redone again.

Um, in 2.2, 1/2 is still 0, unless you use python -Qnew. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)


From urnerk@qwest.net  Fri Oct 11 18:27:21 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 10:27:21 -0700
Subject: [Edu-sig] re: Types and true division (was Re: strange
 output
In-Reply-To: <00e201c2713d$7d489e10$9865fea9@arthur>
Message-ID: <5.1.1.6.0.20021011101449.027e7be0@pop.ptld.qwest.net>

At 11:47 AM 10/11/2002 -0400, Arthur wrote:

>Why clutter up the list with quotes and links. It's all there on the record.

OK, thanks for clarifying.  I've not followed the literature
as closely as you have.

I think if newbie confusions had been the only motivation for
the change, at the expense of language coherence, then it'd be
as you suppose, a politically expedient maneuver that dumbed
down the language but broadened its appeal to the masses.

My view is the vetting process, including PEPs, whereby a whole
community gets to examine proposed changes, is critical, and
changes with a shaky technical basis could and should be shot
down, or at least exposed as shaky, during this stage -- even
were they to come from Guido.  This vetting process is what the
community is engaged in currently, around adding rational
numbers as a new type (plus other PEPs).

If the problems with div were originally connected to the problems
of newbies, and if this were the *only* justification for the
making the change, then I think you'd have a point.

As I understand it, you wish there'd be some acknowledgement that
at some point in the evolutionary trajectory, there was a time
when newbie concerns seemed to weigh too heavily in the balance.
You resent being portrayed as irrational merely for wanting to
insist on this historical point.

As I said above, I haven't followed the literature closely enough
to know what the original PEP said or didn't say in detail, but
were this point to be granted in some way, then you'd be
satisfied.

I take it you are also, for your part, willing to acknowledge
that the final motivations for the change, after vetting and
input from a broader community, ended up having to do with
purely technical issues not of concern to newbies.  So that, in
fact, newbies are only happier with this change as a matter of
coincidence, whereas in other cases (e.g. not including copy()
as a built-in) newbie concerns are not being addressed, once
again for technical reasons (i.e. technical reasons have so
far carried the day in both cases).

>I quite believe Tim that that was not the substance of *his* discussions
>on the matter with Guido.
>
>So?
>
>Art

I don't think it's irrelevant that technical justifications for
the change do exist, irrespective of newbie concerns.  The lesson
to draw from this is, if you can't argue your position on technical
merits, it has less chance of surviving.  Just championing the
"new user" is not going to carry the day when it comes to the
Python community's assessment process.  And yes, sometimes newbies
and pros will find themselves in agreement (other times not).

Kirby





From urnerk@qwest.net  Fri Oct 11 18:45:24 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 10:45:24 -0700
Subject: [Edu-sig] RE: Rationals
In-Reply-To: <200210111715.g9BHFk525855@pcp02138704pcs.reston01.va.comca
 st.net>
References: <Your message of "Fri, 11 Oct 2002 10:12:57 PDT." <5.1.1.6.0.20021011100442.027e7d20@pop.ptld.qwest.net>
 <5.1.1.6.0.20021011100442.027e7d20@pop.ptld.qwest.net>
Message-ID: <5.1.1.6.0.20021011104408.027e0350@pop.ptld.qwest.net>

At 01:15 PM 10/11/2002 -0400, Guido van Rossum wrote:
> > This conflicts with the current redefinition of div such
> > that int/int --> float, meaning code currently being redone
> > to match 2.2 will have to be redone again.
>
>Um, in 2.2, 1/2 is still 0, unless you use python -Qnew. :-)
>
>--Guido van Rossum (home page: http://www.python.org/~guido/)

Yes --- getting ahead of myself.  By "current redefinition" I'm
really talking about the fait accompli:  the __future__ is
inevitable (we are Borg, resistence is futile etc. etc.).

Kirby





From list-python@ccraig.org  Fri Oct 11 19:10:41 2002
From: list-python@ccraig.org (Christopher A. Craig)
Date: 11 Oct 2002 14:10:41 -0400
Subject: [Edu-sig] Re: rationals
In-Reply-To: <5.1.1.6.0.20021011071935.0297aec0@pop.ptld.qwest.net>
References: <5.1.1.6.0.20021010142628.02ce16d0@pop.ptld.qwest.net> <Your
 message of "Thu, 10 Oct 2002 12:41:33 PDT."
 <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
 <000d01c2706d$fbc568c0$9865fea9@arthur>
 <200210101517.g9AFHmP07054@odiug.zope.com>
 <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010142628.02ce16d0@pop.ptld.qwest.net>
 <5.1.1.6.0.20021011071935.0297aec0@pop.ptld.qwest.net>
Message-ID: <whk7kokfry.fsf@olorin.ts.gatech.edu>

"Kirby Urner" <urnerk@qwest.net> writes:

> (I like the r as the final symbol in the number name, as L used to
> be for longs).
> 
> Kirby

It's my understanding that that is exactly what Guido is proposing.
He is, I believe, proposing that the regular expression ([0-9]*)r
define a rational number with the integral value of the parenthesized
group.  So, much like present CPython where -3 actually defines the
integer three and then negates it and 1+2j defines the integer 1 and
the complex (0+2j) and adds them, 3/2r would define the integer 3 and
the rational (2/1)r and then divide them to get (3/2)r (This could, of
course, be optimized to a real definition by a different/future
compiler).

-- 
Christopher A. Craig <list-python@ccraig.org>
"It's the one thing I understand, I guess." Bill Gates, about BASIC


From urnerk@qwest.net  Fri Oct 11 19:24:21 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 11:24:21 -0700
Subject: [Edu-sig] Re: rationals
In-Reply-To: <whk7kokfry.fsf@olorin.ts.gatech.edu>
References: <5.1.1.6.0.20021011071935.0297aec0@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010142628.02ce16d0@pop.ptld.qwest.net>
 <Your message of "Thu, 10 Oct 2002 12:41:33 PDT." <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
 <000d01c2706d$fbc568c0$9865fea9@arthur>
 <200210101517.g9AFHmP07054@odiug.zope.com>
 <5.1.1.6.0.20021010094347.02e03560@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010122007.02e35540@pop.ptld.qwest.net>
 <5.1.1.6.0.20021010142628.02ce16d0@pop.ptld.qwest.net>
 <5.1.1.6.0.20021011071935.0297aec0@pop.ptld.qwest.net>
Message-ID: <5.1.1.6.0.20021011111702.028745b0@pop.ptld.qwest.net>

At 02:10 PM 10/11/2002 -0400, Christopher A. Craig wrote:
>"Kirby Urner" <urnerk@qwest.net> writes:
>
> > (I like the r as the final symbol in the number name, as L used to
> > be for longs).
> >
> > Kirby
>
>It's my understanding that that is exactly what Guido is proposing.

OK, so I think we're on the same page then.

It's still two extra symbols (both / and r) vs. one (r) to write
1/2r versus 1r2, and it takes even more symbols to write (1/2)r.

I like J's economy, but I can see 1/2r as a very viable alternative.
As you say, it has much in common with 1+2j, where you need both
+ and j (two symbols) to signify complex.

An argument for 1r2 is that 1e2 sets a precedent.  But 1j2 is not
legal in Python, as it is in J, so the consistency is shakier
(not as *much* precedent).

Another point:

With longs, I can use either upper or lower case l, which isn't
so readable in code, as lowercase l looks like 1.  But r and R
are clearly not numbers.  So I assume the following would likewise
be legal:

     >>> 1/2R
  (1/2)r

or maybe that's 1/2r -- not sure which.

Kirby





From jjposner@snet.net  Fri Oct 11 19:52:33 2002
From: jjposner@snet.net (John Posner)
Date: Fri, 11 Oct 2002 14:52:33 -0400
Subject: [Edu-sig] RE: Rationals
In-Reply-To: <200210111715.g9BHFk525855@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <000001c27157$5c369690$6501a8c0@biped>

Hi --

  >> > This conflicts with the current redefinition of div such
  >> > that int/int --> float, meaning code currently being redone
  >> > to match  2.2 will have to be redone again.
  >> 
  >> Um, in 2.2, 1/2 is still 0, unless you use python -Qnew. :-)

Was the "int/int --> float" decision made before the "rational" numeric
type was being considered? A few years/releases down the road, if int's
and float's and rational's are all in common usage, the decision to make
int/int yield a float may be as perplexing (to some people) as "3/2
yields the integer 1" is perplexing now (to some people).

I like this point of Kirby's:

   >> Sometimes people *want* floats from ints, so the compromise
   >> of making at least one int a rat, in order to get a rat,
   >> seems worth making (to me).

Could Python officially support multiple "numeric modes"? They could be
called with various flavors of "-Q" or some other command-line option:

* "python -Qsci" --> scientific mode: the result of some (or all?)
numeric operations that yield a real number are automatically cast to
the "float" type. This would include:

  1 + 2
  1 / 2
  1 * 2
  3 / 2

More radically, even this expression might yield a float in "scientific
mode":

  42


The list of numeric modes would include "rational" (where 3/2 yields
3/2r) and "integer" (where 3/2 yields 1).

(Actually, I'd rather see 3/2 raise an exception in "integer mode",
since the set of integers is not closed with respect to division -- kind
of like dividing by zero. And what the heck -- for elementary school
kids, there could be a "natural number mode", where the expression "3 -
5" would raise an exception.)

-John

--
John Posner
jjposner@snet.net



From dennis.hamilton@acm.org  Fri Oct 11 21:11:50 2002
From: dennis.hamilton@acm.org (Dennis E. Hamilton)
Date: Fri, 11 Oct 2002 13:11:50 -0700
Subject: [Edu-sig] Re: rationals
In-Reply-To: <5.1.1.6.0.20021011111702.028745b0@pop.ptld.qwest.net>
Message-ID: <NGBBIKAHMDNFPKNEPALEOEJHIOAA.dennis.hamilton@acm.org>

I know this isn't the place for this, but the conversation is a lot of fun.

If I were creating a canonical form for input-output, it would be based
around

<simple-rational> ::= <simple-non-rational-numeral>R |
<simple-non-rational-numeral>r

<rational-numeral> ::= <simple-rational> | <simple-rational> /
<simple-non-rational-numeral>

where the "/..." part is optional and one might even relax the denominator
<simple-non-rational-numeral> constraint in an input stream.

Note that 1.5e-3r/17

would be a valid input, but the canonical output of its value is more likely
to be "3r/34000".

In expressions, the "/" would just be a "/" and everything works as expected
for "/".

-- orcmid

------------------
Dennis E. Hamilton
http://NuovoDoc.com/
mailto:dennis.hamilton@acm.org
tel. +1-206-932-6970
cell +1-206-779-9430
     The Miser Project: http://miser-theory.info/
     AIIM DMware: http://DMware.info/

-----Original Message-----
From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On
Behalf Of Kirby Urner
Sent: Friday, October 11, 2002 11:24
To: Christopher A. Craig
Cc: edu-sig@python.org
Subject: Re: [Edu-sig] Re: rationals


[ ... ]

I like J's economy, but I can see 1/2r as a very viable alternative.
As you say, it has much in common with 1+2j, where you need both
+ and j (two symbols) to signify complex.

An argument for 1r2 is that 1e2 sets a precedent.  But 1j2 is not
legal in Python, as it is in J, so the consistency is shakier
(not as *much* precedent).

Another point:

With longs, I can use either upper or lower case l, which isn't
so readable in code, as lowercase l looks like 1.  But r and R
are clearly not numbers.  So I assume the following would likewise
be legal:

     >>> 1/2R
  (1/2)r

or maybe that's 1/2r -- not sure which.

Kirby




_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig





From guido@python.org  Fri Oct 11 21:18:42 2002
From: guido@python.org (Guido van Rossum)
Date: Fri, 11 Oct 2002 16:18:42 -0400
Subject: [Edu-sig] RE: Rationals
In-Reply-To: Your message of "Fri, 11 Oct 2002 14:52:33 EDT."
 <000001c27157$5c369690$6501a8c0@biped>
References: <000001c27157$5c369690$6501a8c0@biped>
Message-ID: <200210112018.g9BKIiF10220@pcp02138704pcs.reston01.va.comcast.net>

> Was the "int/int --> float" decision made before the "rational" numeric
> type was being considered?

PEP 238 actually says that it should be a rational when we have
rationals.  But I am now getting second thoughts about whether it is
really a good idea to make rationals this pervasive.

> A few years/releases down the road, if int's
> and float's and rational's are all in common usage, the decision to make
> int/int yield a float may be as perplexing (to some people) as "3/2
> yields the integer 1" is perplexing now (to some people).

Hardly.  Float and rational both give a useful answer to questions
like "how much is 1/3".  When you print the result, you'll usually
want it in decimal notation, so the fact that the rational is "more
exact" doesn't do you any good.  This is fundamentally different from
the answer you get for 1/3 today.

I'm not saying that float is necessarily the better answer -- just
saying that it's not as a perplexing as 0.

Th arguments for choosing float stem from conservatism: we don't know
how well returning a rational works in practice.  This would be a good
exercise to try though.

> I like this point of Kirby's:
> 
>    >> Sometimes people *want* floats from ints, so the compromise
>    >> of making at least one int a rat, in order to get a rat,
>    >> seems worth making (to me).
> 
> Could Python officially support multiple "numeric modes"?

I think this is a bad idea, at least when there is a single "global"
mode: different parts of the library may require different modes, and
temporarily switching the global mode to suit your own needs is
fraught with errors (even if you restrict it to your own thread).

This idea and similar ideas (e.g. a "fuzz" for comparisons) *always*
comes up when the various choices in numerics are discussed, and they
are always shot down for these reasons.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From urnerk@qwest.net  Fri Oct 11 22:31:09 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 14:31:09 -0700
Subject: [Edu-sig] RE: Rationals
In-Reply-To: <000001c27157$5c369690$6501a8c0@biped>
References: <200210111715.g9BHFk525855@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <5.1.1.6.0.20021011142808.03b93510@pop.ptld.qwest.net>


>Could Python officially support multiple "numeric modes"? They could be
>called with various flavors of "-Q" or some other command-line option:

I don't personally like using switches to change behavior, as
then you can't just cut and paste code and run it -- you have
to know which "-Q" is being used.

>(Actually, I'd rather see 3/2 raise an exception in "integer mode",
>since the set of integers is not closed with respect to division -- kind
>of like dividing by zero. And what the heck -- for elementary school
>kids, there could be a "natural number mode", where the expression "3 -
>5" would raise an exception.)
>
>-John

As Danny Yoo pointed out, ML takes this route.  But I think it's
OK for non-closure to open a door to another type automatically,
just as ordinary ints now create longs when int boundaries are
exceeded (textbook math doesn't know about "int boundaries" --
but this is computer science, with math a backseat driver).

Kirby





From ajs@ix.netcom.com  Sat Oct 12 00:07:36 2002
From: ajs@ix.netcom.com (Arthur)
Date: Fri, 11 Oct 2002 19:07:36 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output
Message-ID: <00ec01c2717a$fdc6acc0$9865fea9@arthur>

>As I understand it, you wish there'd be some acknowledgement that
>at some point in the evolutionary trajectory, there was a time
>when newbie concerns seemed to weigh too heavily in the balance.

Actually what I *wish* is that Michael Williams ruled the world.

There I am in high asshole mode, contending with Williams of the "/" issue.

And in the course of a few exchanges he made the following clear:

1) Whether he liked or approved of me was not to a point.
2) That he understood my position, in substance.
2) That he understood my position , in substance (double credit, because
that seems to be of some importance to me)
3) That he disagreed with me.
4) That he was willing tacitly  to acknowledge that he did not see my
position as motivated by one-up-man-ship, by some interest to draw attention
to myself, or to make someone else look stupid or be wrong.  It was what I
believed (and he disagreed) was the right answer, based on a decent
understanding of the issues that were on his mind as an instructor of Python
to physics students.
5) That he took something away from the exchange that was useful to him.

I would like to at least nominate Mr. Williams to the post of Chancelor for
Foreign Affairs.

I will be the Foreign Affiars.

Art






From urnerk@qwest.net  Sat Oct 12 00:45:33 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 16:45:33 -0700
Subject: [Edu-sig] re: Types and true division (was Re: strange
 output
In-Reply-To: <00ec01c2717a$fdc6acc0$9865fea9@arthur>
Message-ID: <5.1.1.6.0.20021011162015.0287a650@pop.ptld.qwest.net>

At 07:07 PM 10/11/2002 -0400, Arthur wrote:
> >As I understand it, you wish there'd be some acknowledgement that
> >at some point in the evolutionary trajectory, there was a time
> >when newbie concerns seemed to weigh too heavily in the balance.
>
>Actually what I *wish* is that Michael Williams ruled the world.
>
>There I am in high asshole mode, contending with Williams of the "/" issue.
>
>And in the course of a few exchanges he made the following clear:
>
>1) Whether he liked or approved of me was not to a point.
>2) That he understood my position, in substance.

....Which I am still trying to do (only because you seem to
very much *want* to be understood).

You side-step my question, as to whether what you're after is
acknowledgement that a reasonable person reading the PEP at
some point in the past, might have concluded, as you apparently
did, that the behavior of the div operator was being changed
by Guido solely in order to mollify specific concerns, Sherwood's
& Pausch's in particular.

Not having that PEP in front of me, I'll give you the benefit of
the doubt and accept that a reasonable person might indeed so
conclude.  I might reassess my position if I ever revisit the
PEP as it appeared at that time, but I have no strong desire
to do that.

Then I'll go on to say that, ultimately, the case for making the
change wasn't about mollifying these individuals.  There are
good reasons for doing so completely aside from whether students
find 1/3=0 confusing on first exposure.

What I'm unclear on is whether you accept the relevance of these
other reasons.  Furthermore, I think one might reasonably doubt
that you really understand these reasons, as you consistently and
concertedly never seem to address them, which accounts for much
of the frustration with this thread I've seen expressed by others
(you're not the only one experiencing frustration).

In any case, my position is (a) you are not irrational for wanting
to insist that S&P might have, at one point in time, have at least
appeared to have had an unwarranted and detrimental influence over
Python's evolution (whether they did in reality is probably an
unknowable from my point of view) and (b) this is not at this point
in time an important point to make, as the change in div's behavior
is now recognized as a design improvement on technical grounds,
history and personalities aside.

That'll be my final word on this topic.  If you clarify further,
great, and if you choose not to, great.  At this point, it's all
water under the bridge.  I can't see spending a lot more time on
this footnote-to-a-footnote.

Kirby





From ajs@ix.netcom.com  Sat Oct 12 01:02:38 2002
From: ajs@ix.netcom.com (Arthur)
Date: Fri, 11 Oct 2002 20:02:38 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output
Message-ID: <00f501c27182$d968b3c0$9865fea9@arthur>

>If you clarify further, great, and if you choose not to, great.

Oh Lord why must I be so misunderstood?

I am certainly not saying that Michael either understands or gives two shits
about my "position" as to the historical record.  I am saying I think he
understands the trade-off I raise between making the div operator more
intuitive for the physics student, and lulling them into a false sense of
security as to the importance of the underlying typing.

To repeat.

He disagrees with me, though, as to where I come out..

Guess what, I can handle that fine.

Art







From urnerk@qwest.net  Sat Oct 12 01:10:49 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 17:10:49 -0700
Subject: [Edu-sig] re: Types and true division (was Re: strange
 output)
In-Reply-To: <008101c27095$3746cca0$9865fea9@arthur>
Message-ID: <5.1.1.6.0.20021011164653.0287dd60@pop.ptld.qwest.net>

Oh, OK, twist my arm, one more...

At 03:42 PM 10/10/2002 -0400, Art wrote:

>The old "/" operator is a gotcha if one choses to see it that way.  I had
>told you in a private note some time ago, that I found it a particulary
>nasty gotcha when raising to a fractional power. From an experiential point
>of view, that tended to be the only time I would *actually* get caught with
>my pants down.

But how much time have you spent trying to read code as elaborate
and math-invested as Pygeo's, yet not written by yourself?

>But I have the ability to foresee where Bruce's and Michael's students are
>most likely to get caught with *their* pants down, under the new operator.
>Which are ways even more subtle, IMO, but just as likely to arise as with my
>raised to a power issue.  So, on the gotcha score - at best a wash, IMO.

(You don't spell out the gotchas with the new behavior -- examples
might have been nice.)

Again, your model is the of lone coder, trying to get results,
wrestling with his or her own confusions and overcoming them.

But what about teams of coders writing stuff that future maintainers
will need to wrap their heads around?

The change in the div operator is what'll make Pygeo easier to grasp
when you're no longer around to explain how it works.  Commenting helps
of course, but a function like

   def op(a,b,c):
     return (a/b)+c

buried on line 10000, is just going to puzzle a reader (including a
pro), if they don't know immediately all the places op is invoked (and
why should they), and whether op expects floats, or integers -- and
given no explicit declarations, this'll be hard to determine (like,
maybe a,b,c are read from some raw data file -- this isn't Kansas
a.k.a. the C language, where you'd have int a; int b; float c declared
elsewhere, along with the return type of the function itself).

>With no generalizations to be made beyond that observation.
>
>Art
>

It's an observation based on an overly-narrow appreciation for what
programming involves, which is *not* just person X overcoming some
initial confusions and producing an elaborate, functional program.
You need one of those jobs where someone hands you 10000 lines of
Python code, with some subtle math-related bugs in it, and asks you
to track them down (by tomorrow, latest).

These days, I'm struggling with some Visual FoxPro thing (Xbase)
written by an amateur coder with a day job as a plumber.  He's since
moved to Colorado (I'm changing some of the facts, to protect the
guilty).  My client uses this program all day for mission critical
stuff.  There's no time to start over, so I have to gradually puzzle
through all this stuff, a lot of which is written in quirky ways
because he didn't really know Xbase all that well.

A test of Xbase's power and long term viability is how well it holds
up (in terms of readability, comprehensibility) in circumstances
like these.  If I have doubts about APL and J (REBOL?), it's in
this area also:  are these "write once, read never" languages? --
I haven't learned J well enough to know if easy fluency around
*other peoples code* (not just mine) is trully attainable
(presumably it is, but it takes more than a year to get there).

Kirby





From urnerk@qwest.net  Sat Oct 12 01:21:03 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 17:21:03 -0700
Subject: [Edu-sig] re: Types and true division (was Re: strange
 output
In-Reply-To: <00f501c27182$d968b3c0$9865fea9@arthur>
Message-ID: <5.1.1.6.0.20021011171342.0289ae30@pop.ptld.qwest.net>

At 08:02 PM 10/11/2002 -0400, Arthur wrote:

> >If you clarify further, great, and if you choose not to, great.
>
>Oh Lord why must I be so misunderstood?

I didn't want to go back and reread all Michael's comments in order
to understand *your* position (better you should just be misunderstood).

I was hoping you'd just answer my particular question.  Oh well...

>I am certainly not saying that Michael either understands or gives two shits
>about my "position" as to the historical record.  I am saying I think he
>understands the trade-off I raise between making the div operator more
>intuitive for the physics student, and lulling them into a false sense of
>security as to the importance of the underlying typing.

I conclude that you don't yourself understand the importance of typing,
or you wouldn't wish div to remain so ambiguous.

>To repeat.
>
>He disagrees with me, though, as to where I come out..

I wasn't trying to understand what you're saying about Michael.  I was
repeating a question I'd asked you before -- not related to Michael's
comments in any way.

>Guess what, I can handle that fine.
>
>Art

And I guess I can handle irrelevance.

End of story (how many times will I say that?).

Kirby





From ajs@ix.netcom.com  Sat Oct 12 01:34:50 2002
From: ajs@ix.netcom.com (Arthur)
Date: Fri, 11 Oct 2002 20:34:50 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output)
Message-ID: <010001c27187$2f86c400$9865fea9@arthur>

>But I have the ability to foresee where Bruce's and Michael's students are
>most likely to get caught with *their* pants down, under the new operator.
>Which are ways even more subtle, IMO, but just as likely to arise as with
my
>raised to a power issue.  So, on the gotcha score - at best a wash, IMO.

Kirby writes -

>(You don't spell out the gotchas with the new behavior -- examples
>might have been nice.)

Gotchas with the new behavior are not directly gotchas with the new
behavior.  They are gotchas that arise when being blindsided by the fact
that numeric typing matters.  Something clear to anyone functioning under
the old system.

The one I raised to Michael was:

>>> fromNumeric import *
>>> a=array([1,2,3])
>>> a[1]=.5
>>> a
array([1, 0, 3])

Huh? under new "/"
ouch - I should have seen that coming under old "/"

Michael acknowledged that that exact situation had already arisen and thrown
folks for a loop in his class.

Which is what was so bizarre to me about the discussion.  That 1/2 = 0 would
be an intial surprise to Bruce's students is so obviously true that it isn't
worth mentioning.  We could have all agreed as a starting point - relying on
nothing but our common sense - that we got an issue on our hands.

What might have been productive and interesting and actually a little
scientific, is to test the full reprecussions of the*change* to 1/2 = .5 for
Bruce's students.  And then *begin* a discussion of pros and cons.

And *I'm* the English major.

Art






From lha2@columbia.edu  Sat Oct 12 01:52:23 2002
From: lha2@columbia.edu (Lloyd Hugh Allen)
Date: Fri, 11 Oct 2002 20:52:23 -0400
Subject: [Edu-sig] Re: rationals
References: <20021011150901.29623.63565.Mailman@mail.python.org>
Message-ID: <3DA77247.8BAFCC84@mail.verizon.net>

> But it would look like this:
> 
>   >>> a = 3/2r
>   >>> b = 1/2r
>   >>> a * b
>   (3/2r)

That won't do at all. (3/2)(1/2)==(3/4). I got terribly confused going
from here to the decimal representation. (And I suppose I'll never be
able to get implied division without a '*', while people are whining
about ninny things).

>   >>> float(a*b)
>   0.75

Here's a question from someone who hasn't used rationals outside of
Mathematica, TI-89/92, some sort of weird Casio, and the like, mostly in
an interactive basis, on an issue that people had later in the thread:
besides the representation given by the "print" command, how would code
be affected if the programmer expected a float and the engine had been
upgraded to return a rational instead? What would break?


From ajs@ix.netcom.com  Sat Oct 12 02:15:07 2002
From: ajs@ix.netcom.com (Arthur)
Date: Fri, 11 Oct 2002 21:15:07 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output
Message-ID: <010701c2718c$ce344f50$9865fea9@arthur>

>I conclude that you don't yourself understand the importance of typing,
>or you wouldn't wish div to remain so ambiguous.

Conclude what you like.

After you understand my position.

Python, I thought, was always interested in the practical outcome rather
than theoretical purity. Which is why my mind does shut off I bit when you
and Guido and Tim explain to me the *real* reason the div operator had to
change.  It's theoretical "right". I'm sure.  Its symetrical, and all that.
Does it help someone trying to get a handle on things? How?

My position has *no* theoretical basis.  Beyond the fact that - and please
don't jump all over me if there is something technical amiss in this
wording - it better exposes the reality of what we are dealing with (a
pretty thin wrapper around standard C, no?).

And that is only my attempt to say in higher falutin language, that my point
is experiental - not theoretical.  And not unlikely wrong.  Which you are
well entitled to tell me. But I will definitely take it better if I think
you have first taken in the practical point I am making.

Michael did.

You haven't.

Art






From dennis.hamilton@acm.org  Sat Oct 12 02:25:24 2002
From: dennis.hamilton@acm.org (Dennis E. Hamilton)
Date: Fri, 11 Oct 2002 18:25:24 -0700
Subject: [Edu-sig] Re: rationals
In-Reply-To: <3DA77247.8BAFCC84@mail.verizon.net>
Message-ID: <NGBBIKAHMDNFPKNEPALEGEJMIOAA.dennis.hamilton@acm.org>

The biggest difference is that some floating-point calculations that will
converge (disappear at 0 or converge on a fixed value) will not terminate in
rational computation.

Since this sort of thing is not a very good way to use floats either, it
should provoke more-appropriate numerical techniques.

-- Dennis

-----Original Message-----
From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On
Behalf Of Lloyd Hugh Allen
Sent: Friday, October 11, 2002 17:52
To: edu-sig@python.org
Subject: Re: [Edu-sig] Re: rationals

[ ... ]

Here's a question from someone who hasn't used rationals outside of
Mathematica, TI-89/92, some sort of weird Casio, and the like, mostly in
an interactive basis, on an issue that people had later in the thread:
besides the representation given by the "print" command, how would code
be affected if the programmer expected a float and the engine had been
upgraded to return a rational instead? What would break?

_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig





From Jason Cunliffe" <jasonic@nomadics.org  Sat Oct 12 02:41:20 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Fri, 11 Oct 2002 21:41:20 -0400
Subject: lonely programming vs. teamwork => was :{Re: [Edu-sig] re: Types and true division (was Re: strange  output)}
References: <5.1.1.6.0.20021011164653.0287dd60@pop.ptld.qwest.net>
Message-ID: <001901c27190$772778a0$6501a8c0@vaio>

> Again, your model is the of lone coder, trying to get results,
> wrestling with his or her own confusions and overcoming them.
>
> But what about teams of coders writing stuff that future maintainers
> will need to wrap their heads around?

As a lone programmer myself, I appreciate that.
So recently I have been gently inspired by some good lessons from the Extreme
folks:

http://www.extremeprogramming.org/rules.html

Especially working alone, I find just __thinking__ about their approach has
given me fresh insight. Daily results and testing are something a loner person
can do. It's encouraging. If Extreme Programming is really just a banner for
applying continuous and extreme common sense, then I figure we can all do with
some of that.

Python already has lots and especially when it comes to teamwork [readability].
I am beginning to suspect that many of the 'newbie/novice' issues raised here
are indeed symptomatic of 'lone-ly programmers'.

Of course, I don't mean simply people programming on their own, but rather the
lack of development feedback which comes with concerted team effort. The shining
lights of openSource...

./Jason



From urnerk@qwest.net  Sat Oct 12 02:47:51 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 18:47:51 -0700
Subject: [Edu-sig] Typed arrays (not about div)
In-Reply-To: <010001c27187$2f86c400$9865fea9@arthur>
Message-ID: <5.1.1.6.0.20021011183438.029f5be0@pop.ptld.qwest.net>

At 08:34 PM 10/11/2002 -0400, Arthur wrote:
> >But I have the ability to foresee where Bruce's and Michael's students are
> >most likely to get caught with *their* pants down, under the new operator.
> >Which are ways even more subtle, IMO, but just as likely to arise as with
>my
> >raised to a power issue.  So, on the gotcha score - at best a wash, IMO.
>
>Kirby writes -
>
> >(You don't spell out the gotchas with the new behavior -- examples
> >might have been nice.)
>
>Gotchas with the new behavior are not directly gotchas with the new
>behavior.  They are gotchas that arise when being blindsided by the fact
>that numeric typing matters.  Something clear to anyone functioning under
>the old system.
>
>The one I raised to Michael was:
>
> >>> fromNumeric import *
> >>> a=array([1,2,3])
> >>> a[1]=.5
> >>> a
>array([1, 0, 3])
>
>Huh? under new "/"
>ouch - I should have seen that coming under old "/"

OK, now look at this:

  >>> from Numeric import *
  >>> b = array([1,2,3])
  >>> b[1] = 'a'
  >>> b
  array([ 1, 97,  3])

Same issue, yet very clearly this has nothing whatever to do with
the behavior of div, either way.  We're facing the fact that Numeric
doesn't allow mixing types inside an array type.  To bring div into
it only confuses the issue. 'a' is being coerced to an int:

   >>> ord('a')
   97

Note that Numeric is extrinsic to core Python and has a number
of dialectical wrinkles.  Closer to home would have been to use
the array module itself, which takes the type as a first
argument, thereby clarifying what's going on:

  >>> from array import *
  >>> b = array([1,2,3])     # can't get away without declaring type
  Traceback (most recent call last):
    File "<pyshell#1>", line 1, in ?
      b = array([1,2,3])
  TypeError: array() takes exactly 2 arguments (1 given)
  >>> b = array('i',[1,2,3])
  >>> b
  array('i', [1, 2, 3])
  >>> b[1] = 'a'             # doesn't coerce  (unlike Numeric)
  Traceback (most recent call last):
    File "<pyshell#4>", line 1, in ?
      b[1] = 'a'
  TypeError: an integer is required
  >>> b[1] = 2.
  >>> b                  # ah, so there's automatic coercion of floats
  array('i', [1, 2, 3])
  >>> b[1] = 2.1         # ... akin to going int(2.1)
  >>> b
  array('i', [1, 2, 3])

>Michael acknowledged that that exact situation had already arisen and thrown
>folks for a loop in his class.

No doubt.  Linking this to the behavior of div (which doesn't change
either way) would have only confused them more.

>And *I'm* the English major.
>
>Art

Any serious study of programming qua programming (philosophy major)
involves studying types,. And, as Danny Yoo pointed out above, you
*don't* want to use Python as your primary vehicle for studying types.

Any programming course that just looks at one and only one computer
language isn't really a programming course, the way I see it.  It's
fine to *concentrate* on one language, but you need others in the
picture to compare and contast.

The argument can be made that "mono-lingual computer programmer"
is an oxymoron (as an English major, you no doubt grok).

Kirby





From urnerk@qwest.net  Sat Oct 12 03:04:12 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 19:04:12 -0700
Subject: [Edu-sig] Re: rationals
In-Reply-To: <3DA77247.8BAFCC84@mail.verizon.net>
References: <20021011150901.29623.63565.Mailman@mail.python.org>
Message-ID: <5.1.1.6.0.20021011184852.029facc0@pop.ptld.qwest.net>

At 08:52 PM 10/11/2002 -0400, Lloyd Hugh Allen wrote:

>Here's a question from someone who hasn't used rationals outside of
>Mathematica, TI-89/92, some sort of weird Casio, and the like, mostly in
>an interactive basis, on an issue that people had later in the thread:
>besides the representation given by the "print" command, how would code
>be affected if the programmer expected a float and the engine had been
>upgraded to return a rational instead? What would break?

It's not just a question of what would break, either.  It's also a
question of whether I want the extra overhead of CPython internally
managing numerators and denominators when inverting a matrix (say).

If I start with a matrix of integers and invert it, it'll take a
lot longer to return rational results.

   >>> matrix  # some object
1 _2  3
5  7 _1
2  9  8

Floating point inverse:

   >>> matrix.inverse()

  0.268595   0.177686 _0.0785124
_0.173554 0.00826446  0.0661157
  0.128099  _0.053719  0.0702479

Rational inverse:

   >>> matrix.inverse()
  65/242r  43/242r -19/242r
-21/121r   1/121r   8/121r
  31/242r -13/242r  17/242r

Internally, these two are vastly different, in terms of both
CPU cycles and algorithms.

Presumably if I start with all elements in a matrix rational,
I want a rational inverse (2nd form).  But what if just one
element is rational and the rest are integers?  I think we're
going to get floating point answers, because a lot of the
divisions won't "know" there's a rational in the picture
(and int/int-->float).

With the regime currently under consideration in this thread,
I think there'll be a bias for complicated multi-variable calcs
to "decay" into floats, unless they start with rats and only
rats.  Alternatively, you can write a matrix routine that
starts by converting everything it gets to rats, e.g. running
matrix.rinverse(), even on ints, would get a rational output
(but on floats?).

Kirby





From tim.one@comcast.net  Sat Oct 12 03:06:49 2002
From: tim.one@comcast.net (Tim Peters)
Date: Fri, 11 Oct 2002 22:06:49 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output
In-Reply-To: <5.1.1.6.0.20021011162015.0287a650@pop.ptld.qwest.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEBEBLAB.tim.one@comcast.net>

[Kirby Urner, to Arthur]
> ...
> You side-step my question, as to whether what you're after is
> acknowledgement that a reasonable person reading the PEP at
> some point in the past, might have concluded, as you apparently
> did, that the behavior of the div operator was being changed
> by Guido solely in order to mollify specific concerns, Sherwood's
> & Pausch's in particular.

A reasonable person could have concluded that Guido was *primarily*
motivated by that at the time.

Those folks were the first to bring up the issue forcefully, and Guido
recognized the correctness of their conclusion at once.  Figuring out *why*
the conclusion was correct stretched out over years, and Guido didn't move
to change the language until after his brain caught up with his designer's
intuition.  That's often how the creative process works, and the original
inspiration is irrelevant at the end.  Heck, for all I know, the Mona Lisa
didn't have a truly good reason for smiling, either.  According to

    http://library.thinkquest.org/13681/data/link2.htm

Da Vinci actually painted a self-portait in drag.  Does it matter?  The
smile is exactly right regardless.



From urnerk@qwest.net  Sat Oct 12 03:21:35 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 19:21:35 -0700
Subject: [Edu-sig] re: Types and true division (was Re: strange
 output
In-Reply-To: <010701c2718c$ce344f50$9865fea9@arthur>
Message-ID: <5.1.1.6.0.20021011190456.029feec0@pop.ptld.qwest.net>

At 09:15 PM 10/11/2002 -0400, Arthur wrote:

>My position has *no* theoretical basis.  Beyond the fact that - and please
>don't jump all over me if there is something technical amiss in this
>wording - it better exposes the reality of what we are dealing with (a
>pretty thin wrapper around standard C, no?).

I'd say a pretty *thick* wrapper, if you judge in terms of the distance
between the respective semantics.  Python is not about trying to make
you think like a C programmer.

>And that is only my attempt to say in higher falutin language, that my point
>is experiental - not theoretical.  And not unlikely wrong.  Which you are
>well entitled to tell me. But I will definitely take it better if I think
>you have first taken in the practical point I am making.
>
>Michael did.

I think you're mislabeling other peoples' experience as "theoretical"
just because you don't happen to share those same experiences.  Kinda
like saying some people are theoretically experiencing starvation
right now.

It's a real experience (of frustration) trying to read complex code
written by others (or by oneself years previously).  The old behavior
of div made this even more frustrating.  This isn't just some ivory
tower view in comparison to which you represent all that is practical
and grounded.  I simply don't buy that premise.

>You haven't.

I've made my position clear:  you're not irrational for insisting
certain people at one time maybe had too much influence (maybe they
did), but beyond this, the technical arguments for changing the
behavior of div are in my view stronger than the arguments for
keeping it (you being one of many who preferred the status quo).

Your specific example of a "new confusion" drawn from Numeric did
not seem to speak to the issue in any direct way (I shouldn't
need to repeat why).

Kirby





From ajs@ix.netcom.com  Sat Oct 12 03:25:31 2002
From: ajs@ix.netcom.com (Arthur)
Date: Fri, 11 Oct 2002 22:25:31 -0400
Subject: [Edu-sig] re: Typed arrays (not about div)
Message-ID: <011001c27196$b4ba3350$9865fea9@arthur>

Kirby -

>Same issue, yet very clearly this has nothing whatever to do with the
behavior of div, either way.

Thanks for the change in subject line anyway.

But yikes and duh. What is so difficult about the point that I am trying to
make and you keep walking right past. A point that I am willingly to say
that I am blowing out of proportion, that I am missing for the trees, that
have misweighed and misjudged.  Once you tell me you see that it is there.

1/2 = 0 brings us to attention that there is numeric typing and that it
matters.  And reminds us of it now and again. And we go from there to deeper
matters if and when they arise.  With less surprise.

>To bring div into it only confuses the issue. 'a' is being coerced to an
int:

*I* am not bringing div into the behavior of typed arrays.  Why the hell
would I.  What I said was:

>Huh? under new "/"
>ouch - I should have seen that coming under old "/"

The "fun" I keep referring to is the fun of making the whirlygig go 'round.

What I am pointing to here is a practical point of the most fundamental
kind.  It *doesn't* make me right about the "/" operator.  But you keep
telling me you have *no* idea what I am saying, and I can't understand why.

Art





From urnerk@qwest.net  Sat Oct 12 03:57:24 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 11 Oct 2002 19:57:24 -0700
Subject: [Edu-sig] re: Typed arrays (not about div)
In-Reply-To: <011001c27196$b4ba3350$9865fea9@arthur>
Message-ID: <5.1.1.6.0.20021011193743.03ad96a0@pop.ptld.qwest.net>

At 10:25 PM 10/11/2002 -0400, Arthur wrote:

>*I* am not bringing div into the behavior of typed arrays.  Why the hell
>would I.  What I said was:
>
> >Huh? under new "/"
> >ouch - I should have seen that coming under old "/"

What you said was kind of elliptical (English major talk), but it
*does* mention "/", as if this were somehow relevant.

Forgive me, but I thought you were saying the old "/" would have
been an implied "heads up" (and as to why 'a' becomes 97 when
assigned to b[1] in Numeric? -- I don't think so).

After all, I'd asked you what a new gotcha associated the new
"/" might be, and this was your reply.  Now you say:  "*I* am
not bringing div into the behavior of typed arrays" -- but this
*was* a typed array, and you *were* showing it's behavior.
Forgive me for being confused.

Your argument seems to boil down to:  as long as stuff keeps
knocking me on the head, I'll remember to be careful.  So therefore
an intelligently designed language will deliberately knock me
on the head.

>The "fun" I keep referring to is the fun of making the whirlygig go 'round.

Lost ya.

What I did understand was:

"Reserve the right to mouth off only when a PEP addresses the
needs of beginners as the *prime* motivation of a foundation
level change." (you, in an earlier post).

And Tim recently says "A reasonable person could have concluded
that Guido was *primarily* motivated by that at the time."

So I see you as consistent in your mouthing off.  When it comes
to newbies and their experiences, you're entitled to a voice.
You've self-taught your way into becoming the guy behind a
sophisticated and one-of-a-kind 3D geometry package of which
you are rightly proud (takes a lot of smarts to do that, no
question).  And you have wisely limited your scope.  Nothing
irrational so far.

But I also see that, since then (since Guido was brought to the
div question by newbies), the mainline div discussion has taken
several twists and turns which eventually took it *out* of your
self-proclaimed territory.  It's not really about newbies and
their experiences any more.

>What I am pointing to here is a practical point of the most fundamental
>kind.  It *doesn't* make me right about the "/" operator.  But you keep
>telling me you have *no* idea what I am saying, and I can't understand why.
>
>Art

I've not said you have *no* idea what you're saying.  You have some
very definite ideas.  But you yourself have said it might not be
right.  So I'm agreeing with you there:  it's not right.

Thanks to Tim for the Mona Lisa URL (not sure I'm persuaded by the
GIF though -- almost *any* two faces, properly aligned, can be smoothly
connected by a good morphing program (but I'm sure there must be more
to it than that)).

Kirby





From Jason Cunliffe" <jasonic@nomadics.org  Sat Oct 12 04:26:53 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Fri, 11 Oct 2002 23:26:53 -0400
Subject: [Edu-sig] re: Typed arrays (not about div)
References: <5.1.1.6.0.20021011193743.03ad96a0@pop.ptld.qwest.net>
Message-ID: <000b01c2719f$3639eda0$6501a8c0@vaio>

> Thanks to Tim for the Mona Lisa URL (not sure I'm persuaded by the
> GIF though -- almost *any* two faces, properly aligned, can be smoothly
> connected by a good morphing program (but I'm sure there must be more
> to it than that)).

..and so too it seems can any edu-sig debate ;-)

./Jason



From lha2@columbia.edu  Sat Oct 12 11:24:35 2002
From: lha2@columbia.edu (Lloyd Hugh Allen)
Date: Sat, 12 Oct 2002 06:24:35 -0400
Subject: [Edu-sig] Re: rationals
References: <20021012022201.24113.21443.Mailman@mail.python.org>
Message-ID: <3DA7F863.4730A00E@mail.verizon.net>

> From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
> To: <edu-sig@python.org>
> Subject: RE: [Edu-sig] Re: rationals
> Date: Fri, 11 Oct 2002 18:25:24 -0700
>
> The biggest difference is that some floating-point calculations that will
> converge (disappear at 0 or converge on a fixed value) will not terminate in
> rational computation.
> 
> Since this sort of thing is not a very good way to use floats either, it
> should provoke more-appropriate numerical techniques.

Right--I thought that the more accepted technique was to (if we're going
for zero) pick an epsilon, and then exit when abs(arg)<epsilon (and if
we converge to something else, perhaps to pick an epsilon, and quit when
the last ten arguments were within epsilon of each other).

re: int/int --> float
Wha? But the definition of rational is the set of numbers that can be
represented as int/int! I understand the speediness argument, but
please, let us not go float unless we coerce there! I thought the whole
point of the rational thread was for "1/3" to simplify to something
meaningful.

Would it work (just throwing this out, having no real idea of how rats
are implemented elsewhere) to set each of the numerator and the
denominator to be a dict of the prime factorization thereof (assuming we
are working with <100 digit numerals)?

Or we could say that "int/int --> float, int//int --> int, and int///int
--> rational". But this feels like a dangerous road.

It'll be neat to have a set of numbers, though, where division is
cheaper than addition.


From michael.williams@st-annes.oxford.ac.uk  Sat Oct 12 14:24:13 2002
From: michael.williams@st-annes.oxford.ac.uk (Michael Williams)
Date: Sat, 12 Oct 2002 14:24:13 +0100
Subject: [Edu-sig] re: Types and true division (was Re: strange output
In-Reply-To: <00ec01c2717a$fdc6acc0$9865fea9@arthur>
Message-ID: <E62B7E12-DDE5-11D6-8E43-000393C5BF0A@st-annes.oxford.ac.uk>

On Saturday, October 12, 2002, at 12:07 AM, Arthur wrote:

>> As I understand it, you wish there'd be some acknowledgement that
>> at some point in the evolutionary trajectory, there was a time
>> when newbie concerns seemed to weigh too heavily in the balance.
>
> Actually what I *wish* is that Michael Williams ruled the world.

Me too!

> There I am in high asshole mode, contending with Williams of the "/" 
> issue.
>
> And in the course of a few exchanges he made the following clear:
>
> 1) Whether he liked or approved of me was not to a point.
> 2) That he understood my position, in substance.
> 2) That he understood my position , in substance (double credit, 
> because
> that seems to be of some importance to me)

Eek! I thought I did but you seem to have got your knickers in a bit of 
a twist over the course of this discussion, to the extent that no one 
really knows what you're talking about anymore. Maybe we should just 
drop the whole thing for the time being--the discussion has rather 
stagnated.

> 5) That he took something away from the exchange that was useful to 
> him.

Correct. :-)

-- 
Michael



From urnerk@qwest.net  Sat Oct 12 15:54:20 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Sat, 12 Oct 2002 07:54:20 -0700
Subject: [Edu-sig] Re: rationals
In-Reply-To: <3DA7F863.4730A00E@mail.verizon.net>
References: <20021012022201.24113.21443.Mailman@mail.python.org>
Message-ID: <5.1.1.6.0.20021012072402.02cd6e60@pop.ptld.qwest.net>

At 06:24 AM 10/12/2002 -0400, Lloyd Hugh Allen wrote:

>re: int/int --> float
>Wha? But the definition of rational is the set of numbers that can be
>represented as int/int! I understand the speediness argument, but
>please, let us not go float unless we coerce there!

An argument for int/int --> float is that this keeps preserves
closure between existing Python types and doesn't stick a big
"under construction sign" in the language for many versions to
come.  Then rationals can be added without disruption, as it'd
take new syntax (e.g. 1r/3) to invoke them, leaving older code
to run as it always has.

Given that you can go either way with int/int, I think the above
argument maybe tilts the balance in favor of int/int --> float.

Kirby

PS:

The idea of storing prime factors internally is not practical, as
nobody knows how to get the prime factors of really big integers
quickly, whereas rational arithmetic (including reducing to lowest
terms), *is* possible with these same big integers.  Requiring an
internal dict of primes would put a ceiling on rationals that
doesn't really need to be there.

The beauty of Euclid's Algorithm is it finds the gcd *without*
needing a prime factorization -- which is why it should be taught
earlier, so kids don't get the impression that those "factor trees"
are necessary when finding the gcd of two composites.

NOTE:

Althought it's true the pure Scheme supports int/int -> rational,
PLT Scheme goes with int/int -> float in many of its teaching
modes (this is a language where there *is* one of those
"environment switches" such as some have proposed for Python).

Examples:

Welcome to DrScheme, version 201.
Language: Advanced Student.
 > (/ 3 4)
0.75

Welcome to DrScheme, version 201.
Language: Textual (MzScheme, includes R5RS).
 > (/ 3 4)
3/4

Also, in J (evolved from APL), int/int --> float is the norm:

    3 % 4  NB.  % is the div operator
0.75

but make either argument rational, leaving the other int, and you
get a rational result:

   3x % 2
3r2
    3 % 2x
3r2

This latter mode could be true for Python too.

   >>> 3 / 4
0.75
   >>> 3r / 4
3/4r

The alternative you propose would look like this (I presume):

   >>> 3 / 4
3/4r
   >>> 3. / 4
0.75
   >>> 3 / 4.
0.75

Basically, it boils down to whether we have to use a . (dot) or an r
to coerce a float or rational result respectively.

Kirby





From guido@python.org  Sat Oct 12 16:19:49 2002
From: guido@python.org (Guido van Rossum)
Date: Sat, 12 Oct 2002 11:19:49 -0400
Subject: [Edu-sig] Re: rationals
In-Reply-To: Your message of "Sat, 12 Oct 2002 07:54:20 PDT."
 <5.1.1.6.0.20021012072402.02cd6e60@pop.ptld.qwest.net>
References: <20021012022201.24113.21443.Mailman@mail.python.org>
 <5.1.1.6.0.20021012072402.02cd6e60@pop.ptld.qwest.net>
Message-ID: <200210121519.g9CFJnG24616@pcp02138704pcs.reston01.va.comcast.net>

> Basically, it boils down to whether we have to use a . (dot) or an r
> to coerce a float or rational result respectively.

Except of course, in reality, the values are in variables, and
possibly we don't even know the types of those variables.

So then you can write

  (x * 1r) / y

to force a rational as long as x and y are ints or rationals; this
yields a float or complex if either x or y is that.

Aside: you could also use

  (x + 0r) / y

but if x is an IEEE float with the value -0, adding 0 turns it into
+0, while multiplying by 1 keeps the sign the same.  The distinction
between +0 and -0 may be important when it is the result of underflow.

For example:

  >>> x = -1.0
  >>> while x:
  ...     x = x*0.5
  ...
  >>> x
  -0.0
  >>> x*1
  -0.0
  >>> x+0
  0.0
  >>> x < 0
  False
  >>> 

--Guido van Rossum (home page: http://www.python.org/~guido/)


From ajs@ix.netcom.com  Sun Oct 13 03:02:47 2002
From: ajs@ix.netcom.com (Arthur)
Date: Sat, 12 Oct 2002 22:02:47 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output
Message-ID: <011d01c2725c$b3fd12e0$9865fea9@arthur>

Tim writes -

>Those folks were the first to bring up the issue forcefully, and Guido
>recognized the correctness of their conclusion at once.  Figuring out *why*
>the conclusion was correct stretched out over years, and Guido didn't move
>to change the language until after his brain caught up with his designer's
>intuition.

If you are saying that there was a totally serendipitous concurrence by
which where Randy's and Bruce's forceful statement of the more than obvious
issues related to 1/2 =0 and the newbie gets Guido to thinking, which
thinking then lights on:

"It has to do with substitutability of equal values with different types.
When a==A and b==B, then a+b
should be == A+B, at least within reasonable precision. "

OK, I guess, if you say so.

But we agree that one thing has absolutely nothing to do with the other.
Don't we? And we understand how when total serendipity comes into play, us
reasonably minded observers can get confused.  No?

So I'm forgivven.

Yes?

Art





From Jason Cunliffe" <jasonic@nomadics.org  Sun Oct 13 15:24:55 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Sun, 13 Oct 2002 10:24:55 -0400
Subject: [Edu-sig] EducationGuardian.co.uk  Schools  Before he had no future. Now he is a talented
Message-ID: <000501c272c4$4dfedce0$6501a8c0@vaio>


 http://education.guardian.co.uk/schools/story/0,5500,811079,00.html



From Jason Cunliffe" <jasonic@nomadics.org  Mon Oct 14 00:30:32 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Sun, 13 Oct 2002 19:30:32 -0400
Subject: [Edu-sig] Fwd: Which way did the chicken cross the road?
Message-ID: <001d01c27310$8630a0c0$6501a8c0@vaio>

A nice story from a discussion elsewhere on XML... 
[Assumptions, formatting, parsing components and their designers]

Joel Neely wrote:
> EWD told a wonderful story about giving an individualized test where
> the student is presented with a problem and is expected to "think
> aloud" while designing a solution on the board in the professor's
> presence.  The problem he described involves achieving a specified
> condition in a single pass across a one-dimensional array, where the
> obvious solution would sweep back-and-forth multiple times.  He had
> been accustomed (over many uses of this problem) to seeing the
> students end up with some processing upon elements in "increasing"
> (left-to-right) positional order.
> 
> He was surprised by a student from Israel, who developed an equally
> valid solution which swept the array in *decreasing* (right-to-left)
> positional order.  He wondered how much growing up reading r-to-l
> Hebrew instead of a l-to-r European language influenced the way the
> student conceptualized the problem.
> 
> Makes one wonder, doesn't it?!

./Jason



From guido@python.org  Mon Oct 14 00:59:39 2002
From: guido@python.org (Guido van Rossum)
Date: Sun, 13 Oct 2002 19:59:39 -0400
Subject: [Edu-sig] Fwd: Which way did the chicken cross the road?
In-Reply-To: Your message of "Sun, 13 Oct 2002 19:30:32 EDT."
 <001d01c27310$8630a0c0$6501a8c0@vaio>
References: <001d01c27310$8630a0c0$6501a8c0@vaio>
Message-ID: <200210132359.g9DNxdq09944@pcp02138704pcs.reston01.va.comcast.net>

> > He was surprised by a student from Israel, who developed an equally
> > valid solution which swept the array in *decreasing* (right-to-left)
> > positional order.  He wondered how much growing up reading r-to-l
> > Hebrew instead of a l-to-r European language influenced the way the
> > student conceptualized the problem.

Interesting...  I would have guessed that a Hebrew student would draw
an array like this:

  [9] [8] [7] [6] [5] [4] [3] [2] [1] [0]

i.e. use ascending indices in r-to-l order.  But apparently he drew it
like we do, and simply reversed his notion of "first" index.  Very
curious!  Nice quote, Jason!

--Guido van Rossum (home page: http://www.python.org/~guido/)


From dyoo@hkn.eecs.berkeley.edu  Mon Oct 14 05:17:05 2002
From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo)
Date: Sun, 13 Oct 2002 21:17:05 -0700 (PDT)
Subject: [Edu-sig] Fwd: Which way did the chicken cross the road?
In-Reply-To: <001d01c27310$8630a0c0$6501a8c0@vaio>
Message-ID: <Pine.LNX.4.44.0210132105250.3520-100000@hkn.eecs.berkeley.edu>


On Sun, 13 Oct 2002, Jason Cunliffe wrote:

> > He had been accustomed (over many uses of this problem) to seeing the
> > students end up with some processing upon elements in "increasing"
> > (left-to-right) positional order.
> >
> > He was surprised by a student from Israel, who developed an equally
> > valid solution which swept the array in *decreasing* (right-to-left)
> > positional order.

This reminds me of the electrifying shock I felt when I read through
snippets of code in TAOCP: in almost all of his inner loops, the index
variable decrements from n to 0, rather than from 0 to n.  The reason was
that a comparison against zero was slightly faster than a comparison
between arbitrary numbers!

(It doesn't take much to shock me.  *grin*)



From Jason Cunliffe" <jasonic@nomadics.org  Mon Oct 14 05:35:41 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Mon, 14 Oct 2002 00:35:41 -0400
Subject: [Edu-sig] Fwd: Which way did the chicken cross the road?
References: <001d01c27310$8630a0c0$6501a8c0@vaio>  <200210132359.g9DNxdq09944@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <002201c2733b$28f673a0$6501a8c0@vaio>

Guido van Rossum wrote:
> Interesting...  I would have guessed that a Hebrew student would draw
> an array like this:
>
>   [9] [8] [7] [6] [5] [4] [3] [2] [1] [0]
>
> i.e. use ascending indices in r-to-l order.  But apparently he drew it
> like we do, and simply reversed his notion of "first" index.  Very
> curious!  Nice quote, Jason!

Funny..

Yes math and most computer programs read from right to left, while Hebrew goes
the other way. So I suppose doing international math in Hebrew, or with Hebrew
writing habits offers at least two contrapuntal models.

Arabic is the same also isn't it? Home of algorithms ..hmmmm

And what about the vertical column oriented ones?
Japanese and Chinese used to be al vertical I think, but are they still?

leftbrain-rightbrain-inner~outer~brain

Graphic designers deal with this directional counterpoint logic too in
interesting ways:
'Text' demands that it follow the appropriate visual layout reading logic.
But it is often different from the visual flow rules adn momentum of logotypes,
images, icons and symbols.

Logo- and display types are right in the magic edge zone between readability [as
parsable symbol] and viewability [as compositional elements]. The 'distressed'
type movement of the 90's as practiced by David Carson and many others pushed
the enevlope of that. And anmaited typogtraphics, motion graphisc do too. TV
ads, Film Titles, 'Flash', Signs in the street, Web etc..  For those of us
exposed to modern media, the influential forces on our 'reading' habits are huge
and complex. Arguably, much broader than the influences and experience of our
writing habits.

Which is another extreme way if way of saying why computational literacy is so
important, and interesting, and why it makes strong modern sense to expose
everybody to it.


..Anyway Joel Neely from the Rebol list just sent me his story source:

<quote>
I think I heard Dijkstra speak of this several years ago.  It is
referenced in his book

    A Discipline of Programming
    (c) 1976, Prentice-Hall, Inc.
    Englewood Cliffs, NJ
    ISBN 0-13-215871-X

on page 116 under "The Problem of the Dutch National Flag".
</quote>


./Jason



From tim.one@comcast.net  Mon Oct 14 05:53:23 2002
From: tim.one@comcast.net (Tim Peters)
Date: Mon, 14 Oct 2002 00:53:23 -0400
Subject: [Edu-sig] Fwd: Which way did the chicken cross the road?
In-Reply-To: <Pine.LNX.4.44.0210132105250.3520-100000@hkn.eecs.berkeley.edu>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEFNBLAB.tim.one@comcast.net>

[Danny Yoo]
> This reminds me of the electrifying shock I felt when I read through
> snippets of code in TAOCP: in almost all of his inner loops, the index
> variable decrements from n to 0, rather than from 0 to n.  The reason was
> that a comparison against zero was slightly faster than a comparison
> between arbitrary numbers!

Many C loops in Python's implementation are written the same way, for the
same reason.  In fact, the HW you're probably using automatically sets a
"was the result 0?" flag on every subtraction, so that no explicit
comparison instruction is needed then.  There's nothing like learning
assembly language for helping you to focus on the wrong things <wink>.

the-world-would-be-a-better-place-if-uncle-don-used-python-ly y'rs
    = tim



From w.aprile@interaction-ivrea.it  Mon Oct 14 08:24:23 2002
From: w.aprile@interaction-ivrea.it (Walter A. Aprile)
Date: Mon, 14 Oct 2002 09:24:23 +0200
Subject: [Edu-sig] the legality of naked expressions
Message-ID: <DMECLINEEGEBEGKDLNCJKECPCFAA.w.aprile@interaction-ivrea.it>

Hello,
	I have noticed (or rather: my students have painfully noticed) that in
Python
it is legal but confusing to have certain expressions as statements. One
that seems
to bite people regularly in my class is the
function-reference-that-is-not-a-function-call:

def bemoan():
	print "Woe is me!"

a=1

if (a==1):
	bemoan
else:
	print "I am happy!"

	When run this code, obviously and correctly, produces absolutely
nothing --- but
puzzlement. Demonstrating that, at the prompt,

>>> bemoan
<function bemoan at 0x008B3C40>

	helps somewhat. Is there perhaps some warning that can be turned on in the
interpreter?
In the same vein, certain students find it perplexing that

if (a==1):
	1+1
else:
	2+2

	is perfectly legal yet looks a bit pointless - even if I realize that
__add__ could be
performing untold magic behind the scenes.

	I hope that I am not rehashing an old point here, but I haven't found this
in the PEPs. Thank you for your attention,

		Walter



From guido@python.org  Mon Oct 14 13:27:26 2002
From: guido@python.org (Guido van Rossum)
Date: Mon, 14 Oct 2002 08:27:26 -0400
Subject: [Edu-sig] the legality of naked expressions
In-Reply-To: Your message of "Mon, 14 Oct 2002 09:24:23 +0200."
 <DMECLINEEGEBEGKDLNCJKECPCFAA.w.aprile@interaction-ivrea.it>
References: <DMECLINEEGEBEGKDLNCJKECPCFAA.w.aprile@interaction-ivrea.it>
Message-ID: <200210141227.g9ECRQO11685@pcp02138704pcs.reston01.va.comcast.net>

Try pychecker.  It warns about these.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From tim.one@comcast.net  Tue Oct 15 02:13:46 2002
From: tim.one@comcast.net (Tim Peters)
Date: Mon, 14 Oct 2002 21:13:46 -0400
Subject: [Edu-sig] the legality of naked expressions
In-Reply-To: <DMECLINEEGEBEGKDLNCJKECPCFAA.w.aprile@interaction-ivrea.it>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEKCBLAB.tim.one@comcast.net>

[Walter A. Aprile]
> ...
> In the same vein, certain students find it perplexing that
>
> if (a==1):
> 	1+1
> else:
> 	2+2
>
> is perfectly legal yet looks a bit pointless - even if I realize that
> __add__ could be performing untold magic behind the scenes.

If you type that into an interactive Python session, and a is defined,
you'll find that it actually displays one of 2 or 4.  That's a "deeper
reason" here.  The same thing that's confusing your students is also
delighting them when they do stuff like

>>> 1+2
3
>>>

interactively.  In fact, in its *very* early days, Python printed the value
of "raw expression statements" in interactive mode (which it still does)
*and* in batch mode (which it no longer does).

>>> for i in range(10):
...     i*i
...
0
1
4
9
16
25
36
49
64
81
>>>



From tim.one@comcast.net  Tue Oct 15 03:04:02 2002
From: tim.one@comcast.net (Tim Peters)
Date: Mon, 14 Oct 2002 22:04:02 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output
In-Reply-To: <011d01c2725c$b3fd12e0$9865fea9@arthur>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEKEBLAB.tim.one@comcast.net>

[Tim]
>> Those folks were the first to bring up the issue forcefully, and Guido
>> recognized the correctness of their conclusion at once.  Figuring out
>> *why* the conclusion was correct stretched out over years, and Guido
>> didn't move to change the language until after his brain caught up
>> with his designer's intuition.

[Art]
> If you are saying that there was a totally serendipitous concurrence by
> which where Randy's and Bruce's forceful statement of the more
> than obvious issues related to 1/2 =0 and the newbie gets Guido to
> thinking, which thinking then lights on:

I don't think what I wrote needs rewording to be clear, and it certainly
won't be clarified by loading up on hyperbole ("totally serendipitous",
"more than obvious", "absolutely nothing" (below)).

> "It has to do with substitutability of equal values with different types.
> When a==A and b==B, then a+b should be == A+B, at least within
> reasonable precision. "
>
> OK, I guess, if you say so.

Minus the hyperbole, that's my view of it.

> But we agree that one thing has absolutely nothing to do with the other.
> Don't we?

I don't know what this means:  there was certainly cause and effect here, so
"absolutely nothing" can't apply.  Design issues are complex, and I doubt
Guido believes that "1/3 == 0" was doing newbies a favor regardless of how
much it pains experienced programmers (in fact, I pissed away an hour this
weeked tracing a subtle bug to exactly that!  the expression exp(-x*x/2) was
subtly wrong in some cases of large x, and it turned out x was being passed
as int in these case several layers above).  There are multiple reasons for
the change, but the one that carries most force now boils down to the
substitutability argument Guido summarized.  Newbies aren't immune from that
bad consequences of that either, of course, although they're far less aware
of them as such.

> And we understand how when total serendipity comes into play, us
> reasonably minded observers can get confused.  No?
>
> So I'm forgivven.
>
> Yes?

I never damned you, Art -- there's nothing to forgive.  You do some mondo
cool things with Python, and outside of this particular topic I value your
presence in our little community.



From ajs@ix.netcom.com  Tue Oct 15 07:00:56 2002
From: ajs@ix.netcom.com (Arthur)
Date: Tue, 15 Oct 2002 02:00:56 -0400
Subject: [Edu-sig] re: Types and true division (was Re: strange output
Message-ID: <01ed01c27410$3c3aa410$9865fea9@arthur>

Tim writes -

>I value your presence in our little community.

Glad to hear that.

Because, porting PyGeo to Ocaml(?) was beginning to sound like quite the
pain-in-the-ass.
 :)

Art






From hancock@anansispaceworks.com  Tue Oct 15 09:12:04 2002
From: hancock@anansispaceworks.com (Terry Hancock)
Date: Tue, 15 Oct 2002 01:12:04 -0700
Subject: [Edu-sig] Fwd: Which way did the chicken cross the road?
In-Reply-To: <002201c2733b$28f673a0$6501a8c0@vaio>
References: <001d01c27310$8630a0c0$6501a8c0@vaio> <200210132359.g9DNxdq09944@pcp02138704pcs.reston01.va.comcast.net> <002201c2733b$28f673a0$6501a8c0@vaio>
Message-ID: <E181Mpm-0000sN-00@scaup.mail.pas.earthlink.net>

On Sunday 13 October 2002 09:35 pm, Jason Cunliffe wrote:
> And what about the vertical column oriented ones?
> Japanese and Chinese used to be al vertical I think, but are they still?

Serious text (e.g. in novels, manga, letters, etc.) in Japanese is still 
written vertically, starting from the upper right-hand corner and reading 
down, and then to the left. Horizontal text (reading left-to-right) is used 
in many technical and mathematical texts, presumeably for ease of mixing with 
Western scripts and mathematical notation.  In my experience, horizontal text 
is easy to set with Japanese variants of LaTeX, but correctly setting 
vertical text still eludes me.

I believe the same is true of Chinese, but I don't have much experience with 
that.

Interestingly, since Japanese is written at the word or syllable level, it 
causes less dissonance to read it in an unusual direction, and context often 
supercedes convention.  I've noticed vehicles labelled front-to-back 
regardless of which direction that implies. They extend this practice to 
English letters, too, evidently, as I have seen a picture of a Taxi labeled 
"IXAT" on the right-hand side of the vehicle (the left-hand side would read 
"TAXI" as you'd expect). Same with ships.  (If you think about it, this is 
more comfortable since the text will naturally scroll in the right direction 
as the vehicle moves).  (Caveat -- I've never been to Japan, so I'm looking 
at media sources only).

More traditional Japanese text, such as on signs will sometimes read 
horizontally, right-to-left. Presumeably this can be thought of as a series 
of columns only one-character high.  The left-to-right "truly horizontal" 
mode was introduced from the West.

Cheers,
Terry
-- 
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com


From Jason Cunliffe" <jasonic@nomadics.org  Tue Oct 15 19:58:41 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Tue, 15 Oct 2002 14:58:41 -0400
Subject: [Edu-sig] Fwd: Which way did the chicken cross the road?
References: <001d01c27310$8630a0c0$6501a8c0@vaio> <200210132359.g9DNxdq09944@pcp02138704pcs.reston01.va.comcast.net> <002201c2733b$28f673a0$6501a8c0@vaio> <E181Mpm-0000sN-00@scaup.mail.pas.earthlink.net>
Message-ID: <001701c2747c$e0eeac60$6501a8c0@vaio>

Thanks Terry.

I love the TAXI story..

Q: Which way did the chicken cross the road?
A: Depends which way you are looking!


./Jason



From pobrien@orbtech.com  Fri Oct 18 15:53:19 2002
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Fri, 18 Oct 2002 09:53:19 -0500
Subject: [Edu-sig] Slightly OT: O'Reilly article
Message-ID: <200210180953.19589.pobrien@orbtech.com>

This might be slightly off-topic, but considering the things Jason sends =
our=20
way (just kidding!), I figured "what the heck". Anyway, O'Reilly just=20
published an article of mine on Beginning Python for Bioinformatics. Whil=
e=20
the target audience is the biology community, I think the content is a pr=
etty=20
good introduction to Python in general. And, who knows, you might find th=
e=20
biology stuff interesting as well. So, here is a link to the article:

http://www.onlamp.com/pub/a/python/2002/10/17/biopython.html

--=20
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------



From urnerk@qwest.net  Fri Oct 18 16:10:35 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 18 Oct 2002 08:10:35 -0700
Subject: [Edu-sig] Slightly OT: O'Reilly article
In-Reply-To: <200210180953.19589.pobrien@orbtech.com>
Message-ID: <5.1.1.6.0.20021018080828.02d68d10@pop.ptld.qwest.net>

At 09:53 AM 10/18/2002 -0500, you wrote:
>This might be slightly off-topic, but considering the things Jason sends our
>way (just kidding!), I figured "what the heck".


I found that article "hyper relevant" to edu-sig -- *exactly* the
kind of stuff I'm looking for re Python in education.  Good job.

This is one of those simple-yet-useful applications of a programmming
language that teachers are always desperate to come up with.

Kirby





From guido@python.org  Fri Oct 18 16:28:18 2002
From: guido@python.org (Guido van Rossum)
Date: Fri, 18 Oct 2002 11:28:18 -0400
Subject: [Edu-sig] Slightly OT: O'Reilly article
In-Reply-To: Your message of "Fri, 18 Oct 2002 09:53:19 CDT."
 <200210180953.19589.pobrien@orbtech.com>
References: <200210180953.19589.pobrien@orbtech.com>
Message-ID: <200210181528.g9IFSIC20607@pcp02138704pcs.reston01.va.comcast.net>

> http://www.onlamp.com/pub/a/python/2002/10/17/biopython.html

I've added the link to http://www.python.org/doc/Newbies.html

Everybody, please review that page -- are there any missing resources?
Beginners books that I should list?

--Guido van Rossum (home page: http://www.python.org/~guido/)


From Jason Cunliffe" <jasonic@nomadics.org  Fri Oct 18 22:13:07 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Fri, 18 Oct 2002 17:13:07 -0400
Subject: [Edu-sig] Slightly OT: O'Reilly article
References: <200210180953.19589.pobrien@orbtech.com>  <200210181528.g9IFSIC20607@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <000901c276eb$281126c0$6501a8c0@vaio>

> Everybody, please review that page -- are there any missing resources?
> Beginners books that I should list?

I think Wesley Chun's "Core Python Programming" is a good 'beginner' book.
Slow enough to drive some of you crazy ;^)
The author assumes little, but never talks down. He takes care to explain
everything, especially background ideas and jargon. The book build-up very
gently for the first half. Brief mini tutorials and/or exercise questions [with
code answers] at the end of each chapter. The copy I have is good for 1.6 and
anticipates 2.0

Two quickie random excerpts ...

Chapter 2: Getting Started
2.8 Lists and Tuples
    Lists and tuples can be thought of as generic "buckets" with which to hold
an arbitrary number of arbitrary Python objects. The items are ordered and
accessed via indexed offsets, similar to arrays, except that lists and tuples
can store different types of objects.
    The main difference between lists and tuples are: Lists are enclosed in  [ ]
and their elements and size can be changed, while tuples are enclosed in
parentheses ( ) and cannot be updated. Tuples can be thought of for now as
"read-only" lists. Subsets can be taken with the slice operator [] and [:] in
the same manner as strings.
<code examples follow.
<in-depth discussion about uses and differences of list and tuples comes later
on. >


Chapter 10: Errors and Exceptions
10.1 Exceptions
10.1.1 Errors
    Before we get into details about what exceptions are, let us review what
errors are. In the context of software, errors are either syntactical or logical
in nature. Syntax errors indicate errors with the construct of the software and
cannot be executed by the interpreter or compiled correctly. These errors must
be repaired before execution can occur.
    Once programs are semantically correct, the only errors which remain are
logical. Logical errors can be caused by lack of invalid input, or, in other
cases, by the logic's not being able to generate, calculate, or otherwise
produce the desired results based on the input. These errors are sometimes known
as domain and range errors, respectively.
    When errors are detected by Python, the interpreter indicates that it has
reached a point where continuing to execute the current flow is no longer
possible. This is where exceptions come in into the picture.

./Jason



From Jason Cunliffe" <jasonic@nomadics.org  Sat Oct 19 16:52:12 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Sat, 19 Oct 2002 11:52:12 -0400
Subject: [Edu-sig] Slightly OT: O'Reilly article
References: <200210180953.19589.pobrien@orbtech.com>
Message-ID: <003701c27787$7d566720$6501a8c0@vaio>

http://www.onlamp.com/pub/a/python/2002/10/17/biopython.html

Patrick

Thanks very much for a great article :-)
./Jason 



From Jason Cunliffe" <jasonic@nomadics.org  Sat Oct 19 17:00:15 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Sat, 19 Oct 2002 12:00:15 -0400
Subject: Tutorials => was {Re: [Edu-sig] Slightly OT: O'Reilly article}
References: <200210180953.19589.pobrien@orbtech.com>  <200210181528.g9IFSIC20607@pcp02138704pcs.reston01.va.comcast.net> <000901c276eb$281126c0$6501a8c0@vaio> <003101c27787$5b8c3200$6501a8c0@vaio>
Message-ID: <003f01c27788$9d450900$6501a8c0@vaio>

> Here's a funny one:
> 
> http://uselesspython.com/JoeUselessWritesAProgram.html

See also the varied list of tutorials:

http://uselesspython.com/tutorials.html

which includes:

Non-Programmers Tutorial For Python
by Josh Cogliati
http://www.honors.montana.edu/~jjc/easytut/easytut/easytut.html

./Jason



From pobrien@orbtech.com  Sat Oct 19 16:59:20 2002
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Sat, 19 Oct 2002 10:59:20 -0500
Subject: [Edu-sig] Slightly OT: O'Reilly article
In-Reply-To: <003701c27787$7d566720$6501a8c0@vaio>
References: <200210180953.19589.pobrien@orbtech.com> <003701c27787$7d566720$6501a8c0@vaio>
Message-ID: <200210191059.20225.pobrien@orbtech.com>

On Saturday 19 October 2002 10:52 am, Jason Cunliffe wrote:
> http://www.onlamp.com/pub/a/python/2002/10/17/biopython.html
>
> Patrick
>
> Thanks very much for a great article :-)

You are very welcome. I plan to write more. In fact, I just submitted one=
 to=20
IBM for their developerWorks site on the topic of Python Persistence=20
Management. Basically, I cover just about everything you'd want to know a=
bout=20
pickling, without turning it into a book. I seem to have trouble writing =
an=20
article in less than 4,000 words. :-)

--=20
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------



From Jason Cunliffe" <jasonic@nomadics.org  Sat Oct 19 17:07:49 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Sat, 19 Oct 2002 12:07:49 -0400
Subject: [Edu-sig] Slightly OT: O'Reilly article
References: <200210180953.19589.pobrien@orbtech.com> <003701c27787$7d566720$6501a8c0@vaio> <200210191059.20225.pobrien@orbtech.com>
Message-ID: <004801c27789$ac249a20$6501a8c0@vaio>

Patrick K. O'Brien wrote:
> You are very welcome. I plan to write more. In fact, I just submitted one to
> IBM for their developerWorks site on the topic of Python Persistence
> Management. Basically, I cover just about everything you'd want to know about
> pickling, without turning it into a book. I seem to have trouble writing an
> article in less than 4,000 words. :-)

Good news, and that's a great topic.. 
I hope you find some way to introduce Berkeley bsddb and standalone ZODB.

best wishes
./Jason



From dyoo@hkn.eecs.berkeley.edu  Sat Oct 19 20:09:42 2002
From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo)
Date: Sat, 19 Oct 2002 12:09:42 -0700 (PDT)
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for newbies?]
Message-ID: <Pine.LNX.4.44.0210191318090.1645-100000@hkn.eecs.berkeley.edu>

> Everybody, please review that page -- are there any missing resources?
> Beginners books that I should list?

Hi Guido,


Would it be good to put Useless Python on the Newbies page too?

    http://uselesspython.com



From guido@python.org  Sat Oct 19 21:27:30 2002
From: guido@python.org (Guido van Rossum)
Date: Sat, 19 Oct 2002 16:27:30 -0400
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for newbies?]
In-Reply-To: Your message of "Sat, 19 Oct 2002 12:09:42 PDT."
 <Pine.LNX.4.44.0210191318090.1645-100000@hkn.eecs.berkeley.edu>
References: <Pine.LNX.4.44.0210191318090.1645-100000@hkn.eecs.berkeley.edu>
Message-ID: <200210192027.g9JKRU828618@pcp02138704pcs.reston01.va.comcast.net>

> Would it be good to put Useless Python on the Newbies page too?
> 
>     http://uselesspython.com

Sorry, it doesn't really strike me as a strong newbie resource.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From rob@uselesspython.com  Sat Oct 19 22:06:56 2002
From: rob@uselesspython.com (Rob)
Date: Sat, 19 Oct 2002 16:06:56 -0500
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for newbies?]
In-Reply-To: <200210192027.g9JKRU828618@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <MPEOIFCOPCIHEDCLBLPBCEIFCIAA.rob@uselesspython.com>

> > Would it be good to put Useless Python on the Newbies page too?
> >
> >     http://uselesspython.com
>
> Sorry, it doesn't really strike me as a strong newbie resource.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>

Since it has come up....

Would it be a strong newbie resource if improved in certain ways? Or is it
just not a great idea?

Useless Python has received a few hundred "thanks for existing" email
messages from newbies, despite what I consider to be grossly-inadequate
management on my own part. This is the reason the site remains in place so
far.

Since the site is an out-of-pocket expense stemming from my love of the
language, I would appreciate constructive advice.

thanks,
Rob Andrews
Useless Python




From guido@python.org  Sat Oct 19 22:07:54 2002
From: guido@python.org (Guido van Rossum)
Date: Sat, 19 Oct 2002 17:07:54 -0400
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for newbies?]
In-Reply-To: Your message of "Sat, 19 Oct 2002 16:06:56 CDT."
 <MPEOIFCOPCIHEDCLBLPBCEIFCIAA.rob@uselesspython.com>
References: <MPEOIFCOPCIHEDCLBLPBCEIFCIAA.rob@uselesspython.com>
Message-ID: <200210192107.g9JL7t628813@pcp02138704pcs.reston01.va.comcast.net>

> > > Would it be good to put Useless Python on the Newbies page too?
> > >
> > >     http://uselesspython.com
> >
> > Sorry, it doesn't really strike me as a strong newbie resource.
> 
> Since it has come up....
> 
> Would it be a strong newbie resource if improved in certain ways? Or
> is it just not a great idea?
> 
> Useless Python has received a few hundred "thanks for existing"
> email messages from newbies, despite what I consider to be
> grossly-inadequate management on my own part. This is the reason the
> site remains in place so far.
> 
> Since the site is an out-of-pocket expense stemming from my love of
> the language, I would appreciate constructive advice.

I think the idea is great, but the presentation is a bit offputting.
I realize that that may be part of the gimmick of the site -- but
still...  E.g. What's with the 16 numbered lists?  How am I supposed
to navigate my way around there?  Just click random links until
something useful pops up?  Etc.  Maybe you can make the home page a
bit more useful for first-time visitors.

PS if I don't respond further, it's because I'm about to disappear for
a week.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From Jason Cunliffe" <jasonic@nomadics.org  Sat Oct 19 22:47:58 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Sat, 19 Oct 2002 17:47:58 -0400
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for newbies?]
References: <MPEOIFCOPCIHEDCLBLPBCEIFCIAA.rob@uselesspython.com>
Message-ID: <000f01c277b9$3114d860$6501a8c0@vaio>

Guido
> >   http://uselesspython.com
> >
> > Sorry, it doesn't really strike me as a strong newbie resource.

I am surprised by that.
What kind of newbie, is the *key* question to ask?

I would imagine uselesspython is very welcome site, especially the tutorials
page which I proposed earlier. The informal, irreverent tone and evident
self-deprecating sense of humor throughtout will turn off some, but surely
attract others. There is nothing to intimidate here. The personal tone of labor
of love, and slightly wacky mood is great. The real message is simple and
important:
"Hey you too can program Python and its fun!" Pefect for some newbies imho.

Rob
> Useless Python has received a few hundred "thanks for existing" email
> messages from newbies, despite what I consider to be grossly-inadequate
> management on my own part. This is the reason the site remains in place so
> far.

Rob, please can you characterize your readers for us:

What level, age, response ?
What's most popular, what sort of questions ?

> Since the site is an out-of-pocket expense stemming from my love of the
> language, I would appreciate constructive advice.

Thanks, and please do keep it up.
and since you asked the conventional designer in me says

Navigation 1:
A direct short site intro and clear table of contents might be a good idea.
Since some pages are longish, repeat navbar at the bottom discretely.
Make the "Useless Python" logotype a home page button.

Navigation 2:
The un-identified 16 numbered source page links at the top could be improved.
Any kind of table of contents, tabbed navbar, simple row of names right under
the main menu or blog-style down the left margin in small list.

Also once one has clicked it should be clear which page of the 16 one is one.
Likewise which have already been visited. This can be done using a couple of
lines of simple CSS in an external linked file so you can quickly tweak the
results to your satisfaction.


Navigation 3:
Rollover alternate graphics for your main menu would them clearly buttons not
just text. [yeah its eye candy, but it helps]

Master Index:
A simple large table page with links to everything on the site, and one-line
description would be good. At-a-glance what's here.

Yeah all boring stuff I know.
./Jason




From dcraig@cris.com  Sat Oct 19 23:00:03 2002
From: dcraig@cris.com (David Craig)
Date: Sat, 19 Oct 2002 15:00:03 -0700
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for newbies?]
References: <MPEOIFCOPCIHEDCLBLPBCEIFCIAA.rob@uselesspython.com>  <200210192107.g9JL7t628813@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <001f01c277ba$e3d05960$bd010140@dpslq01>

Gentlemen,

I respectfully disagree.  I am a relative newbie and I find that with the
exceptions of tutorials, I spend more time at Useless Python than anywhere
else.  It gives me great challenges and examples that help me to practice
writing code without being discouraged.  I find it highly helpful and Rob, I
thank you for your efforts.  Please keep it up.

Dave Craig
----- Original Message -----
From: "Guido van Rossum" <guido@python.org>
To: "Rob" <rob@uselesspython.com>
Cc: "Danny Yoo" <dyoo@hkn.eecs.berkeley.edu>; <edu-sig@python.org>
Sent: Saturday, October 19, 2002 2:07 PM
Subject: Re: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for
newbies?]


> > > > Would it be good to put Useless Python on the Newbies page too?
> > > >
> > > >     http://uselesspython.com
> > >
> > > Sorry, it doesn't really strike me as a strong newbie resource.
> >
> > Since it has come up....
> >
> > Would it be a strong newbie resource if improved in certain ways? Or
> > is it just not a great idea?
> >
> > Useless Python has received a few hundred "thanks for existing"
> > email messages from newbies, despite what I consider to be
> > grossly-inadequate management on my own part. This is the reason the
> > site remains in place so far.
> >
> > Since the site is an out-of-pocket expense stemming from my love of
> > the language, I would appreciate constructive advice.
>
> I think the idea is great, but the presentation is a bit offputting.
> I realize that that may be part of the gimmick of the site -- but
> still...  E.g. What's with the 16 numbered lists?  How am I supposed
> to navigate my way around there?  Just click random links until
> something useful pops up?  Etc.  Maybe you can make the home page a
> bit more useful for first-time visitors.
>
> PS if I don't respond further, it's because I'm about to disappear for
> a week.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig@python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
>



From rob@uselesspython.com  Sat Oct 19 23:16:19 2002
From: rob@uselesspython.com (Rob)
Date: Sat, 19 Oct 2002 17:16:19 -0500
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for newbies?]
In-Reply-To: <000f01c277b9$3114d860$6501a8c0@vaio>
Message-ID: <MPEOIFCOPCIHEDCLBLPBEEIGCIAA.rob@uselesspython.com>

> I would imagine uselesspython is very welcome site, especially
> the tutorials
> page which I proposed earlier. The informal, irreverent tone and evident
> self-deprecating sense of humor throughtout will turn off some, but surely
> attract others. There is nothing to intimidate here. The personal
> tone of labor
> of love, and slightly wacky mood is great. The real message is simple and
> important:
> "Hey you too can program Python and its fun!" Pefect for some
> newbies imho.
>

This seems to be a major point of appeal. I toned down the wacky-ness a
while back, and received numerous requests to change it back.

> Rob
> > Useless Python has received a few hundred "thanks for existing" email
> > messages from newbies, despite what I consider to be grossly-inadequate
> > management on my own part. This is the reason the site remains
> in place so
> > far.
>
> Rob, please can you characterize your readers for us:
>
> What level, age, response ?
> What's most popular, what sort of questions ?
>

The only ones who have mentioned their ages seem to be in their early to
middle teens. However, responses seem to range from young people learning
Python as a first language, college/graduate students who think Python is "a
breath of fresh air", and professional programmers dabbling in Python for
the first time.

Only a few have asked questions of me upon discovery of the site, and I have
consistently suggested the Python Tutor list as an appropriate place to ask
programming questions. I have learned quite a bit, but I know where those
questions belong. (And, despite my own fingerprints all over the site, I
still consider it a direct side-effect of the Python Tutor email list.)

> > Since the site is an out-of-pocket expense stemming from my love of the
> > language, I would appreciate constructive advice.
>
> Thanks, and please do keep it up.
> and since you asked the conventional designer in me says
>
> Navigation 1:

I feel that navigation is the second weakest element of the site, and have
been giving a lot of thought to how to address the matter without messing up
the experience too much. The site's single greatest point of weakness is
that it lacks automation and is maintained manually by one person.
Automating the site could well be the means to resolving both the navigation
and management issues.

The tricky part is that the original design concept was indeed for the user
to rummage through the randomly-ordered source files. This didn't seem as
problematic when there were only a few dozen source files, but with the next
major update the number should increase to well over 200. At this size, I
can certainly understand the frustrations expressed by a few. (Fewer than
half a dozen to date, including today's comments.)

regards,
Rob




From tim.one@comcast.net  Sun Oct 20 00:19:37 2002
From: tim.one@comcast.net (Tim Peters)
Date: Sat, 19 Oct 2002 19:19:37 -0400
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for
 newbies?]
In-Reply-To: <200210192027.g9JKRU828618@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEMJBMAB.tim.one@comcast.net>

[Guido van Rossum, on http://uselesspython.com]
> Sorry, it doesn't really strike me as a strong newbie resource.

Maybe that's why it's successful <wink>.  Useless Python started
spontaneously on the Tutor List, and has been very popular there ever since.
People love that it's not all dead serious, and the organized link
collections linked to at the top ("Getting Started", "Python Challenge",
"Tutorials", etc) are really top-notch by any measure -- check 'em out.

Rob, keep it up!  I expect Guido will grow fonder of it when he gets back
from his trip and has more time to click around.  Heck, stumbling into
treasures is part of the fun of the site!

precognitively-channeling-ly y'rs  - tim



From hancock@anansispaceworks.com  Sun Oct 20 04:19:26 2002
From: hancock@anansispaceworks.com (Terry Hancock)
Date: Sat, 19 Oct 2002 20:19:26 -0700
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for newbies?]
In-Reply-To: <200210192027.g9JKRU828618@pcp02138704pcs.reston01.va.comcast.net>
References: <Pine.LNX.4.44.0210191318090.1645-100000@hkn.eecs.berkeley.edu> <200210192027.g9JKRU828618@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <E1836eF-0004XN-00@albatross.prod.itd.earthlink.net>

On Saturday 19 October 2002 01:27 pm, Guido van Rossum wrote:
> > Would it be good to put Useless Python on the Newbies page too?
> >
> >     http://uselesspython.com
>
> Sorry, it doesn't really strike me as a strong newbie resource.

I respectfully disagree -- I think I'm still enough of a newbie to
speak from personal impressions. I've spent less time there than
I would like, but what I did spend was very pleasant.

It goes a long way to showing the sorts of things one can do
with Python, which is one of the first things a newbie wants to
know: "Why should I learn this? What's it good for?"  Seeing
easy or compact solutions for problems which seem hard
is a great builder of confidence in the language.  Furthermore,
the site is full of ideas about how to tackle a problem, which
is something else newbies are often looking for.

Now, I'm not a newbie to programming, but only to Python
(and since I've been at it a year or so, I'm not so much of a
newbie anymore), but I found it very invigorating, if a bit
misnamed ;-). The light humor, though, makes it a lot less
threatening.

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com


From tim.one@comcast.net  Sun Oct 20 04:31:45 2002
From: tim.one@comcast.net (Tim Peters)
Date: Sat, 19 Oct 2002 23:31:45 -0400
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for
 newbies?]
In-Reply-To: <E1836eF-0004XN-00@albatross.prod.itd.earthlink.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENEBMAB.tim.one@comcast.net>

[Terry Hancock, also defends http://uselesspython.com ]

Note that Guido added a link to this, at

    http://www.python.org/doc/Newbies.html

before going on his trip.  So it's safe for at least a week <wink>.


From guido@python.org  Sun Oct 20 12:11:00 2002
From: guido@python.org (Guido van Rossum)
Date: Sun, 20 Oct 2002 07:11:00 -0400
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for newbies?]
In-Reply-To: Your message of "Sat, 19 Oct 2002 20:19:26 PDT."
 <E1836eF-0004XN-00@albatross.prod.itd.earthlink.net>
References: <Pine.LNX.4.44.0210191318090.1645-100000@hkn.eecs.berkeley.edu> <200210192027.g9JKRU828618@pcp02138704pcs.reston01.va.comcast.net>
 <E1836eF-0004XN-00@albatross.prod.itd.earthlink.net>
Message-ID: <200210201111.g9KBB0D05951@pcp02138704pcs.reston01.va.comcast.net>

OK, OK.  Useless Python isn't!  I've added it to the list of "online
tutorials" (for want of a better category).

--Guido van Rossum (home page: http://www.python.org/~guido/)


From Louis.Bertrand@durhamc.on.ca  Mon Oct 21 13:55:52 2002
From: Louis.Bertrand@durhamc.on.ca (Louis Bertrand)
Date: Mon, 21 Oct 2002 08:55:52 -0400
Subject: [Edu-sig] Electronic assignment submission?
Message-ID: <F2C8C13002B9CB428ABC33A605E3762099DBBA@osms01.oncampus.local>

Not necessarily a Python question (unless the solution is implemented in =
Python).

I'm looking for a system to hand in programming assignments =
electronically, and return them to the students (IMHO, a trickier =
problem). Web, email or other, ideally running on a freenix server =
(BSD).

It would be fun to write my own, and I've been looking at pulling mail =
attachments via IMAP and the MIME tools, or some sort of Web script.
But if it's already out there...

Any leads?

Thanks
 --Louis


From rhseabrook@aacc.edu  Mon Oct 21 15:08:04 2002
From: rhseabrook@aacc.edu (Seabrook, Richard)
Date: Mon, 21 Oct 2002 10:08:04 -0400
Subject: [Edu-sig] Electronic assignment submission?
Message-ID: <B4B00B1CCF9795449A4AC24C63AAFFB493D555@aacc-mail1.aacc.cc.md.us>

 

-----Original Message-----
From: Louis Bertrand
To: edu-sig@python.org
Sent: 10/21/02 8:55 AM
Subject: [Edu-sig] Electronic assignment submission?

Not necessarily a Python question (unless the solution is implemented in
Python).

I'm looking for a system to hand in programming assignments
electronically, and return them to the students (IMHO, a trickier
problem). Web, email or other, ideally running on a freenix server
(BSD).

It would be fun to write my own, and I've been looking at pulling mail
attachments via IMAP and the MIME tools, or some sort of Web script.
But if it's already out there...

=======================================================

For just turning them in and you sending back comments, regular
email seems best -- as long as they include the program text
in the body of the message -- processing attachments usually requires
extra steps.  If you want to test the program however, the message
should arrive at the machine where you can run the test -- and you 
need to be able to get the program out in runnable form in as few
steps as possible. With only a few programs coming in it doesn't
much matter how you set things up, but when you have 50-60 coming
in they need to be in the right place and easy to process.
I use email for UNIX shell scripts and receive them on a Linux
server where I can save them to a special directory, remove the header
and execute them with a shell.
Dick S.


From Jason Cunliffe" <jasonic@nomadics.org  Mon Oct 21 15:56:01 2002
From: Jason Cunliffe" <jasonic@nomadics.org (Jason Cunliffe)
Date: Mon, 21 Oct 2002 10:56:01 -0400
Subject: [Edu-sig] Electronic assignment submission?
References: <B4B00B1CCF9795449A4AC24C63AAFFB493D555@aacc-mail1.aacc.cc.md.us>
Message-ID: <001001c27911$f9380c00$6501a8c0@vaio>

> I'm looking for a system to hand in programming assignments
> electronically, and return them to the students (IMHO, a trickier
> problem). Web, email or other, ideally running on a freenix server
> (BSD).
>
> It would be fun to write my own, and I've been looking at pulling mail
> attachments via IMAP and the MIME tools, or some sort of Web script.
> But if it's already out there...

Try looking at Zope => http://zope.org
It is a powerful web application framework. 100% Python. Free openSource,
cross-platform. Lots of plug-in openSource 'products' are available. I am pretty
sure at least some of those may do exactly what you want.

Several people on this list are using it. Zope is many things to many people.
Swiss army knife of web and content management. Perhaps overkill, perhaps not.
You can leverage against some wonderful features, supported by the generous,
dedicated momentum of a solid community. That community is half users who
install other's toolkits and script with them, and the hard-core developer
pushing-the-envelope Zopistas reinventing everything all the time, planning the
better brighter future. [consumer warning: Zope can be addictive!]

As a turnkey deal, it is painless to download and install. In 10 minutes you
will have a full web-server with FTP access into a powerful object database
[ZODB]. Then use the built-in components to start creating your site/application
through the HTML interface and/or via other tools.  If there is some special
feature you need, check the contributed component lists and download and install
those as you need. Most

Importing and exporting the site or parts of it is very easy to do. The same
.zexp [Zope export] file can be saved from one machine and installed on another
remotely. That includes cross-platform. Provided there are no special external
dependencies  you can imedateialy immediately working. It is thus quite common
to find people developing on laptop in Zope using Windows, but also transferring
or backing up work to a remote Linux server.

Built-in search and cataloguing, as well as fine-grained permission control,
make Zope excellent for the type of content management workflow you may want to
do. Most admin is done entirely through web forms. Zope is very modular and now
template driven, so presentation and features can change with context. Your can
program directly using external Python scripts which use the Zope API. These
also act as a bridge to any other non-Zope python you want to use. Many well
known modules have been wrapped into Zope products - database adapters, image
processing, etc.

If you do use Zope but prefer a shell command line paradigm, then be sure to
check out Jerome Alet's ZShell:
http://cortex.unice.fr/~jerome/
http://www.librelogiciel.com/software/ZShell/action_Presentation

Zope.org is the community site, and the only way to really decide about Zope is
download and try it out yourself. The Zope mailing lists are high volume and
very responsive to all kinds of need and detail.
http://www.zope.org/Resources/MailingLists

Zope.com is the commercial home, and has some handy couch-potato tradeshow demos
in flash/quicktime:
http://www.zope.com/Demos
Also a client list and case studies:
http://www.zope.com/ZopeClientList
http://www.zope.com/CaseStudies


hth
good luck!
./Jason




From dyoo@hkn.eecs.berkeley.edu  Mon Oct 21 23:03:28 2002
From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo)
Date: Mon, 21 Oct 2002 15:03:28 -0700 (PDT)
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for
 newbies?]
In-Reply-To: <MPEOIFCOPCIHEDCLBLPBEEIGCIAA.rob@uselesspython.com>
Message-ID: <Pine.LNX.4.44.0210211450570.29179-100000@hkn.eecs.berkeley.edu>


> I feel that navigation is the second weakest element of the site, and
> have been giving a lot of thought to how to address the matter without
> messing up the experience too much. The site's single greatest point of
> weakness is that it lacks automation and is maintained manually by one
> person. Automating the site could well be the means to resolving both
> the navigation and management issues.

I wish I knew more Zope to help out here; I'm still trying to get my head
around it.  But from what I understand, perhaps Zopifying Useless Python
may help with the content-management side of things!



> The tricky part is that the original design concept was indeed for the
> user to rummage through the randomly-ordered source files. This didn't
> seem as problematic when there were only a few dozen source files, but
> with the next major update the number should increase to well over 200.
> At this size, I can certainly understand the frustrations expressed by a
> few. (Fewer than half a dozen to date, including today's comments.)

I know it's heretical to look at what the Perl folks are doing, but I
can't help it.  *grin*

The Perl folks have a site called http://www.perlmonks.org that combines
aspects of both the Tutor mailing list and Useless Python.  It's a large
repository for Perl knowledge.

It might be nice to see what things perlmonks is doing right, and see if
we can apply those things to Useless Python.



From rob@uselesspython.com  Mon Oct 21 23:45:32 2002
From: rob@uselesspython.com (Rob)
Date: Mon, 21 Oct 2002 17:45:32 -0500
Subject: [Edu-sig] re: Slighly OT: O'Reilly article [other resources for newbies?]
In-Reply-To: <Pine.LNX.4.44.0210211450570.29179-100000@hkn.eecs.berkeley.edu>
Message-ID: <MPEOIFCOPCIHEDCLBLPBCEKOCIAA.rob@uselesspython.com>

I've looked at PerlMonks before, although it's been a while.

As far as successfully automating Useless Python goes, I've got a few
general thoughts. My vision:

- Newbie (or non-newbie) decides to upload a source file and fills out a
form to do so. Form elements would be the author's name, a description of
the program (brief), and a field to browse their hard drive to select the
file. An administrative email is sent to the small team of volunteers who
approve/deny the submission. Denial would only occur in cases in which the
submission is wildly irrelevant (such as it not being a Python program in
any way).

- For browsing files to rummage through, which is currently done by clicking
on the numbered pages, I would like to add options. This could mean
searching for keywords or modules used in the source files, which might make
Useless Python a truly powerful repository. Alternatively, we could have a
database of general categories that source files fit into (such as "GUI",
"socket", etc., etc.), which is vastly more limited, but probably easy
enough to implement.

There appear to be a number of web hosting services available where we would
have access to any number of resources, and costs appear to be
non-prohibitive with some Python-friendly hosts.

Any thoughts?

Rob

> -----Original Message-----
> From: Danny Yoo [mailto:dyoo@hkn.eecs.berkeley.edu]
> Sent: Monday, October 21, 2002 5:03 PM
> To: Rob
> Cc: edu-sig@python.org
> Subject: RE: [Edu-sig] re: Slighly OT: O'Reilly article [other resources
> for newbies?]
>
>
>
>
> > I feel that navigation is the second weakest element of the site, and
> > have been giving a lot of thought to how to address the matter without
> > messing up the experience too much. The site's single greatest point of
> > weakness is that it lacks automation and is maintained manually by one
> > person. Automating the site could well be the means to resolving both
> > the navigation and management issues.
>
> I wish I knew more Zope to help out here; I'm still trying to get my head
> around it.  But from what I understand, perhaps Zopifying Useless Python
> may help with the content-management side of things!
>
>
>
> > The tricky part is that the original design concept was indeed for the
> > user to rummage through the randomly-ordered source files. This didn't
> > seem as problematic when there were only a few dozen source files, but
> > with the next major update the number should increase to well over 200.
> > At this size, I can certainly understand the frustrations expressed by a
> > few. (Fewer than half a dozen to date, including today's comments.)
>
> I know it's heretical to look at what the Perl folks are doing, but I
> can't help it.  *grin*
>
> The Perl folks have a site called http://www.perlmonks.org that combines
> aspects of both the Tutor mailing list and Useless Python.  It's a large
> repository for Perl knowledge.
>
> It might be nice to see what things perlmonks is doing right, and see if
> we can apply those things to Useless Python.
>
>




From cccccttttt@hotmail.com  Tue Oct 22 00:20:51 2002
From: cccccttttt@hotmail.com (cam trenor)
Date: Mon, 21 Oct 2002 23:20:51 +0000
Subject: [Edu-sig] question
Message-ID: <F7mRXf2LTrpwACkWHZq00000165@hotmail.com>

<html><div style='background-color:'><DIV>is there a users group in the seattle--bellevue area?</DIV>
<DIV>&nbsp;</DIV>
<DIV>cam trenor</DIV></div><br clear=all><hr>Surf the Web without missing calls! Get MSN Broadband. <a href="http://g.msn.com/8HMZEN/2022">Click Here</a> </html>


From i.linkweiler@gmx.de  Fri Oct 25 11:56:30 2002
From: i.linkweiler@gmx.de (Ingo Linkweiler)
Date: Fri, 25 Oct 2002 12:56:30 +0200
Subject: [Edu-sig] ANN: PyNassi - a structure chart editor
Message-ID: <3DB9235E.4000901@gmx.de>

PyNassi - A program structure chart editor

DESCRIPTION:
------------
(DEUTSCH siehe unten)

PyNassi 1.2 (24.10.02)
 A program structure chart editor and a debugger written with and
for Python. PyNassi allows the interactive design of
"Nassi Shneiderman" structure charts and can generate
Python source code. Program structure charts permit an easily
understandable diagram of functions and programs.
PyNassi can be used for education for the representation and
production of programs as well as an introduction to the basics of=20
programming
techniques in the form of program structure charts.

VERSION:
--------
1.2 (first public release)

CHANGES:
--------
v1.2:
- english and german language
- new setup dialog
- printing

URL:
----
http://www.ingo-linkweiler.de/diplom/

 ***

BESCHREIBUNG:
-------------
Ein Struktogramm-Editor und Debugger in Python.
PyNassi erm=F6glicht die Erstellung von Python-Scripten in Form
von Nassi-Shneiderman-Struktogrammen. Struktogramme erlauben
eine leicht verst=E4ndliche, grafische Darstellung von Funktionen
und Programmen. Besonders im Bereich der Ausbildung zur Einf=FChrung
in die Grundlagen der Programmiertechnik bietet sich die
Darstellung und Erstellung von Programmen in Form von
Struktogrammen an.

VERSION:
--------
1.2 erste =F6ffentliche Version

NEUERUNGEN:
-----------
v.1.2:
Mehrsprachig
Druckfunktion
Setupdialog

URL:
----
http://www.ingo-linkweiler.de/diplom/




From i.linkweiler@gmx.de  Fri Oct 25 12:16:25 2002
From: i.linkweiler@gmx.de (Ingo Linkweiler)
Date: Fri, 25 Oct 2002 13:16:25 +0200
Subject: [Edu-sig] ANN: SuM - Von Stiften und Maeusen (german)
Message-ID: <3DB92809.9040801@gmx.de>

SuM - Von Stiften und M=E4usen

DESCRIPTION:
------------
German only: About pens and mice,
a conversion of the well-known didactical learning software to Python.

BESCHREIBUNG:
-------------
Eine Umsetzung der bekannten didaktischen Lernsoftware nach Python.

Einf=FChrung in die Grundlagen der objektorientierten Programmierung.
Anhand fertiger Klassen "Stift", "Maus", "Bildschirm" u.a. kann in
dieser Lernumgebung  der Einstieg in die objektorientierte=20
Softwareentwicklung
mit einfacher Computergrafik vermittelt werden.

VERSION:
--------
1.0 erste =F6ffentliche Version

URL:
----
http://www.ingo-linkweiler.de/diplom/




From nobody@maui.dnsvault.com  Wed Oct 30 00:38:49 2002
From: nobody@maui.dnsvault.com (Nobody)
Date: Tue, 29 Oct 2002 19:38:49 -0500
Subject: [Edu-sig] A larger gold balance!
Message-ID: <E186gsj-0002AI-00@maui.dnsvault.com>

<html>
<head>
	<title>Untitled</title>
</head>

<body>
<h1 align="center"><font size="+3"><font color="red">Hello all E-Gold and EVOcash account holders!</font></font></h1>
<P align=justify><b>&nbsp;&nbsp; We here at Your Gold Chance 
are honest, reliable and willing to help you achieve what you want most..... A 
larger e-gold balance! We have developed a program to give you a smart return 
without the usual wait of hyip's. For speed and convenience we utilize online 
digital currencies. We accept E-Gold and EVOcash.</b></P><B>
<P align=justify>&nbsp;&nbsp;&nbsp; All investments are based on a 33 week plan. We pay you 10% per week for a total of 33 weeks. You first payment starts 7 days after you invest and your capital is returned to you at the end of the 33th week.</P>
<P align=justify>&nbsp;&nbsp;&nbsp;The minimum Investment is $25.00USD and the maximum Investment is $25,000 USD. Do not send us any amount outside these parameters otherwise your investment will be returned without profit.<br></P></B>
<p align="left"><font size="+1"><font color="Red">If you are interested in this program visit site:</font></font></p>
<a href="http://www.yourgoldchance.net/invest.html"><font color="Blue">http://www.yourgoldchance.net/invest.html</font></a>
<p align="left"><font size="+1"><font color="Red">All additional  information you can get here:</font></font></p>
<a href="http://www.yourgoldchance.net/"><font color="Blue">http://www.yourgoldchance.net/</font></a>

<p align="left"><font size="+1"><font color="Red">If you would like to contact us, please send us an email:</font></font></p>
<A href="mailto:yourgoldchance@yourgoldchance.net"><font color="Blue">yourgoldchance@yourgoldchance.net</font></A>
<p  align="justify"><b>Our company will continue its best efforts to make good on every
payments on our program without any delay.</b></p>

<p><b>Thanks for choosing Your Gold Chance!<br>
Karen Andreozzi,<br>
President<br>
Yor Gold Chance, Inc.</b></p>
        

</body>
</html>