Programming for Fun Quote
Jason writes -
The orginal writer's view was that for teaching purposes in shools, programming is perhaps better approached from linguistic perspective first, than to be treated as Mathematics.
At least part of my perspective is related not so directly on how to teach programming, per se, but how most effectively to fit programming fundamentals into a curriculum. A select few take programming courses, while we are all (correctly, IMO) exposed to math courses. An understanding of programming fundamentals allows for an enhanced math curriculum - ala Kirby, for example. And I believe that enhancing and enlivening a mathematics curriculum justifies the commitment of resources to teaching/learning programming as core curriculum, to an extent beyond what is true for programming - standalone. Art
Yes, Art is here stating a view I share rather pithily. Kirby
And I believe that enhancing and enlivening a mathematics curriculum justifies the commitment of resources to teaching/learning programming as core curriculum, to an extent beyond what is true for programming - standalone.
Art
[Kirby Urner]
New in 2.2a4 -- conversion to long integer happens automatically when needed:
2**34 17179869184L a =1983409182340981239481 a 1983409182340981239481L
I like it!
Me too <wink>. Note that this is a partial implementation of PEP 237 (Unifying Long Integers and Integers), and indeed is as much as we dared implement without tickling serious compatibility issues: http://python.sourceforge.net/peps/pep-0237.html There are some other new niceties hiding in 2.2a4, like
import math math.log10(10 ** 10000) 10000.0
In earlier versions, you got an infinity, NaN, or simply nonsense, from trying to find the log of a long too big to convert to a C double. That bothered me for about 10 years -- so one guess as to who fixed it <wink>. About that "compatibility" issue: There's one context where ints don't auto-convert to longs as needed, and that's left shifts:
1L << 100 1267650600228229401496703205376L 1 << 100 0
I don't know what we can do about that, because we *know* there's code out there that depends on (short) int left shifts acting as if in a fixed-width window, losing the bits shifted "off the end". The other cases of auto-conversion raised OverflowError before, and it's hard to conceive of working code that will miss that (all examples we found caught the OverflowError and then redid the computation from scratch after explicitly converting to long); but left-shift behavior both was and would remain silent, but with different results.
participants (3)
-
Arthur Siegel -
Kirby Urner -
Tim Peters