Usage of _cached_info

[Rik Schepens]

In my first steps to improve matroid visualization as part of my Bachelor thesis, I wanted to use the cache option as is implemented by Jayant Apte to immediately visualize some standard (named) matroids. For more information see ticket #20175.
My current solution writes the information directly on _cached_info, as is done multiple times in other pieces of code. This _cached_info is just used to store this positioning information. My thesis supervisor (Rudi Pendvingh) mentioned it might be better to use a method instead of saving it directly. This method is already in place and is called _fix_positions. Using this method works just fine if we use it just for adding this information for the matroids in the catalog. Though replacing current (direct saving) code in the plot method within this method gives some errors I wasn't able to identify. (see attachment)

I would love to know some of your opinions on whether to saving directly or using the current method is the preferable way to implement these standard visualizations. And I was also wondering if this method is the preferable way, as I think it might be, then why do these errors appear when this is used in other methods.

Kind regards,
Rik

[Dima Pasechnik]

I notice that matroid code does not make any use of @cached decorator.

Perhaps it could simplify parts of code it it was used.

[Simon King]

On 2016-03-17, Dima Pasechnik <dim...@gmail.com> wrote:
> I notice that matroid code does not make any use of @cached decorator.
> Perhaps it could simplify parts of code it it was used.

Note that it isn't just "@cached", but "@cached_method". See
sage.misc.cachefunc for some variations of the theme (e.g., there is a
decorator for cached functions, for cached methods, for a cache that is
stored in the parent rather than in the element, for using a weak key
dictionary, ...

And it is rather fast. I don't know if your code is Python or Cython.
But if you use a self-made cache in Python, then I wouldn't be surprised
if @cached_method were faster.

Best regards,
Simon

[Stefan van Zwam]

Hi all,

I don’t think the cached_method discussion is relevant here. What we do is save some plot defaults (coordinates of points, possibly others) into the data structure so that a matroid “knows” how it is best drawn, and so that subsequent calls to “plot” or “show” give the same drawing, even if the internal “active” basis has changed.

As for the error, it’s a bit strange. In line 7297, we call that method, apparently with argument pos_dict equal to “None”. But that code is inside an “if” statement prohibiting that! So what I’d do is add a bunch of 

print “Line xxxx”, pos_dict

statements for debugging, so you know exactly what kind of data structure is passed on in each step.

Generally speaking, methods are a cleaner, safer way to do things than direct assignment. That way any changes in future versions of the object are less likely to introduce slumbering errors.

Hope this helps,

Stefan.

--

---
You received this message because you are subscribed to the Google Groups "sage-matroid" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-matroid...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<Fix_positions error>

[Rik Schepens]

Hi Stefan,

The usage cached_method is not that relevant here indeed. Cached_info here is only used to remember visualization preferences and is not used for complex computations.

I found a fix by putting an extra safeguard to the method, to make sure the _cached_info is not left non-existent. I've  also made sure the method is used in other parts of the code in the updated branch. Addition of other matroid positions is on it's way.


Rik

Op maandag 21 maart 2016 02:34:15 UTC+1 schreef Stefan van Zwam: