Will Dana's profile - activity

Having dug into the source of the arrangements package, I see that the constructor for arrangements sorts the supplied list of hyperplanes, which is what causes the scrambling mentioned in the first bullet point. I believe this will happen both when I construct the arrangement I start with and when I restrict, so I decided it was not worth the trouble of unscrambling these sorting operations.

Instead, I tried to use the workaround of the second bullet point, just using the equations of the hyperplanes (which I know) and evaluating them at representative points of all the regions (which I can delegate to Sage). At this point, it was simpler just to directly work out equations for the hyperplanes in the restriction and construct the actual hyperplane arrangement object from that. For reference, though, the way Sage does this automatically is to choose the variable with the largest coefficient in the equation of the hyperplane H to restrict to (breaking ties by choosing the first such variable) and eliminate that variable from the equations of the other hyperplanes by subtracting off a multiple of the equation of H.

I have a way of constructing hyperplane arrangements, which involves taking the restriction of a larger arrangement to one of the hyperplanes in it. I want to output a list of the sign vectors of the regions of this arrangement, where the order of the coordinates in the sign vector corresponds to a specific order I want to impose on the hyperplanes. This has turned out surprisingly tricky, because of a couple of seemingly arbitrary decisions Sage's hyperplane arrangement package makes:

• The hyperplane arrangement constructor seems to not preserve the order of the hyperplanes fed into it, so if I just run the built-in sign_vector method, the coordinates of the resulting vectors may be rearranged from how I want them.
• On the other hand, I'm not sure how to go about manually determining the sign vector, because I'm not sure how Sage decides to coordinatize the hyperplanes in the restricted arrangement. So while I have equations for the hyperplanes in the original ambient space, I'm not sure how I could automatically turn them into equations in the hyperplane I'm restricting to.

Does anyone have advice on how to systematically resolve either of these arbitrary decisions, or how to find a different workaround?

I believe I've found the issue. The __init__() referred to in the error message seems to be that of the class I'm defining. Presumably when I run the path_semigroup() method, it attempts to initialize a new DoubleQuiver for some reason, and includes an input for the "weighted" argument, something that the DiGraph constructor takes but the DoubleQuiver constructor, as written, does not.

Inserting **kwargs into the arguments of __init__ and the call it makes to DiGraph's __init__ appears to fix the problem by allowing for any missing arguments:

def __init__(self, digraph, multiedges=True, **kwargs):
edges = []
self._edgePairs = {}
for e in digraph.edges():
    self._edgePairs[(e[0], e[1], e[2] + '0')] = (e[1], e[0], e[2] + '1')
    self._edgePairs[(e[1], e[0], e[2] + '1')] = (e[0], e[1], e[2] + '0')
    edges.append((e[0], e[1], e[2] + '0'))
    edges.append((e[1], e[0], e[2] + '1'))
super(DoubleQuiver, self).__init__(edges, multiedges=True, **kwargs)

An aside: Another problem that this revealed, which provides further evidence that path_semigroup() calls __init__ again, is that the resulting path semigroup actually had all the arrows doubled again. I fixed this by checking whether the digraph input to __init__ is already an instance of DoubleQuiver.

I would like to do some computations with preprojective algebras, variations on the path algebra of a quiver in which every arrow has a partner going the other direction. I will want to construct representations of the "double quiver" in which I can conveniently compare the linear map associated to each arrow to that of its partner.

I figured I should create a class (something I haven't done in Python before) inheriting from DiGraph which has the extra data of a dictionary pairing the edges. My code to do this, with the constructor taking an arbitrary quiver and adding reversed copies of all the edges, is as follows:

class DoubleQuiver(sage.graphs.digraph.DiGraph):
def __init__(self, digraph):
    edges = []
    self._edgePairs = {}
    for e in digraph.edges():
        self._edgePairs[(e[0], e[1], e[2] + '0')] = (e[1], e[0], e[2] + '1')
        self._edgePairs[(e[1], e[0], e[2] + '1')] = (e[0], e[1], e[2] + '0')
        edges.append((e[0], e[1], e[2] + '0'))
        edges.append((e[1], e[0], e[2] + '1'))
    super(DoubleQuiver, self).__init__(edges, multiedges=True)

def flip(self, edge):
    assert edge in self.edges()
    return self._edgePairs[edge]

If I make a test digraph and run

DoubleQuiver(test)

it runs fine, and running methods like edges() or vertices() produces the results I expected. However, when I attempt to evaluate

DoubleQuiver(test).path_semigroup()

I get an error:

Error in lines 1-1
Traceback (most recent call last):
  File "/cocalc/lib/python2.7/site-packages/smc_sagews/sage_server.py", line 1234, in execute
    flags=compile_flags), namespace, locals)
  File "", line 1, in <module>
  File "/ext/sage/sage-8.9_1804/local/lib/python2.7/site-packages/sage/graphs/digraph.py", line 2511, in path_semigroup
    return PathSemigroup(self)
  File "sage/misc/classcall_metaclass.pyx", line 335, in sage.misc.classcall_metaclass.ClasscallMetaclass.__call__ (build/cythonized/sage/misc/classcall_metaclass.c:1741)
    return cls.classcall(cls, *args, **kwds)
  File "/ext/sage/sage-8.9_1804/local/lib/python2.7/site-packages/sage/quivers/path_semigroup.py", line 118, in __classcall__
    Q = Q.copy(immutable=True, weighted=True)
  File "/ext/sage/sage-8.9_1804/local/lib/python2.7/site-packages/sage/graphs/generic_graph.py", line 1206, in copy
    data_structure=data_structure)
TypeError: __init__() got an unexpected keyword argument 'weighted'

How should I modify my class definition to avoid this error, or is there a better way of accomplishing what I'm trying to do? (Also, is it relevant that I'm trying this on CoCalc?)