#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 ncohen):
Yo !
> 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.
Hmmm.. I thought I had a way but it turned out to be wrong. 2sc seems a
lot though `O_o`
> An other idea would be to have only one find function for product +
wilson one truncated + wilson two truncated.
We would only save the time it takes to run the product+wilson
constructions. Either way let's do this on another ticket.
> 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).
I did it this way for the brouwer function because I would have had to add
4 different imports in the same function otherwise.
> 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".
We can actually add this at the top of the file (before the module's doc)
{{{
# cython: cdivision=True
}}}
Other flags are listed there if you are interested:
https://github.com/cython/cython/wiki/enhancements-compilerdirectives
> 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.
I don't mind the imports, if it can be detected then no problem. I just
don't want reviews to become "coding style fights"..... I do mind the 10
lines in exchange for the bad "for', though `:-P`
Can we keep this as it is until we find a proper way to avoid it ?
Nathann
P.S. : Sorry for the delay, I am kind of on "holidays" this week. But
seeing how this goes I feel that I may escape and go back to work much
sooner than expected.
--
Ticket URL: <http://trac.sagemath.org/ticket/16879#comment:34>
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.
