Mailman 3 September 2006 - Edu-sig

More on teaching about namespaces
by kirby urner Sept. 14, 2006

Sept. 14, 2006

What I like about namespaces is the idea is intuitively obvious to anyone spending any time in academia, because every professor is one. It takes time to learn just what each means by this or that key term, although supposedly in math it's easier, because all the definitions are agreed upon in advance, axioms too, plus rules of deduction, so the theorems also. My idea of a good first move, after booting some Python GUI shell for the first time, is to go dir(). IDLE 1.2b2 >>> dir() ['__builtins__', '__doc__', '__name__'] Already the filling is: we're not alone. And what are those weird __xxx__ things. They look strange. Thinking like a computer scientist, you mentally pair tics and decide we have three quoted words, like a list of some time. See? Python fits your brain. You're already thinking like a pro. Instead of words we say strings, and a space is just one more character (ASCII 32). But here comes the *big* revelation: >>> dir(__builtins__) ['ArithmeticError', 'AssertionError', 'AttributeError', 'BaseException', 'DeprecationWarning', 'EOFError', 'Ellipsis', 'EnvironmentError', 'Exception', 'False', 'FloatingPointError', 'FutureWarning', 'GeneratorExit', 'IOError', 'ImportError', 'ImportWarning', 'IndentationError', 'IndexError', 'KeyError', 'KeyboardInterrupt', 'LookupError', 'MemoryError', 'NameError', 'None', 'NotImplemented', 'NotImplementedError', 'OSError', 'OverflowError', 'PendingDeprecationWarning', 'ReferenceError', 'RuntimeError', 'RuntimeWarning', 'StandardError', 'StopIteration', 'SyntaxError', 'SyntaxWarning', 'SystemError', 'SystemExit', 'TabError', 'True', 'TypeError', 'UnboundLocalError', 'UnicodeDecodeError', 'UnicodeEncodeError', 'UnicodeError', 'UnicodeTranslateError', 'UserWarning', 'ValueError', 'Warning', 'WindowsError', 'ZeroDivisionError', '_', '__debug__', '__doc__', '__import__', '__name__', 'abs', 'all', 'any', 'apply', 'basestring', 'bool', 'buffer', 'callable', 'chr', 'classmethod', 'cmp', 'coerce', 'compile', 'complex', 'copyright', 'credits', 'delattr', 'dict', 'dir', 'divmod', 'enumerate', 'eval', 'execfile', 'exit', 'file', 'filter', 'float', 'frozenset', 'getattr', 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'intern', 'isinstance', 'issubclass', 'iter', 'len', 'license', 'list', 'locals', 'long', 'map', 'max', 'min', 'object', 'oct', 'open', 'ord', 'pow', 'property', 'quit', 'range', 'raw_input', 'reduce', 'reload', 'repr', 'reversed', 'round', 'set', 'setattr', 'slice', 'sorted', 'staticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'unichr', 'unicode', 'vars', 'xrange', 'zip'] Ohmygod omygod, what *is* going on now? Obviously errors are a big part of the Python experience (why else would that be the major topic in like the whole first half of the list?), and then you have a bunch of underunder guys (ribs?), and then some short words, including one especially ugly one with an internal underbar. Now, as the teacher, I've probably just been projecting so far, encouraging students to all focus on the big screen up front, and the bouncing laser pointer dot, which drifts over this stuff as I vocalize about content. So I'm the one that shows 'em they can now select from the above list and go (for example): >>> help(iter) Help on built-in function iter in module __builtin__: iter(...) iter(collection) -> iterator iter(callable, sentinel) -> iterator Get an iterator from an object. In the first form, the argument must supply its own iterator, or be a sequence. In the second form, the callable is called until it returns the sentinel. Aha. Lots of jargon. iterator, callable, argument, sequence... Let's try another. >>> help(max) Help on built-in function max in module __builtin__: max(...) max(iterable[, key=func]) -> value max(a, b, c, ...[, key=func]) -> value With a single iterable argument, return its largest item. With two or more arguments, return the largest argument. Hmmmmm, overlapping jargon. There's that iterable notion again. Gotta learn that square brackets mean *optional* stuff, i.e. you don't need it. Is a bare list an iterable? >>> max([1,2,3,4]) 4 Looks like. Let's explore some more.... >>> max([1,2,3,4]) 4 >>> a = [1,2,3,4] >>> b = iter(a) >>> id(a) 23472728 >>> id(b) 23397744 >>> type(a) <type 'list'> >>> type(b) <type 'listiterator'> >>> max(b) 4 and so on... This might be more for adults with some programming experience already, but not much with Python. But you see how I'm bringing the namespace idea in right away. Immediately upon being in the shell, we're already in one. Best to look around. dir() and help() are your friends. Later, we'll import. But already, we're in a huge fish tank, lots to see and do. Could take an hour at least, to get through this aquarium -- very interactive, so now I'll turn off the projector (actually, I'll leave what you see). Go crazy, play, explore. We'll start up with the formal talk in about 15 minutes, and answer any questions. Bathroom is down the hall to your right. Kirby

3 5

Namespaces in the Humanities
by kirby urner Sept. 14, 2006

Sept. 14, 2006

This is going to seem a bit off-topic, but my goal is to show how CS might recruit more liberal arts majors by focusing on namespaces in the humanities. Like I was saying earlier, every professor, of Near Eastern Studies, of Molecular Biology, of Postmodern Poetics, whatever BS, is a walking talking live specimen namespace. And when you get two or more professors in a room, what typically happens? Name collisions, and lots of them. So how has computer science helped solve the problem of name collisions, at least for the benefit of our poor slave electronic robots (AI bots), with no hope of understanding the subtlties of "context" without it? By means of dot notation, is one way. In Python, we'll see what that looks like. But let's get back to those professors for a moment, and take a good example of a name collision, familiar to everyone who studies Bucky Fuller's stuff on occasion (i.e. probably most gnu math teachers). Over on Synergeo (another obscure archive where I'm sometimes active), you'll maybe find some "chalkboard notation" like this: coxeter.4d < > einstein.4d < > fuller.4d What that refers to is the three different trajectories taken by the '4D' meme since like around 1900, when it was caught up in a maelstrom of competing schools of thought.[1] In his 'Regular Polytopes' this master geometer (who recently died -- there's new bio out), H.S.M. Coxeter takes pains to differentiate *his* meaning of "four dimensional" from that of the spacetime Relativity's.[2][3] Coxeter's *not* saying the Einsteinians are wrong to have their own namespace, just that the two schools have different usages for this same '4D' meme. Not getting that there's a difference will lead only to confusion. He mentions some science fiction that fell into this trap. The difference? In hyperspatial geometry, you have as many dimensions as you want, and they're all spatial. In Relativity, the time dimension is singled out for special treatment. Fuller, meanwhile, held back publishing his gestating meaning for '4D' until much later in life (1970s), and, upon unveiling, it turned out to be neither Coxeter's nor Einstein's, but had some family resemblance to both. Fuller's 4D is very like everyday high school's 3D, i.e. the XYZ apparatus, anchored at an origin (0,0,0) is conceived to exist independently of any specific event in spacetime. There's no "where or when" questions that need answering. XYZ exists in pure conceptuality, and gives us a refined idea of "a mathematical space" that's very like our own personal circumstances (i.e. spatial, volumetric), yet is conveniently devoid of what philosophers of the day called "secondary characteristics" e.g. color, sound, tactility -- the messy business of energetic reality. Why Fuller called it 4D instead of 3D is he was very impressed by the simple nature of the Tetrahedron, the fact that it had fewer faces, edges and vertices than the cube. In the world of hard edges, skeletons, sticks, it seemed the simplest of shapes (not a new realization -- mathematicians often call it The Simplex). Spheres seem a lot smoother, true, but in stick world they're just hugely multi-faceted and hence not simple at all. Axiomatically, one needn't buy a Continuum to practice geometry per Democritus. Buckaneering is digital, seems analog only because everything does. And the tetrahedron simply radiates 4ness, really more than 3ness, although the two complementary 3-edge spiral zig-zags always and only co-exist (as the local namespace would have it). And then, taking a page from Kant, we simply identify conceptuality with this Tetrahedron Space (a 4-space) and scoff at Abbott's 'Flatland' as a conceptual impossibility (i.e. we only *pretend* we can imagine a space of fewer dimensions -- always forgetting about the camera). Anyway, this is all a very different namespace than either Professor Coxeter or Professor Einstein were using. More philosophical, vs. Coxeter's mathematical and Einstein's physical. Each guy had his own trademark brand of 4D, and developed his thinking accordingly, systematically, consistently. Fuller came along late in the game, threw a new '4D' in the ring. So as of the 1970s, we have at least three, distinct, not-equal usage patterns, yet all using the same name. What are the chances of name collisions? Very high. But learning from computer science, and Python especially, we have this simple way of cleaning up the mess: use dot notation, to anchor names to their users, their professors (those who profess (Fuller claimed not to be "professing" but was just quibbling over verbs (always the stickler))). coxeter.4d < > einstein.4d < > fuller.4d In sum, I'm including this little chalkboard lecture on "The Three Meanings of 4D" in order to show how we, the liberal arts humanties types, have become enamoured of dot notation as a way to sort out name collisions, and the messes they sometimes engender. Ever since we in the Fuller School got clear on this "three schools" picture, we've had a lot easier time lowering the noise level in our meetings. As Fuller Schoolers, we're less likely to flounder around in BS, and we credit nearby Python Nation's high level of intelligence and civilization for helping us out. We import. We thrive. And we hope our exports are valued too (it's about trading, not stealing i.e. keeping in balance). Kirby [1] Linda Dalrymple Henderson. The Fourth Dimension and Non-Euclidean Geometry in Modern Art (Hardcover). ISBN 0691040087 [2] H.S.M Coxeter, 'Regular Polytopes' ISBN 0486614808, pg. 119 [3] The King of Infinite Space: Donald Coxeter: the Man Who Saved Geometry (Hardcover) by Siobhan Roberts -- which I just purchased about a minute ago from Amazon.com.

