[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming

Designing a suite of algorithms in C++

Paul

2/1/2016 11:39:00 AM

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
6 Answers

Mark Carroll

2/1/2016 12:04:00 PM

0

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

Paul

2/1/2016 1:52:00 PM

0

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

Mark Carroll

2/1/2016 3:11:00 PM

0

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

gw7rib

2/1/2016 10:16:00 PM

0

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?

Bartc

2/1/2016 11:00:00 PM

0

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

Kaz Kylheku

2/1/2016 11:25:00 PM

0

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.