GithubHelp home page GithubHelp logo

grid.jl's Introduction

Grid operations for the Julia language

Grid Build Status Coverage Status

Continuous objects, such as functions or images, are frequently sampled on a regularly-spaced grid of points. The Grid module provides support for common operations on such objects. Currently, the two main operations are interpolation and restriction/prolongation. Restriction and prolongation are frequently used for solving partial differential equations by multigrid methods, but can also be used simply as fast, antialiased methods for two-fold resolution changes (e.g., in computing thumbnails).

Note: for interpolation, Grid.jl is deprecated in favor of Interpolations. Julia 0.5 is the latest release on which Grid.jl will be installable.

Installation

Within Julia, use the package manager:

Pkg.add("Grid")

Usage

To use the Grid module, begin your code with

using Grid

Interpolation

Let's define a quadratic function in one dimension, and evaluate it on an evenly-spaced grid of 5 points:

c = 2.3  # center
a = 8.1  # quadratic coefficient
o = 1.6  # vertical offset
qfunc = x -> a*(x-c).^2 + o
xg = Float64[1:5]
y = qfunc(xg)

From these evaluated points, let's define an interpolation grid:

yi = InterpGrid(y, BCnil, InterpQuadratic)

The last two arguments will be described later. Note that only y is supplied; as with Julia's arrays, the x-coordinates implicitly start at 1 and increase by 1 with each grid point. It's easy to check that yi[i] is equal to y[i], within roundoff error:

julia> y[3]
5.569000000000003

julia> yi[3]
5.569000000000003

However, unlike y, yi can also be evaluated at off-grid points:

julia> yi[1.9]
2.8959999999999995

julia> qfunc(1.9)
2.8959999999999995

It's also possible to evaluate the slope of the interpolation function:

julia> v,g = valgrad(yi, 4.25)
(32.40025000000001,31.590000000000003)

julia> 2*a*(4.25-c)
31.59

or the second-order derivative (in multidimensional cases, the Hessian matrix):

julia> v,g,h = valgradhess(yi, 4.25)
(32.40025,31.59000000000001,16.200000000000017)

julia> 2a
16.2

Interpolation of a function on a (evenly-spaced) grid that is scaled and/or shifted can be created with CoordInterpGrid that is similar to InterpGrid but takes a range as additional argument:

x = -1.0:0.1:1.0
z = sin(x)

zi = CoordInterpGrid(x, z, BCnil, InterpQuadratic)

julia> zi[-1.0]
-0.8414709848078965

While these examples are one-dimensional, you can do interpolation on arrays of any dimensionality. In two or more dimensions CoordInterpGrid expects a tuple of ranges for scaling. For example:

x = -1.0:0.1:1.0
y = 2.0:0.5:10.0
z_2d = Float64[sin(i+j) for i in x, j in y]

z_2di = CoordInterpGrid((x,y), z_2d, BCnil, InterpQuadratic)

julia> z_2di[0.2, 4.1]
-0.9156696045493824

The last two parameters of InterpGrid and CoordInterpGrid specify the boundary conditions (what happens near, or beyond, the edges of the grid) and the interpolation order. The choices are specified below:

mode Meaning
BCnil generates an error when points beyond the grid edge are needed
BCnan generate NaN when points beyond the grid edge are needed
BCreflect reflecting boundary conditions
BCperiodic periodic boundary conditions
BCnearest when beyond the edge, use the value at the closest interior point
BCfill produce a specified value when beyond the edge

Most of these modes are activated by passing them as an argument to InterpGrid or CoordInterpGrid as done in the description above. To activate BCfill, pass the number which is to be produced outside the grid as an argument, instead of the mode "BCfill".

The interpolation order can be one of the following:

InterpNearest nearest-neighbor (one-point) interpolation
InterpLinear piecewise linear (two-point) interpolation (bilinear in two dimensions, etc.)
InterpQuadratic quadratic (three-point) interpolation
InterpCubic cubic (four-point) interpolation

Note that quadratic and cubic interpolation are implemented through B-splines which are technically "non-interpolating", meaning that the coefficients of the interpolating polynomial are not the function values at the grid points. InterpGrid solves the tridiagonal system of equations for you, so in simple cases you do not need to worry about such details. InterpQuadratic is the lowest order of interpolation that yields a continuous gradient, and hence is suitable for use in gradient-based optimization, and InterpCubic is similarly the lowest order of interpolation that yields a continuous Hessian.

Note that InterpCubic currently doesn't support all types of boundary conditions; only BCnil and BCnan are supported.

In d dimensions, interpolation references n^d grid points, where n is the number of grid points used in one dimension. InterpQuadratic corresponds to n=3, and InterpCubic corresponds to n=4. Consequently, in higher dimensions quadratic interpolation can be a significant savings relative to cubic spline interpolation.

Low-level interface

It should be noted that, in addition to the high-level InterpGrid interface, Grid also has lower-level interfaces. Users who need to extract values from multi-valued functions (e.g., an RGB image, which has three colors at each position) can achieve significant savings by using this low-level interface. The main cost of interpolation is computing the coefficients, and by using the low-level interface you can do this just once at each x location and use it for each color channel.

Here's one example using the low-level interface, starting from the one-dimensional quadratic example above:

y = qfunc(xg)
# Do the following once
interp_invert!(y, BCnan, InterpQuadratic)   # solve for generalized interp. coefficients
ic = InterpGridCoefs(y, InterpQuadratic)    # prepare for interpolation on this grid

# Do the following for each evaluation point
set_position(ic, BCnil, true, true, [1.8])  # set position to x=1.8, computes the coefs
v = interp(ic, y)                           # extract the value
# Do this if you want the slope at the same point
set_gradient_coordinate(ic, 1)              # change coefs to calc gradient along coord 1
g = interp(ic, y)                           # extract the gradient
# Do this to evaluate the Hessian at that point
set_hessian_coordinate(ic, 1, 2)            # change coefs to calc hessian element H[1,2], i.e. d2/dxdy
h = interp(ic, y)                           # extract hessian element

If this were an RGB image, you could call interp once for the red color channel, once for the green, and once for the blue, with just one call to set_position.

Here is a second example, using a multi-dimensional grid to do multi-value interpolation. Consider that instead of an image, the main data unit of interest is a one-dimensional spectrum, with length Npixels, with three parameters which describe a single spectrum: x1, x2, and x3. If you have a grid of simulations that output spectra for regularly spaced values of these parameters, the following example shows how to interpolate a spectrum with an arbitrary value of x1, x2, and x3.

