BlasMatrix constructors

[B Saunders]

I'm getting errors on Ubuntu with g++ version 4.4.3 and g++ version
4.4.5 (2 different machines) that I did not get on a solaris machine
with g++ version 4.4.1.

It seems that blas-matrix.inl defines a constructor having a signature
not declared in blas-matrix.h. It has to do with the types of the
dimensions (the last two arguments). BlasMatrix declares and/or
defines a smorgasbord of constructors using various signed and
unsigned integer types, not to mention a type template parameter for
some. Version 4.4.1 of g++ apparently ignores an extra definition,
where the more recent versions do not.

Do we really need such verbosity of declarations and definitions? I
would like to think that all relevant signed and unsigned types can
get implicitly cast to a size_t (with compile time warning). I
actually think it is good practice in programs to make explicit casts
to our indexing type, size_t, as the preferred way to avoid type
warnings or errors.

Size_t has been our indexing type since the very first design of
Turner and Kaltofen. I do feel that there could be a review of this
at some point. A case can be made for a signed type (ptrdiff_t, for
instance), because it is sometimes convenient to take differences that
could be negative or even have a negative index. Also a case can be
made for a type permitting larger values than the range of memory
addresses. Not all matrix representations are limited to an index
range that maps directly to memory addresses.

Bottom line: it seems there is a detail to fix in BlasMatrix and a
larger issue to discuss somewhere down the road.

Best,
-dave

