No. But there are actually a few tests which pass under our testing
framework (bin/test) but not under py.test.  Here's the output

sympy/physics/mechanics/tests/test_kane3.py:253:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _

self = <sympy.physics.mechanics.kane.KanesMethod object at 0x7f921ae68208>
kwargs = {}

    def linearize(self, **kwargs):
        """ Linearize the equations of motion about a symbolic operating
point.

            If kwarg A_and_B is False (default), returns M, A, B, r for the
            linearized form, M*[q', u']^T = A*[q_ind, u_ind]^T + B*r.

            If kwarg A_and_B is True, returns A, B, r for the linearized
form
            dx = A*x + B*r, where x = [q_ind, u_ind]^T. Note that this is
            computationally intensive if there are many symbolic
parameters. For
            this reason, it may be more desirable to use the default
A_and_B=False,
            returning M, A, and B. Values may then be substituted in to
these
            matrices, and the state space form found as
            A = P.T*M.inv()*A, B = P.T*M.inv()*B, where P =
Linearizer.perm_mat.

            In both cases, r is found as all dynamicsymbols in the
equations of
            motion that are not part of q, u, q', or u'. They are sorted in
            canonical form.

            The operating points may be also entered using the ``op_point``
kwarg.
            This takes a dictionary of {symbol: value}, or a an iterable of
such
            dictionaries. The values may be numberic or symbolic. The more
values
            you can specify beforehand, the faster this computation will
run.

            As part of the deprecation cycle, the new method will not be
used unless
            the kwarg ``new_method`` is set to True. If the kwarg is
missing, or set
            to false, the old linearization method will be used. After next
release
            the need for this kwarg will be removed.

            For more documentation, please see the ``Linearizer`` class."""

        if 'new_method' not in kwargs or not kwargs['new_method']:
            # User is still using old code.
            SymPyDeprecationWarning('The linearize class method has changed
'
                    'to a new interface, the old method is deprecated. To '
                    'use the new method, set the kwarg `new_method=True`. '
                    'For more information, read the docstring '
                    'of `linearize`.').warn()
>           return self._old_linearize()

sympy/physics/mechanics/kane.py:494:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _

self = <sympy.physics.mechanics.kane.KanesMethod object at 0x7f921ae68208>

    def _old_linearize(self):
        """Old method to linearize the equations of motion. Returns a tuple
of
            (f_lin_A, f_lin_B, y) for forming [M]qudot = [f_lin_A]qu +
[f_lin_B]y.

            Deprecated in favor of new method using Linearizer class.
Please change
            your code to use the new `linearize` method."""

        if (self._fr is None) or (self._frstar is None):
            raise ValueError('Need to compute Fr, Fr* first.')

        # Note that this is now unneccessary, and it should never be
        # encountered; I still think it should be in here in case the user
        # manually sets these matrices incorrectly.
        for i in self.q:
            if self._k_kqdot.diff(i) != 0 * self._k_kqdot:
                raise ValueError('Matrix K_kqdot must not depend on any q.')

        t = dynamicsymbols._t
        uaux = self._uaux
        uauxdot = [diff(i, t) for i in uaux]
        # dictionary of auxiliary speeds & derivatives which are equal to
zero
>       subdict = dict(list(zip(uaux + uauxdot, [0] * (len(uaux) +
len(uauxdot)))))

sympy/physics/mechanics/kane.py:522:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _

self = Matrix(0, 0, []), other = []

    @wraps(func)
    def binary_op_wrapper(self, other):
        if hasattr(other, '_op_priority'):
            if other._op_priority > self._op_priority:
                try:
                    f = getattr(other, method_name)
                except AttributeError:
                    pass
                else:
                    return f(self)
>       return func(self, other)

sympy/core/decorators.py:118:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _

self = Matrix(0, 0, []), other = []

    @call_highest_priority('__radd__')
    def __add__(self, other):
>       return super(DenseMatrix, self).__add__(_force_mutable(other))

sympy/matrices/dense.py:531:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _

self = Matrix(0, 0, []), other = []

    def __add__(self, other):
        """Return self + other, raising ShapeError if shapes don't match."""
        if getattr(other, 'is_Matrix', False):
            A = self
            B = other
            if A.shape != B.shape:
                raise ShapeError("Matrix size mismatch.")
            alst = A.tolist()
            blst = B.tolist()
            ret = [S.Zero]*A.rows
            for i in range(A.shape[0]):
                ret[i] = list(map(lambda j, k: j + k, alst[i], blst[i]))
            rv = classof(A, B)._new(ret)
            if 0 in A.shape:
                rv = rv.reshape(*A.shape)
            return rv
>       raise TypeError('cannot add matrix and %s' % type(other))
E       TypeError: cannot add matrix and <class 'list'>

sympy/matrices/matrices.py:579: TypeError
------------------------------- Captured stderr
--------------------------------
/home/ptb/gitrepos/sympy/sympy/physics/mechanics/kane.py:493:
SymPyDeprecationWarning:

