juliageometry / oldimmutablearrays.jl Goto Github PK

For types like these that are likely to be fairly ubiquitous, I like names that are short and sweet. I wrote an analogous piece of C++ library code at work following a very similar naming convention and have gotten lots of positive feedback. I'm open to hearing criticism, especially if there is some reason to believe there is a more Julian choice.

Hi, when loading GLPlot with the latest master I receive this error, which I believe may be a problem with ImmutableArrays:

ERROR: LoadError: LoadError: MethodError: convert has no method matching convert(::Type{ImmutableArrays.Vector3{Float32}})
This may have arisen from a call to the constructor ImmutableArrays.Vector3{Float32}(...),
since type constructors fall back to convert methods.
Closest candidates are:
convert{T}(::Type{ImmutableArrays.Vector3{T}}, ::ImmutableArrays.Vector3{T})
convert{T}(::Type{ImmutableArrays.Vector3{T}}, ::AbstractArray{T,1})
convert{T}(::Type{T}, ::T)
in call at /home/cody/.julia/v0.4/GLAbstraction/src/GLUniforms.jl:48

Am I correct? Thanks!

For reference, this issue was introduced here: JuliaLang/julia@3046190
I am seeing the following ambiguous definition notices (repeated numerous times) when using ImmutableArrays.

Warning: New definition 
    -(Number,Matrix4x3{T}) at /home/steve/.julia/ImmutableArrays/src/generate_arrays.jl:313
is ambiguous with: 
    -(Bool,AbstractArray{Bool,N}) at array.jl:774.
To fix, define 
    -(Bool,Matrix4x3{Bool})
before the new definition.

This is only noticed with plus and minus operators.

cc: @jayschwa

Since FixedSizeArrays seems to be reaching maturity, these packages are redundant. I think by 0.5, there should be one package in this space. These are the current packages depending on ImmutableArrays:

Contour      
GLAbstraction
Meshes       
GLWindow   
GLPlot

cc @SimonDanisch

It'd be nice if there were an easy way to create an immutable array from a native Julia array. Example:

julia> x
2x2 Int64 Array:
 1  2
 3  4

julia> Matrix2x2(x)
2x2 Int64 Matrix2x2:
 1  3
 2  4

Using this on an up-to-date 0.2 prerelease, there are a whole lot of ambiguity warnings for the .^ operator.

julia> versioninfo()
Julia Version 0.2.0-prerelease+3863
Commit 721c9fb* 2013-09-27 05:26:59 UTC
Platform Info:
  System: Linux (x86_64-linux-gnu)
  WORD_SIZE: 64
  BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: liblapack
  LIBM: libopenlibm

julia> using ImmutableArrays
Warning: New definition
    .^(Number,Vector1{T}) at /home/vagrant/.julia/ImmutableArrays/src/generate_arrays.jl:122
is ambiguous with
    .^(MathConst{:e},AbstractArray{T,N}) at constants.jl:85.
Make sure
    .^(MathConst{:e},Vector1{T})
is defined first.
...
Warning: New definition
    .^(Number,Matrix4x4{T}) at /home/vagrant/.julia/ImmutableArrays/src/generate_arrays.jl:308
is ambiguous with
    .^(MathConst{:e},AbstractArray{T,N}) at constants.jl:85.
Make sure
    .^(MathConst{:e},Matrix4x4{T})
is defined first.

There's one of those for each type in the package.

I have gone with x,y,z,w for the existing types, but I'm wondering if it wouldn't be better to do something like field1,field2,... or f1,f2,... or e1,e2,... to, for instance, help ease the pain of adding automatic generation of higher dimensional types.

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.

I can't really do much useful yet, since we are missing multiplication and sum between our vectors and arbitrary scalars (should be for all subtypes of Number I guess, so it works for complex numbers too).

It would be nice to find out if our randmatstat microbenchmark, which is a benchmark that uses a lot of small matrices would benefit with immutable arrays.

