Date: Mon, 7 Oct 1996 11:10:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: ache@nagual.ru (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Cc: terry@lambert.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.org, current@FreeBSD.org, bde@zeta.org.au Subject: Re: I plan to change random() for -current (was Re: rand() and random()) Message-ID: <199610071810.LAA14432@phaeton.artisoft.com> In-Reply-To: <199610071720.VAA01227@nagual.ru> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 7, 96 09:20:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Repeatability means identical results compared to historical values > > for the same interface. > > We must follow standards and not some bad programmer practice. > The fix I mean confirm standards. The thing you want not described > in any standard and no more that bad programmer assumption. Bullshit. It says right in the man page that it is a pseudo-random number generator, and there is an interface for setting the seed value. I have every right to expect the thing to produce repeatable values over time. > I suspect (I'll try to check it in near time) that BSD random() > change its formulae in BSD lifetime. Not without notification it hasn't, and not without publicaton of the prevous algorithm. For a long time, the Berkeley code had an integrer overflow based random generator included with the package. It was found to be unreliable because of differences in number of bits. > > The particular code in question uses the 48 bit linear congruential > > method. However, it is reasonable to presume that similar code exists > > for any given interface dependency. > > rand48 family is different thing which I not plan to touch. That is not the point. The point is that there is a random function that is documented as being pseudo-random and which has a settable seed value, and neither you nor I can believably claim that the random number generator is not depended upon in this way for someone's important work. Work a hell of a lot more important than satisfying some programmer's idea of correct aesthetics. > > you want a different (not better) random distribution than what you > > currently get. > > I don't change random distribution at all with this fix, please > look at it more carefully. I change only initial seeding behaviour. If I call srandom with the same values I have historically called it with, will I get the same results I have hostorically gotten? If so, I withdraw my objection; if not I maintain and reaffirm it. > Well, it sounds like "golden code" syndrome.... It *is* "golden code syndrome". That doesn't make it any less of a valid argument. > We already do this thing before and I don't see your complaints. > I mean Bruce's fixes to math library precision f.e. > All math calculations which uses affected function will produce > different results! All physic experiments becomes not-repeatable! > Etc. And you keep silence it that case I don't understand why. As I said, comparison is impossible. Luckily, the experiments have been run on Sun Hardware, and the FreeBSD hardware was only used for the FORTRAN to C conversion process, and not for real results. If you want FreeBSD to be trusted for this kind of work, you must correct your process and assumptions. Much of the NetBSD math lib work results in a cleanup of many of these issues, and is portable to FreeBSD. Using the NetBSD code and the Sun libm code, the results were identical to those obtained on the Sun (for a single comparison, anyway) and the Sun's results identical to those obtained on the CDC and Cray systems at Los Alamos and on the KL-10/KL-11 based DEC 10 and 20 systems on which the code has also been run. It *is* "golden code syndrome". Where we seem to disagree is in deciding if this is a bad thing or not. Unless you are a mathematical programmer, you are unlikely to be able to aprehend the consequences of even a trivial change away from mathematical standards will have. There are verifiable standards of correctness, and each standard dictates issues of precision to which one can trust the code. Obviously, differences after the significant digits can be ignored for comparison -- and are, in fact, stripped from results as the "noise" that they are. I suggest strict adherence to standards -- mathematical standards, not ANSI or ISO C standards -- with regard to maintaining precision and historical implementation, as required to ensure repeatability and trust. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610071810.LAA14432>