The linearize class method has changed to a new interface, the old
method is deprecated. To use the new method, set the kwarg
`new_method=True`. For more information, read the docstring of
`linearize`.

  'of `linearize`.').warn()


On Fri, Sep 26, 2014 at 9:28 AM, Jason Moore <moorepa...@gmail.com> wrote:

> BTW, Peter, did that kane3 test pass on your machine?
>
>
> Jason
> moorepants.info
> +01 530-601-9791
>
> On Fri, Sep 26, 2014 at 11:27 AM, Jason Moore <moorepa...@gmail.com>
> wrote:
>
>> It is certainly too slow to be a useful test. But that example should be
>> available to run at least before any SymPy release. We have many unit tests
>> in the mechanics package, but that example provides a minimal example that
>> exercises almost all of the functionality in the Kane class. I'd personally
>> like a suite of benchmark multibody dynamics problems with known results
>> that we could run to exercise the mechanics package, with this example as
>> one.
>>
>> But regardless, it is fine to skip it now because it obviously is not
>> working and we haven't fixed that.
>>
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>> On Fri, Sep 26, 2014 at 11:21 AM, James Crist <crist...@umn.edu> wrote:
>>
>>> The `test_kane3` test I think is not a good test in general. It's going
>>> to run slow, and personally I've never had it complete (although my laptop
>>> is slow). It's a fine example of the capabilities of our library, but as a
>>> test - not so good. I doubt the rest of the mechanics team would agree with
>>> me on removing it though, so perhaps a veryslow tag should be used?
>>>
>>> - Jim
>>>
>>>
>>> On Friday, September 26, 2014 10:13:33 AM UTC-5, Peter Brady wrote:
>>>>
>>>> Thanks to some recent PR's I was able to run the slow tests under
>>>> py.test which supports a --durations flags.  Here are the slowest of the
>>>> slow tests:
>>>>
>>>> ========================== slowest 15 test durations
>>>> ===========================
>>>> 6745.05s call     sympy/physics/mechanics/tests/test_kane3.py::
>>>> test_bicycle
>>>> 2083.29s call     sympy/solvers/tests/test_ode.py::test_1st_exact2
>>>> 1522.66s call     sympy/integrals/tests/test_failing_integrals.py::
>>>> test_issue_4540
>>>> 1221.33s call     sympy/core/tests/test_wester.py::test_W25
>>>> 1090.84s call     sympy/integrals/tests/test_failing_integrals.py::
>>>> test_issue_4941
>>>> 963.31s call     sympy/solvers/tests/test_solvers.py::test_issue_6528
>>>> 437.72s call     sympy/integrals/tests/test_heurisch.py::test_pmint_
>>>> WrightOmega
>>>> 411.27s call     sympy/core/tests/test_wester.py::test_W24
>>>> 138.77s call     sympy/polys/tests/test_groebnertools.py::test_
>>>> benchmark_czichowski_buchberger
>>>> 111.14s call     sympy/integrals/tests/test_failing_integrals.py::test_
>>>> issue_4891
>>>> 108.96s call     sympy/functions/elementary/tests/test_trigonometric.py
>>>> ::test_tancot_rewrite_sqrt
>>>> 90.53s call     sympy/stats/tests/test_finite_rv.py::
>>>> test_binomial_symbolic
>>>> 67.98s call     sympy/core/tests/test_wester.py::test_W6
>>>> 62.59s call     sympy/simplify/tests/test_hyperexpand.py::test_
>>>> prudnikov_3
>>>> 48.68s call     sympy/simplify/tests/test_hyperexpand.py::test_
>>>> prudnikov_8
>>>>
>>>>
>>>> Currently the timeout limit is set to 180s on the slow  tests and due
>>>> to issues with travis, the signal does not appear to always be respected
>>>> leading to travis timeout errors.  I think there are two good solutions to
>>>> this problem:
>>>>
>>>> 1. Mark all the tests which report runtimes over 180s as skip
>>>>
>>>> 2. Introduce a new mark 'veryslow` or something like that so that these
>>>> tests can still be run if someone chooses by setting the appropriate flag.
>>>>
>>>> Any thoughts? Votes?
>>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "sympy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to sympy+unsubscr...@googlegroups.com.
>>> To post to this group, send email to sympy@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/sympy.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sympy/97a9bf63-6db9-4b94-870d-ebbeeb59c7d9%40googlegroups.com
>>> <https://groups.google.com/d/msgid/sympy/97a9bf63-6db9-4b94-870d-ebbeeb59c7d9%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "sympy" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sympy/xDM4NHWP9cA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sympy+unsubscr...@googlegroups.com.
> To post to this group, send email to sympy@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAP7f1AjrdBMsW8WMTT_qbLhUEDgG7MrXQO6gL1jy3Pj6eOVJaQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CAP7f1AjrdBMsW8WMTT_qbLhUEDgG7MrXQO6gL1jy3Pj6eOVJaQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CALoNiQexCaKgXTktGCkK3c%2BaSWbPRAEJMR6JAY9SeMkNxz7D%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to