There are many places where Sage provides a nice frontend class while the
actual computation is implemented differently. Of course you could just use
libsingular directly to compute with polynomial, right? ;-)
In particular, it would be perfectly reasonable to have a "frontend" class
that acts as a parent (like Set) and deals with the whole translation of
arbitrary symbols into range(n) and non-time-critical constructions. Then a
specialized "backend" code just works with lists of lists of integers, say.
And once you find that the backend isn't fast enough you can switch to C++
and use std::set, say. Without having to deprecate the user interface.
On Saturday, June 7, 2014 8:14:41 AM UTC+1, vdelecroix wrote:
>
> > Actually, I was kind of surprised that they were just lists of lists
> when I
> > was looking at the code. Surely one wants more structure than that, or
> > don't they have more structure? This is exactly the kind of thing we
> are
> > just talking about with the game theory code - we want a class because
> you
> > want to *do* something with it. Tab-completion rules! But I suppose
> it's
> > possible that all these designs really are just lists of lists.
>
> Yes, a combinatorial design is basically a set of subsets. The current
> code of combinatorial design is intended to do lengthy computation for
> constructing them. It is already a lot of time to run the code.
> Involving some badly designed class would be at the moment the worse
> thing to do. As an example
>
> sage: timeit("for s in Subsets(range(5)): pass") # return Set
> 125 loops, best of 3: 3.97 ms per loop
> sage: timeit("for s in subsets(range(5)): pass") # return list
> 625 loops, best of 3: 53.3 µs per loop
>
> I am not saying that we do not need a proper class (note: there is
> already IncidenceStructure). There are many things that one would like
> to do with an orthogonal array:
> - getting various graphs from it
> - computing automorphism groups
> - comparing isomorphism with another one
> - looking for substructures
> - etc
>
> But right now, what Nathann is trying to do is rather orthogonal to
> these questions. If somebody comes with a nice class that *does not*
> slow down his construction code, everybody will be happy. Sage is open
> to contributions and not only to critics ;-P
>
> >> It is still largely possible to refactor the code, especially the
> >> functions that are available from the global namespace. And it can be
> >> done easily as it is just about modifying "design_catalog.py" which is
> >> rather independent from the coming tickets.
> >
> >
> >> For the internals, many constructions in combinatorial designs are
> >> recursive and complicated. So separating the existence from
> >> construction means do an exact copy of the code. The boolean answer is
> >> just intended to cut the actual construction (the object are rather
> >> big). So we can not live with two functions. On the other hand, this
> >> function can be hidden from the global namespace.
> >
> > I guess I'm just surprised you need two functions; why can't you have
> one
> > (underscore?) function that both of them call? That is what was
> surprising
> > to me, if it really is an *exact* copy of the code?
>
> more precisely:
> {{{
> if construction_X_is_possible(k,n):
> if existence: return True
> else: return build_the_design_with_X(k,n) # long time
> }}}
> But see Volker proposal about a function which returns None or functions
> as in
> {{{
> if construction_X_is_possible(k,n):
> return build_the_design_with_X
> }}}
>
> > Thanks both Nathann and Vincent for explaining some of the more
> technical
> > details.
>
> Thanks for having a look into this.
>
> Vincent
>
--
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/d/optout.
