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

maxevals produces InexactError() #4

Closed
davorh opened this issue Jan 23, 2017 · 10 comments
Closed

maxevals produces InexactError() #4

davorh opened this issue Jan 23, 2017 · 10 comments
Assignees

Comments

@davorh
Copy link

davorh commented Jan 23, 2017

Simple increase in value for maxevals produces error. You can replicate problem with this simple code
(Debian Linux, julia 0.5.1, 64 bit kernel)

In[]:= vegas((x,f)->f[1]=cos(0.1*x[1]), maxevals = 1e9)
Out[]:= ([0.998335],[4.70961e-5],[-999.0],1000,0,0)

In[]:= vegas((x,f)->f[1]=cos(0.1*x[1]), maxevals = 3e9)
Out[]:= InexactError()
in dointegrate(::Symbol, ::Ptr{Void}, ::Int64, ::Int64, ::Ptr{Void}, ::Int64, ::Float64, ::Float64, ::Int64, ::Int64, ::Int64, ::Int64, ::Int64, ::Int64, ::Int64, ::Int64, ::Int64, ::Int64, ::Float64, ::Int64, ::Int64, ::Int64, ::Int64, ::Float64, ::Float64, ::Float64, ::Int64, ::Int64, ::Int64, ::Int64, ::Ptr{Void}, ::Int64, ::String, ::Ptr{Void}) at /home/sageusr/.julia/v0.5/Cuba/src/Cuba.jl:169
in #vegas#1(::Int64, ::Float64, ::Float64, ::Int64, ::Int64, ::Int64, ::Float64, ::Int64, ::Int64, ::Int64, ::Int64, ::String, ::Ptr{Void}, ::Cuba.#vegas, ::##33#34, ::Int64, ::Int64) at /home/sageusr/.julia/v0.5/Cuba/src/Cuba.jl:295
in (::Cuba.#kw##vegas)(::Array{Any,1}, ::Cuba.#vegas, ::Function, ::Int64, ::Int64) at ./:0 (repeats 2 times)

@giordano
Copy link
Owner

giordano commented Jan 23, 2017

That happens because currently Cuba.jl wraps only the routines with 32-bit integers, so maxevals is limited to be

julia> typemax(Int32)
2147483647

This explains why you can have 1e9 maximum evaluations but not 3e9.

I could wrap the functions with 64-bit integers as well, but not anytime soon.

Anyway, unless you have specific reasons to use Vegas algorithm, I'd suggest you to try cuhre function: in most cases this is much faster and much more accurate than the other integration methods, so you usually need less evaluations to get a good result.

@davorh
Copy link
Author

davorh commented Jan 24, 2017

Thanks. Since we need Vegas (due to the high dimensionality) can you steer us in the right direction how to make 64 bit wrapper.

@giordano
Copy link
Owner

It's not hard to do it (I already did it locally yesterday), but I'm deciding what's the best interface for the user. I have the following options:

  • wrap only 64-bit integer functions,
  • provide new functions (named llvegas, llcuhre, etc..., like in Cuba) that wraps the corresponding Cuba functions
  • add a longint keyword to existing functions in order to choose which function to choose, whether the 64-bit or 32-bit integers.

@giordano
Copy link
Owner

giordano commented Jan 24, 2017

I'm working on this. I decided to use follow the second option (define new functions). This is not particularly elegant, but closely tracks how Cuba library works. I hope to be able to tag a new release in a few hours.

@davorh
Copy link
Author

davorh commented Jan 24, 2017 via email

@giordano
Copy link
Owner

@davorh Cuba.jl 0.3.0 is now officially registered, you should get it upon updating your packages. Use llvegas instead of vegas, the syntax is just the same but you can specify maxevals up to 2^63 - 1 (but there is no way to overcome this limit). Please, do let me know if it works for you.

@davorh
Copy link
Author

davorh commented Jan 25, 2017 via email

@giordano
Copy link
Owner

Thank you! Please, do cite Thomas Hahn's papers listed in https://github.com/giordano/Cuba.jl#license as well. He wrote all integration functions, I'm only responsible for the Julia interface ;-)

@davorh
Copy link
Author

davorh commented Jan 25, 2017 via email

@giordano giordano self-assigned this Jul 3, 2017
@giordano
Copy link
Owner

With release of v0.4.0, all functions wrap the 64-bit integer versions of integrator routines and the functions named ll* are now deprecated (because they're equivalent to base ones). This is basically the first option I mentioned in this message above.

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

No branches or pull requests

2 participants