Hi,

FPC fixes_3_0, Linux X86:
"
var
 i1: int32;
begin
 for i1:= 0 to 5 do begin
  writeln(random(int32(-16)));
 end;
 writeln('*************');
 for i1:= 0 to 5 do begin
  writeln(random(int64(-16)));
 end;
end;
"

produces
"
-9
-9
-11
-13
-10
-13
*************
3
9
5
4
6
8
"
Is this intended? If not, which one is correct?
https://www.freepascal.org/docs-html/current/rtl/system/random.html states for 32 and 64 bit
"
Random returns a random number larger or equal to 0 and strictly less than L. "
which raises the question, what means "less"?

Martin

Martin Schreiber wrote

Is this intended? If not, which one is correct?

random(x) is undefined for negative parameters. It should have had an unsigned parameter, like in Turbo Pascal (where it is word). Delphi defines it as always returning a positive value, but I don't know what happens if you pass a negative parameter there.

Jonas

Martin Schreiber wrote

Hi, FPC fixes_3_0, Linux X86:"var i1: int32;begin for i1:= 0 to 5 do begin writeln(random(int32(-16))); end; writeln('*************'); for i1:= 0 to 5 do begin writeln(random(int64(-16))); end;end;" produces"-9-9-11-13-10-13*************395468"Is this intended? If not, which one is correct?https://www.freepascal.org/docs-html/current/rtl/system/random.htmlstates for 32 and 64 bit"Random returns a random number larger or equal to 0 and strictly less than L."which raises the question, what means "less"?

What does it do if the parameter is +ve? Note
https://mantis.freepascal.org/view.php?id=31693

Hello,

At least in 3.0 (trunk not tested as I don't have it compiled) the first and second random numbers are always the same value, so:

Randomize;
A:=Random(n);
B:=Random(n);

A and B will be always the same value.

Can someone with trunk test it ?

José Mejuto wrote

At least in 3.0 (trunk not tested as I don't have it compiled) the first and second random numbers are always the same value, so:

That is unrelated to this thread, but has been fixed in FPC 3.0.2.

Jonas

Jonas Maebe wrote

random(x) is undefined for negative parameters. It should have had an unsigned parameter, like in Turbo Pascal (where it is word). Delphi defines it as always returning a positive value, but I don't know what happens if you pass a negative parameter there.

I already reported that the documentation is a bit "off": https://bugs.freepascal.org/view.php?id=31642

Bart

Well, I waited to see if one of the designers would have answer it... you are not passing it a negative, nor is it responding with a negative. You are passing it with the high (MSR) bit on, Int32(-16) = 1000000000010000

The compiler is obviously type casting the result to Int32, showing as -9 etc.

I have noticed when working with Int64, FPC is actually working as UInt64 is some of my other projects.

My two cents.
O.

Jonas, sorry for the late response:

The implementation is _*not *_undefined for negative values,_unless you say that you define it as undefined_.

Because you seem to have implemented it or most of it.

It renders a mathematical comparable distribution in the negative to the positive values.

In both Turbo Pascal as in Delphi and because they use a different algorithm and made an implementation error as well, the negative values are indeed not defined. But that's because of the algorithm and because of the implementation by Borland (yes, it stems from Borland times).

The Mersenne Twister we use is also valid for negative values and if you want I can send you the mathematical proof.

I already made the LCG in Delphi compatible mode available on the wiki and that implementation differs in so far as that it corrects the "undefined for negative values" for that algorithm too. It is 100% compatible for the Delphi documented range, btw.

I am busy evaluating important Random implementions for different languages, so an FPC library is available for data that is generated in a different language and relies on a particular PRNG.

Also note that the output of the current random is strictly valid for 32 bit only.

In my code I already added a 64 bit version.

Regards,

Thaddy

Of course 64 and 32 bit are the sizes, not the platform! That may not be clear.

Thaddy de Koning wrote

The implementation is _*not *_undefined for negative values,_unless you say that you define it as undefined_.

That is exactly what "undefined" means: the implementation was not designed to handle such values, so whatever you get as a result is undefined.

Jonas