Skip to content
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

Refactor @round to transform a+b to +(a, b, RoundDown) #188

Merged
merged 54 commits into from
Jan 30, 2017

Conversation

dpsanders
Copy link
Member

@dpsanders dpsanders commented Jan 9, 2017

Transforms e.g.

@round(a.lo+b.lo, a.hi+b.hi)

to

Interval(+(a.lo, b.lo, RoundDown), +(a.hi, b.hi, RoundUp))

@dpsanders dpsanders changed the title Refactor so transforms to Refactor @round to transform a+b to +(a, b, RoundDown) Jan 9, 2017
@lbenet
Copy link
Member

lbenet commented Jan 9, 2017

Tests are not passing...

@dpsanders
Copy link
Member Author

Yes, unfortunately that will require quite a lot of work. But I think this is a good direction to go in.

@coveralls
Copy link

coveralls commented Jan 24, 2017

Coverage Status

Coverage decreased (-27.7%) to 64.851% when pulling b724ebe on refactor_rounding into 50eb702 on master.

@codecov-io
Copy link

codecov-io commented Jan 24, 2017

Current coverage is 90.70% (diff: 85.90%)

Merging #188 into master will decrease coverage by 1.80%

@@             master       #188   diff @@
==========================================
  Files            21         23     +2   
  Lines           988        990     +2   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits            914        898    -16   
- Misses           74         92    +18   
  Partials          0          0          

Powered by Codecov. Last update 50eb702...7e67cbd

@coveralls
Copy link

coveralls commented Jan 24, 2017

Coverage Status

Coverage decreased (-27.8%) to 64.683% when pulling a7fc08e on refactor_rounding into 50eb702 on master.

@coveralls
Copy link

coveralls commented Jan 24, 2017

Coverage Status

Coverage decreased (-27.8%) to 64.683% when pulling e6b1f6f on refactor_rounding into 50eb702 on master.

@coveralls
Copy link

coveralls commented Jan 24, 2017

Coverage Status

Coverage decreased (-27.8%) to 64.683% when pulling e6b1f6f on refactor_rounding into 50eb702 on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-16.0%) to 76.511% when pulling e02bf46 on refactor_rounding into 50eb702 on master.

2 similar comments
@coveralls
Copy link

Coverage Status

Coverage decreased (-16.0%) to 76.511% when pulling e02bf46 on refactor_rounding into 50eb702 on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-16.0%) to 76.511% when pulling e02bf46 on refactor_rounding into 50eb702 on master.

@dpsanders
Copy link
Member Author

Tests are passing on 0.4 and 0.5, and almost on 0.6 with known issues (one in FixedSizeArrays.jl, and the other in Base). cc @lbenet

@dpsanders
Copy link
Member Author

I split out the rounding macros into a new file, rounding_macros.jl.
(Actually there is now only one rounding macro.)

@dpsanders
Copy link
Member Author

dpsanders commented Jan 28, 2017

I should say that part of the motivation for this whole change, which was in my head but not necessarily mentioned anywhere, was that this will make it much easier to experiment with different types of rounding: the only place that needs to be changed are now the definitions in rounding.jl!

EDIT: See the rounding_modes branch for an example. The ROUNDING variable can be taken e.g. from an environment variable. In Julia 0.6 it will be possible to change this interactively by just redefining all these functions!

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.9%) to 90.597% when pulling bafad26 on refactor_rounding into 50eb702 on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.8%) to 90.698% when pulling bafad26 on refactor_rounding into 50eb702 on master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage decreased (-1.8%) to 90.698% when pulling bafad26 on refactor_rounding into 50eb702 on master.

@dpsanders
Copy link
Member Author

Tests are passing on 0.4 and 0.5. I think this is ready to merge!

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.8%) to 90.698% when pulling 7e67cbd on refactor_rounding into 50eb702 on master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage decreased (-1.8%) to 90.698% when pulling 7e67cbd on refactor_rounding into 50eb702 on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.8%) to 90.707% when pulling 7e67cbd on refactor_rounding into 50eb702 on master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage decreased (-1.8%) to 90.707% when pulling 7e67cbd on refactor_rounding into 50eb702 on master.

Copy link
Member

@lbenet lbenet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you included the documentation for the macros? I think it would be useful in this PR.

I must admit that I feel unconfortable with the current implementation: For x = @biginterval(27), x^(1/3) does not include the true answer! Simply, try it with displaymode(format=:full).

In any case, this is almost ready!

end

^(a::Interval{BigFloat}, x::AbstractFloat) = a^big(x)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about setting it back as it was before?

@dpsanders
Copy link
Member Author

The macro documentation is in rounding_macros.jl -- see https://github.com/dpsanders/ValidatedNumerics.jl/blob/7e67cbd3cbf3b895a29c8839221f3f9e0bb7ff3e/src/intervals/rounding_macros.jl

Is that what you were looking for?

Since 1/3 is not the true one third, x^(1/3) doesn't need to contain the "true" answer for the true one-third power.

I see this as analogous to the fact that you can do Interval(1/3) if you want to use the floating-point number closest to the true one third, or use @interval(1/3) if you want to include the true one third.

Similarly you can do x^(1/3) to use the floating-point value 1/3, or e.g. x^(1//3) to use the true real number one third.

@dpsanders
Copy link
Member Author

I think we should merge this and can come back and change things later if necessary.

@lbenet
Copy link
Member

lbenet commented Jan 30, 2017

Ok. I'm merging.

@lbenet lbenet merged commit d059a3b into master Jan 30, 2017
@dpsanders
Copy link
Member Author

Thanks!

@@ -155,6 +155,25 @@ end

//(a::Interval, b::Interval) = a / b # to deal with rationals

if VERSION >= v"0.6.0-dev"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this won't work for all 0.6-dev versions, should be more specific about version-depedent cutoffs or use isdefined

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean isdefined(:Iterators)? I don't know how to find the exact cutoff where this change was made. In any case, if it's a dev version isn't the expectation that people will keep updating it to the latest version?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be a PR linked to in NEWS or otherwise not too hard to find, and there's the contrib/commit-name.sh script you can use


if VERSION < v"0.5"
min(x) = x
max(x) = x
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since you've imported these, this is type piracy and could change the behavior of other unrelated code

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are just not defined on 0.4. Do you mean that I should change this to VERSION <= v"0.4"?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I mean do you need to be extending a base method on base types? If these are backporting something that worked in later versions of Julia, is it available in Compat?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are indeed backporting something that is in 0.5 onwards. It is not available in Compat, but probably should be. JuliaLang/Compat.jl#313

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated in master to use the correct precise versions, thanks.

@@ -0,0 +1,75 @@
# Define rounded versions of elementary functions
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

didn't you have PR's to add these to base?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, just for BigFloat constructors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants