Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add LinearAlgebra::Vector derived from ReadWriteVector and VectorSpaceVector #1800

Merged
merged 5 commits into from
Nov 19, 2015

Conversation

Rombur
Copy link
Member

@Rombur Rombur commented Oct 27, 2015

This is the first vector class based on the new interface when it will be done it should replace the current Vector.


/**
* Initialize the vector with a given range of values pointed to by the
* iterators. This function is there in analogy to the @p std::vector class.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is there -> This function exists

@tjhei
Copy link
Member

tjhei commented Oct 27, 2015

I don't quite remember our conclusion on how the final layout of the classes is going to look like. Is this the replacement for the current Vector<double>? Functions that needs vectors (like integrate_difference) will then be instantiated for ReadWriteVector?

Did we decide that it is supposed to be a ReadWriteVector and a VectorSpaceVector? One argument against this is that serial and parallel code will look quite different.

@@ -154,7 +157,7 @@ namespace LinearAlgebra
virtual size_type size() const = 0;

/**
* Return an index set that describes which elements of this vector are
* Returns an index set that describes which elements of this vector are
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're inconsistent in the way we use this, but I think in most places we use "Return this and that" as opposed to "[This function] Returns this and that."

@bangerth
Copy link
Member

On 10/27/2015 03:54 PM, Timo Heister wrote:

I don't quite remember our conclusion on how the final layout of the
classes is going to look like. Is this the replacement for the current
|Vector|?

In the longer term yes.

Functions that needs vectors (like
|integrate_difference|) will then be instantiated for |ReadWriteVector|?

Correct. At least if they need element-wise access. It will no longer be
necessary to instantiate them for all sorts of arguments. In fact, we
could replace their current VectorType argument by ReadWriteVector
right away and let the compiler do the cast right away.

Did we decide that it is supposed to be a ReadWriteVector and a
VectorSpaceVector? One argument against this is that serial and parallel
code will look quite different.

Yes, I think we agreed as a group (I know you didn't) that it's ok to
let sequential and parallel programs use different vector types where
the sequential vector kind is a lot simpler to handle.

typename ReadWriteVector<Number>::real_type norm = 0.;
for (unsigned int i=0; i<this->size(); ++i)
if (std::abs(this->val[i])>norm)
norm = std::abs(this->val[i]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use std::max()?

@Rombur
Copy link
Member Author

Rombur commented Oct 28, 2015

I have done the modifications.

@Rombur
Copy link
Member Author

Rombur commented Nov 11, 2015

I have added read/write functions and added(scalar) (see #1848). This is ready to be merged.

@Rombur
Copy link
Member Author

Rombur commented Nov 18, 2015

Can we merge this.

@tjhei
Copy link
Member

tjhei commented Nov 19, 2015

I looked over the changes again and it looks good to me, but I would prefer a few more eyes on this before we merge it. It is a complicated patch after all. @kronbichler ?

/**
* Scaling and simple vector addition, i.e. <tt>*this = s*(*this)+V</tt>.
*/
virtual void sadd(const Number s, const VectorSpaceVector<Number> &V);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a more general question: Any reason to have this method? One can easily obtain the desired behavior by sadd(s, 1.0, V). Since we're changing interfaces right now anyway, why not minimize here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't this be optimized further than sadd(s,1.0,V)? Otherwise, we could get ride of it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's redundant and doesn't save a lot of CPU time, I'm in favor of getting rid of things.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(To be sure, I would imagine that an operation such as sadd(s,1.0,V) is entirely memory-bound, and so no slower than sadd(s,V) which simply omits the multiplication.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @bangerth . The redundant multiplication by 1.0 will definitely not show up on any reasonable processor. Not even if the vectors were in L1 cache and the operation was fully vectorized.

@kronbichler
Copy link
Member

A more general remark is why this vector is not using any parallelism, i.e., all the initialization and computation is done with a single thread. Is this a temporary solution (i.e., we will later import all the 'optimized' functions from dealii::Vector) or is this on purpose and will there be a separate vector class for thread parallelism?

As for an initial realization and establishing the interfaces, I have no further comments apart from the above two questions. Regarding implementation I would take over the implementations from dealii::Vector (the parallelism in vector manipulations, reductions, initialization (first-touch), memory access optimizations...)

@Rombur
Copy link
Member Author

Rombur commented Nov 19, 2015

Yes, the implementation will change in the future (same for ReadWriteVector). I just want to have a stable interface before I start optimizing the implementation

@kronbichler
Copy link
Member

Yes, the implementation will change in the future (same for ReadWriteVector). I just want to have a stable interface before I start optimizing the implementation

Agreed.

@kronbichler
Copy link
Member

So I suggest you remove the sadd() method from the two vectors and merge yourself.

Rombur added a commit that referenced this pull request Nov 19, 2015
Add LinearAlgebra::Vector derived from ReadWriteVector and VectorSpaceVector
@Rombur Rombur merged commit 9092248 into dealii:master Nov 19, 2015
* C++ standard library, this class implements an element of a vector space
* suitable for numerical computations.
*
* @authod Bruno Turcksin, 2015.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

authod?

@Rombur Rombur deleted the la_vector branch April 5, 2016 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants