#16879: OA caching in C
-------------------------------------+-------------------------------------
Reporter: ncohen | Owner:
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.4
Component: combinatorial | Resolution:
designs | Merged in:
Keywords: | Reviewers:
Authors: Nathann Cohen | Work issues:
Report Upstream: N/A | Commit:
Branch: public/16879 | 3db376f043c01b5ff58e46a845bb69e704c1eacf
Dependencies: #16875 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by vdelecroix):
Replying to [comment:32 ncohen]:
> Helloooooo !!!
>
> > I understand, but there is really something to improve here... no
problem to remove my modifications but then what?
>
> What about forgetting the lower bound ? This trick was there to save
calls to `orthogonal_array(existence=True)` but now that we have this cdef
function it's fine and it does not cost very much to check whether there
exists a `OA(q+15,q)`. And it will become the the usual for loop
afterward, with the 'range' replaced by C code.
Nope. I made a mistake the first time I tried and just set the lower bound
to k+1 instead of 1. And guess what... you win like 2 secs (and all tests
pass)! There are three level of loops and adding one test case to the
first one costs. I can redo the timings if you wish.
It would be a good thing to see if corner cases (like m=1 or t=1 in Wilson
constructions with one or two truncated blocks) are not handled by other
constructions. These corner cases seem to be really expansive.
An other idea would be to have only one find function for product + wilson
one truncated + wilson two truncated.
> > A very big cost, indeed!! I split the commits into two. The second one
is about imports. The following timings refer to %time MOLS_table(60)
> > - with the head at 093ace3 (with the imports as you did): 12.9 s
> > - with the head at 680d22b (with the import on top): 12.7 s
>
> God. It can actually be detected ? `O_o`
Not really. I would have said that 0.02 seconds is not significant (see
the timings below). But still you have strange conventions: sometimes you
put the import as the first line of the function and sometimes you put the
import just before the return. I would prefer to have everything
standardized (and I guess just before return is faster).
> By the way, the `%` and `/` and `//` operators are not translated into
pure Cython code as they should. There is still some Python code about
handling the /0 and %0 cases. There is a workaround though:
>
> https://github.com/cython/cython/wiki/enhancements-division
>
WTF. With pure C variable we still get some crazy Python translations!
Cython is sometimes very nice but sometimes really annoying. I dream of a
special flag that allows you to say "do not translate this block to
anything, this is pure C and I known what I am doing".
Timings:
{{{
commit 3db376f043c01b5ff58e46a845bb69e704c1eacf (yours)
MOLS_table(30) 4.66 s
MOLS_table(60) 13.4 s
MOLS_table(90) 26.3 s
commit 093ace30591e1beed6296c9e5bd16afa37188e4b (my first set of optim)
MOLS_table(30) 4.4 s
MOLS_table(60) 12.7 s
MOLS_table(90) 24.6 s
commit 680d22b2d7dba0c39a0953be1532590ec6bd7113 (the imports)
MOLS_table(30) 4.42 s
MOLS_table(60) 12.7 s
MOLS_table(90) 24.2 s
}}}
conclusion: the win of moving the imports part is small. Depending on what
you think for this ticket I will split my first commit to see what
matters.
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/16879#comment:33>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
