trac 16005: Waste of time in iterator_edges 2
trac #16091: A missing obvious case for BIBD
Fixed parallelizaion using p_iter_fork.

Fixed parallelizaion using p_iter_fork in src/sage/schemes/projective.projective_morphism.py
Minor changes to fix initial bugs in fix.
Changed code to comply with style.
trac #16005: merge into 6.2.beta8
Switched parallelization to p_iter_fork.
Added documentation on new keyword ncpus.
moved import to header
trac 11669: optimize quaternion algebra elements a bit, in some obvious ways
Get rid of warnings about missing git templates after relocating Sage
Get rid of warnings about missing git templates after relocating Sage
Trac 16305: set (DY)LD_LIBRARY_PATH before MPLCONFIGDIR
Trac #16168: use p_iter_fork in projective_morphism

projective_morphism uses parallel calls in several functions. It uses
the multiprocessing.py function parallel_iter. It seems on OSX that
there is some issue with the function. For example, calling
possible_periods on a function multiple times (usually 50 is sufficient)
will result in a error which varies. This does seem appear to occur on
linux.

The p_iter_fork function seems more stable and does not have this issue.

While we are adjusting how parallel works, I think a ncpus kwd should
also be added.

URL: http://trac.sagemath.org/16168
Reported by: bhutz
Ticket author(s): Dillon Rose
Reviewer(s): Ben Hutz
Trac #16091: A missing obvious case for BIBD

A (v,v,1)-BIBD is a set of size v. Though right now :

{{{
sage: designs.BalancedIncompleteBlockDesign(10,10)
...
ValueError: I don't know how to build this design.
}}}

URL: http://trac.sagemath.org/16091
Reported by: ncohen
Ticket author(s): Nathann Cohen
Reviewer(s): Kannappan Sampath
Trac #16005: Waste of time in iterator_edges 2

As reported by Marc in #15978, `iterator_edges` wastes a lot of time.
Computationally, returning all edges of a graph currently works this
way:

{{{
for each edge E of the graph: # Okay, linear time
    <Something equivalent to checking that E is an edge> # Totally
useless
    return E

}}}

This can be solved by creating a function that is somehow between
- Returning all neighbors of a vertex (which is not sufficient to find
the edges incident to this vertex)
- Work directly with the data structure, i.e. a binary tree

This function is named `out_neighbors_BTNode_unsafe` and does what some
part of the code already did, before throwing the information away. It
builds the list of `BTNodes` describing the [neighbors of/edges incident
to] a vertex, from which all that we need can be deduced.

As a result, the useless computations reported above can be removed.

Nathann

URL: http://trac.sagemath.org/16005
Reported by: ncohen
Ticket author(s): Nathann Cohen
Reviewer(s): Vincent Delecroix
Trac #15901: git-related doctest failures after moving sage installation

I've compiled sage in {{{/local/data/krenn/sage-dev/sage-6.1.1}}} and
then moved it to another directory. I am getting the following when
testing sage:
{{{
File "src/sage/dev/test/config.py", line 43, in
sage.dev.test.config.DoctestConfig
Failed example:
    DoctestConfig()
Expected:
    Config('''
    [trac]
    username = doctest
    ticket_cache = ...
    [UI]
    log_level = 1
    [git]
    ssh_key_set = True
    repository_anonymous = remote_repository_undefined
    repository = remote_repository_undefined
    src = ...
    dot_git = ...
    [sagedev]
    ''')
Got:
    warning: templates not found /local/data/krenn/sage-
dev/sage-6.1.1/local/share/git-core/templates
    Config('''
    [trac]
    username = doctest
    ticket_cache =
/home/krenn/.sage/temp/brown/8826/dir_0ABZH9/ticket_cache
    [UI]
    log_level = 1
    [git]
    ssh_key_set = True
    repository_anonymous = remote_repository_undefined
    repository = remote_repository_undefined
    src = /home/blub/.sage/temp/brown/8826/dir_0ABZH9/repo
    dot_git = /home/blub/.sage/temp/brown/8826/dir_0ABZH9/repo/.git
    user.name = doctest
    user.email = doc@test.test
    user_email_set = True
    [sagedev]
    ''')
}}}
There are a couple of other files with similar warnings.

URL: http://trac.sagemath.org/15901
Reported by: dkrenn
Ticket author(s): John Palmieri
Reviewer(s): Peter Bruin
Trac #16305: sage-env must wait longer before setting MPLCONFIGDIR

When the environment variable `MPLCONFIGDIR` is set by `sage-env`,
`LD_LIBRARY_PATH` has not been set to the correct value yet.  This can
cause the setting of `MPLCONFIGDIR` to fail; see comment:17:ticket:15901
and follow-up comments.  We should move this part of `sage-env` further
down.

URL: http://trac.sagemath.org/16305
Reported by: pbruin
Ticket author(s): Peter Bruin
Reviewer(s): Leif Leonhardy
Trac #11669: optimize quaternion algebra elements a bit, in some obvious ways

This ticket depends on #11670.

There are a couple of simple optimizations to quaternion algebras that
will help a lot with speed.  For example, before this patch:
{{{

sage: K.<a> = NumberField(x^2-x-1); Q.<i,j,k> =
QuaternionAlgebra(K,-1,-1); z=2*i+3*j+4/3*k+5/8
sage: type(z)
<type 'sage.algebras.quatalg.quaternion_algebra_element.QuaternionAlgebr
aElement_generic'>
sage: timeit('~z')
625 loops, best of 3: 115 µs per loop
sage: v = [z+i for i in range(1000)]
sage: time k = loads(dumps(v))
Time: CPU 1.80 s, Wall: 1.80 s
sage: timeit('a*z')
625 loops, best of 3: 96.4 µs per loop
}}}
and after:
{{{
sage: K.<a> = NumberField(x^2-x-1); Q.<i,j,k> =
QuaternionAlgebra(K,-1,-1); z=2*i+3*j+4/3*k+5/8
sage: type(z)
<type 'sage.algebras.quatalg.quaternion_algebra_element.QuaternionAlgebr
aElement_generic'>
sage: timeit('~z')
625 loops, best of 3: 20.6 µs per loop
sage: v = [z+i for i in range(1000)]
sage: time k = loads(dumps(v))
Time: CPU 0.31 s, Wall: 0.31 s
sage: timeit('a*z')
625 loops, best of 3: 4.63 µs per loop
}}}

The changes in the patch to give this "order of magnitude" speedup are
very simple, and will make quaternion arithmetic over all base rings
much faster for certain important operation.  The main idea of the patch
(after I had tried many things and deleted most of them) is just to add
a check parameter to get rid of some coercion that isn't needed, plus
adding lmul and rmul methods generically.  That's it.  But it leads to
6-20 times speedups on basic operations of importance to me.

URL: http://trac.sagemath.org/11669
Reported by: was
Ticket author(s): William Stein
Reviewer(s): R. Andrew Ohana