Leif wrote:

> Any reasonable compiler does constant folding and loop-invariant code
> motion; even Python's byte-code compiler should do that.

Almost none is done.  Only the most trivial cases are handled.  For
example, addition:

sage: preparser(False)
sage: type(2)
<type 'int'>
sage: def f():
....:         x = 2+3
....:
sage: dis.dis(f)
  2           0 LOAD_CONST               3 (5)
              3 STORE_FAST               0 (x)
              6 LOAD_CONST               0 (None)
              9 RETURN_VALUE

But not division:

sage: def g():
....:         x = 2/3
....:
sage: dis.dis(g)
  2           0 LOAD_CONST               1 (2)
              3 LOAD_CONST               2 (3)
              6 BINARY_DIVIDE
              7 STORE_FAST               0 (x)
             10 LOAD_CONST               0 (None)
             13 RETURN_VALUE

As for code motion:

sage: def h():
....:         for i in range(10):
....:             if x < (2/3):
....:                 x += 1
....:
sage: dis.dis(h)
  2           0 SETUP_LOOP              51 (to 54)
              3 LOAD_GLOBAL              0 (range)
              6 LOAD_CONST               1 (10)
              9 CALL_FUNCTION            1
             12 GET_ITER
        >>   13 FOR_ITER                37 (to 53)
             16 STORE_FAST               0 (i)

  3          19 LOAD_FAST                1 (x)
             22 LOAD_CONST               2 (2)
             25 LOAD_CONST               3 (3)
             28 BINARY_DIVIDE
             29 COMPARE_OP               0 (<)
             32 JUMP_IF_FALSE           14 (to 49)
             35 POP_TOP

  4          36 LOAD_FAST                1 (x)
             39 LOAD_CONST               4 (1)
             42 INPLACE_ADD
             43 STORE_FAST               1 (x)
             46 JUMP_ABSOLUTE           13
        >>   49 POP_TOP
             50 JUMP_ABSOLUTE           13
        >>   53 POP_BLOCK
        >>   54 LOAD_CONST               0 (None)
             57 RETURN_VALUE


Simon wrote:

> Since we talk about a spyx-file (not pyx), the Sage preparser is
> applied to 2/3, if I am not mistaken. Hence, 2/3 is not 0 but the
> rational number 2/3.

I think you're mistaken.  That's why I brought up the missing decimal
point in the first place, because the comparison was always failing so
it was always taking the maximum number of loops.

sage: cat "spre2.spyx"
print 2, type(2)
print 2/3, type(2/3)
print 2./3, type(2./3)
sage: !touch spre2.spyx
sage: load "spre2.spyx"
Compiling ./spre2.spyx...
2 <type 'int'>
0 <type 'int'>
0.666666666667 <type 'float'>

"NO Sage preparsing is applied to spyx files, e.g., 1/3 will result in
0 in a spyx file instead of the rational number 1/3."


Doug

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to