www.digitalmars.com         C & C++   DMDScript  

D - bitten by rand

reply Helmut Leitner <helmut.leitner chello.at> writes:
Recently I was bitten by rand from c.stdlib and phobos.random.
I meant to call the D version but called stdlib instead.

The problem is that the stdlib version is quite different:

import c.stdio;
import c.stdlib;
import random;

int main (char [][] args)
{
    for(int i=0; i<10; i++) {
       printf("c.stdlib.rand=%u\n",c.stdlib.rand());
    }

    for(int i=0; i<10; i++) {
       printf("random.rand=%u\n",random.rand());
    }
    return 0;
}

====
Output:

c.stdlib.rand=16838
c.stdlib.rand=5758
c.stdlib.rand=10113
c.stdlib.rand=17515
c.stdlib.rand=31051
c.stdlib.rand=5627
c.stdlib.rand=23010
c.stdlib.rand=7419
c.stdlib.rand=16212
c.stdlib.rand=4086
random.rand=2329848284
random.rand=966896356
random.rand=2223890246
random.rand=3572420830
random.rand=2088501916
random.rand=4169283756
random.rand=1218664906
random.rand=125222921
random.rand=1576103088
random.rand=4163571171

====

I think that there should be no D functions named identically. It will only
result in confusion or code drawn into a project from different sources for
the same purpose. (isdigit, ...)

If they are named identically they should behave identically.

BTW I think that no decent C compiler should have an anachronistic 
16-bit generator. 

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
May 06 2003
next sibling parent Chris Lawson <cl nospamhere.tinfoilhat.ca> writes:
Helmut Leitner wrote:

 
 I think that there should be no D functions named identically. It will only
 result in confusion or code drawn into a project from different sources for
 the same purpose. (isdigit, ...)


I don't think this is a good idea.  Isn't this what the namespaces are for?

Chris
May 06 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
What I'm going to do is (finally) implement the notion of a private import.
That should resolve most of this. Also, C's rand behavior is defined by the
C spec.
May 06 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Good.  Does that mean import a module, but *not* what it imports?  Or import
a module but its symbols aren't exported in this module's namespace?
So why does the C spec define it to have 16 bits?

Sean

"Walter" <walter digitalmars.com> wrote in message
news:b99f9b$phh$2 digitaldaemon.com...

 What I'm going to do is (finally) implement the notion of a private


import.

 That should resolve most of this. Also, C's rand behavior is defined by


the

 C spec.
May 06 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:b9a3o0$1ehc$1 digitaldaemon.com...

 Good.  Does that mean import a module, but *not* what it imports?


Yes.


  Or import
 a module but its symbols aren't exported in this module's namespace?
 So why does the C spec define it to have 16 bits?


It just solidified legacy practice.
May 07 2003
next sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Walter wrote:

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:b9a3o0$1ehc$1 digitaldaemon.com...
 

Good.  Does that mean import a module, but *not* what it imports?


 
 Yes.


Is it quite a safe practice?

I mean, maybe if a module imports another one, it may also also export 
symbols which rely on that import? Like, struct definition which 
includes a struct from an imported module would become unusable in 
another module?

Is it possible to just make an import inside a private section, which 
would mean that this imported module is not exported, but only available 
to the implementation of the module and does not make a part of its 
interface?

What syntax/semantics are you thinking of right now?


So why does the C spec define it to have 16 bits


 
 It just solidified legacy practice.


My Speccy 48 also had a 16-bit random. :>

-i.
May 09 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
No, the struct imported would be usable, as *it* has the imports visible.
By the time you use it, it's already defined fully.  But the user of the
struct could not also automatically use the contents of the imported module
used to build the struct, but only the stuff in the module containing the
struct itself.

I suppose template name lookup could be tricky for this.

Sean

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b9gp14$oo2$1 digitaldaemon.com...

 Walter wrote:

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:b9a3o0$1ehc$1 digitaldaemon.com...


