Re: Fastcode Poll IntToStr64/32 Two Challenges or One

From poll > All FP based challenges have 3 in one because overloaded
Extended, Double and Single precision functions are made.

Why are we not overloaded integer and int64 ?

We build the libraries with overloaded Int / Int64 functions where
possible. This can be done no matter how the challenges are
organized. No argument to combine - or not - challenges in B&V's here.

FP functions in the 3 precisions are almost identical, this is not
the case for Int/Int64 functions. This is an argument for separating
Int/Int64 challenges.

Although the functions differ more, the algorithms used are identical.
One cannot reuse the code from either for the other, given one can
easily write a function that performs the conversion in exactly the
smae way. This parallel development allows contributors to develop both
entries together, even though it requires more coding than in the FP
case.

Another point is that re-use of the IntToStr32 function will not count
for the IntToStr64 code size penaly now. ISTM this is realistic, since
a fast IntToStr32 will be there anyways.

The benchmark and validation code differs for the two cases, but not
really more than in the FP case - and this is not an argument for
separating the two challenges.

In fact it is even an argument for not separating them. Again,
developing them together is more effecitve. The validators and
benchmarks perform the same operations between the subchallenges.

The points in FP based challenges are given such that eg. an Extended
function winner/entry will give 1/3 of the points a winner/entry
gives. 1/3 point for an entry and 3.333 points for a target winner.
In Integer based challenges full points are given. Eg. Max(Int) gives
10 winner points and a Max ( Int64) winner also gives 10 points. If
we give combine IntToStr32/64 we change the point system. This change
has not been defined anywhere.

True.

The change is, however, very minor. For development, testing,
validation and benchmarking the subchallenges are together, but for
scoring they are considered separate.

If you combine the two challenges then the version number system
breaks. Changing the IntToStr32 benchmark updates the version number
and signals changes to the IntToStr64 benchmark as well - which is
incorrect.

Changes in the B&V code are always simultaneous. Therefore this goes
only for function submission. Like for the FP case, i think that people
aught to (but not have to) submit these functions together.

Note that the B&V tool gives the possibility to have separate version
numbers, although for clarity i prefer not to use that.

Change conventions and you will create a mess and 100 questions. Why
is IntToStr32/64 combined when Max/Min.... are not?

IMO they could have been. The same goes for Pos/PosEx. This is,
however, no reason to combine them now. Afterwards this would not give
the same advantages anymore. It would be a waste of work.

How many points
should a winner and an entry give?

The same as if they were separate.

How should I understand the
version numbering?

One number together.

Who fixes the SpreadssheetCreator?

Can it already handle combined FP challenges? In that case the
differences should not be great (only the separate scoring)

Is it necessary
to rerun IntToStr32 benchmarks and validations on all targets when
adding a IntToStr64 function?

Typically both would be changed together.

--
The Fastcode Project: http://www.fastcodeproject.org/
.