Hi Dli,
Dli, I and ries were discussing about LibreCAD 3 maths part and I guess you might be busy, we had a few questions, so you could reply those here, 1) Dli, I realised we were using 2x2 matrices only at the max. Eigen provides matrices as MatrixXd means dynamic doubles matrix and as Matrix2d which means 2x2 matrix so should we use Matrix2d? will that be fine? 2) Ries was looking over the code, and found that the constructors always gave newer objects and not the references to the older objects, From IRC discussion, 18:12 UTC ries I think the copy constructor has side effects the way it's created, eg, it doesn't make a real copy 18:15 UTC ries For Quadratic rotate(const double& a); do you perhaps mean Quadratic& rotate(const double& a); 18:15 UTC ries So you can do quadratic.rotate(a).move(b); ?? need your thoughts on this one also. Ries prefers the maths related classes to be immutable, I remember we opted for the mutable due to performance reasons, but I and ries had a deal long time ago to compare mutable and immutable classes and check the difference we get. So I guess I might be doing that too, just for testing purposes. This was just for keeping you informed. :) Ries could add more, 
Administrator

Conceptually, say, we want to perform householder transform of a matrix.
It involves taking submatrices sub column vectors, and transforming them. Performance of code is actually only part of the story. Ideally, the code should express the math well. If code becomes much more complex because of the choice, it may not even worth the effort to get high performance but complicated code. Can you try to play with some features to see whether tye immutable requirement makes the code more compact or not. 
Administrator

gaganjyot,
I looked at a few usecases for Quadratic on our current LibreCAD version and came to the conclusion that it looks fine to me if we make this a immutable. This will most likely not affect anything for us. This means all methods can be made const eg Quadratic rotate(const double& a) const; Make sure you add a good copy constructor that just copies values, aswell as proper move assignment and move constructors. Let me know if you have any questions. 
In reply to this post by dxli
On Sat, Apr 23, 2016 at 1:41 AM, dxli [via LibreCAD]
<[hidden email]> wrote: > Conceptually, say, we want to perform householder transform of a matrix. > > It involves taking submatrices sub column vectors, and transforming them. > > Performance of code is actually only part of the story. Ideally, the code > should express the math well. > > If code becomes much more complex because of the choice, it may not even > worth the effort to get high performance but complicated code. > > Can you try to play with some features to see whether tye immutable > requirement makes the code more compact or not. Yes sure, that's the part of the testing of immutable vs mutable. I'll check that. Further I wonder about the other questions, is it supposed to be, Quadratic rotate(const double& a); or Quadratic& rotate(const double& a); and if its fine if we use static 2x2 matrix for quadratic operations or we need a dynamic one?  Thanks Gaganjyot "Jai Sai Naath" 
In reply to this post by R. van Twisk
On Sat, Apr 23, 2016 at 5:01 PM, R. van Twisk [via LibreCAD]
<[hidden email]> wrote: > gaganjyot, > > I looked at a few usecases on our current LibreCAD version and came to the > conclusion that it looks fine to me if we make this a immutable. This will > most likely not affect anything for us. I see, > This means all methods can be made const eg Quadratic rotate(const double& > a) const; > Make sure you add a good copy constructor that just copies values, aswell as > proper move assignment and move constructors. Alright. I'll keep that in mind. > Let me know if you have any questions. Sure,  Thanks Gaganjyot "Jai Sai Naath" 
Administrator

In reply to this post by gaganjyot
You won't return a reference but a new copy, so it would be : const Quadratic rotate(const double& a) const; I would keep it static, if there comes a need to make it dynamic then this should be a very easy change that's would be very easy to refactor. Use initialization lists where possible Ries 
Free forum by Nabble  Scala forum  Edit this page 