3 5

Working with Vpython
by kirby urner Sept. 14, 2006

Sept. 14, 2006

For just starting to explore with VPython window, getting one's feet wet, I'm looking at such as stickworks.py as a simple place to begin (excerpts below). The stickworks namespace wants us to think of Vector objects as radiating from (0,0,0), i.e. they're always tail anchored to the origin. class Vector (object): """ A wrapper for visual.vector that expresses a cylinder via draw(), always pegged to the origin """ radius = 0.03 def __init__(self, xyz, color=(0,0,1)): self.v = vector(*xyz) self.xyz = xyz self.color = color self.cyl = None def draw(self): """define and render the cylinder""" self.cyl = cylinder(pos = (0,0,0), axis = self.v, radius = self.radius, color = self.color) def erase(self): """toss the cylinder""" if self.cyl: self.cyl.visible = 0 self.cyl = None def __repr__(self): return 'Vector @ (%s,%s,%s)' % self.xyz # some vector ops, including scalar multiplication def cross(self, other): temp = cross(self.v, other.v) return Vector((temp.x, temp.y, temp.z)) etc. Edges, on the other hand, otherwise known as line segments, may connect any two points in space, and as such are defined by the arrow *tips* of two Vectors of the type defined above. class Edge (object): """ Edges are defined by two Vectors (above) and express as cylinder via draw(). """ radius = 0.03 def __init__(self, v0, v1, color=(1,0,0)): self.v0 = v0 self.v1 = v1 self.color = color self.cyl = None def draw(self): """define and render the cylinder""" temp = (self.v1 - self.v0).xyz self.cyl = cylinder(pos = self.v0.xyz, axis = vector(*temp), radius = self.radius, color = self.color) def erase(self): """toss the cylinder""" if self.cyl: self.cyl.visible = 0 self.cyl = None def __repr__(self): return 'Edge from %s to %s' % (self.v0, self.v1) You'll find this dichotomy in some published linear algebra books e.g. this one by Wayne Bishop and Stewart Venit ISBN: 087150300X (Wayne being a Cal State prof and one of my sparring partners on math-teach). I'm not using VPython's cylinder and vector objects directly because I'm wanting an even simpler namespace. Vectors are my primary constituent, followed by edges as pairs of vectors, and faces as tuples of vectors defining three or more edges. Of course in the Fuller School we quickly move to a small subset of polyhedra organized in a particular way (or core mandala, source of many dharmas). We harp on Euler's V + F = E + 2. We talk in an alien manner about our 4D Simplex with energy added (4D++). But that doesn't mean every gnu math teachers needs to follow our lead and/or sequence. The curriculum is a network, and the many trailheads go to many places (partially overlapping) in different orders. Plus Arthur of Pygeo has a whole other toolset you could explore. Save the Bucky stuff for later, if ever. Tell 'em I said it was OK. The sequence I'm developing here is: intro to namespaces --> import stickworks as a namespace --> explore in VPython Given stickworks is provided, student creativity will be more in what they can *do* with it. I'll be thinking of some projects. Dissecting and tweaking source code will also be a focus, as fluency gradually develops, plus writing new modules that assume the above as all given. Kirby

