Re: [PHP-DEV] RFC: mt_* functions

[Jeroen van Wolffelaar]

> > Both function families are the same in syntax & returning, only the
> > algorithm is different. I.e.: the semantics is the same. The algorithm -
if
> > correct - shouldn't bother, and shouldn't be the concern of the
programmer,
> > but rather the system maintainer (specific cases excluded, but than you
> > leave the high-level of PHP, and go to low-level implementation
issues.).
>
> But they are different in that each will produce a deterministic sequence
> based on their seeds.  If I, as an application developer, distributes a
> regression test harness which tests my app with a specific seed expecting
> a specific sequence and the server my app runs on has switched rand() to
> use the mt_rand() algorithm my regression test will fail.

True... though IMHO a regression test is not strictly using PHP in a
high-level way, but goes into internal behaviour of it. In the
documentation, rand() is defined to "return a pseudo-random value between 0
and RAND_MAX". It states nothing about that the same seed yields the same
sequence.

True, this is the case in (almost) any pseudo-random-generator. But relying
on that behaviour is IMO using low-level implementation knowledge.
Of course, it is not forbidden to use that knowledge, but if you do, I
believe that it is your own responsibility to keep an eye on the changelog
when upgrading. And with a rand_generator = system setting, you actually
have a guarantee that the system's rand is used, with all it's properties.


I'm not denying that this change could break a script (though IMO it would
be rare). A solution would be to have it defaulted to 'system', and let the
mt_* functions always use mt, regardless of the ini-setting. By default, no
result will be different then, while still rand()'s behaviour is determined
by an ini-setting. In the end, it'd be best (IMO) to switch the default to
mt, and that change - though with less impact - has technically the same
consequences as turning register_globals off by default.

> This is somewhat like saying that we should make crypt() just be an alias
> for md5() since md5() is a better algorithm.  The fact that it is better
> is rather irrelevant since the output of the algorithm itself is sometimes
> important.  Many times you can swap crypt() for md5(), but many times you
> can't.  Same goes for rand() and mt_rand().

'somewhat like', indeed, since crypt is defined to use DES, and is targetted
at being the same on the same input. This definitely not the case with
rand(), it is a regretful consequence of the way computers work why it
sometimes can be predicted.

> -Rasmus
>
Jeroen


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RFC: mt_* functions

[Rasmus Lerdorf]

> >Sure, although rand() tends to be the same everywhere as well.  At least
> >on all the systems I care about it is the same.  Linux, FreeBSD, OpenBSD
> >and Solaris all seem to use the same algorithm.
>
> Then why do some people have troubles with rand() on Solaris? :)
> Or is it some specific version of it?

No idea.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RFC: mt_* functions

[Jani Taskinen]

On Sat, 4 Aug 2001, Rasmus Lerdorf wrote:

>> On Sat, 4 Aug 2001, Rasmus Lerdorf wrote:
>> >based on their seeds.  If I, as an application developer, distributes a
>> >regression test harness which tests my app with a specific seed expecting
>> >a specific sequence and the server my app runs on has switched rand() to
>> >use the mt_rand() algorithm my regression test will fail.
>>
>> So, if you always use mt_rand() you should be okay? Since the algorithm
>> for rand() might be different from system to system..?
>
>Sure, although rand() tends to be the same everywhere as well.  At least
>on all the systems I care about it is the same.  Linux, FreeBSD, OpenBSD
>and Solaris all seem to use the same algorithm.

Then why do some people have troubles with rand() on Solaris? :)
Or is it some specific version of it?

--Jani


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RFC: mt_* functions

[Rasmus Lerdorf]

> On Sat, 4 Aug 2001, Rasmus Lerdorf wrote:
> >based on their seeds.  If I, as an application developer, distributes a
> >regression test harness which tests my app with a specific seed expecting
> >a specific sequence and the server my app runs on has switched rand() to
> >use the mt_rand() algorithm my regression test will fail.
>
> So, if you always use mt_rand() you should be okay? Since the algorithm
> for rand() might be different from system to system..?

Sure, although rand() tends to be the same everywhere as well.  At least
on all the systems I care about it is the same.  Linux, FreeBSD, OpenBSD
and Solaris all seem to use the same algorithm.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RFC: mt_* functions

[Jani Taskinen]

