On Thu, Dec 8, 2011 at 8:48 AM, Graeme Geldenhuys
wrote:
> [like what was told to me numerous times before] They (FPC users)
> should speak up now, or forever hold your peace. And those that have
> spoken so far, all seem to be fine with a less statistically strong
> default Random(), and have th
Am 08.12.2011 08:48, schrieb Graeme Geldenhuys:
>
> [like what was told to me numerous times before] They (FPC users)
> should speak up now,
Actually those who depend on speed should have spoken up ten years ago
when the MT was implemented.
___
fpc-pa
On 8 December 2011 09:25, Felipe Monteiro de Carvalho wrote:
>
> And what if it changes in the future to being slow and statistically
> strong, we change again too?
The random number generator can be implemented in such a way that the
backend generator is user selectable.
> And what about people
Am 08.12.2011 08:25, schrieb Felipe Monteiro de Carvalho:
> On Thu, Dec 8, 2011 at 7:27 AM, Jürgen Hestermann
> wrote:
>> Fully agree. Especially, because ex Delphi (and ex Turbo Pascal) users would
>> expect it like that. And most of them (coming from Delphi/TP) believe that
>> the randomness is
On Thu, Dec 8, 2011 at 7:27 AM, Jürgen Hestermann
wrote:
> Fully agree. Especially, because ex Delphi (and ex Turbo Pascal) users would
> expect it like that. And most of them (coming from Delphi/TP) believe that
> the randomness is not very reliable. They mainly don't even know (like me)
> that t
Graeme Geldenhuys schrieb:
I would suggest the default Random() call uses a higher
speed performance generator though, and not the MT one.
Fully agree. Especially, because ex Delphi (and ex Turbo Pascal) users
would expect it like that. And most of them (coming from Delphi/TP)
believe tha
On 7 December 2011 19:31, Jürgen Hestermann wrote:
> compression. There is no need to have a *real* random number in this case. I
> always wondered, why this program reported slightly faster network transfer
> in Delphi than in Lazarus/FPC but now I now why. Here it is a bad thing that
I just fo
Linux/i386, 2_6 branch
var
a : QWord;
x : QWordBool;
y : QWordBool;
begin
a := QWord($);
x := QWordBool(a);
y := not x;
fpwinglet.lpr(21,3) Fatal: Internal error 200109227
(Line 21 is the line y := not x)
I stumbled over this while I was experimenting with finding out ho
- "Jürgen Hestermann" schreef:
> But now we have a fast random() function in Delphi and a statistical
> good one in FPC but none of them has both.
just my 2cts, but...
The Delphi 7 help states about "function System.Random [ ( Range: Integer) ];"
the following
--
In Delphi code, Rando
Florian Klaempfl schrieb:
> Well, once we thought we try to do things better than Delphi ;) Some
> people, I think John Lee, asked for a better random in FPC years ago so
> Jonas implemented a MT.
I think there are two very different approaches. I wrote a small tool
for testing network performan
I have noticed the following code in Tstrings, in the quicksort;
" Pivot := L + Random(R - L); // they say random is best "
On 07/12/11 13:10, Graeme Geldenhuys wrote:
On 7 December 2011 14:54, Jonas Maebe wrote:
That's correct. We use the mersenne twister, Delphi probably a linear
cong
On Wed, Dec 7, 2011 at 18:35, Florian Klaempfl wrote:
>
> FPC uses MT at least for 10 years and nobody complained about
> performance yet. So I suspect the cases might be very rare when random
> performance matters and having good random numbers is always a good
> thing ... I prefer not to change
FPC uses MT at least for 10 years and nobody complained about
performance yet. So I suspect the cases might be very rare when random
performance matters and having good random numbers is always a good
thing ... I prefer not to change it but it's fine for me for delphi
compatibility's sake ;)
Or ma
Maybe implementing something other :
"The main advantages of the MWC method are that it invokes simple
computer integer arithmetic and leads to very fast generation of
sequences of random numbers with immense periods, ranging from around
260 to 2200."
http://en.wikipedia.org/wiki/Multiply-wit
Am 07.12.2011 16:03, schrieb Graeme Geldenhuys:
> On 7 December 2011 14:54, Jonas Maebe wrote:
>>
>> That's correct. We use the mersenne twister, Delphi probably a linear
>> congruential generator. The mersenne twister has a much larger period.
>
> I was reading a bit more about this. The Mersen
Abbrevia 5.0 is now available.
Abbrevia is a data compression toolkit for Embarcadero Delphi, C++
Builder, and Kylix, and FreePascal. It supports PKZip, Microsoft CAB,
tar, gzip, bzip2 and zlib compression formats, and the creation of
self-extracting archives. It includes several visual components
On 7 December 2011 14:54, Jonas Maebe wrote:
>
> That's correct. We use the mersenne twister, Delphi probably a linear
> congruential generator. The mersenne twister has a much larger period.
I was reading a bit more about this. The Mersenne Twister (MT)
generator has a massive period of 2^19937
On 7 December 2011 15:54, Peter wrote:
>
> I would recommend using Marsaglia's XORShift.
> Blisteringly fast, high quality statistically, and very easy to implement.
Thanks for the info. Like I said, the original code in tiOPF is just
an extra [sample / simple] encryption implementation. There al
How does it compare re 'randomness' cf current fpc version? The wikipedia
reference doesn't make this clear. Or the original fpc/delphi versions?
Jonas?
John
On 7 December 2011 14:08, Inoussa OUEDRAOGO wrote:
> 2011/12/7 Peter :
> > Graeme,
> >
> > I would recommend using Marsaglia's XORShift.
>
2011/12/7 Peter :
> Graeme,
>
> I would recommend using Marsaglia's XORShift.
> Blisteringly fast, high quality statistically, and very easy to implement.
>
> http://en.wikipedia.org/wiki/Xorshift
For those who want to test it here is an Object Pascal implementation.
--
Inoussa O.
hrandom.pas
Graeme,
I would recommend using Marsaglia's XORShift.
Blisteringly fast, high quality statistically, and very easy to implement.
http://en.wikipedia.org/wiki/Xorshift
Regards,
Peter
On 07/12/11 13:10, Graeme Geldenhuys wrote:
On 7 December 2011 14:54, Jonas Maebe wrote:
That's correct
On 7 December 2011 15:40, wrote:
>
> A good point.
>
> Please add an entry in the bug tracker, or it is likely I will forget :/
http://bugs.freepascal.org/view.php?id=20834
Report created with a patch. Tweak the text as you see fit.
--
Regards,
- Graeme -
__
Why not use the previous fpc version - I guess similar to that in delphi- I
can remember an email when Jonas changed it quite a few years ago - Jonas
must have older version - but can't really remember the fpc version -
v1.0? My guess it could be found in either svn or more likely the older cvs
f
On Wed, 7 Dec 2011, Graeme Geldenhuys wrote:
On 7 December 2011 14:54, Jonas Maebe wrote:
That's correct. We use the mersenne twister, Delphi probably a linear
congruential generator. The mersenne twister has a much larger period.
OK thanks for the info. This is a serious performance hit,
On 7 December 2011 14:54, Jonas Maebe wrote:
>
> That's correct. We use the mersenne twister, Delphi probably a linear
> congruential generator. The mersenne twister has a much larger period.
OK thanks for the info. This is a serious performance hit, but I
understand that the FPC implementation i
On 07 Dec 2011, at 13:51, michael.vancann...@wisa.be wrote:
I think the random() algorithm is simply much more complicated in FPC.
That's correct. We use the mersenne twister, Delphi probably a linear
congruential generator. The mersenne twister has a much larger period.
Jonas
__
On Wed, 7 Dec 2011, Graeme Geldenhuys wrote:
Hi,
I'm busy working on some of the remaining unit tests for the tiOPF
project that doesn't run 100% to my satisfaction yet under FPC
(compared to Delphi 7). One of the tests is for a Simple Encryption
algorithm implemented in tiOPF, that runs extr
Hi,
I'm busy working on some of the remaining unit tests for the tiOPF
project that doesn't run 100% to my satisfaction yet under FPC
(compared to Delphi 7). One of the tests is for a Simple Encryption
algorithm implemented in tiOPF, that runs extremely slow under FPC
2.4.x (and 2.6.0-rc), and nea
28 matches
Mail list logo
