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 F
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 en
On Thu, 08 Dec 2011 10:52:01 +0100, Graeme Geldenhuys
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 a
bit excessive, and con
> 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.
>
In europe electricity is sometimes 220 volts. Twice
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 ne
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.
But,
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 o
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 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 Rando
On Fri, 9 Dec 2011 10:47:15 +0200
Graeme Geldenhuys wrote:
> Like I said, I didn't write that code, and I don't specialise in
> encryption algorithms.
That's not your fault. Your fault was to not identify the problem correctly but
blame FPCs implementation and later rant about "double standards"
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
p
On Fri, 09 Dec 2011 07:27:46 +0100
Jürgen Hestermann 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
> strong argument in
- "Graeme Geldenhuys" 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 do... Does
> t
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 remov
- "Felipe Monteiro de Carvalho" schreef:
> On Fri, Dec 9, 2011 at 9:39 AM, Graeme Geldenhuys
> 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 th
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 do... Does
that stop anybody. ;-)
Like I said, I didn't write th
On Fri, Dec 9, 2011 at 9:39 AM, Graeme Geldenhuys
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 not be utilized 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.
http://tiopf.svn.sourceforge.net/viewvc/tiopf/tiOPF
Am 09.12.2011 09:02, schrieb Vincent Snijders:
> 2011/12/7 Graeme Geldenhuys :
>> 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
Am 09.12.2011 08:59, schrieb Graeme Geldenhuys:
> 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,
Nothing, but I don't mess with things I don
2011/12/7 Graeme Geldenhuys :
> 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.
>
> 01 for Index :=
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 und
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 doin
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 t
Why don't refactoring the slow RTL random to MyRandom so you can switch? You
can do it in a few miniutes.
In my opinion the current RTL random function should not change, because
other FPC developers are depend on current code base.
But a fast random or other random implementation should put into
My Delphi's random is only 7 times faster then fpc's random (Celeron 700).
Bart
On 12/8/11, Marco van de Voort 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 p
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 people interested in keeping
> the current solution raised their voice (which at least Felipe and
> Karl-Michael did).
And me.
On Thu, 08 Dec 2011 12:51:18 -0500
waldo kitty wrote:
> i wouldn't say specifically place it in the maths unit but what's wrong with
> having both available via a "fastrandom" boolean parameter that is passed? if
> the parameter is not passed, it is defaulted to TRUE... if one wants the MT
> r
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 w
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 tim
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 intereste
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 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
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 statistic
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 applicat
On 08/12/11 09:13, Vincent Snijders wrote:
2011/12/8 Graeme Geldenhuys:
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
2011/12/8 Graeme Geldenhuys :
> 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 us
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 cross-platf
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 o
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
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
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 d
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
- "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
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
68 matches
Mail list logo
