1. 05 Nov, 2018 3 commits
    • Michael Orlitzky's avatar
      Trac #26639: use PEP 289 generator expressions in geometry/cone.py. · 7b512897
      Michael Orlitzky authored
      A generator expression in Python is a more general version of a list
      comprehension. The problem with list comprehensions is that, well,
      they create lists. And often, we don't need the list for anything
      other than to traverse it. In that case, an iterator would be more
      efficient, although the list comprehension syntax is pretty convenient.
      That's where generator expressions come in. The following code creates
      a list of unit-norm generators for the cone K, and then sums its entries:
        sage: K = Cone([(2,0), (0,2)])
        sage: sum([ vector(QQbar,g).normalized() for g in K ])
      However, we don't need that list: we just want the sum. In a generator
      expression, the list brackets are replaced by parentheses, and an
      iterator (as opposed to a list) is returned. In many cases, this is a
      more efficient drop-in replacement for a list comprehension. For
        sage: K = Cone([(2,0), (0,2)])
        sage: sum(( vector(QQbar,g).normalized() for g in K ))
      This commit fixes a few "easy" cases where list comprehensions were
      used, but where generator expressions should work too.
    • Michael Orlitzky's avatar
      Trac #26639: add two missing set_random_seed() calls to geometry/cone.py. · 5fa22d55
      Michael Orlitzky authored
      The set_random_seed() function needs to be called before every test
      that uses randomness. Two were overlooked at some point in the past;
      this commit adds them.
    • Michael Orlitzky's avatar
      Trac #26639: use future-proof range() iterator in geometry/cone.py · e63b0ce8
      Michael Orlitzky authored
      The python-2.x version of range() always returns a list. This can be
      inefficient, if, for example, you're using it to sum a bunch of numbers:
        sage: sum(range(10))
      The code above constructs the entire list [0,1,...,9], and *then* sums
      its entries. Storing the list wastes memory; an iterator that lets us
      consider each element one-at-a-time (without storing the whole list)
      would be more efficient.
      In python-2.x, the xrange() function does what we want. But in
      python-3.x, there is no xrange() -- it's been replaced by a smarter
      version of range()! We don't want to leave the list-building range()
      calls in there for python-2.x, but we can't "upgrade" them to xrange()
      without creating problems for the python-3.x migration down the road.
      So what to do? Fortunately, python-2.6 has the new version of the
      range() function, but it's hidden by default. We gain access to it with
        from six.moves import range
      at the top of geometry/cone.py. This automatically affects all library
      code and doctests in that file, converting their uses of range() to
      iterators. The code has been inspected to make sure that this is
      semantically correct (that is, nothing is really expecting range() to
      return a list).
  2. 04 Nov, 2018 1 commit
  3. 01 Nov, 2018 1 commit
  4. 31 Oct, 2018 10 commits
  5. 30 Oct, 2018 25 commits