On Wed, Nov 07, 2012 at 03:20:05PM -0800, Andrew Mathas wrote:
> Thanks for this Nicolas. I didn't know that you had identified the
> problem.
Well, I identified the main issue that Meinholf had pointed out during
his talk; I can't swear there were/are not others!
> I think that I have now officially migrated to sage
Yippee :-)
> but certainly in the back of my mind there was a niggling worry
> that this might be an issue down the track. I was hoping that the
> issue wasn't ultimately the category and coercion models as I
> know from debugging that they both do an awful lot behind the
> scene when objects are created (for example when taking linear
> combinations of objects)...
In principle, once parents/... are set up properly, doing plain linear
combinations should not do any unneeded coercion or call to unrelated
category code.
If you encounter use cases where the code is slower than it ought to
be, please send it here for analysis! More often than not those are
due to trivial oversights, or are amenable to very localized
optimizations that benefit a large range of feature.
> I don't understand what facade does so this might be naive, but if this is
> the way you think that these parental variations should work wouldn't it
> make more sense for the facade=True to be automatically imposed as part of
> the definition of Partitions(3, order=...)?
Please see:
sage: S = Sets()
sage: S.Facade?
Depending on the use case you want or not your parent to be a facade,
so this should be left as an option.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
