Comments (10)
What do you think about this @lbenet?
from intervalarithmetic.jl.
I think the default should be to get the tightest intervals, and it that sense, it shouldn't be the default. I wouldn't mind to have it as default for the :wide
rounding mode, though.
Do you think that the current ^
could be speed-up using power_by_squaring
somewhere?
from intervalarithmetic.jl.
In this particular case, I don't agree. The reason is simply that using the tight ^
requires the use of BigFloat
(rounding powers is difficult), and hence is reaallly slooow.
For a real use case I just tried, just changing the two instances of ^
to pow
in a function that is evaluated many times gave a 10x speedup.
As soon as power_by_squaring
is used, tightness is lost -- but (a lot of) speed is gained.
(I believe it is still possible to speed up, and possibly make more accurate, pow
in :errorfree
mode.)
I also don't think that we should change the behaviour based on the rounding type (more than is necessary).
from intervalarithmetic.jl.
Just to make my point clear: I am in favor of the slow version (^
), since it assures tighter intervals.
My comment about the :wide
mode is, simply, that in this case we already loose the tightness of the intervals, and therefore it may be appropriate to have ^
equivalent to
pow`. But I guess this may complicate things a lot.
You are probably right; using Base.power_by_squaring
may not be useful as such to get tighter intervals. What I had in mind was to use the same algorithm but with tighter versions (e.g., a^2
instead of a*a
). I'll think about it...
from intervalarithmetic.jl.
My proposal is not to remove the tight version, just to not make it the default.
In my opinion, it's more of a "gotcha" (unpleasant, unexpected outcome) to surprise the user by making the standard functions too slow, rather than to document that a very slightly tighter option is the pow
function (in the new version).
from intervalarithmetic.jl.
I understand your point for the "gotcha" about the speed, and agree that the problem lies in the conversion to BigFloat's, performing there the calculations, and convert back to Float64.
Yet, I think the aim of the package is reliability rather than speed, and this includes the tightness of the bounds. Tightness is so important that it is mentioned in the standard. We give the option to the user who prefers speed (by sacrificing tightness) which is the :wide
rounding mode. I think it is consistent with this to have the slow ^
version as default, but allow to use pow
.
from intervalarithmetic.jl.
I recall that when I was dealing with ^
, few (special) ITF1788 tests where failing. I couldn't get around them with Float64
which led to using BigFloat
s. Maybe we should use only for those special cases the trick with big53
. That would speed things up again.
from intervalarithmetic.jl.
I believe that the standard only requires documenting how strict each function is.
The current pow is correct, and only slightly wider in most cases.
from intervalarithmetic.jl.
I do think that the standard requires tightness for pown
. I must go out now, but I'll look later to get the specific reference to this.
In any case, see #47 for an implementation of pown
without big53
.
from intervalarithmetic.jl.
addressed in #388
from intervalarithmetic.jl.
Related Issues (20)
- Union with more than 2 arguments HOT 7
- Support for special functions HOT 1
- interval + inf returns invalid interval HOT 26
- Power of negative numbers is broken for non-rational exponents HOT 3
- Provide tool for checking if a function plays well with intervals HOT 2
- Stack overflow with `rad2deg`
- `convert` can fail to return a valid interval HOT 3
- IntervalArithmetic.jl testing errors / broken found. HOT 2
- replace `StaticArrays.jl` with `StaticArraysCore.jl` HOT 4
- Fractional powers of nonpositive intervals containing zero HOT 2
- Non zero diameter for degenerated interval HOT 3
- What is the best way for interval evaluation of a function with Vector{AbstractFloat} argument ? HOT 7
- Implementing the Riemann-Siegel Formula to find zeros of the Riemann Zeta Function with Interval Arithmetic HOT 1
- Remove IntervalBox in favor of AbstractVector{Interval} HOT 11
- Non-allocating version of set operations HOT 2
- Should the 1.0-dev branch be the master branch? HOT 9
- Derivative of abs(::Interval) HOT 7
- `<` and `>` breaks interval? HOT 2
- Warn or error on every operation mixing Interval and number HOT 1
- Matrix multiplication with mixed Interval SMatrix and SMatrix broken HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from intervalarithmetic.jl.