On Sat, 4 Aug 2001, Rasmus Lerdorf wrote:
>based on their seeds.  If I, as an application developer, distributes a
>regression test harness which tests my app with a specific seed expecting
>a specific sequence and the server my app runs on has switched rand() to
>use the mt_rand() algorithm my regression test will fail.

So, if you always use mt_rand() you should be okay? Since the algorithm
for rand() might be different from system to system..?

--Jani


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RFC: mt_* functions

[Rasmus Lerdorf]

> Both function families are the same in syntax & returning, only the
> algorithm is different. I.e.: the semantics is the same. The algorithm - if
> correct - shouldn't bother, and shouldn't be the concern of the programmer,
> but rather the system maintainer (specific cases excluded, but than you
> leave the high-level of PHP, and go to low-level implementation issues.).

But they are different in that each will produce a deterministic sequence
based on their seeds.  If I, as an application developer, distributes a
regression test harness which tests my app with a specific seed expecting
a specific sequence and the server my app runs on has switched rand() to
use the mt_rand() algorithm my regression test will fail.

This is somewhat like saying that we should make crypt() just be an alias
for md5() since md5() is a better algorithm.  The fact that it is better
is rather irrelevant since the output of the algorithm itself is sometimes
important.  Many times you can swap crypt() for md5(), but many times you
can't.  Same goes for rand() and mt_rand().

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RFC: mt_* functions

[Jeroen van Wolffelaar]

> Please don't.  Ini settings that change semantics are a bother, and
> people should be able to choose their random function.

Both function families are the same in syntax & returning, only the
algorithm is different. I.e.: the semantics is the same. The algorithm - if
correct - shouldn't bother, and shouldn't be the concern of the programmer,
but rather the system maintainer (specific cases excluded, but than you
leave the high-level of PHP, and go to low-level implementation issues.).

>  - Stig

Jeroen



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RFC: mt_* functions

[Sterling Hughes]

At 11:15 PM 8/4/2001 +0200, Stig Sæther Bakken wrote:
>[<[EMAIL PROTECTED]>]
> > Hi,
> >
> > Currently, the rand_functions all have mt_ clones, which use a
> > in-PHP-implementation (Mersenne-Twister) rather than an external
> > implementation.
> >
> > This is IMHO a bit strange way of chosing between implementation. My
> > suggestion is to make it only one familiy of functions, the implementation
> > of which is determined by an ini-entry. (rand = system vs. rand = mt, or
> > something like that, default: mt).
> >
> > The functionality is the same (*), and IMO it's a per-system-decision 
> wether
> > you want to use the mt-algorithms or the system ones. (usually mt, unless
> > your system has a real good / very special one)
> >
> > For backwards compatibility, mt_* can be aliased to their normal
> > equivalents.
>
>Please don't.  Ini settings that change semantics are a bother, and
>people should be able to choose their random function.

+1 for the -1

(does that equal 0?)

-Sterling


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RFC: mt_* functions

[Stig Sæther Bakken]

[<[EMAIL PROTECTED]>]
> Hi,
> 
> Currently, the rand_functions all have mt_ clones, which use a
> in-PHP-implementation (Mersenne-Twister) rather than an external
> implementation.
> 
> This is IMHO a bit strange way of chosing between implementation. My
> suggestion is to make it only one familiy of functions, the implementation
> of which is determined by an ini-entry. (rand = system vs. rand = mt, or
> something like that, default: mt).
> 
> The functionality is the same (*), and IMO it's a per-system-decision wether
> you want to use the mt-algorithms or the system ones. (usually mt, unless
> your system has a real good / very special one)
> 
> For backwards compatibility, mt_* can be aliased to their normal
> equivalents.

Please don't.  Ini settings that change semantics are a bother, and
people should be able to choose their random function.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RFC: mt_* functions

[jeroen]

Hi,

Currently, the rand_functions all have mt_ clones, which use a
in-PHP-implementation (Mersenne-Twister) rather than an external
implementation.

This is IMHO a bit strange way of chosing between implementation. My
suggestion is to make it only one familiy of functions, the implementation
of which is determined by an ini-entry. (rand = system vs. rand = mt, or
something like that, default: mt).

The functionality is the same (*), and IMO it's a per-system-decision wether
you want to use the mt-algorithms or the system ones. (usually mt, unless
your system has a real good / very special one)

For backwards compatibility, mt_* can be aliased to their normal
equivalents.


Greetz,
Jeroen
(*) as far as you can speak of functionality in this context



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]