<div dir="ltr"><blockquote>m = float(rise)/run # avoid dividing two integers ...<br>...<br>print "y = %f x + %f" % (m, b)<br><br>with perhaps some thoughts given to having a set number of decimal<br>
places for the floats.<br><br></blockquote>Certainly, these things makes sense, but given the strange mindset I'm trying to work in, a secondary math
curriculum that is already skeptical about the relevance of programming in
math classes in the first place, worrying about
formatting issues would just further alienate both colleagues and
students. They want things to be as simple as possible,
otherwise, they immediately lose interest. So it's a tricky balance. One detail too much, and it's overload for them. As it is, the float vs. integer division issue will disappear with Python 3K, and I think that will be good for easier integration into math classes.<br>
<br>For math classes I think it's more pertinent to focus on functional interactions and not on IO issues, and that was what I was trying to get at.<br><br>What I have found fascinating is how similar students and teachers are. You know how math students will ask, "How am I ever gonna USE this?" Well, that's the same response I would initially receive from math colleagues when mentioning Python. In both cases, the questioner seldom really wants an answer, they just want to express their disinterest. But thankfully, this is changing. My colleagues might still not be interested in pursuing it themselves, but at least at this point they realize that it isn't just BS.<br>
<br><br><br><div><div><br><div class="gmail_quote">On Fri, Oct 3, 2008 at 6:51 PM, Andre Roberge <span dir="ltr"><<a href="mailto:andre.roberge@gmail.com" target="_blank">andre.roberge@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2008/10/3 michel paul <<a href="mailto:mpaul213@gmail.com" target="_blank">mpaul213@gmail.com</a>>:<br>
<br>
[SNIP]<br>
<div><br>
<br>
><br>
> Here's the same solution in Python:<br>
><br>
> x0, y0 = input('Enter x0, y0 --->')<br>
> x1, y1 = input('Enter x1, y1 --->')<br>
> rise = y1 - y0<br>
> run = x1 - x0<br>
> if rise == 0: print 'y =', y0<br>
> elif run == 0: print 'x =', x0<br>
> else:<br>
> m = rise/run<br>
> b = y0 - m*x0<br>
> print 'y =', m, 'x +', b<br>
><br>
<br>
</div>I find that this (and even more so for the other solutions below) not<br>
as readable as it should be. For me, if/elif/else really gain from<br>
being indented, and blank lines can also add to divide the program<br>
into "functional unit". So I would write instead:<br>
<div><br>
x0, y0 = input('Enter x0, y0 ---> ')<br>
x1, y1 = input('Enter x1, y1 ---> ')<br>
<br>
rise = y1 - y0<br>
run = x1 - x0<br>
<br>
if rise == 0:<br>
print 'y =', y0<br>
elif run == 0:<br>
print 'x =', x0<br>
else:<br>
</div> m = float(rise)/run # avoid dividing two integers ...<br>
b = y0 - m*x0<br>
print "y = %f x + %f" % (m, b)<br>
<br>
with perhaps some thoughts given to having a set number of decimal<br>
places for the floats.<br>
<br>
Just a thought...<br>
<br>
André<br>
<div><div></div><div><br>
<br>
<br>
> You can see the same logic, but it's a bit shorter. That's because there's<br>
> no use of GOTO. The elimination of GOTO was one of the important features<br>
> in the development of PASCAL, and ever since those days GOTO has been<br>
> considered bad style. It produces crazy and cumbersome code. Functional<br>
> organization is far superior.<br>
><br>
> You can see that the Python version is just as easy to read, or easier, than<br>
> the BASIC. So, you can use Python in this simple procedural sort of way.<br>
> However, Python supports various paradigms, so you can also organize things<br>
> functionally:<br>
><br>
> def slope_intercept(A, B):<br>
> x0, y0 = A<br>
> x1, y1 = B<br>
> rise, run = y1 - y0, x1 - x0<br>
> if run == 0: return None, x0<br>
> m = rise/run; b = y0 - m*x0<br>
> return m, b<br>
><br>
> And even here, the code is longer than it needs to be. You can cut it down<br>
> to:<br>
><br>
> def slope_intercept(A, B):<br>
> rise, run = A[1] - B[1], A[0] - B[0]<br>
> if run == 0: return None, A[0]<br>
> return rise/run, A[1] - rise/run*A[0]<br>
><br>
> And you can even cut it down more, but that's not the point.<br>
><br>
> This accomplishes the same thing as the original, just without printing the<br>
> equations. You would then call this function to obtain the values of m and<br>
> b for printing, if that's what you wanted to do, or, you could chain this<br>
> function together with other functions to construct something more complex.<br>
> It's what functional analysis is all about. You consider I/O stuff<br>
> decoration. It's not the important part mathematically speaking.<br>
><br>
> Functional decomposition of tasks ---> sure sounds like Analysis to me! :<br>
> ) Isn't it essentially the same kind of thinking?<br>
</div></div>> _______________________________________________<br>
> Edu-sig mailing list<br>
> <a href="mailto:Edu-sig@python.org" target="_blank">Edu-sig@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/edu-sig" target="_blank">http://mail.python.org/mailman/listinfo/edu-sig</a><br>
><br>
><br>
</blockquote></div><br></div></div></div>