Michael Stevens wrote:
> Toon,
>
>>Indiana university is willing to host the uBLAS mailinglist in the
>>future (just like the currently host the boost-ml too). Now we also need
>>a list-owner or administrators for the ml. Any volunteers ?
>
> Sure count me in. I think we need at least 3 people.

Gunther already offered to do it and I thus proposed myself as being the
backup to the sys admin at IU. I will contact him and ask if he can add
you too.

t

Toon,
> Indiana university is willing to host the uBLAS mailinglist in the
> future (just like the currently host the boost-ml too). Now we also need
> a list-owner or administrators for the ml. Any volunteers ?
Sure count me in. I think we need at least 3 people.

Thanks for organising this,
	 Michael

Hi all,

Micheal has already put in a lot of effort to clean up uBLAS and has
done all that in the uBLAS_pure branch (while the HEAD was being
prepared for 1.32). Since the 1.32 is done, I would like to merge the
current uBLAS_pure into the HEAD and continue working on that. The
uBLAS_pure branch might be continued by Micheal but is purely experimental.

Please let me know if anyone objects to the merge ?

(If you can't post to the ml, you can mail me privately or on boost-users)

toon

Hi Russell,

> I have spent a large part of this past week evaluating and experimenting
> with the ublas and bindings library with a view to employing them in a
> large coding project in the quasi real-time image processing domain. I
> have several questions for the ublas development community and would
> also like to pass on some comments based on my evaluation.
OK sounds good!

> 1. What is the status of the array_adaptor class within the ublas library?
> This class is currently undocumented, however, provides a very important
> role in providing a method to view data that is not owned by the
> library. Can developers write applications using this class to access
> the power of ublas and be confident that it is not suddenly going to
> disappear in future releases? Is the intention to eventually document
> the class and make it a first class citizen in the library? In the image
> processing field the ability to manipulate the image data (which may
> have been stored by a 3rd party image acquisition library, for example)
> using ublas is very attractive.

I think the reason that array_adaptor is not yet a first class citizen is that
it is just one of very many possible variations. There is such a variety and
array_adaptor is simply a useful example to build from.
I think array_adaptor will stay and eventually be documented as a example of a
storage array. Much more importantly there has been a fair bit of work by
Toon and me recently on defining the Storage concepts so the interface to
classes like array_adaptor is clearly defined.

> 2. Will ublas continue to work with the bindings library (and in
> particular the ATLAS bindings) in future releases?
> There has been quite a lot of discussion in the mailing list about
> protecting access to class members and slimming down the public
> interface. It appears that as of Boost v1.32 (on MSVC v7.1 platform)
> this has already started to happen. The ATLAS bindings require access to
> the ublas::vector.expression() and ublas::matrix.expression() member. In
> the latest release these functions have been made private resulting in
> compiler errors. The simplest workaround I have found is to #define
> BOOST_UBLAS_NESTED_CLASS_DR45 in my application before including the
> ublas headers as this ensures that the expression() function is public.

The future of uBLAS and Bindings are closely linked. I hope we can get some
regression tests into uBLAS so stupid mistakes like the .expression problem
don't arise in the future.
Your workaround sounds fine. Hopefully there is a more general fix to the
bindings that will work with 1.31 and 1.32
> <begin personal rant>
> Whilst I am sure that many of the implementors of the ublas library
> focus on the  "theoretical correctness" of the library and its
> interfaces, much of the power of the library stems from the fact that it
> can be used to manipulate numerical vectors and matrices efficiently. In
> this case, efficiently relates not just to the the time taken to develop
> readable and correct applications, but also to the runtime. In the
> latter case, the ability to access the optimised linear algebra provided
> by ATLAS, CBLAS, CLAPACK, etc, and do so through a simple and clean
> interface, significantly adds to the value of the ublas library. I am
> therefore a  concerned that the push to slim the public interface to the
> library in future releases may prevent application developers from
> accessing its real benefits, as demonstrated by the bindings library.
> Those people driving the design and implementation of the ublas library
> have unquestionably put an awful lot of effort into the development of
> this library (and should be very proud of the result) and I feel that it
> would be a terrible shame to introduce barriers to its adoption by
> application developers. In many ways, it seems that the forces
> associated with formal generic programming and the forces associated
> with practical application development often pull in opposite directions
> when looking at the fine detail.
> <end personal rant>
I think the aim of the current development is to make these interface well
defined so all this is much less error prone. I think most of the serious
uBLAS users have the same requirements as you.

> 3. What is the feeling in the community regarding interoperability
> between ublas::vector, ublas::matrix and boost::multi_array?
> This is a topic that has been addressed in some posts in the mailing
> list, both in relation to adaptors and bindings, but I am unclear of the
> current situation. The main difficulty referred to in the mailing list
> seems to relate to the fact that although the storage_order could be
> defined in the constructor, it was not possible to query this property
> later. It seems, according to the documentation at least, that
> multi_array now supports querying of the storage order through the
> storage_order() member. Personally, I seems completely logically to
> provide "array adaptors" for multi_array objects, but I cannot comment
> on its feasibility. Following my comments in section 2, it will not
> surprise you to learn that I also strongly encourage support for
> multi_array in the bindings library.
"array adaptors" for multi_array would be great. I think it just need someone
with a requirement to do this to implement and document it!


> 4. As a newcomer to the libraries I have to admit that I found it a very
> steep learning curve as the documentation is definitely NOT end-user
> orientated, and I often had to search the mailing list to find a more
> human readable answer to my queries. In many instances I also had to
> refer to the source code to research undocumented features referred to
> in the mailing list. This is a very time consuming exercise and will
> deter the majority of application developers. I would therefore like to
> add my vote to the many that have already been cast...please review the
> library documentation. Personally I would like to see some really simple
> examples in the documentation...how to construct, fill, manipulate,
> perform arithmetic on the important classes. Also, how to use the
> array_adaptor class, how to interact with the binding library. Perhaps
> these are already in the Yahoo ublas files section, but unfortunately I
> have not been able to access this as new members are not currently been
> enrolled. If not, I have written a short application that demonstrates
> some of these things that I would be happy to make available as a
> starting point.
That would be good. Think about using the "Effective uBLAS" wiki to either
place your documentation or links to a web site with them. That way they will
be available to all and also can be integrated into the official
documentation.

> Finally, I would like to thank all those developers who have contributed
> time to developing the ublas and bindings libraries. Both libraries are
> clearly of a particularly high standard.
:-)

