You can subscribe to this list here.
2010 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}
(8) 
_{Jul}
(16) 
_{Aug}
(6) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}
(5) 

2011 
_{Jan}
(4) 
_{Feb}
(3) 
_{Mar}
(5) 
_{Apr}

_{May}
(24) 
_{Jun}

_{Jul}
(5) 
_{Aug}
(17) 
_{Sep}

_{Oct}
(6) 
_{Nov}
(9) 
_{Dec}
(8) 
2012 
_{Jan}
(5) 
_{Feb}
(14) 
_{Mar}
(25) 
_{Apr}
(7) 
_{May}
(15) 
_{Jun}
(12) 
_{Jul}
(22) 
_{Aug}
(4) 
_{Sep}
(10) 
_{Oct}
(10) 
_{Nov}
(19) 
_{Dec}
(17) 
2013 
_{Jan}
(8) 
_{Feb}
(10) 
_{Mar}
(16) 
_{Apr}
(3) 
_{May}
(16) 
_{Jun}
(26) 
_{Jul}

_{Aug}
(9) 
_{Sep}

_{Oct}
(8) 
_{Nov}
(17) 
_{Dec}
(2) 
2014 
_{Jan}
(37) 
_{Feb}
(15) 
_{Mar}
(6) 
_{Apr}
(9) 
_{May}
(11) 
_{Jun}
(11) 
_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1

2

3

4
(3) 
5

6

7
(2) 
8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31







From: Karl Rupp <rupp@iu...>  20110707 15:55:47

Hi Nicolas, thanks for you email and the explanations about your work :) The overhead of the CRS format over CDS is approximately a factor of two in memory. There is also some overhead in the execution time, I would say it's roughly a factor of 1.5 to 2. We are already working on support for the CDS scheme, it will be included in one of the future releases. In the meanwhile, I can only advise you to use the compressed_matrix for the moment and switch to the CDS scheme that will be introduced with an upcoming release. Best regards, Karli On 07/07/2011 05:35 PM, Nicolas Bigaouette wrote: > Hi all, > > I just stumbled upon ViennaCL and it seems really nice. I'd like to use > it in one of my programs, but I need to clarify something first. > > I'm using a custom Compress Diagonal Storage (CDS) scheme to store my > matrix as it only have 7 diagonals. CDS stores the diagonals as 1D > arrays with another array for offset from the main diagonals. See > http://web.eecs.utk.edu/~dongarra/etemplates/node376.html (note that in > this link, the offsets 1D array is not stored as they are regular 2, > 1, 0, +1, +2, etc. from the main diagonal). > > Because my matrix comes from an operator containing a 3D Laplacian, the > diagonals are not close to the main diagonal and the offsets are not > "regular". The offsets are Nx*Ny, Nx, 0, Nx, Nx*Ny so there is some > big gaps between each diagonals. Because of the matrix's structure, > using anything else then CDS does not make sense: you cannot find a > scheme that uses less memory then just storing these diagonals. > > Up to now, I've not find useful package using CDS. I see ViennaCL has > some compressed representation, but not CDS. Also, ViennaCL implements > the Stabilized BiConjugate Gradient (BiCGStab) iterative solver which > is what I normally use. This solver only requires vectorvector and > vectormatrix addition/multiplications, which are trivial in CDS. > > My question is... Would it be possible to have CDS in ViennaCL? If not, > any idea on the overhead switching to "compressed_matrix" from CDS could > lead? > > Thank you! > > > >  > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunkd2dc2 > > > > _______________________________________________ > ViennaCLsupport mailing list > ViennaCLsupport@... > https://lists.sourceforge.net/lists/listinfo/viennaclsupport 
From: Nicolas Bigaouette <nbigaouette@gm...>  20110707 15:35:15