# Our spectra are stored as pixels in a 4d grid
Npixels = 200
grid = rand(10, 10, 10, Npixels)

# For example, the first spectrum (x1=1, x2=1, x3=1), length Npixels, is stored in
# the grid as `raw_spec = grid[:,:,:,1]`
grid_size = size(grid) #(10,10,10,200)
grid_strides = strides(grid) #(1,10,100,1000)

strd = stride(grid, 4) #1000

# solve for the generalized interp. coefficients
# but select only the 1st through 3rd axes for interpolation `dimlist = 1:3`
interp_invert!(grid, BCnil, InterpCubic, 1:3)

# prepare for interpolation on this grid
# but also specify the dimensions and strides of the first three dimensions which we want
# to interpolate over
ic = InterpGridCoefs(eltype(grid), InterpCubic, grid_size[1:3], grid_strides[1:3])

# Set the grid position to the indices corresponding to the x1=1.5, x2=1.5, x3=1.5
# value we wish to interpolate
set_position(ic, BCnil, false, false, [1.5, 1.5, 1.5])

# Iterate over the pixels in the spectrum to interpolate each pixel into a new array
spec = Array(Float64, (Npixels,))
index = 1
for i = 1:Npixels
    spec[i] = interp(ic, grid, index)
    index += strd
end

Restriction and prolongation

Suppose you have an RGB image stored in an array img, where the third dimension is of length 3 and specifies the color. You can create a 2-fold smaller version of the image using restrict:

julia> size(img)
(1920,1080,3)

julia> imgr = restrict(img, [true,true,false]);

julia> size(imgr)
(961,541,3)

The second argument to restrict specifies which dimensions should be down-sampled.

Notice that the sizes are not precisely 2-fold smaller; this is because restriction is technically defined as the adjoint of prolongation, and prolongation interpolates (linearly) at intermediate points. For prolongation, you also have to supply the desired size:

julia> img2 = prolong(imgr, [size(img)...]);

julia> size(img2)
(1920,1080,3)

If a given dimension has size n, then the prolonged dimension can be either of size 2n-2 (if you want it to be even) or 2n-1 (if you want it to be odd). For odd-sized outputs, the interpolation is at half-grid points; for even-sized outputs, all output values are interpolated, at 1/4 and 3/4 grid points. Having both choices available makes it possible to apply restrict to arrays of any size.

If you plan multiple rounds of restriction, you can get the "schedule" of sizes from the function restrict_size:

julia> pyramid = restrict_size(size(img), [true true true true; true true true true; false false false false])
3x4 Int64 Array:
 961  481  241  121
 541  271  136   69
   3    3    3    3

Restriction and prolongation are extremely fast operations, because the coefficients can be specified in advance. For floating-point data types, this implementation makes heavy use of the outstanding performance of BLAS's axpy.

Credits

The main authors of this package are Tim Holy, Tomas Lycken, Simon Byrne, and Ron Rock.

grid.jl's People

Contributors

andrewgibb avatar blakejohnson avatar iancze avatar mbauman avatar ranjanan avatar rsrock avatar sglyon avatar simonbyrne avatar swt30 avatar thuener avatar timholy avatar tomasaschan avatar yuyichao avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

grid.jl's Issues

LAPACKException for InterpGrid

Hey Tim,

I'm receiving this LAPACKException lately:

ERROR: LAPACKException(13567071543623680)
 in gtsv! at linalg/lapack.jl:1235
 in \ at linalg/tridiag.jl:181
 in Woodbury at linalg/woodbury.jl:25
 in _interp_invert_matrix at /home/rje/.julia/Grid/src/interp.jl:663
 in interp_invert! at /home/rje/.julia/Grid/src/interp.jl:637
 in InterpGrid at /home/rje/.julia/Grid/src/interp.jl:50

I'm on Archlinux 64-bit with an Intel i7 processor.

I've tried rebuilding the latest Julia release candidate (Version 0.2.0-rc1+131). Using the system provided BLAS (64-bit) and the Julia-make compiled Suitesparse; I still have yet to try OpenBLAS (my system gives out an incredibly annoying beep sound during compliation, so I will need to wait until everyone has left the office! :/ ). Cross-posting this to the JuliaLang repo, as well (JuliaLang/julia#4624).

Thanks,
Rob

valgradhess does not work with CoordInterpGrid

The following code:

using Grid
x = 0:0.1:6
y = 10:0.1:15
z = sin(x * y')
zi = CoordInterpGrid((x,y),z, BCnil,InterpQuadratic)
v,g,h = valgradhess(zi, x[2], y[2])

generates the error:

no method valgradhess(Array{Float64,1}, Array{Float64,2}, CoordInterpGrid{Float64,2,BCnil,InterpQuadratic,(FloatRange{Float64},FloatRange{Float64})}, Float64, Float64)
while loading In[8], in expression starting on line 1
in valgradhess at c:\home\simonp.julia\v0.3\Grid\src\interp.jl:242

Error on `using Grid`

julia> using Grid
ERROR: solve not defined
 in reload_path at loading.jl:152
 in _require at loading.jl:67
 in require at loading.jl:51
while loading /Users/rrock/.julia/v0.3/Grid/src/interp.jl, in expression starting on line 3
while loading /Users/rrock/.julia/v0.3/Grid/src/Grid.jl, in expression starting on line 15

Git bisect picks out JuliaLang/julia/d193ce640 as the bad commit. I can't figure out what happened to solve in all of that, however.

Good thing I can just roll back julia in the meantime...

Array Input support for CoordInterpGrid

Is CoordInterpGrid could be modified to support array input?
Below example gives error

x = sort(collect([-1.0:0.1:1.0;2:0.01:3]))
y = collect( 2.0:0.5:10.0)
z_2d = Float64[sin(i+j) for i in x, j in y]

z_2di = CoordInterpGrid((x,y), z_2d, BCnil, InterpQuadratic);

while this works.

x = [-1.0:0.1:1.0;2:0.01:3]
y = 2.0:0.5:10.0
z_2d = Float64[sin(i+j) for i in x, j in y]

z_2di = CoordInterpGrid((x,y), z_2d, BCnil, InterpQuadratic);

Coordinates would not be always range type if we do some fitting from experimental data.
I hope CoordInterpGrid to support range or is there some other way?

"solve" not defined

I'm receiving the following error when trying to interpolate a 1-D vector, using the "BCnil" and "InterpQuadratic" options. Could it be that I'm missing a required package?

ERROR: solve not defined
 in interp_invert! at /home/rje/.julia/Grid/src/interp.jl:641
 in InterpGrid at /home/rje/.julia/Grid/src/interp.jl:50
 in include at boot.jl:238

Thanks,
Rob

Low level interface help/documentation

I'm extremely happy to have found Grid.jl, it seems like the perfect tool for doing the type of interpolation that I need. However, I am having a bit of difficulty getting started for my specific example. While combing the source of interp.jl has gotten me pretty far, I still can't quite get the behavior I want.

My main data unit is a 1d spectrum, with length of about 200,000 pixels. There are three parameters which describe a spectrum (call them x, y, and z), and I have about 500 spectra which are produced for regularly spaced combinations of these three parameters. My problem is analogous to the image/RGB example in the documentation, but in this case instead of the two spatial dimensions x and y and a third color dimension c (with size 3), I have three dimensions (x, y, z) and my color dimension is size 200,000.

Therefore, what I actually want to interpolate is a 1d vector with length 200,000 (i.e., a spectrum) which has been interpolated over the x, y, z axes but not the color axis. My attempt is the following, but I cannot figure out where to properly limit the dimensions to avoid interpolation over the color axis.

grid #my array of spectra on a grid, with size (11,8,6,216631), ie axes (x, y, z, c)
interp_invert!(grid, BCnan, InterpCubic, 1:3)   # solve for generalized interp. coefficients
ic = InterpGridCoefs(grid, InterpCubic) #gives error

#Then, suppose I want to interpolate a spectrum with values x=1.5, y=1.5, z=1.5
set_position(ic, BCnil, false, false, [1.5, 1.5, 1.5])  # set position to a point in the grid, computes the coefs

spec = Array(Float64, (Npix,))
for i=1:Npix
    spec[i] = interp(ic, grid[:,:,:,i])
end

However, different combinations of setting dimensions and limiting the interpolation have been unsuccessful for me. Although the README alludes to the ability to do interpolation like this with RGB channels, it would be helpful if the documentation included a more detailed example. If someone would gratefully help me solve my interpolation problem, I would be very happy to submit a pull request with a detailed example.

Thank you for your help!

Build fails on 0.2

The latest Travis builds seem to be failing for Julia 0.2, with

ERROR: StepRange not defined

Is StepRange new in 0.3? If so, maybe we should update REQUIRE to match that, and tag a new version (major? minor? at least more significant than bugfix, IMO...).

@timholy

[PkgEval] Grid may have a testing issue on Julia 0.3 (2014-10-09)

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.3

  • On 2014-10-08 the testing status was Tests pass.
  • On 2014-10-09 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("Grid")' log
INFO: Cloning cache of Grid from git://github.com/timholy/Grid.jl.git
INFO: Installing Grid v0.3.4
INFO: Package database updated

>>> 'using Grid' log
Julia Version 0.3.1
Commit c03f413* (2014-09-21 21:30 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

>>> test log
ERROR: test failed: yi[1.1,2.8]
 in error at error.jl:21
 in default_handler at test.jl:19
 in do_test_throws at test.jl:55
 in anonymous at no file:167
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
 in _start_3B_1712 at /home/idunning/julia03/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.3/Grid/test/grid.jl, in expression starting on line 165
while loading /home/idunning/pkgtest/.julia/v0.3/Grid/test/runtests.jl, in expression starting on line 2


INFO: Testing Grid
================================[ ERROR: Grid ]=================================

failed process: Process(`/home/idunning/julia03/usr/bin/julia /home/idunning/pkgtest/.julia/v0.3/Grid/test/runtests.jl`, ProcessExited(1)) [1]

================================================================================
INFO: No packages to install, update or remove
ERROR: Grid had test errors
 in error at error.jl:21
 in test at pkg/entry.jl:715
 in anonymous at pkg/dir.jl:28
 in cd at ./file.jl:20
 in cd at pkg/dir.jl:28
 in test at pkg.jl:67
 in process_options at ./client.jl:213
 in _start at ./client.jl:354
 in _start_3B_1712 at /home/idunning/julia03/usr/bin/../lib/julia/sys.so

>>> end of log

Some sort of convert bug? Started on June 18th

INFO: Installing Grid v0.3.2
INFO: Package database updated
ERROR: no method convert(Type{Array{Float64,1}}, Array{Float64,2})
 in ctranspose! at array.jl:1280
 in ctranspose at array.jl:1316
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
while loading /home/idunning/pkgtest/.julia/v0.3/Grid/test/grid.jl, in expression starting on line 294
while loading /home/idunning/pkgtest/.julia/v0.3/Grid/test/runtests.jl, in expression starting on line 1
INFO: Package database updated

CoordInterpGrid does not work with InterpCubic in 2 dimensions

I used the example provided on the main page:

x = -1.0:0.1:1.0
y = 2.0:0.5:10.0
z_2d = Float64[sin(i+j) for i in x, j in y]

With these variables, InterpQuadratic works fine but if I try

z_2di = CoordInterpGrid((x,y), z_2d, BCnil, InterpCubic)

I get:

ERROR: DimensionMismatch("Coordinate lengths do not match grid size.")
 in CoordInterpGrid at /Users/mathieu/.julia/Grid/src/coord.jl:7
 in CoordInterpGrid at /Users/mathieu/.julia/Grid/src/coord.jl:13
 in CoordInterpGrid at /Users/mathieu/.julia/Grid/src/coord.jl:21

no method solve

Hello.

I'm not sure if it's a bug, maybe I'm doing something wrong. When I'm running code from README I get:

using Grid
c = 2.3  # center
a = 8.1  # quadratic coefficient
o = 1.6  # vertical offset
qfunc = x -> a*(x-c).^2 + o
xg = Float64[1:5]
y = qfunc(xg)
yi = InterpGrid(y, BCnil, InterpQuadratic)
ERROR: no method solve(Array{Float64,1}, Range1{Int64}, Tridiagonal{Float64}, Array{Float64,1}, Range{Int64})
 in solve at linalg/woodbury.jl:82
 in interp_invert! at ~/.julia/Grid/src/interp.jl:641
 in InterpGrid at ~/.julia/Grid/src/interp.jl:50

Also when trying to run unit tests:

~/.julia/Grid/test $ julia runtests.jl 
ERROR: no method solve(Array{Float64,1}, Range1{Int64}, Tridiagonal{Float64}, Array{Float64,2}, Range{Int64})
 in solve at linalg/woodbury.jl:82
 in interp_invert! at ~/.julia/Grid/src/interp.jl:641
 in InterpGrid at ~/.julia/Grid/src/interp.jl:50
 in anonymous at no file:45
 in include at boot.jl:238
while loading ~/.julia/Grid/test/grid.jl, in expression starting on line 43
while loading ~/.julia/Grid/test/runtests.jl, in expression starting on line 1

I use Julia head version and the newest version of Grid.jl

Regards,
Tomek

Subarrays as second argument

From a matrix A

A = rand(10, 10)

I can interpolate with respect to the first dimension

 CoordInterpGrid(1:10, A[:, 1], BCnearest, InterpLinear)

However, I can't interpolate with respect to the second dimension, i.e. do something like

 CoordInterpGrid(1:10, A[1, :], BCnearest, InterpLinear)
 CoordInterpGrid(1:10, slice(A, 1, :), BCnearest, InterpLinear)

The only solution is to transpose A so that the order of dimensions is inverted. However, adding a support for subarray would probably be faster, no?

Decision: Separate the concepts of boundary condition and extrapolation behavior

After thinking a little about #32 as well as poking around in the code to see what I can do about the problems with InterpCubic (#29, #31, #33) I'm getting more and more frustrated with the lack of separation between the two concepts "boundary conditions" and "extrapolation behavior". As I see it, those are two separate concepts:

  • Boundary conditions define how the interpolation behaves close to, but inside the edges of the domain. For example, the current behavior of quadratic interpolations is (IIUC) to use the coefficients for x in [2,3] also for x in [1,2]. An alternative way of terminating the interpolation would be to use a linear interpolation in the edge interval, and still require smoothness at the edge.
  • Extrapolation behavior defines what happens if an x is provided which is outside the domain (e.g. any x < 1). Currently, there are a couple of behaviors: BCnil and BCnan both do something to indicate an undefined value, while BCfill defines a constant extrapolation independent of the function value at the edge, and BCnearest is in effect a simple constant extrapolation. But this is (could be) independent of what happens inside the domain - it is only concerned with behavior outside.

Some of today's boundary conditions capture both these concepts - BCperiodic and BCreflect intrinsically defines both the boundary condition and the extrapolation behavior - but that's more a special circumstance than anything else.

Separating these two concepts would probably be a quite substantial rewrite of parts of interp.jl, and breaking API changes are likely (if they are separate concepts, both need to be specified by the user...). This is unfortunate, since Grid is used by a lot of people, and in a lot of packages.

Before I start working on anything, I'd love to hear some input from others on whether this is a good idea or not, and (if it is) if there are any special considerations that I might not have thought of.

Pkg installation trouble

This could be my fault: previously I could install Grid fine, but now I get the following error after running Pkg.add("Grid") on a clean ~/.julia

julia> using Grid
ERROR: in module path: Grid not defined

Other packages appear to be working fine.

Not working on Julia 0.5

using Grid
x = -1.0:0.1:1.0
z = sin(x)

zi = CoordInterpGrid(x, z, BCnil, InterpQuadratic)

21-element Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}:
Error showing value of type Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}:
ERROR: MethodError: no method matching coordlookup(::Tuple{FloatRange{Float64}}, ::Tuple{Int64,Int64})
Closest candidates are:
coordlookup{N}(::Tuple{Vararg{T,N}}, ::Tuple{Vararg{T,N}}) at /home/tas/.julia/v0.5/Grid/src/coord.jl:33
in getindex(::Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}, ::Int64, ::Int64) at /home/tas/.julia/v0.5/Grid/src/coord.jl:48
in isassigned(::Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}, ::Int64, ::Int64, ::Vararg{Int64,N}) at ./abstractarray.jl:186
in alignment(::IOContext{Base.Terminals.TTYTerminal}, ::Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}, ::Array{Int64,1}, ::Array{Int64,1}, ::Int64, ::Int64, ::Int64) at ./show.jl:1277
in print_matrix(::IOContext{Base.Terminals.TTYTerminal}, ::Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}, ::String, ::String, ::String, ::String, ::String, ::String, ::Int64, ::Int64) at ./show.jl:1407
in print_matrix(::IOContext{Base.Terminals.TTYTerminal}, ::Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}, ::String, ::String, ::String) at ./show.jl:1379
in #showarray#330(::Bool, ::Function, ::IOContext{Base.Terminals.TTYTerminal}, ::Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}, ::Bool) at ./show.jl:1618
in display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::MIME{Symbol("text/plain")}, ::Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}) at ./REPL.jl:132
in display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}) at ./REPL.jl:135
in display(::Grid.CoordInterpGrid{Float64,1,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64}}}) at ./multimedia.jl:143
in print_response(::Base.Terminals.TTYTerminal, ::Any, ::Void, ::Bool, ::Bool, ::Void) at ./REPL.jl:154
in print_response(::Base.REPL.LineEditREPL, ::Any, ::Void, ::Bool, ::Bool) at ./REPL.jl:139
in (::Base.REPL.##22#23{Bool,Base.REPL.##33#42{Base.REPL.LineEditREPL,Base.REPL.REPLHistoryProvider},Base.REPL.LineEditREPL,Base.LineEdit.Prompt})(::Base.LineEdit.MIState, ::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Bool) at ./REPL.jl:652
in run_interface(::Base.Terminals.TTYTerminal, ::Base.LineEdit.ModalInterface) at ./LineEdit.jl:1579
in run_frontend(::Base.REPL.LineEditREPL, ::Base.REPL.REPLBackendRef) at ./REPL.jl:903
in run_repl(::Base.REPL.LineEditREPL, ::Base.##930#931) at ./REPL.jl:188
in _start() at ./client.jl:360

Type is immutable error with Julia 0.2.0

Hi, I was just running your examples on the latest version of Julia, and it returns

julia> yi = InterpGrid(y, BCnil, InterpQuadratic)
ERROR: in interp_invert!: type is immutable
in interp_invert! at /home/gcam/.julia/Grid/src/Grid.jl:665
in InterpGrid at /home/gcam/.julia/Grid/src/Grid.jl:137

Even something simpler like

julia> b = linspace(1.0,10.0,20)

produces the same error

julia> yi = InterpGrid(b, BCnil, InterpQuadratic)
ERROR: in interp_invert!: type is immutable
in interp_invert! at /home/gcam/.julia/Grid/src/Grid.jl:665
in InterpGrid at /home/gcam/.julia/Grid/src/Grid.jl:137

Do you have any quick fixes? Thanks for writing this!

Weird behaviour at 1.5

using Grid
s = sin(1:10)
sg = InterpGrid(s, BCnil, InterpQuadratic)
(sg[1.499],sg[1.5],sg[1.501])

returns

(0.9920957724797429,-1.4261731450295283,0.9922314253637784)

BCnearest bug

Here's an minimal example. Sorry for the format:

clipboard-1

1d linear interpolation + BCnearest extrapolation. Values higher than the grid look fine but values below the bottom value of the grid are all wrong.

Any suggestions?

Edit: Version 0.3.2 (2014-10-21 22:05 UTC)

Performance issues

The performance of Grid is not as good as it could be. I don't have time to throw in a demo right now, but one can pretty easily write a hand-written function that performs linear interpolation. I've tended to find that it is many times faster than Grid.

Grid got started ages ago (even before there were such things as packages), and now I know a lot more about how to do fast multidimensional operations in Julia. However, one major point of concern: a really fast Grid would currently require one to use Cartesian. I have no desire whatsoever to scare co-developers off (especially @tlycken), so I won't even consider this if there are concerns. (I'm also busy with other things right now.)

Issue with example

This bit from readme.md fails with an error:

x = -1.0:0.1:1.0
y = 2.0:0.5:10.0
z_2d = Float64[sin(i+j) for i in x, j in y]

z_2di = CoordInterpGrid((x,y), z_2d, BCnil, InterpQuadratic)

gives the error:

Invalid location

 in set_position(::Grid.InterpGridCoefs{Float64,Grid.InterpQuadratic}, ::Type{Grid.BCnil}, ::Bool, ::Bool, ::Array{Float64,1}) at /Users/michael/.julia/v0.5/Grid/src/interp.jl:403
 in _getindex at /Users/michael/.julia/v0.5/Grid/src/interp.jl:143 [inlined]
 in getindex at /Users/michael/.julia/v0.5/Grid/src/interp.jl:154 [inlined]
 in getindex(::Grid.CoordInterpGrid{Float64,2,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64},FloatRange{Float64}}}, ::Int64, ::Int64) at /Users/michael/.julia/v0.5/Grid/src/coord.jl:39
 in isassigned(::Grid.CoordInterpGrid{Float64,2,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64},FloatRange{Float64}}}, ::Int64, ::Int64, ::Vararg{Int64,N}) at ./abstractarray.jl:186
 in alignment(::IOContext{Base.AbstractIOBuffer{Array{UInt8,1}}}, ::Grid.CoordInterpGrid{Float64,2,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64},FloatRange{Float64}}}, ::Array{Int64,1}, ::Array{Int64,1}, ::Int64, ::Int64, ::Int64) at ./show.jl:1277
 in print_matrix(::IOContext{Base.AbstractIOBuffer{Array{UInt8,1}}}, ::Grid.CoordInterpGrid{Float64,2,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64},FloatRange{Float64}}}, ::String, ::String, ::String, ::String, ::String, ::String, ::Int64, ::Int64) at ./show.jl:1407
 in print_matrix(::IOContext{Base.AbstractIOBuffer{Array{UInt8,1}}}, ::Grid.CoordInterpGrid{Float64,2,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64},FloatRange{Float64}}}, ::String, ::String, ::String) at ./show.jl:1379
 in #showarray#330(::Bool, ::Function, ::IOContext{Base.AbstractIOBuffer{Array{UInt8,1}}}, ::Grid.CoordInterpGrid{Float64,2,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64},FloatRange{Float64}}}, ::Bool) at ./show.jl:1618
 in limitstringmime(::MIME{Symbol("text/plain")}, ::Grid.CoordInterpGrid{Float64,2,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64},FloatRange{Float64}}}) at /Users/michael/.julia/v0.5/IJulia/src/execute_request.jl:31
 in display_dict(::Grid.CoordInterpGrid{Float64,2,Grid.BCnil,Grid.InterpQuadratic,Tuple{FloatRange{Float64},FloatRange{Float64}}}) at /Users/michael/.julia/v0.5/IJulia/src/execute_request.jl:46
 in execute_request(::ZMQ.Socket, ::IJulia.Msg) at /Users/michael/.julia/v0.5/IJulia/src/execute_request.jl:200
 in eventloop(::ZMQ.Socket) at /Users/michael/.julia/v0.5/IJulia/src/eventloop.jl:8
 in (::IJulia.##9#15)() at ./task.jl:360

Also, it is very unclear from readme.md what is the difference between InterpGrid and CoordInterpGrid - could you elaborate please?

Info about upcoming removal of packages in the General registry

As described in https://discourse.julialang.org/t/ann-plans-for-removing-packages-that-do-not-yet-support-1-0-from-the-general-registry/ we are planning on removing packages that do not support 1.0 from the General registry. This package has been detected to not support 1.0 and is thus slated to be removed. The removal of packages from the registry will happen approximately a month after this issue is open.

To transition to the new Pkg system using Project.toml, see https://github.com/JuliaRegistries/Registrator.jl#transitioning-from-require-to-projecttoml.
To then tag a new version of the package, see https://github.com/JuliaRegistries/Registrator.jl#via-the-github-app.

If you believe this package has erroneously been detected as not supporting 1.0 or have any other questions, don't hesitate to discuss it here or in the thread linked at the top of this post.

Bug in `interp_gcoefs_1d`

In lines 577-602 of src/interp.jl, three methods each for interp_coefs_1d and inter_gcoefs_1d are defined, which seem to correspond to the three interpolation methods currently implemented (nearest, linear, quadratic). However, all of the gcoef methods are for quadratic interpolation, and overwrite eachother, producing the following results:

julia> methods(Grid.interp_coefs_1d)
#3 methods for generic function "interp_coefs_1d":
interp_coefs_1d{T,BC<:BoundaryCondition}(coef1d::Array{T,1},::Type{BC<:BoundaryCondition},::Type{InterpNearest},dx::T) at /home/tlycken/.julia/v0.3/Grid/src/interp.jl:578
interp_coefs_1d{T,BC<:BoundaryCondition}(coef1d::Array{T,1},::Type{BC<:BoundaryCondition},::Type{InterpLinear},dx::T) at /home/tlycken/.julia/v0.3/Grid/src/interp.jl:585
interp_coefs_1d{T,BC<:BoundaryCondition}(coef1d::Array{T,1},::Type{BC<:BoundaryCondition},::Type{InterpQuadratic},dx::T) at /home/tlycken/.julia/v0.3/Grid/src/interp.jl:594

julia> methods(Grid.interp_gcoefs_1d)
#1 method for generic function "interp_gcoefs_1d":
interp_gcoefs_1d{T,BC<:BoundaryCondition}(coef1d::Array{T,1},::Type{BC<:BoundaryCondition},::Type{InterpQuadratic},dx::T) at /home/tlycken/.julia/v0.3/Grid/src/interp.jl:59

wrong array size?

in the following code cg should be 256X256 array. but it returns 258X258 array. Why?

n = 256
d= 0.1
x = -n_d/2.0:d:(n_d - d)/2

da = rand(256, 256)
cg = CoordInterpGrid((x, x), da, 0.0, InterpLinear)

`CoordInterpGrid` produces a transposed interpolation (?)

This is probably a classic PEBKAC, but since I've now torn my hair for the better part of a work day, I might as well ask for some assistance.

I'm having some trouble using the CoordInterpGrid typel to do what I want - it seems to transpose everything when I interpolate, and I can't figure out how to get it right.

Basically, I get my data in a matrix and make a contour plot, and all looks OK. Then, I interpolate the data and fill a new matrix with values from the interpolation, and when I plot the contours of that it is transposed.

I didn't know how to write a concise enough example code, so I put my current code with lots of comments and an accompanying data file in this gist.

I'll be immensely thankful for any hints on what's going on here.

Breaking change: indexing with vectors

There turns out to be an API problem with Grid, due to some foolishness on my part. Given a two-dimensional InterpGrid object A, one can do interpolation with A[x,y]. However, because of Counter, I also allowed a syntax A[c] where c is the two-vector [x,y]. This, of course, violates all expectations of how a vectorized getindex should work. My intention is to change this so that it's much more in line with the rest of Julia. However, if you're using this feature it will be a breaking change, with no graceful deprecation that I see (because you want to allow a one-dimensional InterpGrid object to support A[v]).

InterpGrid will also become of a subtype of AbstractArray and have a number of other changes in its declaration that mesh better with the rest of Julia.

Missing methods for LinSpace Range type

After upgrading to v0.4 I get the following error.

LoadError: MethodError: `coordlookup` has no method matching coordlookup(::LinSpace{Float64}, ::Float64)
Closest candidates are:
  coordlookup(!Matched::FloatRange{T<:AbstractFloat}, ::Real)
  coordlookup(!Matched::StepRange{T,S}, ::Real)
  coordlookup(!Matched::UnitRange{T<:Real}, ::Real)
while loading In[13], in expression starting on line 3

Cubic spline interpolation

I'm about to start tackling the cubic spline interpolation problem, but I feel I'm going to need someone to throw ideas and questions at along the way. As I did in #15, I'll gather them all here until I have something which is ready enough for a PR, and then we can move the discussion there.

Having taken only a quick look at the other interpolation methods, except for what I needed for the Hessian, it seems I definitely need to do the following:

  • Introduce a new type InterpCubic in interpflags.jl
  • Versions of a number of functions that specialize on interpolation type:
    • interp_coords_1d
    • interp_coefs_1d, interp_gcoefs_1d and interp_hcoefs_1d
    • npoints and isvalid
  • Introduce a new matrix Q4inv corresponding to Q3inv for the quadratic case. Where does this matrix come from? I've tried to compare it with some of the presented matrices in the paper ("Interpolation revisited") but I find no matches. Where do I find (or how do I derive) the corresponding matrix for cubic interpolation?

But there might be more I need to do, right? For example, can we piggy-back on interp_invert! and _interp_invert_matrix! for the quadratic case, simply declaring the methods for a union type, or do I need to implement those as well? Where can I read more on what these methods do, and how to implement the corresponding behavior for cubic splines?

Failing on 0.4 master

I am using tagged versions of Gadfly and its dependencies. When I do using Gadfly on 0.4, I get:

julia> using Gadfly
ERROR: LoadError: LoadError: LoadError: LoadError: LoadError: MethodError: `start` has no method matching start(::Type{Array{T<:Number,1}})
 in append_any at base.jl:203
 in include at ./boot.jl:252
 in include_from_node1 at ./loading.jl:134
 in include at ./boot.jl:252
 in include_from_node1 at ./loading.jl:134
 in reload_path at ./loading.jl:158
 in _require at ./loading.jl:70
 in require at ./loading.jl:56
 in include at ./boot.jl:252
 in include_from_node1 at ./loading.jl:134
 in reload_path at ./loading.jl:158
 in _require at ./loading.jl:70
 in require at ./loading.jl:56
 in include at ./boot.jl:252
 in include_from_node1 at ./loading.jl:134
 in include at ./boot.jl:252
 in include_from_node1 at ./loading.jl:134
 in reload_path at ./loading.jl:158
 in _require at ./loading.jl:70
 in require at ./loading.jl:53
while loading /Users/viral/.julia/v0.4/Grid/src/interp.jl, in expression starting on line 326
while loading /Users/viral/.julia/v0.4/Grid/src/Grid.jl, in expression starting on line 20
while loading /Users/viral/.julia/v0.4/KernelDensity/src/KernelDensity.jl, in expression starting on line 6
while loading /Users/viral/.julia/v0.4/Gadfly/src/statistics.jl, in expression starting on line 16
while loading /Users/viral/.julia/v0.4/Gadfly/src/Gadfly.jl, in expression starting on line 1054

Supporting second derivatives

As indicated on the julia-dev mailing list I would find it immensly useful if support was implemented for cubic spline interpolation and second order derivatives. I've started working on the latter, but I keep running into things I want to ask about, so I'll try to post questions here as they pop up. When I start working on cubic spline interpolation, I'll file a separate, similar issue for that purpose.

If I've understood correctly, these are the things that need to be implemented in order to have second order derivatives:

  • A field hcoef1d::Vector{Vector{T}} on InterpGridCoefs{T, IT<:InterpType}. This field should work exactly as e.g. gcoef1d, so initialization code etc for that field could in principle be straight-off duplicated.
  • A function set_hessian_coordinate that does, in principle, exactly the same thing as set_gradient_coordinate but for the new field
  • A function interp_hcoefs_1d that does basically the same thing as interp_gcoefs_1d, but for the hessian.
  • A function valgradhess corresponding to valgrad, which returns a tuple value, gradient, hessian

Question 1: Is my understanding correct, that if these things are implemented correctly then the existing functions for interpolation etc can do the heavy lifting for evaluating second derivatives as well?

Question 2: In lines 577-602 of src/interp.jl, three methods each for interp_coefs_1d and inter_gcoefs_1d are defined, which seem to correspond to the three interpolation methods currently implemented (nearest, linear, quadratic). However, all of the gcoef methods are for quadratic interpolation, and overwrite eachother, producing the following results:

julia> methods(Grid.interp_coefs_1d)
#3 methods for generic function "interp_coefs_1d":
interp_coefs_1d{T,BC<:BoundaryCondition}(coef1d::Array{T,1},::Type{BC<:BoundaryCondition},::Type{InterpNearest},dx::T) at /home/tlycken/.julia/v0.3/Grid/src/interp.jl:578
interp_coefs_1d{T,BC<:BoundaryCondition}(coef1d::Array{T,1},::Type{BC<:BoundaryCondition},::Type{InterpLinear},dx::T) at /home/tlycken/.julia/v0.3/Grid/src/interp.jl:585
interp_coefs_1d{T,BC<:BoundaryCondition}(coef1d::Array{T,1},::Type{BC<:BoundaryCondition},::Type{InterpQuadratic},dx::T) at /home/tlycken/.julia/v0.3/Grid/src/interp.jl:594

julia> methods(Grid.interp_gcoefs_1d)
#1 method for generic function "interp_gcoefs_1d":
interp_gcoefs_1d{T,BC<:BoundaryCondition}(coef1d::Array{T,1},::Type{BC<:BoundaryCondition},::Type{InterpQuadratic},dx::T) at /home/tlycken/.julia/v0.3/Grid/src/interp.jl:59

Is this intentional, or a bug? What behavior should really be implemented for the hessian? The fact that the quadratic interpolation is only regular in C1 suggests to me that second order derivation isn't even really interesting in this case - maybe I should tackle cubic interpolation first, and return to this when that is done?

Thanks a lot for your input.

help me interpolation

I have this points:
x = [0 0.50 1 1.50 2 2.50 3 3.50 4 4.50 5];
y = [1. 3. 4. 6. 9. 7. 8. 4. 3. 8. 10.];

How to yi function using interpolate? only works if x is a range.

CoordInterpGrid incorrectly gives DimensionMismatch error

Try the following:

xg = -10:.5:10
yg = -3:.15:3.5
zg = Float64[sin(x)*cos(y) for x in xg, y in yg]
CoordInterpGrid((xg,yg),zg, 0, InterpLinear)
ERROR: DimensionMismatch("Coordinate lengths do not match grid size.")
 in CoordInterpGrid at /home/tlycken/.julia/v0.3/Grid/src/coord.jl:7
 in CoordInterpGrid at /home/tlycken/.julia/v0.3/Grid/src/coord.jl:13
 in CoordInterpGrid at /home/tlycken/.julia/v0.3/Grid/src/coord.jl:21

This happens because for certain combinations of boundary conditions and interpolation types, the matrix with interpolation coefficients is extended with a "frame" of extra values. Because of this, size(grid) from here doesn't return the size of the original data array, and thus the assertion here fails, although the data provided by the user is actually valid.

I think the easiest fix is to provide methods for size which take this into account, and I'll probably try to put together a PR to this effect. (There might be further problems with InterpCubic related to this matrix resize, too...) However, it'll be a while, since I currently have to focus on finishing up my thesis.

extend interpolation to multichannel images?

It appears that InterpGrid is currently limited to supporting interpolations on Arrays of FloatingPoints. How difficult would it be to extend it to support, e.g., RGBs of FloatingPoints?

From a mathematical perspective, at least, I would think it should be natural to extend interpolation to any type that acts like a vector space over a "field" of FloatingPoints.

If it is anything more than trivial to implement, I'll just implement my own for now, since my current need would be satisfied by bilinear interpolation, but this would certainly represent a longer-term nice-to-have.

Newest commit of julia breaks Grid.jl? - type cannot be constructed

Hi! I just pulled and compiled Version 0.3.0-prerelease+2414 (2014-04-02 14:47 UTC) of Julia, ran Pkg.update() and removed and reinstalled Grid, and now it seems to be broken:

julia> using Grid

julia> InterpGrid(linspace(1,10,100),BCnil,InterpQuadratic)
ERROR: type cannot be constructed
 in interp_invert! at /home/gcamilo/.julia/v0.3/Grid/src/interp.jl:642
 in InterpGrid at /home/gcamilo/.julia/v0.3/Grid/src/interp.jl:52

[PkgEval] Grid may have a testing issue on Julia 0.3 (2014-05-27)

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.2) and the nightly build of the unstable version (0.3). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.3

  • On 2014-05-26 the testing status was Tests pass..
  • On 2014-05-27 the testing status changed to Tests fail, but package loads..

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