When using an (mutable) array of vectors it would be nice to index in with array_vectors[n,m] instead of array_vectors[n,m] array_vectors[n][m].

I will try filing a PR for this.

Hello

It would be useful with support for exponentiation of immutable matrices. With

A = Matrix2x2(eye(2))

A^n for n >= 0 do return the numerically correct matrix (there is a function ^(x, p::Integer) in intfuncs.jl) however for n=0 and n=1 it is just a normal array an not a Matrix2x2{Float64}, for n>1 the type of the returned matrix is of the (expected) type Matrix2x2{Float64}.

Looking at the implementation of ^(x, p::Integer) it seems like a quick fix could be to add copy(::MatrixMxN{T}) and one(::MatrixMxN{T}) although it's perhaps not the cleanest one (the two functions could be added in their own right though).

(Expontentation of an immutable matrix with negative or non-integers throws errors, but those are less used features I guess.)

Should be easy replace-and-tag

It would be good to have an easy-to-run performance test available in the repo. Ideally, the test should perform common operations and compare their speed to the same operations on native Julia arrays. This would allow developers to test prospective changes in a consistent way and provide some good talking points for the package (e.g. "X times faster than native Julia arrays!").

I think @dronir already has something started for this?

Am I missing something, or is this a bug?

julia> a = Matrix4x4(1.0)
4x4 Matrix4x4{Float64}:
 1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0

julia> inv(a)
ERROR: no method A_ldiv_B!(Matrix4x4{Float64}, Array{Float64,2})
 in inv at linalg/generic.jl:223

Best,
Simon

Just noticed this:

julia> a = Vector3{Float64}(0.1, 0.2, 0.3)
3-element Float64 Vector3:
 0.1
 0.2
 0.3

julia> -a
3-element Float64 Array:
 -0.1
 -0.2
 -0.3

Messes up things easily of course.

I have gone with what seems to be an emerging Julian convention of giving the package a plural name to avoid clashing with a similarly named type (although that's not strictly necessary for this package).

Viral suggested SmallVec or SmallMatrix in his response to the package announcement on the mailing list.

Thoughts and opinions welcome on the matter.

Since e0e7bd9 fixes some functionality that is required for Contour.jl (see tlycken/Contourl.jl#20) it would be nice if you could tag a new version where this is included, so we don't have to depend on latest master :)

Example:

julia> Matrix3x3(
       11, 12, 13,
       21, 22, 23,
       31, 32, 33)
3x3 Int64 Matrix3x3:
 11  12  13
 21  22  23
 31  32  33

The current implementation roundtrips the data to/from Array.

For the package name I have followed what seems to be an emerging Julian convention for using a pluralization to avoid clashing with a similarly named type in the package (although that's not strictly necessary in this case).

In response to the package announcement on the mailing list, though, @ViralBShah suggested "SmallVec" or "SmallMatrix".

Opinion and argument welcome.

I'm starting to implement matrices. I'm currently going with a row-major representation, but I wanted to solicit feedback on this question before getting too deep.

The vast majority of the code in this package should be amenable to mechanical generation.

It might even be nice to design it such that a user can instantiate a module with a given number of dimensions. The package can provide a certain number by default (at least 4, maybe as many as 10), but, inevitably, somebody will want more. Hopefully we'll be able to provide a mechanism to satisfy all.

Native Julia arrays can be sliced into sub-arrays:

julia> x
4x4 Float32 Array:
 1.0f0  0.0f0  0.0f0    39.0f0
 0.0f0  1.0f0  0.0f0  9293.0f0
 0.0f0  0.0f0  1.0f0    -2.0f0
 0.0f0  0.0f0  0.0f0     1.0f0

julia> x[2:4,3:4]
3x2 Float32 Array:
 0.0f0  9293.0f0
 1.0f0    -2.0f0
 0.0f0     1.0f0

Ideally, slicing a Matrix4x4 in this manner should produce a Matrix3x2.

Should we have a separate matrix type? Right now I'm relying on a matrix being a vec-of-vecs. We can't subtype AbstractMatrix without matrix types. The number of types we need to define in that case goes as the square of the maximum dimension, though...

The benchmark script spends the majority of the time interpreting the passed function + and *. Manually inlining the functions gives completely different results (in ImmutableArrays favor). This could be fixed with either using a functor (but this doesn't work for 0.3) or by some macroing to generate two different functions with the * and + inlined..

@ViralBShah mentioned that getting this would make for some amazing performance. I, however, don't know what would be involved.

i just found this package after i finished my own and really liked the meta-programming way to generate all the things i coded by hands.

i could find nearly all the functions i coded in this package, except that i need to translate/rotate a large array of Vector4, which is a fairly common thing in 3D graphics.

for example:

mymodel = fill(Vector4(1.0),20)
tm = Matrix4x4([1.0 0.0 0.0  2.0;
                0.0 1.0 0.0  0.0;
                0.0 0.0 1.0  0.0;
                0.0 0.0 0.0  1.0])
transformedmodel = tm*mymodel

i know for small array of Vector4, i could do map(x->tm*x,mymodel). but would be faster if convert the array of Vector4 to a matrix and multiply.

any consideration to add this functionality?

The types should be sub-types of their Abstract counterparts, e.g.:
immutable Vec2{T} <: AbstractVector{T}

This will provide a great deal of functionality with the standard library for free.

This was originally reported in https://groups.google.com/forum/#!topic/julia-users/LIXG4TjUpDI and there is a related bug report filed for Julia: JuliaLang/julia#8010
However, I think there is a problem with ImmutableArrays, too. Here is my original post:

Dear all,

I am seeing an unexpected behaviour when combining ImmutableArrays and struct like types (I forgot what the proper name is). In particular, the following code:

using ImmutableArrays

immutable Mytype
pos::Vector2{Float32}
end

println(Mytype([4.; 5.]))

incorrectly prints "Mytype(Float32[0.0,2.25])" instead of the expected "Mytype(Float32[4.0,5.0])". This is on the latest Ubuntu, Julia 0.3.0-prerelease+3628 (2014-06-11 15:07 UTC).

Both "Mytype([4f0; 5f0])" and "convert(Vector2{Float32},[4.;5.])" work as expected but changing "immutable" to "type" does not change the error.

So is there a bug in ImmutableArrays, in Julia, or am I doing something wrong? If I am doing something wrong, I would at least expect a warning - this error cost me quite some time to find out.

Maybe I do not understand how ImmutableArrays is supposed to work, since

  typeof(convert(Vector2{Float32},[4.;5.]).e1)

gives Float64, not Float32 as expected. So is ImmutableArrays actually an efficient way of storing fixed-size vectors? Or do I have to stick to Float64 even if I do not need the accuracy?

Thank you for your help. Yours,

Jan

It's inevitable (and reasonable) that someone is going to want immutable arrays that can represent rank 3 tensors.

In light of that, I'm thinking it might be worth considering defining arrays of rank 2 and higher recursively in terms of lower rank arrays (in an automated fashion).

Immutable arrays probably should have an unrolled, immutable (and probably unpivoted) Gaussian elimination on which to base linear solving and matrix inversion.

This would resolve the issue first raised in #30.

I'm currently experimenting with Travis CI integration on one of my branches:

Travis CI will allow pushes and pull requests to be automatically tested. Unfortunately, there are no PPAs with a newer version of Julia that supports immutable, among other things. My test branch is only passing right now because I'm applying some disgusting workarounds to make the code compatible with Julia v0.1. Once a newer Julia package is available and I have it passing on my test branch, I will clean the branch up and create a pull request.

Dependencies:

• JuliaLang/julia#2031