At 10:50 AM 12/8/2011, Graeme Geldenhuys wrote:
On 8 December 2011 18:41, Florian Klaempfl wrote:
>
> And? The conclusion is what we concluded years ago: be as delphi
> compatible as possible else people start to cry soon or later. The funny
> thing is only that this time the people cry who didn't draw this
> conclusion yet.
I'll be the first to admit, I think most of this "delphi
compatibility" is crap. But there is a BIG difference between being
compatible, and being totally unusable. Clearly many here have listed
that they use Random in a recursion function, and in such a case the
HUGE speed penalty makes the current Random() implementation
unsuitable and unusable.
Will an implementation like Waldo Kitty suggested be a suitable
compromise? If so, I'll go ahead and create a patch.
Why a patch at all? Sorry, but to me, this is all but a storm in a teacup...
If Jürgen's "test" application is intended to
measure "transfer" speed, the test is
fundamentally flawed when it would depend on the speed of data generation.
So why doesn't he implement his own random
function for his specific needs? That satisfies
his special usage and leaves everyone else, who
doesn't seem to mind/care with the default
function that provides greater "randomness".
For all of my applications, I definitely prefer
the later and can't think of a single instance
where the implementation of the random function
in FPC makes any significant difference in
performance. For me, I prefer" rather safe than sorry (fast)"...
Ralf
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