Good.  Does that mean import a module, but *not* what it imports?


 Yes.


 Is it quite a safe practice?

 I mean, maybe if a module imports another one, it may also also export
 symbols which rely on that import? Like, struct definition which
 includes a struct from an imported module would become unusable in
 another module?

 Is it possible to just make an import inside a private section, which
 would mean that this imported module is not exported, but only available
 to the implementation of the module and does not make a part of its
 interface?

 What syntax/semantics are you thinking of right now?


So why does the C spec define it to have 16 bits


 It just solidified legacy practice.


 My Speccy 48 also had a 16-bit random. :>

 -i.
May 09 2003
prev sibling parent "C. Sauls" <ibisbasenji yahoo.com> writes:
Sounds good to me.. But a couple of questions.  First: would this be useful
in resolving some cycle problems, such as when module A depends on module B
which depends on module A?  Second, and I think it's been brought up
already, what syntax are you looking into?  Aka, would a module declare what
modules it wants hidden from its own dependants, or is it the other way
around?  Or, better yet, both?  I'm picturing something like this:

    module A;
    import B;              //normal
    import(local) C;    //invisible to dependants
    import(base) D;    //excludes D's dependancies

I'm not recommending the labels 'local' and 'base' neccessarily.. although I
do like local, but you get the idea.  And it still wouldn't hurt to allow
the module-aliasing and symbol-import ideas that've been brought up earlier,
a la 'import A as B;' and 'import A.MyClass;' the latter of which could
behave like a 'base' import that's specific to particular component of the
module.

 -- C. Sauls
May 19 2003
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> escribiσ en el mensaje
news:b9a3o0$1ehc$1 digitaldaemon.com...
| Good.  Does that mean import a module, but *not* what it imports?  Or
import
| a module but its symbols aren't exported in this module's namespace?
| So why does the C spec define it to have 16 bits?
|
| Sean
|

I guess I'd prefer the second one. The thing is that, for example, I can't
import both string and date because dmd says "date.d(351): function toString
conflicts with string.toString at string.d(1438)".
Like someone else said (I can't remember right now), I'd expect that at
least there wouldn't be any conflicts with names inside phobos.

—————————————————————————
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.478 / Virus Database: 275 - Release Date: 2003-05-06
May 11 2003
parent Andy Friesen <andy ikagames.com> writes:
Carlos Santander B. wrote:

 "Sean L. Palmer" <palmer.sean verizon.net> escribiσ en el mensaje
 news:b9a3o0$1ehc$1 digitaldaemon.com...
 | Good.  Does that mean import a module, but *not* what it imports?  Or
 import
 | a module but its symbols aren't exported in this module's namespace?
 | So why does the C spec define it to have 16 bits?
 |
 | Sean
 |
 
 I guess I'd prefer the second one. The thing is that, for example, I can't
 import both string and date because dmd says "date.d(351): function toString
 conflicts with string.toString at string.d(1438)".
 Like someone else said (I can't remember right now), I'd expect that at
 least there wouldn't be any conflicts with names inside phobos.
 


I like Python's way of handling imports.  Name conflicts simply aren't 
an issue.

import mod;

mod.method();      // fine
method();          // No good. You need the module name.

import mod.method; // "from mod import method" in Python
method()           // fine now

import mod.*;      // "from mod import *".  Imports everything into the
                    // current namespace

method();          // also fine

Any conflicts that may arise from importing directly into the current 
module namespace would be a compile error then and there, not when a 
conflicted symbol is actually used.
May 11 2003
prev sibling parent Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:

 ...
 Also, C's rand behavior is defined by the C spec.


No. 

The standard (C99, but I don't think anything changed) says:

  The rand function computes a sequence of pseudo-random integers
  in the range of 0 to RAND_MAX.

  RAND_MAX is at least 32767.

  ...

There is an *example* that has been considered harmfulby those that
actually use random numbers:

  int rand(void) {
     next = next * 1103515245 + 12345;
     return (unsigned int) (next/65536)%32768;
  }

because it has such a low quality.

No compiler builder is bound to this example and actually 
only a few have used it. E. g. Borland C provides a 32-bit
rand that passes the typical statistical tests without 
problems.

It is really easy to do because many good generators are available.

It is a quality of implementation issue.

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
May 06 2003