make[3]: Entering directory `/home/saunders/sandbox/linbox/linbox/algorithms'
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I../.. -O2 -pipe -Wall -g -DNDEBUG -U_LB_DEBUG
-DDISABLE_COMMENTATOR -I/home/saunders/sandbox/include -c -o
diophantine-solver.lo diophantine-solver.C
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -O2 -pipe -Wall -g
-DNDEBUG -U_LB_DEBUG -DDISABLE_COMMENTATOR
-I/home/saunders/sandbox/include -c diophantine-solver.C -fPIC -DPIC
-o .libs/diophantine-solver.o
In file included from ../../linbox/matrix/blas-matrix.h:1280,
from ../../linbox/blackbox/compose.h:33,
from ../../linbox/algorithms/rational-solver.h:39,
from ../../linbox/algorithms/diophantine-solver.h:28,
from diophantine-solver.C:24:
../../linbox/matrix/blas-matrix.inl:244: error: prototype for
‘LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, long int, T)’
does not match any in class ‘LinBox::BlasMatrix<_Field>’
../../linbox/matrix/blas-matrix.h:294: error: candidates are:
template<class _Field> template<class StreamVector>
LinBox::BlasMatrix::BlasMatrix(const _Field&,
LinBox::VectorStream<StreamVector>&)
../../linbox/matrix/blas-matrix.h:283: error:
LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, const typename
_Field::Element*, size_t, size_t)
../../linbox/matrix/blas-matrix.h:277: error:
LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, const
std::vector<typename Field::Element, std::allocator<typename
Field::Element> >&, size_t, size_t)
../../linbox/matrix/blas-matrix.h:267: error:
LinBox::BlasMatrix<_Field>::BlasMatrix(const
LinBox::BlasMatrix<_Field>&)
../../linbox/matrix/blas-matrix.h:262: error:
template<class _Field> template<class _Matrix>
LinBox::BlasMatrix::BlasMatrix(const _Matrix&, const _Field&)
../../linbox/matrix/blas-matrix.h:255: error:
template<class _Field> template<class Matrix>
LinBox::BlasMatrix::BlasMatrix(const Matrix&, size_t, size_t, size_t,
size_t)
../../linbox/matrix/blas-matrix.h:243: error:
template<class _Field> template<class Matrix>
LinBox::BlasMatrix::BlasMatrix(const Matrix&)
../../linbox/matrix/blas-matrix.h:237: error:
LinBox::BlasMatrix<_Field>::BlasMatrix(LinBox::MatrixStream<Field>&)
../../linbox/matrix/blas-matrix.h:229: error:
template<class _Field> template<class T>
LinBox::BlasMatrix::BlasMatrix(const _Field&, LinBox::Integer&, T)
../../linbox/matrix/blas-matrix.h:226: error:
template<class _Field> template<class T>
LinBox::BlasMatrix::BlasMatrix(const _Field&, int32_t, T)
../../linbox/matrix/blas-matrix.h:223: error:
template<class _Field> template<class T>
LinBox::BlasMatrix::BlasMatrix(const _Field&, unsigned int, T)
../../linbox/matrix/blas-matrix.h:220: error:
template<class _Field> template<class T>
LinBox::BlasMatrix::BlasMatrix(const _Field&, int64_t, T)
../../linbox/matrix/blas-matrix.h:217: error:
template<class _Field> template<class T>
LinBox::BlasMatrix::BlasMatrix(const _Field&, uint64_t, T)
../../linbox/matrix/blas-matrix.inl:227: error:
LinBox::BlasMatrix<_Field>::BlasMatrix()
../../linbox/matrix/blas-matrix.inl:221: error:
LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&)
../../linbox/matrix/blas-matrix.inl:255: error: prototype for
‘LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, long unsigned
int, T)’ does not match any in class ‘LinBox::BlasMatrix<_Field>’
../../linbox/matrix/blas-matrix.h:294: error: candidates are:
template<class _Field> template<class StreamVector>
LinBox::BlasMatrix::BlasMatrix(const _Field&,
LinBox::VectorStream<StreamVector>&)
../../linbox/matrix/blas-matrix.h:283: error:
LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, const typename
_Field::Element*, size_t, size_t)
../../linbox/matrix/blas-matrix.h:277: error:
LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, const
std::vector<typename Field::Element, std::allocator<typename
Field::Element> >&, size_t, size_t)
../../linbox/matrix/blas-matrix.h:267: error:
LinBox::BlasMatrix<_Field>::BlasMatrix(const
LinBox::BlasMatrix<_Field>&)
../../linbox/matrix/blas-matrix.h:262: error:
template<class _Field> template<class _Matrix>
LinBox::BlasMatrix::BlasMatrix(const _Matrix&, const _Field&)
../../linbox/matrix/blas-matrix.h:255: error:
template<class _Field> template<class Matrix>
LinBox::BlasMatrix::BlasMatrix(const Matrix&, size_t, size_t, size_t,
size_t)
../../linbox/matrix/blas-matrix.h:243: error:
template<class _Field> template<class Matrix>
LinBox::BlasMatrix::BlasMatrix(const Matrix&)
../../linbox/matrix/blas-matrix.h:237: error:
LinBox::BlasMatrix<_Field>::BlasMatrix(LinBox::MatrixStream<Field>&)
../../linbox/matrix/blas-matrix.h:229: error:
template<class _Field> template<class T>
LinBox::BlasMatrix::BlasMatrix(const _Field&, LinBox::Integer&, T)
../../linbox/matrix/blas-matrix.h:226: error:
template<class _Field> template<class T>
LinBox::BlasMatrix::BlasMatrix(const _Field&, int32_t, T)
../../linbox/matrix/blas-matrix.h:223: error:
template<class _Field> template<class T>
LinBox::BlasMatrix::BlasMatrix(const _Field&, unsigned int, T)
../../linbox/matrix/blas-matrix.h:220: error:
template<class _Field> template<class T>
LinBox::BlasMatrix::BlasMatrix(const _Field&, int64_t, T)
../../linbox/matrix/blas-matrix.h:217: error:
template<class _Field> template<class T>
LinBox::BlasMatrix::BlasMatrix(const _Field&, uint64_t, T)
../../linbox/matrix/blas-matrix.inl:227: error:
LinBox::BlasMatrix<_Field>::BlasMatrix()
../../linbox/matrix/blas-matrix.inl:221: error:
LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&)
make[3]: *** [diophantine-solver.lo] Error 1
make[3]: Leaving directory `/home/saunders/sandbox/linbox/linbox/algorithms'
make[2]: *** [all-recursive] Error 1

[Brice Boyer]

Hello again !

2011/10/26 B Saunders <saun...@udel.edu>

well, I don't like size_t very much. I'd rather we have an index_t that is a typedef to a uint32_t for instance (cf ffspmvgpu). I made these constructors because it was faster than finding/fixing all the compile warnings/errors. I just fixed int -> int32_t etc in the inl but none was missing. I'm not sure what problem there is...

--
You received this message because you are subscribed to the Google Groups "linbox-devel" group.
To post to this group, send email to linbox...@googlegroups.com.
To unsubscribe from this group, send email to linbox-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/linbox-devel?hl=en.

--
                                                      Brice Boyer.
____________________________________________________________
brice...@imag.fr                                     Tél. +33(0)4 76 51 45 61
Université Joseph Fourier, Grenoble I.
Laboratoire Jean Kuntzmann, Mathématiques Appliquées et Informatique
LJK - UJF  BP53 38041 Grenoble cedex FRANCE
http://ljk.imag.fr/membres/Brice.Boyer
____________________________________________________________

[B Saunders]

Brice, thanks for that simple fix. With that these recent g++
versions don't complain during make or make check. However there were
a couple of tests which called that constructor with a long for the
dimension argument. The compiler choked. I have changed the
test-dense and test-matrix-domain so that now they compile with these
compilers.
It means that we have a policy that you must use a size_t or
[u]int<2^{8k}>_t. Fine by me.

I also like the convention of using an index_t, and this is
independent of the question of what it is typedef-ed to. (In other
words, even if typedef-ed to size_t, for example, I would like it.).
I don't yet see a clear benefit of a different unsigned type:
uint32_t, which seems to me to be too constrained. What benefit does
it convey over size_t in ffspmvgpu?

Best,
-dave

[Brice Boyer]

2011/10/27 B Saunders <saun...@udel.edu>

Brice, thanks for that simple fix.  With that these recent g++
versions don't complain during make or make check.  However there were
a couple of tests which called that constructor with a long for the
dimension argument.  The compiler choked.   

I have changed the
test-dense and test-matrix-domain so that now they compile with these
compilers.

what's their version ? I tested on a 4.4.5/32bits and no problem. Anyway if the compiler fails on this, it's more a compiler problem than a coding one... 

