Hi y'all... On 2013-10-18, Nils Bruin <nbr...@sfu.ca> wrote: > It seems to me that the digraph can certainly not be expected to be > independent of time. So indeed, if X, Z are first created, they are not > related. Only when Y gets created with an embedding into Z and a coercion > from X do we get a path. Presently I think the absence of a coercion > between X and Z also gets cached, so if this absence was discovered before > the creation of Y then even after the creation of Y one would find no > coercion. > > It's pretty obvious that to get strict conformance, one would have to scrub > caches for possibly invalidated data when the graph gets modified. One > wouldn't just want to invalidate all of the cache, though. So finding a > workable balance (perhaps not invalidating any cache?) would be preferable.
Finding a good balance will be very difficult, I am afraid. First of all, caching the absence of a coercion is important for speed. I do not have a create example in mind, but I expect that dropping the "absence caching" would result in a massive general slow-down. The situation we care about is this: A new node P (=Parent) is inserted into the coercion digraph or an existing node P is modified, such that this node becomes a non-sink and non-source in the digraph. Then there is the possibility that previously unconnected nodes of the digraph can now be connected by a path via P. In order to really get the coercion cache clean, we would need to consider all nodes Q that can be reached by a directed path starting at P and all nodes R such that P can be reached by a directed path starting at R. For all such Q and R, we need to remove the item Q._coerce_from_hash[R] if its current value is None. I doubt that this would be feasible! Thus it seems to me we have a "trilemma": We have the choice to 1. not cache the absence of a coercion, likely resulting in a slow-down. 2. preserve the status quo and live with the fact that some coercions can not be discovered. 3. introduce a very expensive operation (inspecting all nodes Q and R as above) whenever we add an incoming arrow to a node P that already has an outgoing arrow or add an outgoing arrow to a node P that already has an incoming arrow. Do you see further options? What would you suggest to do? Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