Michael

Hi all,

Indiana university is willing to host the uBLAS mailinglist in the
future (just like the currently host the boost-ml too). Now we also need
a list-owner or administrators for the ml. Any volunteers ?


toon

Dear All,

I have spent a large part of this past week evaluating and experimenting
with the ublas and bindings library with a view to employing them in a
large coding project in the quasi real-time image processing domain. I
have several questions for the ublas development community and would
also like to pass on some comments based on my evaluation.

1. What is the status of the array_adaptor class within the ublas library?
This class is currently undocumented, however, provides a very important
role in providing a method to view data that is not owned by the
library. Can developers write applications using this class to access
the power of ublas and be confident that it is not suddenly going to
disappear in future releases? Is the intention to eventually document
the class and make it a first class citizen in the library? In the image
processing field the ability to manipulate the image data (which may
have been stored by a 3rd party image acquisition library, for example)
using ublas is very attractive. However, if I had to copy these large
image arrays into a ublas matrix that would be very inefficient and may
prevent me using the ublas library.

2. Will ublas continue to work with the bindings library (and in
particular the ATLAS bindings) in future releases?
There has been quite a lot of discussion in the mailing list about
protecting access to class members and slimming down the public
interface. It appears that as of Boost v1.32 (on MSVC v7.1 platform)
this has already started to happen. The ATLAS bindings require access to
the ublas::vector.expression() and ublas::matrix.expression() member. In
the latest release these functions have been made private resulting in
compiler errors. The simplest workaround I have found is to #define
BOOST_UBLAS_NESTED_CLASS_DR45 in my application before including the
ublas headers as this ensures that the expression() function is public.

For example,

// -----------------------------------
// Nasty workaround for making the expression() member public
#define BOOST_UBLAS_NESTED_CLASS_DR45
// -----------------------------------

// Boost numeric uBlas library
#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/vector_proxy.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/matrix_proxy.hpp>
#include <boost/numeric/ublas/io.hpp>

// Boost numeric bindings library: Storage traits for std::vector and
std::valarray
#include <boost/numeric/bindings/traits/std_vector.hpp>
#include <boost/numeric/bindings/traits/std_valarray.hpp>

// Boost numeric bindings library: Storage traits for ublas::vector and
ublas::matrix families
#include <boost/numeric/bindings/traits/ublas_vector.hpp>
#include <boost/numeric/bindings/traits/ublas_matrix.hpp>

// Boost numeric bindings library: ATLAS linear algebra library bindings
#include <boost/numeric/bindings/atlas/cblas.hpp>

namespace ublas = boost::numeric::ublas;
namespace atlas = boost::numeric::bindings::atlas;

int main( int argc, char **argv )
{
   // ublas:matrix
   ublas::matrix<double> um (5, 5);
    // Initialise
   double c = 0;
    for (unsigned uiRow = 0; uiRow < um.size1(); uiRow++)
    for (unsigned uiCol = 0; uiCol < um.size2(); uiCol++)
        um(uiRow,uiCol) = c++;
   // Dump
   std::cout << std::endl << "um = " << um << std::endl;

   // Matrix row vector
    ublas::matrix_row<ublas::matrix<double> > umr (um, 1);
   // Dump
   std::cout << std::endl << "umr = " << umr << std::endl;
   // Call ATLAS
    std::cout << "L2-norm = " << atlas::nrm2 (umr) << std::endl;

   return 0;
}

