[Dune] [Dune-Commit] dune-common r6877 - trunk/dune/common

[Dedner, Andreas]

Just yesterday I had a look at this and the MultiIndex can be initialized with zero
apparently without breaking anything. So I assume that we can change that behavior.
I wanted to discuss this with Martin and then commit it but Christian had then already
make the change with the int constructor - but I was also wondering about that int constructor...
So w.r.t. to MultiIndex the change is probably not required....

I do not know if a branch would have been a good idea - the suggestion from Matthias which was
implemented was available for a week and few people seemed to have an opinion on this.
It seems more like the typical case of
 "to get a responds just implement it...."

Another possibility which we used in some of our local FE implementations is a 
template <class T>
class Zero; 
The main reason was to simplify things like
if (std::abs(a)<eps) to
if ( a == Zero<A>()) 
which can be specialized for different classes A (e.g. double, higher precision etc.)
But of course it can also be used to initialize some variable to zero....
   see dune-localfunctions/dune/localfunctions/utility/field.hh
I never really promoted this approach since I was not too happy with it,
the epsilon is still rather arbitrary and there seems to be no easy way of getting 
a generic comparison working but for initialization this works really well....
btw: I was not aware that there was a standard about what a default constructor was
supposed to do....
Andreas

________________________________________
From: dune-bounces+a.s.dedner=warwick.ac.uk at dune-project.org [dune-bounces+a.s.dedner=warwick.ac.uk at dune-project.org] on behalf of Markus Blatt [markus at dr-blatt.de]
Sent: 31 July 2012 13:00
To: dune at dune-project.org
Subject: Re: [Dune] [Dune-Commit] dune-common r6877 - trunk/dune/common

Hi,

frankly, I do not like this patch and I do not see how this improves
the behaviour.

IMHO there is guarantee that a constructor taking an int as an argument
is available.

Concerning multi-index (which was the problem, i guess) I missed
Martin's answer why it is initialized to 1. Isn't the default
constructor supposed to initialize to zero according to the standard?

Meanwhile a static method of the traits class returning a zero value
would probably be the most safe change.

Just my 2 cents.

BTW: This addition would have been perfect example for a branch,
wouldn't it?

Cheers,

Markus

On Tue, Jul 31, 2012 at 12:13:13PM +0200, christi at dune-project.org wrote:
> Author: christi
> Date: 2012-07-31 12:13:12 +0200 (Tue, 31 Jul 2012)
> New Revision: 6877
>
> Modified:
>    trunk/dune/common/densevector.hh
> Log:
> [densevector]
> initialize result with 0
> (patch by Matthias Wohlmuth)
>
> Modified: trunk/dune/common/densevector.hh
> ===================================================================
> --- trunk/dune/common/densevector.hh  2012-07-30 07:28:02 UTC (rev 6876)
> +++ trunk/dune/common/densevector.hh  2012-07-31 10:13:12 UTC (rev 6877)
> @@ -464,7 +464,7 @@
>      template<class Other>
>      typename PromotionTraits<field_type,typename DenseVector<Other>::field_type>::PromotedType operator* (const DenseVector<Other>& y) const {
>        typedef typename PromotionTraits<field_type, typename DenseVector<Other>::field_type>::PromotedType PromotedType;
> -      PromotedType result = PromotedType();
> +      PromotedType result(0);
>        assert(y.size() == size());
>        for (size_type i=0; i<size(); i++) {
>          result += PromotedType((*this)[i]*y[i]);
> @@ -482,7 +482,7 @@
>      template<class Other>
>      typename PromotionTraits<field_type,typename DenseVector<Other>::field_type>::PromotedType dot(const DenseVector<Other>& y) const {
>        typedef typename PromotionTraits<field_type, typename DenseVector<Other>::field_type>::PromotedType PromotedType;
> -      PromotedType result = PromotedType();
> +      PromotedType result(0);
>        assert(y.size() == size());
>        for (size_type i=0; i<size(); i++) {
>          result += Dune::dot((*this)[i],y[i]);
>
>
> _______________________________________________
> Dune-Commit mailing list
> Dune-Commit at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-commit
>

--
Do you need more support with DUNE or HPC in general?

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany
Tel.: +49 (0) 160 97590858  Fax: +49 (0)322 1108991658

_______________________________________________
Dune mailing list
Dune at dune-project.org
http://lists.dune-project.org/mailman/listinfo/dune