Page 1 of 4

Version 0.0: Prototype

Posted: November 7th, 2011, 12:18 pm
by rmax
Thread to discuss an initial prototype implementation.We seem to have had come good thoughts around the design and architecture and people have raised some good points especially around the handling of errors). Are we in a good enough position to think about pulling some elements into an initial prototype.I think the scope of the intial prototype should be small1. Enough that elements interact succesfully2. Standardised termonology / calling methodologies3. DocumentedParticpants should include in this thread what they wish to submit as their initial prototype code for integration. We can get this stablised in terms of a "core" and build-out once the ground works have been laid.Could we shoot for a pre-Christmas initial build? With testing and doc review taking place over Christmas?

Version 0.0: Prototype

Posted: November 7th, 2011, 2:07 pm
by Cuchulainn
That sounds like a good planning. I will hopefully have 1 factor (C++, C#) and 2 factor (C++, C#) framework initial version documented and running.

Version 0.0: Prototype

Posted: November 9th, 2011, 8:45 am
by rmax
There is a lot that needs to be done. But like the ISS ( ) it was not all put into orbit on one rocket!I think if we understand the architecture of how these pieces fit together then we can start with the core module, and slowly build out as required. The key is to have something of a "core" that people understand how to use, and then we can begin to build-out.

Version 0.0: Prototype

Posted: November 9th, 2011, 12:01 pm
by Cuchulainn
QuoteSo I'm fine with initial version that work on some 3rd party library, but at the same time want to have something that refactors that to a different brand which *does* impose strict rules regarding orthogonality, genericality and 3rd party dependency.My 3rd party Matrix is working already, so moving at this stage to satisfy IS09126::Functionality::Compliance is for later indeed. Of course, the old engineering adage "if it don't break, don't fix it" , "good enough" might play a role. What I like is methods for {Min, Max} Index in loops instead of inane 0 and size - 1. BTW my Vector<> is already STL-compliant.Boost can be seen as 3rd party because it does not work under C# or MM, for example. In my FDM code I would say "Boost inside". I V2 I do plan to use Boost libs as plumbing.It will be interesting to see how to handle N:M (e.g. many PDE have many FDM schemes) relationships in generics (C++ does not support multimethods). At this stage I see few competitors/challengers to Visitor pattern.For many reasons and time constraints my approach is 1. Get it working (V1)1A Get user feedback1B Effect user feedback2 Get it right2A Developers give feedback on making code more generic (version V2)2B Users work with V23 Get it optimised (which takes forever)

Version 0.0: Prototype

Posted: November 9th, 2011, 12:16 pm
by rmax
These are all really valid points. I think to get round the "branding" problem, we can have the central "core" that is all good quality etc, and then the pieces around the edge are where people can upload their code that is not subsumed into the main core until it becomes stable. This fits well with outrun's logo of a number of squares!I think we need to be honest: Prototype will be Salyut 1. It should not be expected to be a fully functioning framework or consistent library. Download if you want to tinker and improve, not if you want to use in anger as fully fledged framework!

Version 0.0: Prototype

Posted: November 9th, 2011, 12:28 pm
by Cuchulainn
QuoteOriginally posted by: outrunQuoteOriginally posted by: Cuchulainn What I like is methods for {Min, Max} Index in loops instead of inane 0 and size - 1. BTW my Vector<> is already STL-compliant.I'm thinking about the compliance the other way around. E.g. * The algorithm that uses DD_Vector<> should also work with std::vector, or any other container that provided a stl compliant interface. * {Min, Max} preferences inside the algorithm should not result in interface requirement to the vector container, because stl doesn't have that, and that would cause the algorithm not to work on stl compiant containers. E.g. a user might prefer std::vector over DD_VectorDesign choices like that... Does that make sense? Regarding boost. I think we said that we prefer STL dependency, *then* boost, then self-written code. Lots of libs in boost end up in the C++ standard. It's more likely that functionality in boost will end up in the standard than serlf-written functionality, hence the preference of boost of writing thing yourself.My Vector class is consistent with what we call a mathematical vector space, which std::vector is not. Thus, the latter is the wrong container for maths (valarray tried to solve this, but was not successful). UBLAS vector would be closer to My Vector.std::vector is just a container, so I would not use it in a solver.And MinIndex() flexible is a must for me(C, Fortran styles), otherwise the code becomes unmaintainable.A lot of Boost ends up in C++ and lot does not.

Version 0.0: Prototype

Posted: November 9th, 2011, 12:43 pm
by Cuchulainn
QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunQuoteOriginally posted by: Cuchulainn What I like is methods for {Min, Max} Index in loops instead of inane 0 and size - 1. BTW my Vector<> is already STL-compliant.I'm thinking about the compliance the other way around. E.g. * The algorithm that uses DD_Vector<> should also work with std::vector, or any other container that provided a stl compliant interface. * {Min, Max} preferences inside the algorithm should not result in interface requirement to the vector container, because stl doesn't have that, and that would cause the algorithm not to work on stl compiant containers. E.g. a user might prefer std::vector over DD_VectorDesign choices like that... Does that make sense? Regarding boost. I think we said that we prefer STL dependency, *then* boost, then self-written code. Lots of libs in boost end up in the C++ standard. It's more likely that functionality in boost will end up in the standard than serlf-written functionality, hence the preference of boost of writing thing yourself.My Vector class is consistent with what we call a mathematical vector space, which std::vector is not. Thus, the latter is the wrong container for maths (valarray tried to solve this, but was not successful). UBLAS vector would be closer to My Vector.std::vector is just a container, so I would not use it in a solver.And MinIndex() flexible is a must (C, Fortran styles). A lot of Boost ends up in C++ and lot does not.Ok, so on this we disagree! I want the algorithms to support std::vector, iterators, not self written stuff, that will only make thing complicated and steepen the learning curve.The solution is to implement both.I'll refactor the heat equation solver *algorithm* into one that's STL compliant, and release it on a different brand, call it the C++ STL compliant / generic programming QFCL or something like that.I would say two design decisions that we can check against ISO9126. For FDM apps, std::vector is *mathematically incorrect*. I have tried it already, so not again for FDM. My Vector has been around > 15 years and is easy to use, so in V1 FDM this is what I will deliver (it works now as it is). If anything, uBLAS vector and this 1st option. Contributors can put this it into V2, which is fine.