<begin personal rant>
Whilst I am sure that many of the implementors of the ublas library
focus on the  "theoretical correctness" of the library and its
interfaces, much of the power of the library stems from the fact that it
can be used to manipulate numerical vectors and matrices efficiently. In
this case, efficiently relates not just to the the time taken to develop
readable and correct applications, but also to the runtime. In the
latter case, the ability to access the optimised linear algebra provided
by ATLAS, CBLAS, CLAPACK, etc, and do so through a simple and clean
interface, significantly adds to the value of the ublas library. I am
therefore a  concerned that the push to slim the public interface to the
library in future releases may prevent application developers from
accessing its real benefits, as demonstrated by the bindings library.
Those people driving the design and implementation of the ublas library
have unquestionably put an awful lot of effort into the development of
this library (and should be very proud of the result) and I feel that it
would be a terrible shame to introduce barriers to its adoption by
application developers. In many ways, it seems that the forces
associated with formal generic programming and the forces associated
with practical application development often pull in opposite directions
when looking at the fine detail.
<end personal rant>

3. What is the feeling in the community regarding interoperability
between ublas::vector, ublas::matrix and boost::multi_array?
This is a topic that has been addressed in some posts in the mailing
list, both in relation to adaptors and bindings, but I am unclear of the
current situation. The main difficulty referred to in the mailing list
seems to relate to the fact that although the storage_order could be
defined in the constructor, it was not possible to query this property
later. It seems, according to the documentation at least, that
multi_array now supports querying of the storage order through the
storage_order() member. Personally, I seems completely logically to
provide "array adaptors" for multi_array objects, but I cannot comment
on its feasibility. Following my comments in section 2, it will not
surprise you to learn that I also strongly encourage support for
multi_array in the bindings library.

4. As a newcomer to the libraries I have to admit that I found it a very
steep learning curve as the documentation is definitely NOT end-user
orientated, and I often had to search the mailing list to find a more
human readable answer to my queries. In many instances I also had to
refer to the source code to research undocumented features referred to
in the mailing list. This is a very time consuming exercise and will
deter the majority of application developers. I would therefore like to
add my vote to the many that have already been cast...please review the
library documentation. Personally I would like to see some really simple
examples in the documentation...how to construct, fill, manipulate,
perform arithmetic on the important classes. Also, how to use the
array_adaptor class, how to interact with the binding library. Perhaps
these are already in the Yahoo ublas files section, but unfortunately I
have not been able to access this as new members are not currently been
enrolled. If not, I have written a short application that demonstrates
some of these things that I would be happy to make available as a
starting point.

Finally, I would like to thank all those developers who have contributed
time to developing the ublas and bindings libraries. Both libraries are
clearly of a particularly high standard.

Kind regards,

Russell

Beman Dawes wrote:
> At 06:42 AM 11/23/2004, Toon Knapen wrote:
>
>  >... If we do not have a solution by end of
>  >November I will create a new project on yahoogroups (and we all have to
>  >switch).
>
> If you have to start a new list, please don't use yahoogroups.
> Sourceforge or lists.boost.org are much better.

I think we have a consensus in the ublas-dev to change from yahoogroups
to the lists.boost.org server. Anyone can tell us how to manage this
from a practical point of view ? Who do we need to contact to host the
ublas-dev list at lists.boost.org etc ... ?

toon

Hi,
I started using some of my old code with the ublas_pure branch. I
came across some (small) errors:
=> In several places in the code, it is assumed that  "value_type(0)"
makes always sense. This is a regression, it was correct in the old
ublas version that I had. I had to switch this back
to "value_type()". Similar:
const typename compressed_matrix<T, L, IB, IA, TA>::value_type
compressed_matrix<T, L, IB, IA, TA>::zero_ (0);
has to be
const typename compressed_matrix<T, L, IB, IA, TA>::value_type
compressed_matrix<T, L, IB, IA, TA>::zero_=
 		 compressed_matrix<T, L, IB, IA, TA>::value_type ();

=> function "ref" in matrix_sparse.hpp line 141 was buggy. It should
be
         BOOST_UBLAS_INLINE
         value_type& ref () const {
             pointer p = (*this) ().find_element (i_, j_);
             if (!p)
                 p = &(*this) ().insert_element (i_, j_, value_type
());
             return *p;
         }
Before, insert_element didn't set the pointer p and find_element was
called with (i,i). By the way, it is good this ref-function is there.
Now I don't need to patch ublas anymore.

=> the type deduction generates lots of warnings when compiled on
VC7.1 with /Wp64 on. (Which means 64bit compatibility check)
A critical line for testing is:
typedef promote_traits<__w64 int, __w64 int>::promote_type testtype;
which gets called for every std::difference_type. This creates
a "c4244" warning: conversion from "__w64 int" to "const int". A
platform-specific (?) fix would be to write in returntypedecduction.h:
     template <typename X, typename Y>
     int_value_type
     test(__w64 int const&);