The compiler in the latest stable debian is 4.4.5... (maybe a buildbot with a stable debian + telling on the main page we support g++ for a stable debian should be enough ? For instance, we already know  many 4.2 releases will produce bogus executables if they compile at all. 

It means that we have a policy that you must use a size_t or
[u]int<2^{8k}>_t.  Fine by me.

I'd rather loops use using index_t, as well as vector/matrix/... constructors, with the proper casts. I chose to allow any combination of ([u]int[X]_t,T) just because it was a simpler fix for now (not only does it fix warnings but also errors like "there is no rowdim() member in 'int'...". It is also simpler for the user since she doesn't need to make an explicit cast... By the way, there is the same problem when we initialise Fields/Integers... we often support plenty of types while we would be better off supporting only (Integer/unsigned long/long/double) at the price of casting...

We should discuss all this too for the future design and try to stick to this. Some time ago, I had rewritten plenty of loops with size_t...

I also like the convention of using an index_t, and this is
independent of the question of what it is typedef-ed to. (In other
words, even if typedef-ed to size_t, for example, I would like it.).
I don't yet see a clear benefit of a different unsigned type:
uint32_t, which seems to me to be too constrained.  What benefit does
it convey over size_t in ffspmvgpu?

I don't know the size of a size_t if I don't check it during configure time... As for an index_t (unsigned) and its signed counterpart, we can typedef them  to something (not compiler dependent), the size of which we can choose/we know.

Best,
-dave

In Givaro, I added an uninstall-hook to remove the empty left overs (this is a gnu feature, not a bug I suspect). I did the same in fflas-ffpack.

cheers

[B Saunders]

size_t can hold the size of any memory block and any pointer can be
cast to a size_t. This is platform independent. For indices that is
a good, whereas for field and ring element types, I am more
comfortable with types of fixed size such as uint32_t.

The only argument I can think of against size_t would be if you are
sure you won't use a matrix of over 2^31 entries and you want matrix
handles to be smaller. I'd need to be shown an example where this
matters before I'd consider it. In any case if index_t is settable at
configure time, then one has both options: use size_t in general and
use uint32_t when there are going to be a gazillion small matrices.

On another thread of this conversation, below I show the compilation
problem exemplified by test-dense when I back off to the use of a long
parameter for handing the matrix size parameter to the test function
(changing this long to size_t is what fixed test-dense for me). It is
with gcc 4.4.5/32bit, which seems to be like your environment, Brice.
So I am surprised if your compiler doesn't also complain.

Best,
-dave

(compiler/arch)
scg39:~/sandbox/linbox/tests> g++ -v
Using built-in specs.
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-objc-gc --enable-targets=all
--disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

----------------------------------------------------------------------------
(change the size_t parameter back to a long)
scg39:~/sandbox/linbox/tests> svn diff test-dense.C
...
-static bool testIdentity (Field &F, size_t n, int iterations)
+static bool testIdentity (Field &F, long n, int iterations)
...

------------------------------------------------------------------------------
(try to compile)
scg39:~/sandbox/linbox/tests> !ma
make test-dense
g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../linbox
-I/home/bdsaunde/sandbox/include -I/home/bdsaunde/sandbox/include
-DLinBoxSrcOnly -O0 -Wall -g -DNDEBUG -U_LB_DEBUG -g -DNDEBUG
-U_LB_DEBUG -c -o test-dense.o test-dense.C
test-dense.C: In function ‘bool testIdentity(Field&, long int, int)
[with Field = main(int, char**)::Field]’:
test-dense.C:331: instantiated from here
test-dense.C:66: error: call of overloaded
‘BlasMatrix(LinBox::Modular<unsigned int>&, long int&, long int&)’ is
ambiguous
../linbox/matrix/blas-matrix.inl:268: note: candidates are:
LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, int32_t, T)
[with T = long int, _Field = LinBox::Modular<unsigned int>]
../linbox/matrix/blas-matrix.inl:235: note:
LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, uint32_t, T)
[with T = long int, _Field = LinBox::Modular<unsigned int>]
../linbox/matrix/blas-matrix.inl:244: note:
LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, int64_t, T)
[with T = long int, _Field = LinBox::Modular<unsigned int>]
../linbox/matrix/blas-matrix.inl:255: note:
LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, uint64_t, T)
[with T = long int, _Field = LinBox::Modular<unsigned int>]
test-dense.C:331: instantiated from here
test-dense.C:75: warning: comparison between signed and unsigned
integer expressions
test-dense.C:331: instantiated from here
test-dense.C:88: warning: comparison between signed and unsigned
integer expressions
test-dense.C:331: instantiated from here
test-dense.C:104: warning: comparison between signed and unsigned
integer expressions
make: *** [test-dense.o] Error 1

[Brice Boyer]

2011/10/27 B Saunders <saun...@udel.edu>

size_t can hold the size of any memory block and any pointer can be
cast to a size_t.  This is platform independent.  For indices that is
a good, whereas for field and ring element types, I am more
comfortable with types of fixed size such as uint32_t.

The only argument I can think of against size_t would be if you are
sure you won't use a matrix of over 2^31 entries and you want matrix
handles to be smaller.  I'd need to be shown an example where this
matters before I'd consider it.  In any case if index_t is settable at
configure time, then one has both options:  use size_t in general and
use uint32_t when there are going to be a gazillion small matrices.

On another thread of this conversation, below I show the compilation
problem exemplified by test-dense when I back off to the use of a long
parameter for handing the matrix size parameter to the test function
(changing this long to size_t is what fixed test-dense for me).  It is
with gcc 4.4.5/32bit, which seems to be like your environment, Brice.
So I am surprised if your compiler doesn't also complain.

my fault. I had locally modified headers...
Yes  gcc 4.4.5/32bit complains. There is a problem with the long int type. I fixed it with adding one more constructor... (but only for gcc-4.4.5 on 32bits...). This does not affect the latest release.

--
You received this message because you are subscribed to the Google Groups "linbox-devel" group.
To post to this group, send email to linbox...@googlegroups.com.
To unsubscribe from this group, send email to linbox-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/linbox-devel?hl=en.

cheers,