InterpLinear with more than 4 dimensions

Linear interpolation works fine with 1-4 dimensions, but it breaks at 5.

julia> B=rand(4,4,4,4,4);

julia> Bi=InterpGrid(B,BCnil, InterpLinear);

julia> Bi[2,2,2,2,2]
ERROR: no method interp_coef_generic(Array{Float64,1}, Array{Array{Float64,1},1})
 in interp_coef at /home/mykel/.julia/v0.3/Grid/src/interp.jl:1125
 in set_position at /home/mykel/.julia/v0.3/Grid/src/interp.jl:412
 in getindex at /home/mykel/.julia/v0.3/Grid/src/interp.jl:149

[PkgEval] Grid may have a testing issue on Julia 0.3 (2014-10-11)

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.3

  • On 2014-10-10 the testing status was Tests pass.
  • On 2014-10-11 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("Grid")' log
INFO: Cloning cache of Grid from git://github.com/timholy/Grid.jl.git
INFO: Installing Grid v0.3.5
INFO: Package database updated
INFO: METADATA is out-of-date a you may not have the latest version of Grid
INFO: Use `Pkg.update()` to get the latest versions of your packages

>>> 'using Grid' log
Julia Version 0.3.1
Commit c03f413* (2014-09-21 21:30 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

>>> test log
ERROR: assertion failed: |g[2] - gnum| <= 2.9201805051331457e-12
  g[2] = 9.79849953263584e-5
  gnum = 9.798500104807317e-5
  difference = 5.721714768647246e-12 > 2.9201805051331457e-12
 in error at error.jl:22
 in test_approx_eq at test.jl:109
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
 in _start_3B_1712 at /home/idunning/julia03/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.3/Grid/test/grid.jl, in expression starting on line 191
while loading /home/idunning/pkgtest/.julia/v0.3/Grid/test/runtests.jl, in expression starting on line 2

INFO: Testing Grid
================================[ ERROR: Grid ]=================================

failed process: Process(`/home/idunning/julia03/usr/bin/julia /home/idunning/pkgtest/.julia/v0.3/Grid/test/runtests.jl`, ProcessExited(1)) [1]

================================================================================
INFO: No packages to install, update or remove
ERROR: Grid had test errors
 in error at error.jl:21
 in test at pkg/entry.jl:715
 in anonymous at pkg/dir.jl:28
 in cd at ./file.jl:20
 in cd at pkg/dir.jl:28
 in test at pkg.jl:67
 in process_options at ./client.jl:213
 in _start at ./client.jl:354
 in _start_3B_1712 at /home/idunning/julia03/usr/bin/../lib/julia/sys.so


>>> end of log

[PkgEval] Grid may have a testing issue on Julia 0.4 (2014-10-23)

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.4

  • On 2014-10-22 the testing status was Tests pass.
  • On 2014-10-23 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

Special message from @IainNZ: This change may be due to JuliaLang/julia#8712.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("Grid")' log
INFO: Installing Grid v0.3.6
INFO: Package database updated

>>> 'using Grid' log
Julia Version 0.4.0-dev+1249
Commit 23a9373 (2014-10-23 04:46 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

>>> test log

ERROR: `-` has no method matching -(::InterpGrid{Float64,1,BCreflect,InterpNearest}, ::Array{Float64,1})
 in anonymous at no file:104
 in include at ./boot.jl:242
 in include_from_node1 at ./loading.jl:128
 in include at ./boot.jl:242
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:293
 in _start at ./client.jl:362
 in _start_3B_3776 at /home/idunning/julia04/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.4/Grid/test/grid.jl, in expression starting on line 101
while loading /home/idunning/pkgtest/.julia/v0.4/Grid/test/runtests.jl, in expression starting on line 2

INFO: Testing Grid
================================[ ERROR: Grid ]=================================

failed process: Process(`/home/idunning/julia04/usr/bin/julia /home/idunning/pkgtest/.julia/v0.4/Grid/test/runtests.jl`, ProcessExited(1)) [1]

================================================================================
INFO: No packages to install, update or remove
ERROR: Grid had test errors
 in error at error.jl:21
 in test at pkg/entry.jl:719
 in anonymous at pkg/dir.jl:28
 in cd at ./file.jl:20
 in cd at pkg/dir.jl:28
 in test at pkg.jl:68
 in process_options at ./client.jl:221
 in _start at ./client.jl:362
 in _start_3B_3776 at /home/idunning/julia04/usr/bin/../lib/julia/sys.so

>>> end of log

error: CoordInterpGrid changed?

I get the following error:
no method CoordInterpGrid{T<:FloatingPoint,N,BC<:BoundaryCondition,IT<:InterpType,R}((Array{Float64,1},FloatRange{Float64}), Array{Float64,2}, Float64, Type{InterpLinear})

The code used to work fine until a month ago. I think you have changed the source since then. I have updated to the latest version. What am I doing wrong?

[PkgEval] Grid may have a testing issue on Julia 0.3 (2014-06-10)

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.2) and the nightly build of the unstable version (0.3). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.3

  • On 2014-06-04 the testing status was Tests pass.
  • On 2014-06-10 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

INFO: Installing Grid v0.3.2
INFO: Package database updated
ERROR: no method A_mul_B!(Array{Float64,1}, Triangular{Float64,Array{Float64,2},:U,false}, Array{Float64,1})
 in A_ldiv_B! at linalg/woodbury.jl:85
 in interp_invert! at /home/idunning/pkgtest/.julia/v0.3/Grid/src/interp.jl:890
 in InterpGrid at /home/idunning/pkgtest/.julia/v0.3/Grid/src/interp.jl:61
 in anonymous at no file:49
 in include at boot.jl:244 (repeats 2 times)
 in include_from_node1 at loading.jl:128
while loading /home/idunning/pkgtest/.julia/v0.3/Grid/test/grid.jl, in expression starting on line 43
while loading /home/idunning/pkgtest/.julia/v0.3/Grid/test/runtests.jl, in expression starting on line 1
INFO: Package database updated

Feature request: BCLinExtrapolate

hi!

I thought it would be very useful to have the boundary condition BCLinExtrapolate which would linearly extrapolate the function outside lower and upper bounds, using the first and last two gridpoints respectively to compute this extrapolation.

Error trying to use 'restrict'

507 [hacks/julia/images] $ julia
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" to list help topics
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.2.1 (2014-02-11 06:30 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/                   |  x86_64-apple-darwin12.5.0

julia> using Images
Warning: Possible conflict in library symbol dtrtri_
Warning: Possible conflict in library symbol dgetri_
Warning: Possible conflict in library symbol dgetrf_

julia> using Grid

julia> im = imread("lake.jpg");

julia> arr = convert(Array, im);

julia> size(arr)
(1944,2592,3)

julia> imgr = restrict(arr, [true,true,false]);
ERROR: InexactError()
 in setindex! at array.jl:412
 in restrict at /Users/chris/.julia/v0.2/Grid/src/restrict_prolong.jl:168
 in anonymous at /Users/chris/.julia/v0.2/Grid/src/restrict_prolong.jl:182
 in mapdim at /Users/chris/.julia/v0.2/Grid/src/utilities.jl:15
 in restrict at /Users/chris/.julia/v0.2/Grid/src/restrict_prolong.jl:183
 in restrict at /Users/chris/.julia/v0.2/Grid/src/restrict_prolong.jl:185

This is on a mac, OS X 10.9.3, using the binary Julia downloaded from the site.

Thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.