New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix test failure on Windows (floating point equality) #12762

Merged
merged 1 commit into from Jun 19, 2017

Conversation

Projects
None yet
4 participants
@bjodah
Member

bjodah commented Jun 17, 2017

This supersedes gh-12755

@moorepants

This comment has been minimized.

Show comment
Hide comment
@moorepants

moorepants Jun 17, 2017

Member

As a side note, I've always thought we should have at least some tests run on appveyor. I've had to fix a number of codegen, autowrap bugs for windows and if we ran tests for them it'd help keep them from breaking.

Member

moorepants commented Jun 17, 2017

As a side note, I've always thought we should have at least some tests run on appveyor. I've had to fix a number of codegen, autowrap bugs for windows and if we ran tests for them it'd help keep them from breaking.

@asmeurer

This comment has been minimized.

Show comment
Hide comment
@asmeurer

asmeurer Jun 17, 2017

Member

But in my experience appveyor can be even slower than Travis.

Member

asmeurer commented Jun 17, 2017

But in my experience appveyor can be even slower than Travis.

@moorepants

This comment has been minimized.

Show comment
Hide comment
@moorepants

moorepants Jun 17, 2017

Member

We only have to run a very small subset of tests on appveyor, not the whole suite, as the vast majority of sympy code is portable with little concern.

Member

moorepants commented Jun 17, 2017

We only have to run a very small subset of tests on appveyor, not the whole suite, as the vast majority of sympy code is portable with little concern.

@bjodah

This comment has been minimized.

Show comment
Hide comment
@bjodah

bjodah Jun 17, 2017

Member

Yes, I would say let's run 80% of the tests on appveyor (--veryquickcheck)—should only take a couple of minutes―and then all the codegen tests. (that will be a considerable effort to setup though).

Member

bjodah commented Jun 17, 2017

Yes, I would say let's run 80% of the tests on appveyor (--veryquickcheck)—should only take a couple of minutes―and then all the codegen tests. (that will be a considerable effort to setup though).

@asmeurer

This comment has been minimized.

Show comment
Hide comment
@asmeurer

asmeurer Jun 17, 2017

Member

I mean even for the startup time. It could have changed, but I remember the queue for AppVeyor is even worse than Travis.

That isn't to say I'm against it, but we should be aware that it could be an issue.

Member

asmeurer commented Jun 17, 2017

I mean even for the startup time. It could have changed, but I remember the queue for AppVeyor is even worse than Travis.

That isn't to say I'm against it, but we should be aware that it could be an issue.

@asmeurer

This comment has been minimized.

Show comment
Hide comment
@asmeurer

asmeurer Jun 17, 2017

Member

I wonder if there's a reason that tan is defined that way.

Member

asmeurer commented Jun 17, 2017

I wonder if there's a reason that tan is defined that way.

@bjodah

This comment has been minimized.

Show comment
Hide comment
@bjodah

bjodah Jun 17, 2017

Member

I don't know, do you remember @catchmrbharath ?
I'm thinking it's to save typing (sin and cos functions are quite lengthy)

About appveyor: if we have a private CI server (to avoid waiting time) that runs the quick 80% of the tests first, and upon success spawns linux/mac/windows builds on circleci/travis/appveyor I think waiting times would be considerably reduced. But there is always an overhead with additional infrastructure (handling login credentials, uptime etc.).

Member

bjodah commented Jun 17, 2017

I don't know, do you remember @catchmrbharath ?
I'm thinking it's to save typing (sin and cos functions are quite lengthy)

About appveyor: if we have a private CI server (to avoid waiting time) that runs the quick 80% of the tests first, and upon success spawns linux/mac/windows builds on circleci/travis/appveyor I think waiting times would be considerably reduced. But there is always an overhead with additional infrastructure (handling login credentials, uptime etc.).

@catchmrbharath

This comment has been minimized.

Show comment
Hide comment
@catchmrbharath

catchmrbharath Jun 19, 2017

Contributor

The interval math logic would take care of how to calculate intervals for tan, because it is defined for sin and cos and the operator '/'. Defining how tan works on intervals separately would involve some logic, which I avoided at that point.

Contributor

catchmrbharath commented Jun 19, 2017

The interval math logic would take care of how to calculate intervals for tan, because it is defined for sin and cos and the operator '/'. Defining how tan works on intervals separately would involve some logic, which I avoided at that point.

@bjodah bjodah merged commit b3ad81b into sympy:master Jun 19, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@bjodah

This comment has been minimized.

Show comment
Hide comment
@bjodah
Member

bjodah commented Jun 19, 2017

@bjodah bjodah deleted the bjodah:intervalmath_tan branch Jun 19, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment