Enables rust-blas to build on Rust stable.

This sorts the function prototypes in the FFI by group, and changes the prefix! and similar macros to using the new modules instead of concat_indent!.

The future of concat_ident! is uncertain: https://github.com/rust-lang/rust/issues/29599

Hi, thanks for writing this wrapper @mikkyang! It seems very intuitive and lacks the extra cruft found in some other ports.

As it stands, I was unable to use this library. In my system "libblas" links to the (fortran?) blas library which has a different interface than the cblas library. Note that the blas functions dont have the "cblas_" prefix. The linker couldn't find the functions I wanted to use.

In order to get your code working, I had to link against "cblas" instead. You'll notice I linked against openblas instead of cblas in this pull request. There may be other implementations of blas that users of this port may want to use too. I don't suggest merging this pull, or making a new pull linking to "cblas" instead of "openblas". I think a better solution is to let the user decide which library (with the cblas interface) they want to link to. I'm thinking some sort of ENV variable used in the macros, and if the env-var is not defined, use "cblas" as default.

Thanks again for the port! I'm very new to rust, but if you want this change and you're not feeling up to making this change, I'd be willing to give it a shot. Also, I'm curious if your projects work if you link to "cblas" instead of "blas". I think "cblas" is the proper library to be linking to.

hey,

i’m considering using rblas to speed up some machine learning code i’m working on. i’ve done some benchmarks. unsurprisingly rblas is 4-10 times faster than the same operations in nalgebra.

i need to fill some rblas::math::mat::Mat with data flexibly and programmatically.

unfortunately i've not found a nice way to do so. maybe i’m missing something obvious ?

it would be great if rblas::math::mat::Mat implemented std::ops::IndexMut. is there a specific reason why it doesn't at the moment or is this just an oversight ?

i’d be happy to implement it and do a pull request !

let me know.

best, max

I was curious as to whether there was any reason for using i32 instead of usize for various 'size' parameters? Are negative integers ever returned? And what if (hypothetically speaking) a Vector on a 64-bit machine has a length exceeding the maximum i32 integer?

I'll have a go at implementing this change, but it will unfortunately break quite a lot of function (though easily fixable, and better late than never).

I have added a simple matrix type that wraps a vector and implements your Matrix trait. It allows use like let A = Mat::::new(4,4); A[0][1] = 1f64; ... and since A[i] yields a slice rows can also be used as a vector. This is some of my first rust code ever so I hope it's not too bad.

Right now, using slices as Vector trait objects don't work. This is because the Vector trait is implemented on [T]. Formerly it was implemented on &[T], but I realized this was incorrect. To receive the correct behavior there are two things I can think of immediately, outlined below. Similar things would be done to Matrix for coherency.

Option 1: Split the trait Vector into Vector and VectorMut

Splitting the traits, all of the immutable &self methods would remain in Vector and the mutable &mut self methods would be moved to VectorMut which will be a trait inheriting from Vector.

Function signatures that were previously:

fn axpy(alpha: &Self, x: &Vector<Self>, y: &mut Vector<Self>);

would become:

fn axpy(alpha: &Self, x: &Vector<Self>, y: &mut VectorMut<Self>);

Advantages:

• Actual operation function signatures just replace &mut Vector with &mut VectorMut and everything should work.

Disadvantages:

• This adds a level of indirection (not sure if right word) in the function calls. Essentially, the slices would work because the functions would take &&[T] rather than &[T].
• Breakage. People that were just using Vec and their own types would have to move the method.
• Repetitiveness. You already know that &mut types are mutable. I suppose Index and IndexMut are somewhat similar, though.

Option 2: Generics

Keep the traits the same, and add an unsized annotation to every function that takes a Vector.

Function signatures that were previously:

fn axpy(alpha: &Self, x: &Vector<Self>, y: &mut Vector<Self>);

would become:

fn axpy<V: ?Sized + Vector<Self>, W: ?Sized + Vector<Self>>(alpha: &Self, x: &V, y: &mut W);

Advantages:

• Traits remain the same, which means clearer traits.

Disadvantages:

• Function signatures become much, much more verbose. Especially because &x and &y maybe be different types, we can't constrict them both to the same type and have to specify trait bounds twice.

Currently rblas is not building with the rust nightly due to changes in features. I made a few changes to get things to build as well as migrating unstable features to stable APIs with the same functionality.

