[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
Just because operations involving standard types can be greatly optimized.
For example, when we want to add integer to arbitrary precision number:
mpreal a;
// compiler calls optimized +=(int) operator,
// it is very easy to add simple int to arbitrary precision number.
// no additional memory allocations, constructor call, etc.
a += 1;
// unnecessary call of constructor/memory allocations,
// but the worst - now we have to use heavy artillery to add numbers,
// since they both of arbitrary precision now - optimization is disabled
a += mpreal(1);
Actually huge part of arbitrary precision libraries are devoted to such
optimized cases (just look to GMP/MPFR low level API).
Otherwise we get significant drop in speed.
This is also true for conditional operations (<, >, etc.).
Please let the custom scalar types handle such special cases on its own, so
that it can produce fast code!
On Thu, Aug 11, 2016 at 1:22 AM, Peter <list@xxxxxxxxxxxxxxxxx> wrote:
> Dear All,
>
> SelfAdjointEigenSolver.h assumes that integer will implicitly converted
> to Scalar,
> which may not the case for user defined type.
>
> E.g.
> if(td==0)
> if(e2==0)
> while (start>0 && m_subdiag[start-1]!=0)
> ...
>
> Shouldn't those lines read
>
> if(td==Scalar(0))
> if(e2==0)
> while (start>Scalar(0) && m_subdiag[start-1]!=Scalar(0))
> ...
>
> In addition void computeRoots(const MatrixType& m, VectorType& roots)
> assume that double can explicitly converted to Scalar.
>
>
> const Scalar s_inv3 = Scalar(1.0)/Scalar(3.0);
> const Scalar s_sqrt3 = sqrt(Scalar(3.0));
>
>
> Is there a reason not using
>
> const Scalar s_inv3 = Scalar(1)/Scalar(3);
> const Scalar s_sqrt3 = sqrt(Scalar(3));
>
> However, there's also RealScalar(0.5).
> I'm not sure whether one should use 1/RealScalar(2) here.
>
> The attached version contains the corresponding changes based on
> eigen-eigen-dc6cfdf9bcec .
>
> Best regards,
> Peter
>
>
>
>
--001a114fd124591a3f0539c609bd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote style=3D"margin:0px 0px 0px 40px;border:none;p=
adding:0px"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-lef=
t:1ex" class=3D"gmail_quote"><span style=3D"font-size:12.8px"><i>...which m=
ay not the case for user defined type.</i></span></blockquote></blockquote>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">From my exp=
erience of creating custom scalar type (mpreal) -=C2=A0</div><div class=3D"=
gmail_extra">I can say that keeping code without explicit conversions to Sc=
alar is very beneficial.<br></div><div class=3D"gmail_extra"><br></div><div=
class=3D"gmail_extra">Just because operations involving standard types can=
be greatly optimized.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra"><div class=3D"gmail_extra">For example, when we want to ad=
d integer to arbitrary precision number:=C2=A0</div><div class=3D"gmail_ext=
ra"><br></div></div><blockquote style=3D"margin:0px 0px 0px 40px;border:non=
e;padding:0px"><div class=3D"gmail_extra"><div class=3D"gmail_extra"><font =
face=3D"monospace, monospace">mpreal a;</font></div></div><div class=3D"gma=
il_extra"><div class=3D"gmail_extra"><font face=3D"monospace, monospace"><b=
r></font></div></div><div class=3D"gmail_extra"><div class=3D"gmail_extra">=
<font face=3D"monospace, monospace">// compiler calls optimized +=3D(int) o=
perator,=C2=A0</font></div></div><div class=3D"gmail_extra"><div class=3D"g=
mail_extra"><font face=3D"monospace, monospace">// it is very easy to add s=
imple int to arbitrary precision number.</font></div></div><div class=3D"gm=
ail_extra"><div class=3D"gmail_extra"><font face=3D"monospace, monospace">/=
/ no additional memory allocations, constructor call, etc.</font></div></di=
v><div class=3D"gmail_extra"><div class=3D"gmail_extra"><font face=3D"monos=
pace, monospace">a +=3D 1;=C2=A0</font></div></div><div class=3D"gmail_extr=
a"><div class=3D"gmail_extra"><font face=3D"monospace, monospace"><br></fon=
t></div></div><div class=3D"gmail_extra"><div class=3D"gmail_extra"><font f=
ace=3D"monospace, monospace">// unnecessary call of constructor/memory allo=
cations,=C2=A0</font></div></div><div class=3D"gmail_extra"><div class=3D"g=
mail_extra"><font face=3D"monospace, monospace">// but the worst - now we h=
ave to use heavy artillery to add numbers,=C2=A0</font></div></div><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_extra"><font face=3D"monospace, mono=
space">// since they both of arbitrary precision now - optimization is disa=
bled</font></div></div><div class=3D"gmail_extra"><div class=3D"gmail_extra=
"><font face=3D"monospace, monospace">a +=3D mpreal(1);=C2=A0</font></div><=
/div></blockquote><div class=3D"gmail_extra"><div class=3D"gmail_extra"><br=
></div><div class=3D"gmail_extra">Actually huge part of arbitrary precision=
libraries are devoted to such optimized cases (just look to GMP/MPFR low l=
evel API).</div><div class=3D"gmail_extra">Otherwise we get significant dro=
p in speed.=C2=A0</div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">This is also true for conditional operations (<, >, etc.)=
..<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
Please let the custom scalar types handle such special cases on its own, so=
that it can produce fast code!</div><div class=3D"gmail_extra">=C2=A0<br><=
/div></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">On Thu, Aug 11, 2016 at 1:22 AM, Peter <span dir=
=3D"ltr"><<a href=3D"mailto:list@xxxxxxxxxxxxxxxxx"; target=3D"_blank">li=
st@xxxxxxxxxxxxxxxxx</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Dear All,<br=
>
<br>
SelfAdjointEigenSolver.h=C2=A0 assumes that integer will implicitly convert=
ed to Scalar,<br>
which may not the case for user defined type.<br>
<br>
E.g.<br>
=C2=A0if(td=3D=3D0)<br>
=C2=A0if(e2=3D=3D0)<br>
=C2=A0while (start>0 && m_subdiag[start-1]!=3D0)<br>
....<br>
<br>
Shouldn't those lines read<br>
<br>
=C2=A0if(td=3D=3DScalar(0))<br>
=C2=A0if(e2=3D=3D0)<br>
=C2=A0while (start>Scalar(0) && m_subdiag[start-1]!=3DScalar(0))=
<br>
....<br>
<br>
In addition=C2=A0 void computeRoots(const MatrixType& m, VectorType&=
; roots)<br>
assume that double can explicitly converted to Scalar.<br>
<br>
<br>
const Scalar s_inv3 =3D Scalar(1.0)/Scalar(3.0);<br>
const Scalar s_sqrt3 =3D sqrt(Scalar(3.0));<br>
<br>
<br>
Is there a reason not using<br>
<br>
const Scalar s_inv3=C2=A0 =3D Scalar(1)/Scalar(3);<br>
const Scalar s_sqrt3 =3D sqrt(Scalar(3));<br>
<br>
However, there's also RealScalar(0.5).<br>
I'm not sure whether one should use 1/RealScalar(2) here.<br>
<br>
The attached version contains the corresponding changes based on eigen-eige=
n-dc6cfdf9bcec .<br>
<br>
Best regards,<br>
Peter<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>
--001a114fd124591a3f0539c609bd--