instead of
     template <typename X, typename Y>
     int_value_type
     test(int const&);

Regards, Max

Am Mittwoch, 24. November 2004 17:04 schrieb Gunter Winkler:
>
> On Wednesday 24 November 2004 14:19, Toon Knapen wrote:
> > From the feedback I got about this issue (private and via the ml) I
> > suggest to change to list.boost.org anyway to become consistent with
the
> > other boost ml's and to improve the user experience. Any objections ?

This would be very nice.

> The advantage of a seperate list is the low number of messages. The
boost list
> has sometimes 100 messages per day. Its very easy to miss the important
> ones ...

I believe that the suggestion was to use the boost mailing list server
instead of yahoo, but still have a separate list.


Georg

Hi Toon, Hi Russell,

Correct code is for the VC 7.1 workaround is

// Fill matrix A using iterator method
ublas::matrix<double>::iterator1 it1;
ublas::matrix<double>::iterator2 it2;

// Workaround for shortcomings of MSVC 7.1
for ( it1 = A.begin1(); it1 != A.end1(); ++it1 )
#ifndef BOOST_UBLAS_NO_NESTED_CLASS_RELATION
     for ( it2 = it1.begin(); it2 != it1.end(); ++it2 )
         *it2 = c++;
#else
     for ( it2 = begin(it1, ublas::iterator1_tag()); it2 != end(it1,
ublas::iterator1_tag()); ++it2 )
         *it2 = c++;
#endif

There are a couple of things worth noting:
  1. This problem in VC7.1 is very nasty. Unless you have a very good reason to
use iterators in you code (sparse matrices) then I would avoid it. uBLAS must
use the BOOST_UBLAS_NO_NESTED_CLASS_RELATION internally but I would hate to
see a large body of user code using these nasty constructs.
  2. It seems that the current test versions of VC8 have the bug fixed.
  3. For this work iterators are not faster then indexing and indexing is more
concise.

All the best,
	 Michael

Toon,

>  From the feedback I got about this issue (private and via the ml) I
> suggest to change to list.boost.org anyway to become consistent with the
> other boost ml's and to improve the user experience. Any objections ?
> Anybody can tell me who I need to contact to host the ml at
> lists.boost.org ?

Sounds good. No word from Joerg so I think we must go ahead and do this. A
Boost ML would be much better then yahoo groups anyway! We still need to talk
to Joerg regarding the Boost licencse, but since we have missed 1.32 that is
not too urgent.

Michael

On Wednesday 24 November 2004 14:19, Toon Knapen wrote:
> From the feedback I got about this issue (private and via the ml) I
> suggest to change to list.boost.org anyway to become consistent with the
> other boost ml's and to improve the user experience. Any objections ?

The advantage of a seperate list is the low number of messages. The boost list
has sometimes 100 messages per day. Its very easy to miss the important
ones ...

mfg
Gunter

[Forwarded message from not-accepted member.]

Dear All,

I am a evaluating the uBlas library and unfortunately have stubbled at the
first hurdle. I would be grateful if you are able to advise me where I am
going wrong.

Having built and installed the boost libraries (v1.32) on Win2k using
MSVC7.1 I am trying to compile a short test application that fills a dense
matrix and performs some simple arrithmetic.

The application fails to compile if I include the code to fill the matrix
using iterators, however, will compile and run fine if I omit that section.

I would be very grateful for any assistance with this as I can't really
proceed unless this issue is resolved.

--- Note ---
Note that the compiler error relating to line 42 corresponds to:
for ( it1 = begin( A, ublas::iterator1_tag() ); it1 != end( A,
ublas::iterator1_tag() ); ++it1 )
--- End Note ---

Kind regards,

Russell


I have included below the source code and the compiler error messages...



#include <iostream>

#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/vector_proxy.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/matrix_proxy.hpp>
#include <boost/numeric/ublas/io.hpp>

namespace ublas = boost::numeric::ublas;


// Declarations
int main(int argc, char **argv);

// Function definitions
int main(int argc, char **argv)
{
    // Create general dense matrix
    std::size_t n = 5;
    ublas::matrix<double> A (5, 5);

    std::cout << A << std::endl << std::endl;

    // Counter
    double c = 0.0;

    // Fill matrix A using indexing method
    for (unsigned i = 0; i < A.size1(); i++)
      for (unsigned j = 0; j < A.size2(); j++)
        A(i,j) = c++;

    std::cout << "A = " << A << std::endl << std::endl;

    // Fill matrix A using iterator method
    ublas::matrix<double>::iterator1 it1;
    ublas::matrix<double>::iterator1 it2;

    // Workaround for shortcomings of MSVC 7.1
#ifndef BOOST_UBLAS_NO_NESTED_CLASS_RELATION
    for ( it1 = A.begin1(); it1 != A.end1(); ++it1 )
#else
    for ( it1 = begin( A, ublas::iterator1_tag() ); it1 != end( A,
ublas::iterator1_tag() ); ++it1 )
#endif
      for ( it2 = it1.begin(); it2 != it1.end(); ++it2 )
        *it2 = c++;

    std::cout << "A = " << A << std::endl << std::endl;

    // Create scalar matrix
    ublas::scalar_matrix<unsigned int> B(n, n, 1);

    std::cout << "B = " << B << std::endl << std::endl;

    ublas::matrix<double> C = prod( A, B );

    std::cout << "C = " << C << std::endl << std::endl;

    return 0;
}



Compiling...
PV_uBlasConApp.cpp
c:\pv_dev\cpp\pv\src\PV_uBlasConApp\PV_uBlasConApp.cpp(42) : error C2893:
Failed to specialize function template 'I::dual_iterator_type
boost::numeric::ublas::begin(const I
&,boost::numeric::ublas::iterator2_tag)'
          With the following template arguments:
          'boost::numeric::ublas::matrix<T>'
          with
          [
              T=double
          ]
c:\pv_dev\cpp\pv\src\PV_uBlasConApp\PV_uBlasConApp.cpp(42) : error C2893:
Failed to specialize function template 'I::dual_iterator_type
boost::numeric::ublas::begin(const I
&,boost::numeric::ublas::iterator1_tag)'
          With the following template arguments:
          'boost::numeric::ublas::matrix<T>'
          with
          [
              T=double
          ]
c:\pv_dev\cpp\pv\src\PV_uBlasConApp\PV_uBlasConApp.cpp(42) : error C2893:
Failed to specialize function template 'I::dual_iterator_type
boost::numeric::ublas::end(const I &,boost::numeric::ublas::iterator2_tag)'
          With the following template arguments:
          'boost::numeric::ublas::matrix<T>'
          with
          [
              T=double
          ]
c:\pv_dev\cpp\pv\src\PV_uBlasConApp\PV_uBlasConApp.cpp(42) : error C2893:
Failed to specialize function template 'I::dual_iterator_type
boost::numeric::ublas::end(const I &,boost::numeric::ublas::iterator1_tag)'
          With the following template arguments:
          'boost::numeric::ublas::matrix<T>'
          with
          [
              T=double
          ]
c:\pv_dev\cpp\pv\src\PV_uBlasConApp\PV_uBlasConApp.cpp(44) : error C2039:
'begin' : is not a member of 'boost::numeric::ublas::matrix<T>::iterator1'
          with
          [
              T=double
          ]
          c:\Boost\include\boost-1_32\boost\numeric\ublas\matrix.hpp(494) :
see declaration of 'boost::numeric::ublas::matrix<T>::iterator1'
          with
          [
              T=double
          ]
c:\pv_dev\cpp\pv\src\PV_uBlasConApp\PV_uBlasConApp.cpp(44) : error C2039:
'end' : is not a member of 'boost::numeric::ublas::matrix<T>::iterator1'
          with
          [
              T=double
          ]
          c:\Boost\include\boost-1_32\boost\numeric\ublas\matrix.hpp(494) :
see declaration of 'boost::numeric::ublas::matrix<T>::iterator1'
          with
          [
              T=double
          ]

Build log was saved at
"file://c:\pv_dev\cpp\pv\src\PV_uBlasConApp\tmp\win32\RTd_d\BuildLog.htm"
PV_uBlasConApp - 6 error(s), 0 warning(s)


---------------------- Done ----------------------

      Build: 0 succeeded, 1 failed, 0 skipped

Robbie Vogt wrote:
> Hi Toon,
>
> Toon Knapen wrote:
>
>
>>If we do not have a solution by end of
>>November I will create a new project on yahoogroups (and we all have to
switch).
>>
>>
>
> If it is necessary to start a new list, would it be possible to be
> hosted with the other Boost ml's?
>

  From the feedback I got about this issue (private and via the ml) I
suggest to change to list.boost.org anyway to become consistent with the
other boost ml's and to improve the user experience. Any objections ?
Anybody can tell me who I need to contact to host the ml at
lists.boost.org ?

toon

Hi Toon,

Toon Knapen wrote:

>If we do not have a solution by end of
>November I will create a new project on yahoogroups (and we all have to
switch).
>
>
If it is necessary to start a new list, would it be possible to be
hosted with the other Boost ml's?

>
>Additionally we need to contact Joerg and Mathias (again!) about
>applying the Boost Software License. I currently have the impression
>that they are not willing to change ublas to the BSL. In that case IMO,
>we will have to rewrite uBLAS to not get thrown out of boost.
>
This would definitely be a disappointing outcome, but, on the up side,
it will give us the opportunity to revisit some of the very early design
and implementation issues with much newer and more conforming compilers
in mind.  This may also be an opportunity to incorporate some of the
more interesting ideas raised by Dave Abrahams, et. al. for MTL3 a while
back.

Cheers,
Robbie.

Dear All,

Am back on the uBLAS case too after a couple of weeks break for work!

> - privat +49 (2051) 989855
> - office +49 (201) 8127176

I just gave Joerg a call. Hopefully he will ring me back tonight!

Michael

___________________________________
Michael Stevens Systems Engineering


Navigation Systems, Estimation  and
                  Bayesian Filtering
     http://bayesclasses.sf.net
___________________________________

Hello Mr.Knappen,

here are the two telefon numbers of Joerg.
- privat +49 (2051) 989855
- office +49 (201) 8127176

Regards
Joachim Pyras



> -----Ursprüngliche Nachricht-----
> Von: Toon Knapen [mailto:toon.knapen@...]
> Gesendet: Dienstag, 23. November 2004 12:42
> An: ublas; Michael Stevens; boost-users@...; boost
> Betreff: [ublas-dev] IMPORTANT: yahoogroups admin rights problem
>
>
>
> Hello ALL,
>
> As many of you might know, currently we are unable to add new
> members to
> the ublas-ml. The problem is that only Joerg has the rights to add
> members to the list but Joerg does not respond anymore.
>
> Could some of you try to contact Joerg or give me his
> telephone number
> that I talk to him about this. If we do not have a solution by end of
> November I will create a new project on yahoogroups (and we
> all have to
> switch).
>
>
> Additionally we need to contact Joerg and Mathias (again!) about
> applying the Boost Software License. I currently have the impression
> that they are not willing to change ublas to the BSL. In that
> case IMO,
> we will have to rewrite uBLAS to not get thrown out of boost.
> Again his
> phone-number would be handy if you have it available.
>
>
> Please contact the ml or me asap about the above issues or we
> will need
> to take drastic actions.
>
> toon
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> $9.95 domain names from Yahoo!. Register anything.
> http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/EbFolB/TM
> --------------------------------------------------------------
> ------~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

Salut,

On Tue, 23 Nov 2004, Toon Knapen wrote:

> Could some of you try to contact Joerg or give me his telephone number
> that I talk to him about this. If we do not have a solution by end of
> November I will create a new project on yahoogroups (and we all have to
> switch).


O.k., I'll try to contact Joerg at his private email address I have
from the very first days of ublas.

Best wishes,
Peter
_______________________________________

Dr. Peter Schmitteckert
TKM / CFN  University of Karlsruhe
++49 721 608 3363

Forwarded msg from new (unaccepted by Joerg) member
sorry for the high latency of the forward.

-------- Original Message --------
Subject: prod(compressed_matrix,vector)
Date: Tue, 16 Nov 2004 21:04:06 -0600
From: Daniel L Elliott <dan_elliott@...>
To: Toon Knapen <toon.knapen@...>

Toon,

I figured you might know this.  If you wish, I would appreciate it if you
would post the following to ublas-dev for me.

Why is the following not valid:
la::compressed_matrix<int> compressed1(3,3,9);
la::vector<int> sampleVector1(3);
sampleVector1 = prod(compressed1,sampleVector1);

while the following is:
la::matrix<int> notCompressed1(3,3);
la::vector<int> sampleVector1(3);
sampleVector1 = prod(notCompressed1,sampleVector1);

Both return a vector_expression.  If the first example cannot be
assigned to a
dense vector, then what should be it assigned to (according to the current
code)?  In general, shouldn't the vector determine whether or not the
result
will be dense?

I would be happy to provide additional information if necessary.

Thank you for your time.

Sincerely,

dan elliott

**************************
Dan Elliott
402-210-6429 (me)
       or
402-210-6735 (amy)
dan_elliott@...
**************************

Hello ALL,

As many of you might know, currently we are unable to add new members to
the ublas-ml. The problem is that only Joerg has the rights to add
members to the list but Joerg does not respond anymore.

Could some of you try to contact Joerg or give me his telephone number
that I talk to him about this. If we do not have a solution by end of
November I will create a new project on yahoogroups (and we all have to
switch).


Additionally we need to contact Joerg and Mathias (again!) about
applying the Boost Software License. I currently have the impression
that they are not willing to change ublas to the BSL. In that case IMO,
we will have to rewrite uBLAS to not get thrown out of boost. Again his
phone-number would be handy if you have it available.


Please contact the ml or me asap about the above issues or we will need
to take drastic actions.

toon

as reply to Dan Elliots mail:

On Wednesday 17 November 2004 02:13, you wrote:
> Thank you for the reply.  I am interested in the permutation matrix
> implemented in lu.hpp.  I am not familiar with implementing a
> permuation matrix as a vector.  To make sure we are on the same page,
> I am using the permutation matrix to permute (shift/translate) image
> pixels.  The images are converted from their original matrix form to a
> vector with dimensionality equal to the number of pixels.  Each row of
> the permutation matrix specifies where the pixel moves to.  Is this in
> line with what the permutation matrix in lu.hpp does?

Yes - nearly. The permutation_matrix does not store the new index, but an
index of a element to be exchanged with. For example:

Let phi = (1, 3, 2) and x = (1.0, 2.0, 3.0). Usually you assign y(i) =
x(phi(i)) which gives y = (1.0, 3.0, 2.0). Alternatively you can use a swap
vector psi = (1, 3, 3) and apply it to x:
for i from 0 to 2: swap x(i) and x(psi(i)) if i <> psi(i). The result is the
same.

> As for the errors I am reporting, I elements of the compressed_matrix
> are of the same type as the vector (i.e. int).  I am still at a loss
> as to why my code doesn't work.

Could you please post a short sample program to the list? This helps a lot to
find errors.

some examples:
template <class VEC>
void permutation_to_swap(VEC & x)
{
   typedef typename VEC::size_type  size_type;

   for (size_type i=0; i<x.size(); ++i) {
	 size_type j = x(i);
	 if (j<i) {
	   while (j<i) {
		 j = x(j);
	   }
	   x(i) = j;
	 }
   }
}

template <class VEC>
VEC inverse_permutation(const VEC & p)
{
   typedef typename VEC::size_type  size_type;
   VEC     res(p.size());

   for (size_type i=0; i<p.size(); ++i) {
	 res(p(i)) = i;
   }

   return res;
}

[...main()...]

   // create a permutation matrix
   permutation_matrix<size_t> P( size );
   // default contructions gives the identity-permutation

   // compute a permutation of its elements (compare elements of other
  vectors) std::stable_sort(P.begin(), P.end(), vector_pair_less<V1, V2>
  (v1,v2) );

   // convert the real permutation to a set of swap operations
   permutation_to_swap(P);

   // apply swaps
   swap_rows(P, v1);
   swap_rows(P, v2);
   swap_rows(P, v3);



HTH
Gunter

On Monday 15 November 2004 18:23, Mark Hoemmen wrote:
> Kresimir Fresl wrote:
> >I am using the CVS Head version of uBLAS from approximately one month
> >ago with gcc.  I get a ton of errors when trying to multiply a dense
> >vector by a compact matrix.  This is what my code looks like:
> >
> >la::compressed_matrix<int>* permutationMatrix;
> >template<class T> void Permutation::apply(la::vector<T>& dataPoint){
> >   dataPoint = prod(*permutationMatrix,dataPoint);
> >}
> >

to the prod problem:

you should use a compressed_matrix<double> with a few elements = 1.0 because
multiplication of int*double may not be working. I am not sure if
promote_traits know of this combination of types.

mfg
Gunter

On Monday 15 November 2004 18:23, Mark Hoemmen wrote:
> Kresimir Fresl wrote:
> >I am using the CVS Head version of uBLAS from approximately one month
> >ago with gcc.  I get a ton of errors when trying to multiply a dense
> >vector by a compact matrix.  This is what my code looks like:
> >
> >la::compressed_matrix<int>* permutationMatrix;
> >template<class T> void Permutation::apply(la::vector<T>& dataPoint){
> >   dataPoint = prod(*permutationMatrix,dataPoint);
> >}
> >
> >What, conceptually, am I doing wrong?  If asked, I will happily provide
> >more information.  For now, I am trying to keep this email to a
> >reasonable size.
>
> This is just an aside:  it's not efficient to implement a permutation
> as a general sparse matrix.  It's better to use an array of integers.

There is a permutation_matrix in lu.hpp and corresponding functions
swap_rows(). And I can provide a function that converst a permutation matrix
to a "swap matrix" (which is currently named permutation_matrix ...). Please
have a look at lu.hpp. Feel free to ask me if you need assistance with these
functions.

mfg
Gunter

Kresimir Fresl wrote:

>I am using the CVS Head version of uBLAS from approximately one month
>ago with gcc.  I get a ton of errors when trying to multiply a dense
>vector by a compact matrix.  This is what my code looks like:
>
>la::compressed_matrix<int>* permutationMatrix;
>template<class T> void Permutation::apply(la::vector<T>& dataPoint){
>   dataPoint = prod(*permutationMatrix,dataPoint);
>}
>
>What, conceptually, am I doing wrong?  If asked, I will happily provide
>more information.  For now, I am trying to keep this email to a
>reasonable size.
>
This is just an aside:  it's not efficient to implement a permutation
as a general sparse matrix.  It's better to use an array of integers.

mfh

-------- Original Message --------
Subject: compact matrix/dense vector product
Date: Sat, 13 Nov 2004 10:47:48 -0600
From: Daniel L Elliott <dan_elliott@...>
To: Boost-users@...
CC: Kresimir Fresl <fresl@...>

Hello,

I am using the CVS Head version of uBLAS from approximately one month
ago with gcc.  I get a ton of errors when trying to multiply a dense
vector by a compact matrix.  This is what my code looks like:

la::compressed_matrix<int>* permutationMatrix;
template<class T> void Permutation::apply(la::vector<T>& dataPoint){
    dataPoint = prod(*permutationMatrix,dataPoint);
}

What, conceptually, am I doing wrong?  If asked, I will happily provide
more information.  For now, I am trying to keep this email to a
reasonable size.

Thank you,

-- dan
**************************
Dan Elliott
402-210-6429 (me)
       or
402-210-6735 (amy)
dan_elliott@...
**************************

On Friday 12 November 2004 09:50, Gunter Winkler wrote:
> On Friday 12 November 2004 08:39, Karl Meerbergen wrote:
> > You mentioned an earlier discussion. What was the conclusion?
>
> Please read the thread around
> http://groups.yahoo.com/group/ublas-dev/message/588
>
> I am not sure what the final conlusion was.
>
> mfg
> Gunter


Gunter,


I see a lot of questions in this thread. I see that Joerg was not entirely
happy with this choice.

The discussion looks similar to resize(). We found a very elegant solution by
using free functions, allowing the user all freedom in resizing. Shouldn't we
do the same for assignment?

The fact that m=e and m.assign(e) behave in a different way is confusing, I
think. We currently have noalias(m)=e; Perhaps we could have other
assignments, where resize is done automatically: for example
resized_assign(m)=e, and resized_assign(m).assign(e) without aliasing.

On the other hand, I understand the argument that the non-expert user wants a
simple assignment that assigns an expression to a container, i.e. the
matlab-like behaviour.

The confusing part comes when we want to assign into a proxy. A resize is not
possible in this case. Nor for a fixed size container.

So, I am in favour of not resizing automatically. As Joerg pointed out: in
many cases a size mismatch is due to a bug in the code, so the assertion on
the size is very useful.

We do not have to find a solution to this problem now, but it will show up
again when the documentation is written.


Karl

On Friday 12 November 2004 08:39, Karl Meerbergen wrote:
> You mentioned an earlier discussion. What was the conclusion?

Please read the thread around
http://groups.yahoo.com/group/ublas-dev/message/588

I am not sure what the final conlusion was.

mfg
Gunter

Gunter Winkler wrote:

>On Thursday 11 November 2004 10:09, Karl Meerbergen wrote:
>
>
>>Hello,
>>
>>The difference between m=e and m.assign(e) lies in the creation of a
>>temporary, but there is another important difference: m=e changes the sizes
>>of m when there is a mismatch in size between m and e. m.assign(e) asserts
>>(size1==size2). Is this wanted behaviour or unwanted side effect?
>>
>>
>
>Let me think. There was some discussion long time ago ...
>
>There are two different ideas behind = and assign.
>
>m = e
>Here we discard the content of m and replace it by the content of e. The
>automatic size change is for the convenience of the user. There should be no
>automatic size change from the point of linear algebra, because assigning
>non-matching vectors is a design error. Otherwise it should be possible to
>write code like
>  vector<double> x = other_vector;
>or
>  vector<double> x; x = other_vector;
>without an x.resize(other_vector.size());
>
>Here we have to decide whether we enforce matching sizes or not. (IMO a linear
>algebra library should check the sizes of every assign, because it is a good
>way to find algorithmic problems.)
>
>m.assign(e)
>Here we request an fast assign which is only possible if m and e have the same
>size.
>
>mfg
>Gunter
>
>
>
>

I think, a resize should not be done automatically. In my perception, it
is something I did not expect anyway.

You mentioned an earlier discussion. What was the conclusion?

Thanks

Karl

On Thursday 11 November 2004 10:09, Karl Meerbergen wrote:
> Hello,
>
> The difference between m=e and m.assign(e) lies in the creation of a
> temporary, but there is another important difference: m=e changes the sizes
> of m when there is a mismatch in size between m and e. m.assign(e) asserts
> (size1==size2). Is this wanted behaviour or unwanted side effect?

Let me think. There was some discussion long time ago ...

There are two different ideas behind = and assign.

m = e
Here we discard the content of m and replace it by the content of e. The
automatic size change is for the convenience of the user. There should be no
automatic size change from the point of linear algebra, because assigning
non-matching vectors is a design error. Otherwise it should be possible to
write code like
   vector<double> x = other_vector;
or
   vector<double> x; x = other_vector;
without an x.resize(other_vector.size());

Here we have to decide whether we enforce matching sizes or not. (IMO a linear
algebra library should check the sizes of every assign, because it is a good
way to find algorithmic problems.)

m.assign(e)
Here we request an fast assign which is only possible if m and e have the same
size.

mfg
Gunter

Hello,

The difference between m=e and m.assign(e) lies in the creation of a
temporary, but there is another important difference: m=e changes the sizes
of m when there is a mismatch in size between m and e. m.assign(e) asserts
(size1==size2). Is this wanted behaviour or unwanted side effect?

Have a nice day,

Karl