Hi all, I just stumbled upon ViennaCL and it seems really nice. I'd like to use it in one of my programs, but I need to clarify something first. I'm using a custom Compress Diagonal Storage (CDS) scheme to store my matrix as it only have 7 diagonals. CDS stores the diagonals as 1D arrays with another array for offset from the main diagonals. See http://web.eecs.utk.edu/~dongarra/etemplates/node376.html (note that in this link, the offsets 1D array is not stored as they are regular 2, 1, 0, +1, +2, etc. from the main diagonal). Because my matrix comes from an operator containing a 3D Laplacian, the diagonals are not close to the main diagonal and the offsets are not "regular". The offsets are Nx*Ny, Nx, 0, Nx, Nx*Ny so there is some big gaps between each diagonals. Because of the matrix's structure, using anything else then CDS does not make sense: you cannot find a scheme that uses less memory then just storing these diagonals. Up to now, I've not find useful package using CDS. I see ViennaCL has some compressed representation, but not CDS. Also, ViennaCL implements the Stabilized BiConjugate Gradient (BiCGStab) iterative solver which is what I normally use. This solver only requires vectorvector and vectormatrix addition/multiplications, which are trivial in CDS. My question is... Would it be possible to have CDS in ViennaCL? If not, any idea on the overhead switching to "compressed_matrix" from CDS could lead? Thank you! 
From: Michael Wild <themiwi@us...>  20110704 15:44:54

Thanks for the quick answer! So, is that bug in ViennaCL itself, or is it just the example that is buggy? Michael On 07/04/2011 04:35 PM, Karl Rupp wrote: > Hi Michael, > > ViennaCL 1.1.2 was initially tested with the 2.0.15 version, 2.0.16 > should also work fine. The 3.0.x versions of Eigen have not been tested > and are not supported in 1.1.2. > > The broken build of the iterativeeigen example bug was introduced by a > lastminute patch (argl, the devil is waiting just around the > corner...). Thus, feel free to remove the 'iterativeeigen' example from > the CMakeLists.txt file. Sorry for the troubles. > > Thanks and best regards, > Karli > > > On 07/04/2011 02:59 PM, Michael Wild wrote: >> Hi all >> >> With which version of Eigen is ViennaCL 1.1.2 supposed to work? I tried >> both with 2.0.16 and 3.0.1, and in both cases I get errors compiling the >> examples. In the 2.0.16 case only the iterativeeigen example gives >> errors, in the 3.0.1 case both examples, iterativeeigen and >> eigenwithviennacl fail to compile. See the attached logs. >> >> >> Michael >> 
From: Karl Rupp <rupp@iu...>  20110704 14:52:43

Hi Michael, ViennaCL 1.1.2 was initially tested with the 2.0.15 version, 2.0.16 should also work fine. The 3.0.x versions of Eigen have not been tested and are not supported in 1.1.2. The broken build of the iterativeeigen example bug was introduced by a lastminute patch (argl, the devil is waiting just around the corner...). Thus, feel free to remove the 'iterativeeigen' example from the CMakeLists.txt file. Sorry for the troubles. Thanks and best regards, Karli On 07/04/2011 02:59 PM, Michael Wild wrote: > Hi all > > With which version of Eigen is ViennaCL 1.1.2 supposed to work? I tried > both with 2.0.16 and 3.0.1, and in both cases I get errors compiling the > examples. In the 2.0.16 case only the iterativeeigen example gives > errors, in the 3.0.1 case both examples, iterativeeigen and > eigenwithviennacl fail to compile. See the attached logs. > > > Michael > > > >  > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunkd2dc2 > > > > _______________________________________________ > ViennaCLsupport mailing list > ViennaCLsupport@... > https://lists.sourceforge.net/lists/listinfo/viennaclsupport 
From: Michael Wild <themiwi@us...>  20110704 13:19:25

Hi all With which version of Eigen is ViennaCL 1.1.2 supposed to work? I tried both with 2.0.16 and 3.0.1, and in both cases I get errors compiling the examples. In the 2.0.16 case only the iterativeeigen example gives errors, in the 3.0.1 case both examples, iterativeeigen and eigenwithviennacl fail to compile. See the attached logs. Michael 