On Nov 7, 2006, at 10:02 PM, William Stein wrote: > On Tue, 07 Nov 2006 09:31:43 -0800, <[EMAIL PROTECTED]> wrote: > >> %sage >> notebook code >> notebook code >> notebook code >> >> %html >> ... >> ... >> >> %sage >> notebook code >> notebook code >> >> Would you be allowed to switch contexts within a control structure? > > Hmm. My first thought is "heavens no" (mainly because in Python it > is impossible to modify the locals() dictionary). > >> >> class foo: >> %sagex #this is useful >> def bar(self,n): >> return n*n >> >> %sage >> def baz(self,m): >> n = float(m^3) #that's an exponent >> %sagex #getting ugly... >> cdef double p >> p = n**(-2) >> n = p - n >> %python #holy crap >> k = int(n*100000) >> k = k ^ int(m) #that's an xor >> return p*k
I think the %context thing works great at the top of a cell, but I think it could get very ugly in a file, and not just in control structures. For instance, imagine having a function at the top of a class, and just moving it to the bottom hand having it give different results due to some %pyrex or %python or %sage command (or two or three) somewhere in the middle of the file. There's no obvious place to look to determine your current context--it could be anywhere between where you are now and the top of the file. >> I kinda like how pyrex does it. Maybe you could _judiciously_ add >> a few >> new defs. >> >> xdef -> sagex >> fdef -> f2py >> wdef -> weave > > That might work. That's an interesting idea I hadn't considered, > namely > if a .sage file has > > cdef foo(n,m): > ... > > then the whole body is considered Pyrex. I.e., currently the way > Pyrex works it takes the entire .pyx file and makes it into a c file > that is compiled into an extension. Often big chunks of the file are > in fact plain python code. An alternative would be to somehow > *merge* .pyx into .sage, so that any blocks of code that involve > cdef's (etc.) actually get pyrexed, but the non-cdef stuff all stays > as normal Python. Very interesting. The resulting merged language > could be properly called "SageX". I like this idea much better, things have a more obvious scope. I'm not sure how it would work implementation wise, but it has always seemed like such a waste to me that huge chunks of python code get turned into c and compiled to be able to use it anywhere in the file. It could also speed up compile time a lot (perhaps a recompile would not even always be necessary) though it could be subtle when pyrex is being used (e.g. if values of self are referred too nothing need be explicitly cdef'd). >> I think the coolest thing about sage is that it's native language is >> python. I personally believe that any programmer worth h(er|is) salt >> should be able to rapidly switch between 3 to 10 languages at a time. > > I can't do that. That's one of the reasons I like Pyrex -- it looks > almost the same as Python, so I can have C speed and access to C > libraries > while not having to think that I'm switching from Python to C and > back all the time (with the accompanying messed up braces and > semicolons...). > >> However, that's a poor philosophy when one wants to attract student >> programmers, or worse, SAGE users (mathematicians, many of whom don't >> trust computers already). > > Yes, the primary audience for SAGE is definitely not "programmers > worth > h(er|is) salt" in the sense you describe above! > > William > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
