2011/12/7 Graeme Geldenhuys graemeg.li...@gmail.com:
Hi,
I did a simple GetTickCount() timing around this loop. Delphi executes
the loop in 20 ticks. FPC 2.6.0-rc2 takes 10585 ticks The outer
loop runs 200400 iterations. The types for BitValue, ByteValue and
RandSeed is of type Byte.
Am 09.12.2011 09:02, schrieb Vincent Snijders:
2011/12/7 Graeme Geldenhuys graemeg.li...@gmail.com:
Hi,
I did a simple GetTickCount() timing around this loop. Delphi executes
the loop in 20 ticks. FPC 2.6.0-rc2 takes 10585 ticks The outer
loop runs 200400 iterations. The types for
On 9 December 2011 10:02, Vincent Snijders wrote:
I have one question about this code, why is RandSeed set inside the
loop and not outside the loop or even at the program start?
For the full code as used by tiOPF, see the following URL.
On Fri, Dec 9, 2011 at 9:39 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
I didn't write this encryption code, I merely debugged why the unit
tests for this unit took so long to complete, compared to under
Delphi.
It is specifically written in the Delphi documentation that Random
should
- Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com schreef:
On Fri, Dec 9, 2011 at 9:39 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
I didn't write this encryption code, I merely debugged why the unit
tests for this unit took so long to complete, compared to under
On 09 Dec 2011, at 09:39, Graeme Geldenhuys wrote:
Looking at the code again, I have no idea how it will affect the
encryption algorithm if I move the assignment to RandSeed outside the
loop
It will improve the randomness of the generated numbers. Changing the
random seed all the time
- Graeme Geldenhuys graemeg.li...@gmail.com schreef:
On 9 December 2011 10:42, Felipe Monteiro de Carvalho wrote:
It is specifically written in the Delphi documentation that Random
should not be utilized for encryption...
Delphi documentation mentions a lot of things you mustn't
On Fri, 09 Dec 2011 07:27:46 +0100
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Reimar Grabowski schrieb:
The parameter should default to FALSE to not break existing code relying on
FPCs random function
And what about existing code coming from Delphi/Turbo Pascal? This was a
In our previous episode, Reimar Grabowski said:
Like people already said, lots of talk about a 'problem' that 10 years noone
has seen as one.
(it's afaik not the first. Has been noticed once or twice before. But those
people used it in unittests, and simply changed without much ado when the
On 9 December 2011 15:51, Reimar Grabowski wrote:
knowledge to back up your statements. Next time please take the time to
identify the problem correctly before jumping to conclusions.
No offense ment.
No offense take. Two unknown (to most) facts came out of this
discussion. 1) the FPC Random()
On 9 December 2011 12:42, Jonas Maebe wrote:
It will improve the randomness of the generated numbers.
Thanks Jonas.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
On 9 December 2011 12:50, Dimitri Smits wrote:
I actually doubt that that codesnippet does any real encryption.
It isn't. The sample code / test program I posted is just a snippet of
the actual unit. No point in posting the whole unit here, just to
point out that a single section of code in
Well, lets go to theory :
One way to build a cypher is to XOR the stream that must be encrypted
against a fixed value.
But, this is easy to break using statistical methods.
So the next logical way to do this is to XOR the stream against
another stream of numbers, kind of one time password.
even if FPC implemented a ultra high tech PRNG it would be compatible
with DELPHI :
1 - Delphi asserts that you should not use the Random function to
encryption porpuses.
2 - Delphi asserts no speed guarantees.
3 - Delphi asserts no randomness quality guarantees.
IE : to be compatible you only
On Thu, 08 Dec 2011 10:52:01 +0100, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
On 8 December 2011 11:33, Henry Vermaak wrote:
I agree, quality first.
I would normally agree with that. But such huge magnitudes slower
(20ms vs 10585ms) on a new Quad-Core type system? That just seems
On 9 December 2011 19:55, Jorge Aldo G. de F. Junior wrote:
Well, lets go to theory :
In case you didn't notice the unit name this code comes from
tiEncryptSimple.pas
The name should be a good enough hint that it wasn't meant for
real-world apps. ;-) For real-world apps, tiOPF has other
On 9 December 2011 20:54, wrote:
In europe electricity is sometimes 220 volts. Twice as fast as 110 volts
in Canada, but I'm not sure about africa ;-)
:-) South Africa uses 220 volts too.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform
On 8 December 2011 09:50, Florian Klaempfl wrote:
Actually those who depend on speed should have spoken up ten years ago
when the MT was implemented.
I for one did not even know about the existence of Free Pascal 10 year
ago. I don't believe I am alone either.
On a side note:
As for Jonas
In our previous episode, Graeme Geldenhuys said:
And what about people using FPC only and depending on our Random being
statistically strong, they are less important then theorical Delphi
migrants?
[like what was told to me numerous times before] They (FPC users)
should speak up now, or
Am 08.12.2011 09:03, schrieb Graeme Geldenhuys:
On 8 December 2011 09:50, Florian Klaempfl wrote:
Actually those who depend on speed should have spoken up ten years ago
when the MT was implemented.
I for one did not even know about the existence of Free Pascal 10 year
ago. I don't believe
On 8 December 2011 10:04, Marco van de Voort wrote:
It's a strange case where people are advocating the introduction of a slower
manager to improve the speed of random :-)
It's called an acceptable compromise, by those that use it most.
Just like FPC doesn't do micro code optimizations on
On 8 December 2011 10:08, Florian Klaempfl wrote:
dicussed it years ago might not followed up this mailing list anymore
but just use it so they cannot speak up today either.
That's their loss.
--
Regards,
- Graeme -
___
fpGUI - a
2011/12/8 Graeme Geldenhuys graemeg.li...@gmail.com:
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
On 08/12/11 09:13, Vincent Snijders wrote:
2011/12/8 Graeme Geldenhuysgraemeg.li...@gmail.com:
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
On 8 December 2011 11:33, Henry Vermaak wrote:
I agree, quality first.
I would normally agree with that. But such huge magnitudes slower
(20ms vs 10585ms) on a new Quad-Core type system? That just seems a
bit excessive, and considering most use cases are not even for
statistical type
Hi,
On 8/12/2011 9:48 πμ, 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 the
On Thu, December 8, 2011 08:48, Graeme Geldenhuys wrote:
On 8 December 2011 09:25, Felipe Monteiro de Carvalho wrote:
.
.
And what about people using FPC only and depending on our Random being
statistically strong, they are less important then theorical Delphi
migrants?
[like what was told
2011/12/8 Tomas Hajny :
Anyway: some people expressed their wish to keep the current solution as
the default option exactly like you suggested,
Did I suggest this?
and you still argue with
them that their view is not valid - strange...
Clearly somewhere our lines have crossed. Strange
On Thu, December 8, 2011 16:08, Graeme Geldenhuys wrote:
2011/12/8 Tomas Hajny :
Anyway: some people expressed their wish to keep the current solution as
the default option exactly like you suggested,
Did I suggest this?
.
.
Sorry, I wasn't clear - you suggested that people interested in
On 12/8/2011 02:48, Graeme Geldenhuys wrote:
On 8 December 2011 09:25, Felipe Monteiro de Carvalho wrote:
And what about people using FPC only and depending on our Random being
statistically strong, they are less important then theorical Delphi
migrants?
[like what was told to me numerous
On 8 December 2011 19:51, waldo kitty wrote:
fastrandom boolean parameter that is passed? if the parameter is not
passed, it is defaulted to TRUE... if one wants the MT random, then they
send FALSE in this parameter... seems simple enough... i think ;)
That sounds perfect to me, but now will
My Delphi's random is only 7 times faster then fpc's random (Celeron 700).
Bart
On 12/8/11, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Tomas Hajny said:
the default option exactly like you suggested,
Did I suggest this?
Sorry, I wasn't clear - you suggested that
Reimar Grabowski schrieb:
The parameter should default to FALSE to not break existing code relying on FPCs random function
And what about existing code coming from Delphi/Turbo Pascal? This was a
strong argument in the past for doing even crap coding.
As the fast random function then has
Am 09.12.2011 07:27, schrieb Jürgen Hestermann:
Reimar Grabowski schrieb:
The parameter should default to FALSE to not break existing code
relying on FPCs random function
And what about existing code coming from Delphi/Turbo Pascal? This was a
strong argument in the past for doing even
On 9 December 2011 09:47, Florian Klaempfl wrote:
According to measurements of me and other peoples, random is only 7-10
times slower (depending on the CPU).
What do you feed your computer, because mine differs vastly from yours.
Not to mention that our clients still run P4 workstations under
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
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
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 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 is
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
2011/12/7 Peter pe...@pblackman.plus.com:
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.
--
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 inouss...@gmail.com wrote:
2011/12/7 Peter pe...@pblackman.plus.com:
Graeme,
I would
On 7 December 2011 15:54, Peter 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.
On 7 December 2011 14:54, Jonas Maebe 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
Am 07.12.2011 16:03, schrieb Graeme Geldenhuys:
On 7 December 2011 14:54, Jonas Maebe 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.
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.
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
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
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 performance
- Jürgen Hestermann juergen.hesterm...@gmx.de 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
--
On 7 December 2011 19:31, Jürgen Hestermann juergen.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
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
On Thu, Dec 8, 2011 at 7:27 AM, Jürgen Hestermann
juergen.hesterm...@gmx.de 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
Am 08.12.2011 08:25, schrieb Felipe Monteiro de Carvalho:
On Thu, Dec 8, 2011 at 7:27 AM, Jürgen Hestermann
juergen.hesterm...@gmx.de 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
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: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.
___
56 matches
Mail list logo