The code now builds on nightly rust as of today (2015-07-13) and all the tests pats. The only thing that is keeping it from building on stable and beta is the concat_idents! feature gate.

When calling gemm, the arguments M, N, and K must describe the dimensions of the transposed matrices (as determined by the transa and transb) instead of the original matrices (http://www.netlib.org/lapack/explore-html/d7/d2b/dgemm_8f.html).

As far as I can tell, gemm is the only routine where this matters.

Sorry to pester.

The default implementation of Matrix<T> has RowMajor ordering but returns rows for lead_dim which is in turn used by BLAS as the LDA argument for the matrix. However, unless I'm just being dumb, for a row major ordered matrix, the leading dimension should be the number of columns. This appears to have not bee caught by the tests because they use square matrices. As a minimal example of the problem, consider,

        let a = (2, 3,
                 vec![
                 1.0, -3.0, 1.0,
                 2.0, -6.0, 2.0]);
        let x = vec![2.0, 1.0, 1.0];
        let mut y = vec![1.0, 2.0];
        let t = Transpose::NoTrans;

        Gemv::gemv(t, &1f32, &a, &x, &0f32, &mut y);

        assert_eq!(y, vec![0.0, 0.0]);

which will give an error like BLAS error: Parameter lda passed to cblas_sgemv was 2, which is invalid. depending on what BLAS implementation your using. The solution is either to have lead_dim default to cols or to have it determine the appropriate lead dimension by matching on the ordering. I have a fix in the bugfix branch of my fork if you'd like to use that.

Thanks!

Hi there, we (Rust group @sslab-gatech) are scanning crates on crates.io for potential soundness bugs. We noticed that in these three code locations, unsafe memory is passed to Copy::copy, Copy::copy_mat and Gemv::gemv:

https://github.com/mikkyang/rust-blas/blob/bf6d33139eadb2c1215d259fd3b84bf04b531871/src/vector/mod.rs#L30-L38

https://github.com/mikkyang/rust-blas/blob/bf6d33139eadb2c1215d259fd3b84bf04b531871/src/math/mat.rs#L121-L123

https://github.com/mikkyang/rust-blas/blob/bf6d33139eadb2c1215d259fd3b84bf04b531871/src/math/matrix_vector.rs#L23-L29

Copy and Gemv are currently public and safe traits to implement, maybe they should be marked as unsafe or the individual methods that can receive undefined memory marked as unsafe.

Also note that the Into<Vec<T>> implementation can invoke undefined behavior, see https://doc.rust-lang.org/std/mem/union.MaybeUninit.html#initialization-invariant

As a consequence, zero-initializing a variable of reference type causes instantaneous undefined behavior, no matter whether that reference ever gets used to access memory

which means that just doing something like this can invoke undefined behavior:

#![forbid(unsafe_code)]

use rblas::matrix::Matrix;
use rblas::vector::ops::Copy;
use rblas::vector::Vector;

#[derive(Clone, Debug)]
struct MyType(Box<u64>);

impl Copy for MyType {
    fn copy<V, W>(src: &V, dst: &mut W)
    where
        V: ?Sized + Vector<Self>,
        W: ?Sized + Vector<Self>,
    {
    }

    fn copy_mat(src: &Matrix<Self>, dst: &mut Matrix<Self>) {}
}

fn main() {
    let vec = vec![MyType(Box::new(42))];
    let as_blas_vector = &vec as &Vector<_>;

    let back_to_vec: Vec<MyType> = as_blas_vector.into();
}

I'm on Gentoo and have the sci-libs/cblas-reference and virtual/cblas packages installed. When I run cargo test I get a couple of pages of errors "undefined reference to `cblas_...'"

I eventually figured out that I need to build with CARGO_BLAS=cblas to make it work.

Hello,

I am on Fedora 23, with blas and blas-devel 3.5.0 installed. I get the following error message when trying to run tests in Leaf using cargo.

If I switch to openblas, the link error disapears

Hi, I am probably moving away from rblas to blas-sys, I wanted to leave some observations anyway. I'm also happy to help with questions if you have any.

An issue that mostly only should be important for small matrices and vectors is that trait objects (for example the type &Matrix<T>) cause their method calls to be virtual function calls. This makes them uninlinable. This is a bit unfortunate, since all of .order(), cols(), rows(), as_ptr() and so on are called through the trait object.