1 2

Mindstorm NXT and Python ?
by francois schnell Sept. 13, 2006

Sept. 13, 2006

Hello, I've just read the open source move of Lego concerning it's new Mindstorm NXT: http://slashdot.org/articles/06/05/02/111245.shtml http://mindstorms.lego.com/press/2057/Open%20Source%20Announcement.aspx The firmware sources and blue tooth protocols will be available. :) This definitely interest me and I'll buy one as soon as available (in August). I didn't find anything about using Minstorms with Python yet but it looks like there'a a SDK for Microsoft Visual Studio Express with VB, C#, J#, C++: http://msdn.microsoft.com/coding4fun/lego/default.aspx Even if Iron Python is not integrated in Visual Studio (I believe), using the classes with IronPython shouldn't be a problem (I imagine). Anyway I'm not a fan of .Net/Mono and I'll probably try to explore other ways . I want to see what can be done with Python and this Mindstorms NXT in particular in an "educational/constructivist" context. If you know any projects already using Python and the actual Mindstorms I'm also interested or your thoughts on the subject. Thanks francois

1 1

The fate of raw_input() in Python 3000
by Andre Roberge Sept. 12, 2006

Sept. 12, 2006

The following is something I have been pondering for quite a while now and am wondering what other people on this list think. According to PEP 3100 (http://www.python.org/dev/peps/pep-3100/ ) raw_input() [as well as input()] is recommended for removal from the built-in namespace, to be replaced by sys.stdin.readline(). While I don't think anyone can argue that this removal makes a major difference for Python as a programming language, I believe it makes a significant difference for using Python as a learning language, adding a non-trivial barrier to learning. Consider the following fake sessions at the interpreter prompt, where I use extra parentheses to turn print as a function (as is also proposed in Python 3000) - these parentheses can of course be used with today's Python. # First ever program >>> print("Hello world!") Hello world! # More complicated example from the first interactive session using today's version >>> name = raw_input("Enter your name: ") Enter your name: Andre >>> print("Hello " + name + "!") Hello Andre! # More or less the same example using the proposed changes. >>> import sys >>> print("Enter your name: ") Enter your name: >>> name = sys.stdin.readline() <-- Andre >>> print("Hello " + name + "!") Hello Andre! To explain the above *simple* program to a beginner, we'd need: 1. to introduce the import statement 2. to introduce the dot notation (something Kirby would be happy with ;-) Furthermore, the flow is not the same as with today's raw_input(). I don't like it. While I totally agree with the proposed removal of input() [anything using eval() in a hidden way is *bad*], my preference would be to keep raw_input()'s functionality, perhaps renaming it to user_input() or ask_user(). Thoughts? André

18 58

Re: [Edu-sig] Compatibility and legacy in language evolution
by Radenski, Atanas Sept. 12, 2006

Sept. 12, 2006

> -----Original Message----- > From: edu-sig-bounces(a)python.org [mailto:edu-sig-bounces@python.org] On > Behalf Of Jan Claeys > Sent: Tuesday, September 12, 2006 2:37 PM > To: edu-sig(a)python.org > Subject: Re: [Edu-sig] Compatibility and legacy in language evolution > > Op za, 09-09-2006 te 17:53 -0700, schreef Radenski, Atanas: > > Strictly speaking this is true, but Mr. Stroustrups own papers also > > explain how important the full C/C++ compatibility is - and that > > achieving it is his ideal > > Well, strictly speaking language A can only be fully compatible with > language B and have more features if language B has a mechanism for > extension that ignores unknown features. Considering that C has no such > mechanism, C++ will never be 100% compatible with C. Well, compatibility can be defined in *various* ways of course. If one is an extremist regarding compatibility, one can say that C++ is not compatible with itself. Indeed, the same C++ program may behave differently under different compilers - for the simple reason that some language features, particularly those related to integer types, are left implementation-dependent. The same program may run correctly under one compiler and misbehave under another. Hence - C++ is incompatible with itself. What matters in my opinion is not extremism, but a practical compatibility, as already explained by Joshua Zucker: "... a C programmer can start writing C++ programs without having to change anything -- legal C programs will still run just fine in C++. Then the C programmer can gradually learn whatever parts of the extensions of C++ at whatever rate, and slowly evolve into a C++ programmer. " Thinking of it, this kind of compatibility can provide mighty support for an evolving language. > Jan Claeys Atanas Radenski

1 0

Compatibility and legacy in language evolution
by Radenski, Atanas Sept. 12, 2006

Sept. 12, 2006

Jan Claeys wrote: > Op za, 09-09-2006 te 13:49 -0700, schreef Radenski, Atanas: >> Bjarne Stroustrup was educated in the Simula tradition and recognized >> the benefits of objects, so he decided to improve C by adding objects. >> Most notably, Stroustrup preferred compatible design in his transition >> from C to C++. Indeed, C programs are C++ programs as well. > That's not true and mr. Stroustrups own books explain how and why; even > basic C programs might be invalid as C++ programs (or they work > different in C than in C++, which is even worse). Strictly speaking this is true, but Mr. Stroustrups own papers also explain how important the full C/C++ compatibility is - and that achieving it is his ideal (sect. 5 in this paper): http://www.research.att.com/~bs/compat_short.pdf

4 3

Compatibility and legacy in language evolution
by Radenski, Atanas Sept. 12, 2006

Sept. 12, 2006

Languages do evolve. For example: Pascal => Modula => Oberon C => C++ Java => Generic Java Python => Python 3000 ... etc... Pascal was once so popular that a US president had publicly acknowledged Pascal's importance for his country. Unfortunately, Pascal had some drawbacks, such as ad hoc IO and lack of modules. So Niklaus Wirth designed Modula, a nice language with uniform I/O and modules. Wirth disregarded compatibility: a valid Pascal program was not a valid Modula program. Although Modula - a very good language - gained some popularity, it was a substantial decline in comparison to Pascal' popularity. Because Modula did not have classes, Wirth developed Oberon, a compact and very efficient OO language. Again, Wirth chose incompatible design: a Modula program is not an Oberon program. Now Oberon is so obscure that many on this list might have never heard of it. Bjarne Stroustrup was educated in the Simula tradition and recognized the benefits of objects, so he decided to improve C by adding objects. Most notably, Stroustrup preferred compatible design in his transition from C to C++. Indeed, C programs are C++ programs as well. (In the I/O area in particular, C++ not only preserved C's I/O means, but even added convenient standard I/O idiom for the new I/O objects.) Look at the results of these evolution lines. Incompatible evolution: Pascal (popular) => Modula (less popular) => Oberon (obscure) Compatible evolution: C (popular) => C++ (popular++) One contemporary example: Sun Microsystem's recent extension of Java with genericity was guided first and foremost by the need to provide full compatibility between the two languages. Sun sacrificed language simplicity and orthogonality for full compatibility. Apparently, incompatible language evolution can invalidate the legacy of the evolving language. Unless you are Microsoft, this is difficult to overcome. In contrast, compatible evolution allows the user base of the language a smooth transition to the new language. Now Python is evolving into Python 3000. Will a valid Python program be a valid Python 3000 program? This is important. I think that the thread on the fate of raw_input actually addresses concerns that go way beyond the fate of raw_input. People are concerned because the lack of compatibility will invalidate some Python legacy, at least in the area of using Python as a teaching tool. Even though compatibility in language evolution can be somewhat detrimental to clean language design, it can promote a wider acceptance of the new language. Atanas

3 3

Re: [Edu-sig] The fate of raw_input() in Python 3000
by Joshua Zucker Sept. 12, 2006

Sept. 12, 2006

Thanks, Kirby, for cluing me in that I hadn't posted it to the list. --Joshua ---------- Forwarded message ---------- From: Joshua Zucker <joshua.zucker(a)gmail.com> Date: Sep 8, 2006 2:07 PM Subject: Re: [Edu-sig] The fate of raw_input() in Python 3000 To: kirby urner <kirby.urner(a)gmail.com> On 9/8/06, kirby urner <kirby.urner(a)gmail.com> wrote: > I think the model today is "a person writing code for him or herself" > i.e. "self as client" -- at least in an early context. We're not > guiding the unknowing through a menu tree. We're computer literate, > fluent. > > Why would we ask ourselves for raw_input, when it's much easier to > just pass arguments to functions? As someone who has taught a lot of functional programming (Scheme), I have a lot of sympathy for this argument. It wouldn't occur to me to teach raw_input or its equivalent anywhere early in the course, because designing functions is what it's all about! But the Scheme course I taught also came with a lot of teachpacks (read: modules to import) that did things like provide an interactive session with your function (prompting, like raw_input but with more error handling built in, or GUI). Without those, I might have been tempted to teach those input functions after all. The way my thinking is headed is toward event-driven programming (prompted both by some Java books, for which I apologize, and by some good new introductory Scheme lessons). So I'd rather see some dynamic thing, controlled by mouse clicks or key presses, as a relatively "low-level" input function, instead of just raw_input(). But by then I'd expect them to be comfortable with import anyway. My feeling in favor of keeping raw_input() is that it gives one more good choice for beginners. One of the things I enjoy most about Python is that whether I'm thinking like a Fortran programmer, a C programmer, or a Scheme programmer, I still find myself for the most part able to translate my thinking into reasonably good-looking code. Sometimes raw_input() makes me feel like I'm thinking like a BASIC programmer, but that has its place too, no? My feeling against keeping raw_input() is that we don't want them thinking that way anyway, and if someone really likes it, they should just make their own module and import it, which is a good beginner lesson. This latest from Kirby, reminding us that instead of interactive input we could just define a function and give the input that way, makes me lean even more toward the "against" camp. It'd be better education without it. --Joshua Zucker

2 2

The fate of raw-input() in Python 3000
by Daniel Ajoy Sept. 12, 2006

Sept. 12, 2006

On 12 Sep 2006 at 12:00, edu-sig-request(a)python.org wrote: > To cut to the chase: raw_input() provides an extremely useful > I/O function for simple exercise type problems which are so essential > in building a beginners repertoire of programming techniques and > for 'John Zeller' type problems ( simple quick dirty and effective > solutions that get those housekeeping jobs done). Again, inputs to functions (or procedures), and the prompt, can replace raw_input, as in my first example (simple guessing games). I define the following procedures: to palindrome? :n if 2 > count :n [output "true] if (first :n) = (last :n) [output palindrome? butfirst butlast :n] output "false end to make.pal :n print :n if palindrome? :n [stop] make.pal :n + reverse :n end Then, at the prompt: show palindrome? 121 true I can press the "Trace" button, and I get: show palindrome? 121 ( palindrome? 121 ) ( palindrome? 2 ) palindrome? outputs "true palindrome? outputs "true true show palindrome? 123211 ( palindrome? 123211 ) ( palindrome? 2321 ) palindrome? outputs "false palindrome? outputs "false false Anyway: make.pal 423 423 747 make.pal random 1000 739 1676 8437 15785 74536 138083 518914 938729 1866568 10523249 104755750 162313151 313626412 528252725 1055505550 1610561051 3112211212 5233333325 make.pal random 1000 507 1212 3333 make.pal random 1000 600 606 make.pal 879 879 1857 9438 17787 96558 182127 903408 1707717 8884788 17759676 85455447 159910905 668930856 1326970722 3597766953 7194444906 13288889823 46187778054 91275556218 172541113437 906852258708 1714704517317 8851858591488 17693817173076 84730989012747 159452087916495 754071868171446 1.3982437363419e+15 + doesn't like 51+e9143637342893.1 as input in make.pal I can modify my make.pal procedure, to use lsum instead of "+". to make.pal :n print :n if palindrome? :n [stop] make.pal lsum :n reverse :n end make.pal 879 879 1857 9438 17787 96558 182127 903408 1707717 8884788 17759676 85455447 159910905 668930856 1326970722 3597766953 7194444906 13288889823 46187778054 91275556218 172541113437 906852258708 1714704517317 8851858591488 17693817173076 84730989012747 159452087916495 754071868171446 1398243736341903 4489680109770834 8870459120640678 17630919340181466 84049023732085137 157207047464179185 739178512204881936 1378366914420753873 5161937158617392604 9224874327134784219 18349748644369568448 102836344989054362829 1031099795978498001030 1332108744774477902331 2664206489548955914662 5328402088008801939324 9567793176017603987559 19125686243124317965218 100382657585258586617409 1005099343437844342900410 1145191777925187782805411 2290274655740485554720822 4570549211580961119441744 9041998323271812248892498 17984986745453535487883907 88923865198988990256832878 176747730408977979413665866 845314045388757783451413537 1580628199776515666991827085 7387910196441672446910087936 13785710392884433893820285773 51543913232717882723122044504 92087935365446754446353979019 183185870729892518902707957048 1023945577939707817829786538429 10272302457226894897227542031630 13885327029506744759502962358831 27770653950102489520095034717662 54442397009105087940200970325434 97894704909310065990391049649879 195789398928620021991781990399758 1053782498115819142018611884387349 10491617379283921561203730827260850 16297890183014138074142028198880251 31506779365038285157283066308759512 53102559731076560315566122706520025 105105120453243111622133136502040160 166145326084574337733475490523541661 332290651179148675466950971147083322 555671392358208340043792942303175555 1111242695607505680087595795596352110 1223779651583463480952652861558773221 2447558203266026071796296713128546442 4894016416442953043502503336157103884 9777033932776005096906095782303208868 18465056965651911193811102554696516647 93126626611172023032923018211661573128 175264143222453055955955045323324235267 937796566545993615515505399545665697838 1776593133091987121031021799091331395577 9532524465001958322332239690994645352348 17965059929992927644664478282000289604707 88705758130021215091309151211993284661678 176322406369932430281628202423996470412466 840536481069256633107810236663960074636137 1572172951138623265126511573316920259271185 7383902471434757016282727196585231851983936 13777794052760613933555553304159573594077773 51554843590355754269111087235766298643855504 92110678279622507547122283481521608178701019 183121465460235025985344458052044305466302148 1024325129963675276839788047572576370030423529 10277565430700428034248667434298340069245657730 14053219726704817277725351677380740772702234931 27996440454409525655340704454652581535493469972 55992879907928051300781408810305171980897939944 100986859716845201602661827510620254951895769899 1099954457876297227618389993716722803569854458900 1198499047529379503792389831883950730357399058801 2287008985059750097673779664857010469614809007712 4464018069229390205258449438624911049120707015534 8819125139448791399526798887149931988350315120178 17529340269987682798944687863409863966799630339366 83922643969754619689381566508399592645795834731937 157836387829509249288762133026798284291592769354875 736290355124701732186382464294681227197521552993626 1362689610250493454372874928578362464304943106086263 4989495623744528097011633223361097008245463275948894 9977991347389956104913266446722204916499936541898788 18856972803789902298935542893345398933099773973896587 97426810741588936288289882717899388154098504801862468 183853621582177981476689754446797676418087019503724947 933280927492958796153487398904784350607858304630083328 1756660963896817502206974808798568702305717599359165667 9422280503853992534285633786883364724362904583049832238 17744669907708085168560267673756730548715898166100654487 96190270073897936953064033411432937134873978937097299258 181489549147885874796237956822865983170837958774104508427 906294950625745612867627525051525715868316547516050492608 1712589001241491226736145050202051442636533095042109985217 8838488013647394583098586552222556859012755036463119837388 17675877127293700155208173104445113717916609973926228685776 85434559390231690817179904258885250898171710713198406543447 159869119879363392534369709517770491895343520326407802086905 669549328583986417877967903595486399858778813690386714055856 1328099746267082736755826897280081709628557528379772538001822 3609108099046820994314095969080909695914133901187399017910053 7109305208984632087628291938171719391818268891473808925929116 13228600507068374076256473877343437783746536693838706950968133 46415506467852213739821212650777815621211803741224777451650364 92721121945594428470632425302655521242424697472450653912201828 175531343881199855950274849515211141594848304954900208824314557 930944772683209315354123344656323657543320364513891397167450128 1751999534476407630817146690412647313986641818027793783444899167 9371983978350384838998613583550109454953058998394840527804890738 17742968065600869777997117178099120008806227996779671066598782477 95171757631618567547969378058101319095977407974576471722685707248 179442516254336035095939856017192629281064804949153053336361424407 883866679887686387045348316200118920991723744539683686788976669378 1757833359775372773980795643399148731994337588080467373577953337766 8435166957529110414789652978390527151927803558974240109357486725337 15770443805068120839588206065682044402866596128848380228615083340685 ... Daniel

1 0