Would like a preprocessor.

[Paul Lutus]

I am not sure what you are trying to say here. Are you talking of
optimal solutions or optimal costs?

My point is that an ideal compiler will produce the same object file
(trivial reorderings aside) regardless of which of the legal syntax choices
the programmer makes in designing a specific algorithm. Same speed, same
size, or whatever trait was regarded as most important.

There is no ideal compiler, but this is a hypothetical discussion of what
compilers should do.

Taking a travelling salesman example, let us say you have 8
destinations equally spaced along the periphery of a circle and a
fifth one (the starting point) in the center of the circle, it is easy
to see that there are multiple optimal solutions (16 I think). This is
largely given by the symmetry of the problem. There is, however, only
one optimal shortest travel distance (i.e., optimal cost) - it is the
same for all the 16(?) optimal solutions.

And this is what I mean by saying "trivial reordering aside". It is a
symmetry that rarely appears in practice.

So what do you actually mean by "one optimal outcome"?

See above.

 

[Bent C Dalager]

My point is that an ideal compiler will produce the same object file
(trivial reorderings aside) regardless of which of the legal syntax choices
the programmer makes in designing a specific algorithm. Same speed, same
size, or whatever trait was regarded as most important.

What you seem to be saying, then, is that an ideal compiler will
always produce the exact same output for a given problem and that if
we ignore all other possible outputs that yield the same performance,
there is one and only one specific output such a compiler can yield.

Of course, I then understand "trivial reordering" to mean "a
difference that doesn't impact on performance". If you have a
different definition of "trivial reordering" in mind it would help if
you described it. On its own it is a very vague term.

If this is the case, however, then your statement isn't really of much
interest. It's basically a bit like saying "Ford is the only car
company in the world, given that we ignore everyone else who makes
cars".

Cheers
Bent D

 

[Liz]

Christopher Barber wrote:

/ ...


That would produce different algorithms, so you in fact did not read what I
said.

You are missing a very fundamental point.

1. The only way to justify goto, break, continue, et al.. is to show that
these constructs create the same logic, the same algorithm, as the more
structured alternatives.

I think the GOTO maps into a JMP instruction ;-)

 

[Paul Lutus]

What you seem to be saying, then, is that an ideal compiler will
always produce the exact same output for a given problem and that if
we ignore all other possible outputs that yield the same performance,
there is one and only one specific output such a compiler can yield.

That is not what I said. My remark obviously means that all compiled results
that produce the exact algorithm and meet all the specified requirements
are members of a set, any of which might be the result of the compilation,
and the use of different syntax approaches should not affect that outcome.

Of course, I then understand "trivial reordering" to mean "a
difference that doesn't impact on performance". If you have a
different definition of "trivial reordering" in mind it would help if
you described it. On its own it is a very vague term.

See above.

If this is the case, however, then your statement isn't really of much
interest. It's basically a bit like saying "Ford is the only car
company in the world, given that we ignore everyone else who makes
cars".

Yes, except that is not remotely what I said.

 

[Tony Morris]

A common problem is the lack of distinction between "problem" and
"solution".
You have described a solution to a problem that is not very well defined.
The only description of your problem is "need to optimise".
Your solution is "goto statements, preprocessor, <other-ad-hoc-things/>"
I strongly suggest you review and clarify your problem, then request
suggestions for a solution.
I am inclined to speculate (due to lack of clarity of the problem) that your
solution is a flawed approach since it is a common beginner mistake that has
few, if any, justifications.

 

[Liz]

A common problem is the lack of distinction between "problem" and
"solution".

So this is equivelent to:

A common solution is the lack of distinction between "solution" and
"solution".