Thread overview | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 30, 2004 contracts on abstract class members? | ||||
---|---|---|---|---|
| ||||
I'm currently working reimplementing some of my old C++ libraries to D. I have a family of random number generator classes (using different algorithms) all extending an abstract base class. I want to make sure the random generator never produces a value outside the interval 0..1 by putting an out {} contract in the abstract class, but D apparently can't do this. # abstract class Random # { # abstract double random(); # // This doesn't work # out(result) { assert( (result > 0) && (result < 1) ); } # } Does anybody know if this is possible? Nick |
July 31, 2004 Re: contracts on abstract class members? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick | Nick wrote:
> I'm currently working reimplementing some of my old C++ libraries to D. I have a
> family of random number generator classes (using different algorithms) all
> extending an abstract base class. I want to make sure the random generator never
> produces a value outside the interval 0..1 by putting an out {} contract in the
> abstract class, but D apparently can't do this.
>
> # abstract class Random
> # {
> # abstract double random();
> # // This doesn't work
> # out(result) { assert( (result > 0) && (result < 1) ); }
> # }
>
> Does anybody know if this is possible?
>
> Nick
>
This is what you want:
------------------------------
abstract class Random {
abstract double random()
out(result) {
assert(result > 0 && result < 1);
}
;
}
------------------------------
The semi-colon comes after any contract blocks.
-Chris S.
-Invironz
|
July 31, 2004 Re: contracts on abstract class members? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick | Nick wrote: > I'm currently working reimplementing some of my old C++ libraries to D. I have a > family of random number generator classes (using different algorithms) all > extending an abstract base class. I want to make sure the random generator never > produces a value outside the interval 0..1 by putting an out {} contract in the > abstract class, but D apparently can't do this. ... > Does anybody know if this is possible? Contracts aren't inherited in D at the moment. I believe this was originally intended and just hasn't been implemented yet. Sam |
July 31, 2004 Re: contracts on abstract class members? | ||||
---|---|---|---|---|
| ||||
Posted in reply to C. Sauls | In article <cef15o$fan$1@digitaldaemon.com>, C. Sauls says... >This is what you want: > >------------------------------ >abstract class Random { > abstract double random() > out(result) { > assert(result > 0 && result < 1); > } > ; >} Thank you! I was sure I had tried that, but obviously I hadn't. Oh well. :) Nick |
July 31, 2004 Re: contracts on abstract class members? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sam McCall | In article <cef2ap$frs$1@digitaldaemon.com>, Sam McCall says... > >Contracts aren't inherited in D at the moment. I believe this was >originally intended and just hasn't been implemented yet. >Sam Looks like you're right :-( I hope it *does* get implemented though, it's a good feature IMHO. Nick |
August 01, 2004 Random Numbers (was contracts on abstract class members?) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick | In article <ceeglr$64h$1@digitaldaemon.com>, Nick says... > >I'm currently working reimplementing some of my old C++ libraries to D. I have a family of random number generator classes (using different algorithms) all extending an abstract base class. I have something similar in the pipeline, but my approach is different. The random number classes only need to return random bits. In addition to the random number classes, I have a RandomStream, derived from std.stream.Stream, which you can construct from a random number generator class. Now, if r is a RandomStream, you can use the various r.read() functions to assign floats, doubles, etc.. The code implementing those RandomStream.read() functions ensures that the result is always >=0 and <1. This is, I think, a more flexible approach (feel free to disagree) and it plumbs in nicely with my EntropyProvider classes, enabling users to put together /true/ (not just pseudo) random number generators. There are other filters (for example) to unbias a biased bitstream, provide forward security on demand etc., all very necessary functions in security applications. I'm a little behind schedule right now, but my plans are to finish etc.unicode stage one by next weekend; then fix some bugs in Int; and then get back to etc.random - the random number stuff (which is going to be part of the crypto toolkit). So I guess maybe I'll be back working on it in, say, two weeks. Would it make sense for us to work together on this? For me, the most important part is the flexible architecture, entropy handling and security stuff. If you could live with my architecture, might it be possible to plumb your algorithms into that? If you are happy with that, it would actually really speed up the process. Arcane Jill |
August 01, 2004 Re: Random Numbers (was contracts on abstract class members?) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane Jill | Arcane Jill wrote: > In article <ceeglr$64h$1@digitaldaemon.com>, Nick says... > >>I'm currently working reimplementing some of my old C++ libraries to D. I have a >>family of random number generator classes (using different algorithms) all >>extending an abstract base class. > > > I have something similar in the pipeline, but my approach is different. The > random number classes only need to return random bits. In addition to the random > number classes, I have a RandomStream, derived from std.stream.Stream, which you > can construct from a random number generator class. Now, if r is a RandomStream, > you can use the various r.read() functions to assign floats, doubles, etc.. The > code implementing those RandomStream.read() functions ensures that the result is > always >=0 and <1. My fixed point routines are based on the types per and uper which are 0<=...<1 and -1<...<1 . (So named because I do not know of a better name for variables that are in these ranges.) Perhaps if I figure out why -1*1/2 == 0 and fix that they might be of use. > > This is, I think, a more flexible approach (feel free to disagree) and it plumbs > in nicely with my EntropyProvider classes, enabling users to put together /true/ > (not just pseudo) random number generators. There are other filters (for > example) to unbias a biased bitstream, provide forward security on demand etc., > all very necessary functions in security applications. I think it sounds briliantly designed. > > I'm a little behind schedule right now, but my plans are to finish etc.unicode > stage one by next weekend; then fix some bugs in Int; What sort of primality related functionaly will Int have? |
August 01, 2004 Int primality (was Random Numbers) | ||||
---|---|---|---|---|
| ||||
Posted in reply to parabolis | In article <cejei8$2ap9$1@digitaldaemon.com>, parabolis says... >What sort of primality related functionaly will Int have? Int has actually been finished for a while. It's in Deimos, not Phobos. (There are some outstanding bugs but nothing you can't work around, and I'll be fixing those soon anyway). For Int itself, there is a function isProbablyPrime() which uses the Legendre algorithm to eliminate non-primes for as many rounds as are desired. The probability of isProbablyPrime() incorrectly declaring false is zero; the probability of isProbablyPrime() incorrectly declaring true is vanishingly small. There are also functions like getProbablePrimeGreaterEqual(), and so on. For plain uints, the module etc.prime (shortly to be renamed etc.math.prime), which you get as part of the Int download, there is a function isPrime() which is never wrong, and functions like getPrimeGreaterEqual() to complete the set. Arcane Jill |
August 01, 2004 Re: Random Numbers (was contracts on abstract class members?) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane Jill | In article <cejcng$2a5i$1@digitaldaemon.com>, Arcane Jill says... > >Would it make sense for us to work together on this? For me, the most important part is the flexible architecture, entropy handling and security stuff. If you could live with my architecture, might it be possible to plumb your algorithms into that? If you are happy with that, it would actually really speed up the process. > >Arcane Jill > The algorithms I have are nothing fabulous, really. I mainly use them in scientific projects, where pseudo-randomness is ok. The most important quality is low autocorrelation (avoiding repeating patterns), but also speed. My various algorithms are really just different trade-offs between these two. Besides I'm hardly an expert on random generators :) Nick |
August 02, 2004 Re: Int primality (was Random Numbers) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane Jill | Arcane Jill wrote: > In article <cejei8$2ap9$1@digitaldaemon.com>, parabolis says... > > >>What sort of primality related functionaly will Int have? > > > Int has actually been finished for a while. It's in Deimos, not Phobos. (There > are some outstanding bugs but nothing you can't work around, and I'll be fixing > those soon anyway). Aha! I have found Deimos at dsource.org. > > For Int itself, there is a function isProbablyPrime() which uses the Legendre > algorithm to eliminate non-primes for as many rounds as are desired. The > probability of isProbablyPrime() incorrectly declaring false is zero; the > probability of isProbablyPrime() incorrectly declaring true is vanishingly > small. There are also functions like getProbablePrimeGreaterEqual(), and so on. > > For plain uints, the module etc.prime (shortly to be renamed etc.math.prime), > which you get as part of the Int download, there is a function isPrime() which > is never wrong, and functions like getPrimeGreaterEqual() to complete the set. > I poked around in primes.d and glanced over the Int docs. I have a couple notes about the primes.d implementation. I was quite impressed with the fact your lookup table is half the size of a full binary Eratosthenes sieve. That is probably the smallest table which contains all primes from 0...2^16 and can still be searched without any multiplicatoin or division (excluding shifts). I also liked this loop: for (n=(n|1)-2; n!=1; n-=2) However I could not help playing with the loop in isPrime() over all non-short values from 0x10000 to 0xFFFFFFFF. I eliminated the function calls, unrolled the loop to take better advantage of the pipeline and check almost half the numbers you were checking (now 8 in 30 instead of 15 in 30 - for fun figure out why I can do this). If you (meaning anybody reading this) want to view or use the modifications then send me an email and I will send the new version to you. The reason I asked about the primality was because I have a passing fancy in primality implementations and I was kind of assuming (or hoping) you would be implementing the new "Primes is in P" algorithm along with a linear time perfect power detector and Knuth's new Fast-Fourier Multiplication. I am considering playing around with an implementation of this for isPrime(ulong). On a somewhat related note... Another reason I was interested in what you are doing with the Int class is that my first impressions of Phobos were being underwhelmed and disdain at the (possibly misleading) appreance that things are just being tossed in without attempting to guess where they will likely clash with future additions. At the time I mapped out this bit for the math library: std.math.big std.math.complex std.math.imaginary std.math.integer std.math.fixed std.math.real std.math.symbolic Ever since then I have been curious where the functions to fill those libraries will come from. |
Copyright © 1999-2021 by the D Language Foundation