Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6249 > unrolled thread

Designing a suite of algorithms in C++

Back to article view | Back to comp.programming

Contents

  Designing a suite of algorithms in C++ Paul <pepstein5@gmail.com> - 2016-02-01 03:38 -0800
    Re: Designing a suite of algorithms in C++ Mark Carroll <mtbc@bcs.org> - 2016-02-01 12:04 +0000
      Re: Designing a suite of algorithms in C++ Paul <pepstein5@gmail.com> - 2016-02-01 05:52 -0800
        Re: Designing a suite of algorithms in C++ Mark Carroll <mtbc@bcs.org> - 2016-02-01 15:10 +0000
    Re: Designing a suite of algorithms in C++ Paul N <gw7rib@aol.com> - 2016-02-01 14:15 -0800
    Re: Designing a suite of algorithms in C++ BartC <bc@freeuk.com> - 2016-02-01 23:00 +0000
    Re: Designing a suite of algorithms in C++ Kaz Kylheku <330-706-9395@kylheku.com> - 2016-02-01 23:24 +0000

#6249 — Designing a suite of algorithms in C++

The post below was also sent to comp.lang.c++ but it's been more than half a day, and I haven't got any responses so I'd like to post it to this group.

I am trying to present in C++ a set of algorithms for solving a problem.  It is intended that the set of algorithms will expand.  So far, I have five basic algorithms for solving the same problem.  The end goal (so far) is to develop a simple user interface at the console so that the user can provide the parameters, together with a string indicating the name of the algorithm, and my code will provide the solution (and possibly the runtime). 

Four of these algorithms are simple conceptually (although the maths is complicated).  However, the fifth algorithm is much more involved because it has four or five features which can be absent or present so the fifth algorithm can really be thought of as 16 or 32 algorithms.  (The vagueness is because I haven't decided which features to be settable by the user). 

If I only had the first four to worry about, the design could be very simple. 
I would have a pure abstract class as a base of all the algorithms.  Finding the solution is done via a virtual function which depends on the algorithm selected by the user. 

class Algorithm{ 

public: 
Algorithm(some parameters); 
virtual void findSolution() = 0; 
virtual ~Algorithm()
{}
}; 

class Method1 : public Algorithm 
{ 
   public: 
   Method1(some parameters) : Algorithm(some parameters) 
   { 
    
   } 
  void findSolution() 
   { 

   } 

}; 

Methods 2, 3 and 4 could have the same design as Method 1. 

But the complex method, method 5, makes it harder to design elegantly. 

I could try 

class Method5 : public Algorithm 
{ 
   bool flag1; 
   bool flag2; 
... 
   public: 
   Method5 (some parameters, bool someFlag, bool someOtherFlag): Algorithm(some parameters), flag1(someFlag), flag2(someOtherFlag) 
   { 
  
   } 

  void findSolution() 
  { 
     if(flag1) doThis; 
     if(flag2) doThat; 
     //// 
    
  } 
} 

However, now for Method 5, the approach no longer looks elegant. 

Any ideas?  I'm deliberately being vague about the precise nature of the problem because I want to decouple the maths side from the design side and I definitely don't want help on the maths side. 

Many thanks, 

Paul

[toc] | [next] | [standalone]

#6250

On 01 Feb 2016, Paul wrote:

> The post below was also sent to comp.lang.c++ but it's been more than
> half a day, and I haven't got any responses so I'd like to post it to
> this group.

That's not long to wait!

> If I only had the first four to worry about, the design could be very simple. 
> I would have a pure abstract class as a base of all the algorithms.  Finding the solution is done via a virtual function which depends on the algorithm selected by the user.

... and such details of how OO works are rather C++-specific.

Good luck though.

-- Mark

[toc] | [prev] | [next] | [standalone]

#6251

On Monday, February 1, 2016 at 12:04:08 PM UTC, Mark Carroll wrote:
> On 01 Feb 2016, Paul wrote:
> 
> > The post below was also sent to comp.lang.c++ but it's been more than
> > half a day, and I haven't got any responses so I'd like to post it to
> > this group.
> 
> That's not long to wait!
> 
Perhaps not. Let p be the time of posting.  Let n be the least waiting time which has the property that, if no helpful responses are received by time n, the probability of (any helpful responses being received by time (p + 1 week) < 0.5.  What is your estimate of n?  I was thinking n may well be about half a day.

Paul

[toc] | [prev] | [next] | [standalone]

#6252

On 01 Feb 2016, Paul wrote:

> On Monday, February 1, 2016 at 12:04:08 PM UTC, Mark Carroll wrote:
>> On 01 Feb 2016, Paul wrote:
>> 
>> > The post below was also sent to comp.lang.c++ but it's been more than
>> > half a day, and I haven't got any responses so I'd like to post it to
>> > this group.
>> 
>> That's not long to wait!
>> 
> Perhaps not. Let p be the time of posting. Let n be the least waiting time
> which has the property that, if no helpful responses are received by time n,
> the probability of (any helpful responses being received by time (p + 1 week)
> < 0.5. What is your estimate of n? I was thinking n may well be about half a
> day.

It's worth waiting at least a day: people have different daily routines
that typically don't involve reading news all day, can need time to mull
over a problem while doing something else, and are from different time
zones around the world.

-- Mark

[toc] | [prev] | [next] | [standalone]

#6253

On Monday, February 1, 2016 at 11:38:41 AM UTC, Paul wrote:
> The post below was also sent to comp.lang.c++ but it's been more than half a day, and I haven't got any responses so I'd like to post it to this group.
> 
> I am trying to present in C++ a set of algorithms for solving a problem.  It is intended that the set of algorithms will expand.  So far, I have five basic algorithms for solving the same problem.  The end goal (so far) is to develop a simple user interface at the console so that the user can provide the parameters, together with a string indicating the name of the algorithm, and my code will provide the solution (and possibly the runtime). 
> 
> Four of these algorithms are simple conceptually (although the maths is complicated).  However, the fifth algorithm is much more involved because it has four or five features which can be absent or present so the fifth algorithm can really be thought of as 16 or 32 algorithms.  (The vagueness is because I haven't decided which features to be settable by the user). 
> 
> If I only had the first four to worry about, the design could be very simple. 
> I would have a pure abstract class as a base of all the algorithms.  Finding the solution is done via a virtual function which depends on the algorithm selected by the user. 
> 
> class Algorithm{ 
> 
> public: 
> Algorithm(some parameters); 
> virtual void findSolution() = 0; 
> virtual ~Algorithm()
> {}
> }; 
> 
> class Method1 : public Algorithm 
> { 
>    public: 
>    Method1(some parameters) : Algorithm(some parameters) 
>    { 
>     
>    } 
>   void findSolution() 
>    { 
> 
>    } 
> 
> }; 
> 
> Methods 2, 3 and 4 could have the same design as Method 1. 
> 
> But the complex method, method 5, makes it harder to design elegantly. 
> 
> I could try 
> 
> class Method5 : public Algorithm 
> { 
>    bool flag1; 
>    bool flag2; 
> ... 
>    public: 
>    Method5 (some parameters, bool someFlag, bool someOtherFlag): Algorithm(some parameters), flag1(someFlag), flag2(someOtherFlag) 
>    { 
>   
>    } 
> 
>   void findSolution() 
>   { 
>      if(flag1) doThis; 
>      if(flag2) doThat; 
>      //// 
>     
>   } 
> } 
> 
> However, now for Method 5, the approach no longer looks elegant. 
> 
> Any ideas?  I'm deliberately being vague about the precise nature of the problem because I want to decouple the maths side from the design side and I definitely don't want help on the maths side. 
> 
> Many thanks, 
> 
> Paul

Is there some reason what you don't just have five functions, and five if statements each with a string comparison?

[toc] | [prev] | [next] | [standalone]

#6254

On 01/02/2016 11:38, Paul wrote:
> The post below was also sent to comp.lang.c++ but it's been more than half a day, and I haven't got any responses so I'd like to post it to this group.
>
> I am trying to present in C++ a set of algorithms for solving a problem.  It is intended that the set of algorithms will expand.  So far, I have five basic algorithms for solving the same problem.  The end goal (so far) is to develop a simple user interface at the console so that the user can provide the parameters, together with a string indicating the name of the algorithm, and my code will provide the solution (and possibly the runtime).
>
> Four of these algorithms are simple conceptually (although the maths is complicated).  However, the fifth algorithm is much more involved because it has four or five features which can be absent or present so the fifth algorithm can really be thought of as 16 or 32 algorithms.  (The vagueness is because I haven't decided which features to be settable by the user).
>
> If I only had the first four to worry about, the design could be very simple.


> I would have a pure abstract class as a base of all the algorithms.

That's the least of the problems I think. Maybe forget classes to start 
with.

What exactly will the interface look like? Is it a bunch of numbers and 
stuff all on one line, or will there be some interaction to get the 
parameters depending on the algorithm chosen? How is the algorithm 
specified? (It would be simplest if this is done at the start, before 
any parameters rather than after.)

Maybe then as well as 'handlers' for dealing algorithm N, or finding 
solution N (what's the difference between those?), you can have another 
handler GetParameters N, a dedicated routine for each kind of algorithm. 
Then it doesn't matter if algorithm 3 is very different from 5, as it 
has its own user interface.

(This is feasible for 5 algorithms; if the number grows significantly, 
then you can think about making it table-based, or class-based if you 
must, but then it will be clearer how to approach the problem.

I would also suggest, unless it must be 100% C++ or it has to run within 
an existing application, to use a scripting solution for grabbing the 
input. Then the different algorithms don't even need to be part of the 
same program.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#6255

On 2016-02-01, Paul <pepstein5@gmail.com> wrote:
> class Algorithm{ 
>
> public: 
> Algorithm(some parameters); 
> virtual void findSolution() = 0; 
> virtual ~Algorithm()
> {}
> }; 

This interface only supports algorithms that either find a solution, for
any combination of parameters, or else do not terminate.

Your findSolution function has no way to indicate "I have stopped
searching, and found no solution".

If the function returns, since it has no return value, and the
interface has no useful member functions to inspect any state,
we can assume that the solution was found. So if the solution cannot
be found, the function doesn't return, right?

Not to mention that, quite often, when algorithms find a solution,
we want to know *what* that solution is, not only *that* it exists.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web