[Mono-dev] Mono-basic does not build under Solaris x86 in latest mono-2-6 branch
my previous issue in Solaris-Sparc was resolved - but this problem occurs in Solaris 10 x86 while building mono-basic: make[3]: Entering directory `/Desktop/dev/mono-2-6/mono-basic/vbnc/vbnc' MONO_PATH="../../class/lib/bootstrap:$MONO_PATH" mono --debug ../../class/lib/bootstrap/vbnc.exe @vbnc.exe.rsp-debug -target:exe -out:vbnc.exe @vbnc.exe.sources GC Warning: Large stack limit(133464064): only scanning 8 MB Visual Basic.Net Compiler version 0.0.0.5917 Copyright (C) 2004-2008 Rolf Bjarne Kvinge. All rights reserved. /Desktop/dev/mono-2-6/mono-basic/vbnc/vbnc/source/Statements/ReDimStatement.vb (1,1) : Error VBNC31007: CHANGEME /Desktop/dev/mono-2-6/mono-basic/vbnc/vbnc/source/Statements/ReDimStatement.vb (1,2) : Error VBNC9: vbnc crashed nearby this location in the source code. /Desktop/dev/mono-2-6/mono-basic/vbnc/vbnc/source/Statements/ReDimStatement.vb (1,2) : Error VBNC9: Unexpected error: Object reference not set to an instance of an object at vbnc.Scanner.NextChar () [0x00069] in :0 at vbnc.Scanner.NextFile () [0x0009f] in :0 at vbnc.Scanner.NextUnconditionally () [0x00055] in :0 at vbnc.Scanner.Next () [0x0] in :0 at vbnc.tm.NextToken () [0x000f4] in :0 at vbnc.tm.AcceptEndOfFile () [0x00010] in :0 at vbnc.Parser.ParseAssemblyDeclaration (System.String RootNamespace, vbnc.AssemblyDeclaration assembly) [0x000c7] in :0 at vbnc.Parser.Parse (System.String RootNamespace, vbnc.AssemblyDeclaration assembly) [0x2] in :0 at vbnc.Compiler.Compile_Parse () [0x0006d] in :0 Compilation took 00:00:02.5829790 INTERNAL configuration error: failed to get configuration 'system.diagnostics' at System.Diagnostics.DiagnosticsConfiguration.get_Settings () [0x00051] in :0 at System.Diagnostics.TraceImpl.InitOnce () [0x00020] in :0 at System.Diagnostics.TraceImpl.get_Listeners () [0x0] in :0 at System.Diagnostics.TraceImpl.get_ListenersSyncRoot () [0x0] in :0 at System.Diagnostics.TraceImpl.WriteLine (System.String message) [0x0] in :0 at System.Diagnostics.Debug.WriteLine (System.String message) [0x0] in :0 at vbnc.Main.Main (System.String[] CmdArgs) [0x0003e] in :0 Failed compilation took 00:00:02.6059880 GLib: Cannot convert message: Conversion from character set 'UTF-8' to 'ASCII' is not supported Unhandled Exception: System.Exception: INTERNAL configuration error: failed to get configuration 'system.diagnostics' at System.Diagnostics.DiagnosticsConfiguration.get_Settings () [0x00051] in :0 at System.Diagnostics.TraceImpl.InitOnce () [0x00020] in :0 at System.Diagnostics.TraceImpl.get_Listeners () [0x0] in :0 at System.Diagnostics.TraceImpl.get_ListenersSyncRoot () [0x0] in :0 at System.Diagnostics.TraceImpl.WriteLine (System.String message) [0x0] in :0 at System.Diagnostics.Debug.WriteLine (System.String message) [0x0] in :0 at vbnc.Main.Main (System.String[] CmdArgs) [0x00145] in :0 make[3]: *** [../../class/lib/vbnc/vbnc.exe] Error 1 make[3]: Leaving directory `/Desktop/dev/mono-2-6/mono-basic/vbnc/vbnc' make[2]: *** [do-all] Error 2 make[2]: Leaving directory `/Desktop/dev/mono-2-6/mono-basic/vbnc/vbnc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/Desktop/dev/mono-2-6/mono-basic/vbnc' make: *** [all-recursive] Error 1 bash-3.00# -- View this message in context: http://n4.nabble.com/Mono-basic-does-not-build-under-Solaris-x86-in-latest-mono-2-6-branch-tp1595727p1595727.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SIGSERV in 'mono_arch_get_llvm_call_info' when using up-to-date Mono+LLVM
Hi, This is fixed now in SVN. Zoltan On Tue, Mar 16, 2010 at 4:52 PM, Sergei Dyshel wrote: > Hello, > I get SIGSERV (from mono_arch_get_llvm_call_info at mini-x86.c:1224) > when trying to compile attached example with Mono + LLVM backend. > Both Mono and LLVM updated today: > Mono revision: 153681 > LLVM revision: 98629 > Code, exe and dump are attached. > > This errors happens when when non-static methods have no arguments and > then 'sig->params [i - sig->hasthis]' leads to sig->params[-1] hence > the fault. > Any ideas? > -- > Regards, > Sergei Dyshel > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with System.Random
Hello, > As already said I didn't test and can't comment but keep in mind that the > Random class is used (real-world) under VERY specific situations and none of > them are near random. I am not sure about this. I looked through the svn log for the commits to the Random class, and I can not find any reverted patches to the Random class. In fact, I found a commit that explicitly stated "Switch to Knuth results instead of Microsoft ones". Unless someone has some strong evidence and a regression report on the Random class, I see no problem with replacing our Random implementation with something better (provided the other issuelets have been resolved). But it seems to me that there is a very weak case for regressions in the Random class. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with System.Random
In Text
>Andreas Nahr wrote:
>> I won't comment on the algorithm itself (keep in mind that the existing
one
>> already was replaced once with a "better" one which failed miserably in
real
>> world apps, so had to be reverted).
>I tested a sequence of 68 million 32-bit values for randomness using the
Diehard test suite. Of course this is only a
>heuristic indicator that the sequence has good random characteristics, not
a proof. However, the current implementation
>does not pass (some of) those tests, i.e. there exist cases where it
exhibits bad random characteristics.
As already said I didn't test and can't comment but keep in mind that the
Random class is used (real-world) under VERY specific situations and none of
them are near random. That starts with the initialization to
Environment.Tickcount which IS going to deliver a "relatively" small set of
states in 99% of all cases. On the other hand an initialization with 0 or -1
is probably just about never going to happen (Because it would only happen
for 2 Milliseconds after 50 days of continuous computer uptime).
>> But your patch adds errors for exceptions (which were mostly correct
>> before).
>What errors are you referring to? As far as I can see, all exceptions
mandated by the specification of System.Random are
>thrown (and tested).
>By the way, I forgot the "Locale.GetText()" for the exception messages.
+ throw new ArgumentNullException ("buffer is
null.");
is clearly an error. First parameter is the argument name, not some
descriptive text.
>> And the unit-tests are no "unit-tests". They don't test the
>> implementation against the specification, they test the implementation
>> against the implementation which is useless.
>
>I disagree. The expected values were not generated by my implementation,
but by this reference implementation of the
>algorithm (compiled for 32-bit machines):
I can understand your point, but this means that your ARE testing
implementation against implementation. It might be good for testing if you
correctly implemented your algorithm, but it is imho not suited to test if
it is a conforming CLR/.Net implementation (in fact if you would use it on
MS.Net it would fail completely and if you use it on current mono it would
also fail).
>> And moreover you removed ALL
>> Random() constructor tests which most likely are the only of relevance to
>> real-world applications.
>
>Yes, I forgot this one. However, there's not much you can test for (except
that it doesn't throw an exception): the
>state is private, so it can't be checked directly; the value of
Environment.TickCount() might change between reading it
Well you can at LEAST test all the provided Next() methods with something
similar than you have written.
Greetings
Andreas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with System.Random
Kornél Pál wrote: > Also note that this patch seems to break serialization compatibility > that might be a problem for some applications. That is indeed a problem. However, it should be sufficient to load the state and xor it with the default state if the serialized object is the old version. Is that possible? Best regards, Adrian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with System.Random
Andreas Nahr wrote:
> I won't comment on the algorithm itself (keep in mind that the existing one
> already was replaced once with a "better" one which failed miserably in real
> world apps, so had to be reverted).
I tested a sequence of 68 million 32-bit values for randomness using the
Diehard test suite. Of course this is only a
heuristic indicator that the sequence has good random characteristics, not a
proof. However, the current implementation
does not pass (some of) those tests, i.e. there exist cases where it exhibits
bad random characteristics.
> Also a newsgroup as source doesn't sound reliable at all.
Indeed, but the algorithm is based on the paper "Xorshift RNGs" by George
Marsaglia, published in Journal of Statistical
Software, 2003; http://www.jstatsoft.org/v08/i14/paper .
> But your patch adds errors for exceptions (which were mostly correct
> before).
What errors are you referring to? As far as I can see, all exceptions mandated
by the specification of System.Random are
thrown (and tested).
By the way, I forgot the "Locale.GetText()" for the exception messages.
> And the unit-tests are no "unit-tests". They don't test the
> implementation against the specification, they test the implementation
> against the implementation which is useless.
I disagree. The expected values were not generated by my implementation, but by
this reference implementation of the
algorithm (compiled for 32-bit machines):
static unsigned long x=123456789,y=362436069,z=521288629,w=88675123,v=886756453;
unsigned long xorshift(void)
{
unsigned long t=(x^(x>>7)); x=y; y=z; z=w; w=v;
v=(v^(v<<6))^(t^(t<<13)); return (y+y+1)*v;
}
You could insist on calculating the expected values using pen and paper with
binary vectors and matrices of size
160x160, but it is pretty simple to proof that xorshifts correspond to the
addition of an identity matrix to an
L^a/R^a-matrix (the theory behind this RNG), so comparing against the output of
the reference function should be
sufficient to show that the class correctly implements the algorithm.
As for showing that the algorithm itself fulfills the specification: you can
proof that the output is uniformly
distributed, and you can run statistical tests to make sure (to a certain
degree) that the algorithm behaves in a random
way. There is nothing more you can do (except for running more statistical test
suites on longer outputs).
The old unit tests are actually rather poor: they don't test for a uniform
distribution; the only test for the expected
value of the random variable is commented out because it is unreliable
(NextDouble ()); and no statistical properties
are tested. None of that can actually be done well using unit tests, so the
best way I can think of is to extensively
test the algorithm, and then compare the implementation against the algorithm.
If you know a better approach, let me know :-)
> And moreover you removed ALL
> Random() constructor tests which most likely are the only of relevance to
> real-world applications.
Yes, I forgot this one. However, there's not much you can test for (except that
it doesn't throw an exception): the
state is private, so it can't be checked directly; the value of
Environment.TickCount() might change between reading it
and calling new Random(); and it is so simple, that it hardly does anything. So
how about
[Test]
public void Constructor1()
{
var rng = new Random();
for(var i = 0; i < 100; ++i)
Assert.That(rng.Next(), Is.GreaterThanOrEqualTo(0));
}
Best regards,
Adrian
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] SIGSERV in 'mono_arch_get_llvm_call_info' when using up-to-date Mono+LLVM
Hello, I get SIGSERV (from mono_arch_get_llvm_call_info at mini-x86.c:1224) when trying to compile attached example with Mono + LLVM backend. Both Mono and LLVM updated today: Mono revision: 153681 LLVM revision: 98629 Code, exe and dump are attached. This errors happens when when non-static methods have no arguments and then 'sig->params [i - sig->hasthis]' leads to sig->params[-1] hence the fault. Any ideas? -- Regards, Sergei Dyshel cs-sum.cs Description: Binary data cs-sum.err.log Description: Binary data cs-sum.rename-to-exe Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Method code injection
Thanks, Rodrigo. I'll try this out!
On Sat, Mar 13, 2010 at 6:14 AM, Rodrigo B. de Oliveira <
rodrigobam...@gmail.com> wrote:
> Hey Amir!
>
> Yes, you can use Mono.Cecil:
>
>import System
>import Mono.Cecil
>import Mono.Cecil.Cil
>
>pathToAssembly = "/tmp/test.exe"
>asm = AssemblyFactory.GetAssembly(pathToAssembly)
>
>module = asm.MainModule
>method = module.Types["Program"].Methods.GetMethod("Main")[0]
>
>worker = method.Body.CilWorker
>firstInstruction = method.Body.Instructions[0]
>worker.InsertBefore(firstInstruction, worker.Create(OpCodes.Ldstr,
> "Hello!"))
>worker.InsertBefore(firstInstruction, worker.Create(OpCodes.Call,
> module.Import(typeof(Console).GetMethod("WriteLine", (string,)
>
>AssemblyFactory.SaveAssembly(asm, pathToAssembly)
>AppDomain.CurrentDomain.ExecuteAssembly(pathToAssembly)
>
--
Amir Ebrahimi
Technical Account Manager
Unity Technologies :: http://unity3d.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Can't build svn head on Linux/x86
On Tue, 2010-03-16 at 10:31 +0100, Thierry Lafage wrote: > I've followed what is written on the website and in the README in mono > to build mono from svn (head of trunk), and the build process fails on > my Linux/x86 box (see trace below). ... > $ make > [...] > make[7]: Entering directory > `/udd/lafage/Mono/SVN/trunk/mcs/docs' > MDOC[net_4_0] cs-errors.tree > > ** (./../tools/mdoc/mdoc.exe:21186): WARNING **: The following > assembly referenced > from /udd/lafage/Mono/SVN/trunk/mcs/tools/mdoc/mdoc.exe could > not be loaded: > Assembly: monodoc(assemblyref_index=3) > Version:1.0.0.0 > Public Key: 0738eb9f132ed756 This is (hopefully) fixed in r153683. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] tech talk in downtown Chicago?
I don't do work in the city anymore, but it would be interesting to see if you get any bites. I only started following this list a few days ago. Ordinarily I work on and write about real computers. On Tuesday 16 March 2010 09:16:34 am David Smith wrote: > I moved to Chicago in mid January. I'm wondering if there are any like > minded individuals (people following this list) interested in getting > together in downtown Chicago to talk tech? If so email me and we can meet > up. > > --dave > _ > davidsilvasmith.com | (313)263-3661 | 3250 W Washington Blvd Apt 1E Chicago > IL 60624 > -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.logikalsolutions.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] tech talk in downtown Chicago?
I moved to Chicago in mid January. I'm wondering if there are any like minded individuals (people following this list) interested in getting together in downtown Chicago to talk tech? If so email me and we can meet up. --dave _ davidsilvasmith.com | (313)263-3661 | 3250 W Washington Blvd Apt 1E Chicago IL 60624 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with System.Random
Also note that this patch seems to break serialization compatibility
that might be a problem for some applications.
Kornél
Andreas Nahr wrote:
> I won't comment on the algorithm itself (keep in mind that the existing one
> already was replaced once with a "better" one which failed miserably in real
> world apps, so had to be reverted).
> Also a newsgroup as source doesn't sound reliable at all.
>
> But your patch adds errors for exceptions (which were mostly correct
> before). And the unit-tests are no "unit-tests". They don't test the
> implementation against the specification, they test the implementation
> against the implementation which is useless. And moreover you removed ALL
> Random() constructor tests which most likely are the only of relevance to
> real-world applications.
>
> Greetings
> Andreas
>
> -Ursprüngliche Nachricht-
> Von: mono-devel-list-boun...@lists.ximian.com
> [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Adrian
> Willenbücher
> Gesendet: Montag, 15. März 2010 23:33
> An: mono-devel-list@lists.ximian.com
> Betreff: [Mono-dev] Issues with System.Random
>
> Hello,
>
> I noticed that the implementation of System.Random has a couple of flaws:
> 1.) The algorithm for the random data fails miserably in some of the Diehard
> tests (http://i.cs.hku.hk/~diehard/), even
> if it is slightly changed in order to generate full 32-bit random values.
> 2.) It might return a negative value:
> "if (retVal < 0) retVal += MBIG;"
> results in -1 for retVal == int.MinValue, which is forbidden.
> 3.) The use of floating-point arithmetic introduces numerical errors since
> int.MaxValue is not a power of two (so
> 1.0/int.MaxValue is not representable without errors).
>
> I reimplemented the class using the xorshift algorithm by George Marsaglia,
> which he posted on comp.lang.c
> (http://groups.google.com/group/comp.lang.c/browse_thread/thread/a9915080a44
> 24068/), and tested it with the Diehard
> battery of tests (it passed); it avoids any FP arithmetic where it is not
> needed.
>
> The interface of the class is still pretty screwed up, but sadly we can't
> change that.
>
> I also completely rewrote the unit tests; they are stricter and more precise
> now. The expected values were produced by
> running the C-code given by George Marsaglia.
>
> The patches for the two files can be found below.
>
>
> Regards,
> Adrian
>
>
> Index: mcs/class/corlib/System/Random.cs
> ===
> --- mcs/class/corlib/System/Random.cs (revision 153607)
> +++ mcs/class/corlib/System/Random.cs (working copy)
> @@ -4,12 +4,11 @@
> // Authors:
> // Bob Smith (b...@thestuff.net)
> // Ben Maurer (bmau...@users.sourceforge.net)
> +// Adrian Willenbücher (awillenbuec...@gmx.de)
> //
> // (C) 2001 Bob Smith. http://www.thestuff.net
> // (C) 2003 Ben Maurer
> //
> -
> -//
> // Copyright (C) 2004 Novell, Inc (http://www.novell.com)
> //
> // Permission is hereby granted, free of charge, to any person obtaining
> @@ -39,104 +38,98 @@
> [ComVisible (true)]
> public class Random
> {
> - const int MBIG = int.MaxValue;
> - const int MSEED = 161803398;
> + private uint [] state = new uint [5];
>
> - int inext, inextp;
> - int [] SeedArray = new int [56];
> -
> - public Random ()
> - : this (Environment.TickCount)
> + public Random () : this(Environment.TickCount)
> {
> }
>
> public Random (int Seed)
> {
> - int ii;
> - int mj, mk;
> -
> - // Numerical Recipes in C online @
> http://www.library.cornell.edu/nr/bookcpdf/c7-1.pdf
> - mj = MSEED - Math.Abs (Seed);
> - SeedArray [55] = mj;
> - mk = 1;
> - for (int i = 1; i < 55; i++) { // [1, 55] is
> special (Knuth)
> - ii = (21 * i) % 55;
> - SeedArray [ii] = mk;
> - mk = mj - mk;
> - if (mk < 0)
> - mk += MBIG;
> - mj = SeedArray [ii];
> - }
> - for (int k = 1; k < 5; k++) {
> - for (int i = 1; i < 56; i++) {
> - SeedArray [i] -= SeedArray [1 + (i +
> 30) % 55];
> - if (SeedArray [i] < 0)
> - SeedArray [i] += MBIG;
> - }
> - }
> - inext = 0;
> - inextp = 31;
> + state [0] = 123456789 ^ (uint)Seed;
> + state [1] = 362436069;
> + state [2] = 521288629;
[Mono-dev] Can't build svn head on Linux/x86
Hi, I've followed what is written on the website and in the README in mono to build mono from svn (head of trunk), and the build process fails on my Linux/x86 box (see trace below). Note that the version of mono which is installed is 2.6.1 (from tarball). I don't know what I've missed, and I don't know how to tell the build process that I don't mind if it does not build the doc... Regards, Thierry Lafage. Here is the trace: $ mono --version Mono JIT compiler version 2.6.1 (tarball Wed Feb 10 10:37:30 CET 2010) Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com TLS: __thread GC: Included Boehm (with typed GC and Parallel Mark) SIGSEGV: altstack Notifications: epoll Architecture: x86 Disabled: none $ svn co .../mcs [...] $ svn co .../mono [...] $ cd mono $ autogen.sh --prefix=/path/to/local/install $ make [...] make[7]: Entering directory `/udd/lafage/Mono/SVN/trunk/mcs/docs' MDOC [net_4_0] cs-errors.tree ** (./../tools/mdoc/mdoc.exe:21186): WARNING **: The following assembly referenced from /udd/lafage/Mono/SVN/trunk/mcs/tools/mdoc/mdoc.exe could not be loaded: Assembly: monodoc (assemblyref_index=3) Version: 1.0.0.0 Public Key: 0738eb9f132ed756 The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/udd/lafage/Mono/SVN/trunk/mcs/tools/mdoc/). ** (./../tools/mdoc/mdoc.exe:21186): WARNING **: Could not load file or assembly 'monodoc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of its dependencies. mdoc: A type load exception has occurred. See `mdoc help' for more information. make[7]: *** [cs-errors.tree] Error 1 make[7]: Leaving directory `/udd/lafage/Mono/SVN/trunk/mcs/docs' make[6]: *** [do-all] Error 2 make[6]: Leaving directory `/udd/lafage/Mono/SVN/trunk/mcs/docs' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/udd/lafage/Mono/SVN/trunk/mcs' make[4]: *** [profile-do--net_4_0--all] Error 2 make[4]: Leaving directory `/udd/lafage/Mono/SVN/trunk/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/udd/lafage/Mono/SVN/trunk/mcs' make[2]: *** [all-local] Error 2 make[2]: Leaving directory `/udd/lafage/Mono/SVN/trunk/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/udd/lafage/Mono/SVN/trunk/mono' make: *** [all] Error 2 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with System.Random
I won't comment on the algorithm itself (keep in mind that the existing one
already was replaced once with a "better" one which failed miserably in real
world apps, so had to be reverted).
Also a newsgroup as source doesn't sound reliable at all.
But your patch adds errors for exceptions (which were mostly correct
before). And the unit-tests are no "unit-tests". They don't test the
implementation against the specification, they test the implementation
against the implementation which is useless. And moreover you removed ALL
Random() constructor tests which most likely are the only of relevance to
real-world applications.
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Adrian
Willenbücher
Gesendet: Montag, 15. März 2010 23:33
An: mono-devel-list@lists.ximian.com
Betreff: [Mono-dev] Issues with System.Random
Hello,
I noticed that the implementation of System.Random has a couple of flaws:
1.) The algorithm for the random data fails miserably in some of the Diehard
tests (http://i.cs.hku.hk/~diehard/), even
if it is slightly changed in order to generate full 32-bit random values.
2.) It might return a negative value:
"if (retVal < 0) retVal += MBIG;"
results in -1 for retVal == int.MinValue, which is forbidden.
3.) The use of floating-point arithmetic introduces numerical errors since
int.MaxValue is not a power of two (so
1.0/int.MaxValue is not representable without errors).
I reimplemented the class using the xorshift algorithm by George Marsaglia,
which he posted on comp.lang.c
(http://groups.google.com/group/comp.lang.c/browse_thread/thread/a9915080a44
24068/), and tested it with the Diehard
battery of tests (it passed); it avoids any FP arithmetic where it is not
needed.
The interface of the class is still pretty screwed up, but sadly we can't
change that.
I also completely rewrote the unit tests; they are stricter and more precise
now. The expected values were produced by
running the C-code given by George Marsaglia.
The patches for the two files can be found below.
Regards,
Adrian
Index: mcs/class/corlib/System/Random.cs
===
--- mcs/class/corlib/System/Random.cs (revision 153607)
+++ mcs/class/corlib/System/Random.cs (working copy)
@@ -4,12 +4,11 @@
// Authors:
// Bob Smith (b...@thestuff.net)
// Ben Maurer (bmau...@users.sourceforge.net)
+// Adrian Willenbücher (awillenbuec...@gmx.de)
//
// (C) 2001 Bob Smith. http://www.thestuff.net
// (C) 2003 Ben Maurer
//
-
-//
// Copyright (C) 2004 Novell, Inc (http://www.novell.com)
//
// Permission is hereby granted, free of charge, to any person obtaining
@@ -39,104 +38,98 @@
[ComVisible (true)]
public class Random
{
- const int MBIG = int.MaxValue;
- const int MSEED = 161803398;
+ private uint [] state = new uint [5];
- int inext, inextp;
- int [] SeedArray = new int [56];
-
- public Random ()
- : this (Environment.TickCount)
+ public Random () : this(Environment.TickCount)
{
}
public Random (int Seed)
{
- int ii;
- int mj, mk;
-
- // Numerical Recipes in C online @
http://www.library.cornell.edu/nr/bookcpdf/c7-1.pdf
- mj = MSEED - Math.Abs (Seed);
- SeedArray [55] = mj;
- mk = 1;
- for (int i = 1; i < 55; i++) { // [1, 55] is
special (Knuth)
- ii = (21 * i) % 55;
- SeedArray [ii] = mk;
- mk = mj - mk;
- if (mk < 0)
- mk += MBIG;
- mj = SeedArray [ii];
- }
- for (int k = 1; k < 5; k++) {
- for (int i = 1; i < 56; i++) {
- SeedArray [i] -= SeedArray [1 + (i +
30) % 55];
- if (SeedArray [i] < 0)
- SeedArray [i] += MBIG;
- }
- }
- inext = 0;
- inextp = 31;
+ state [0] = 123456789 ^ (uint)Seed;
+ state [1] = 362436069;
+ state [2] = 521288629;
+ state [3] = 88675123;
+ state [4] = 886756453;
}
- protected virtual double Sample ()
+ /* Uses the xorshift algorithm by George Marsaglia on:
+*
http://groups.google.com/group/comp.lang.c/browse_thre
Re: [Mono-dev] iltest failures on sparc...
Hi, I suspect, like powerpc, that this test should simply be disabled > on sparc. > Done in SVN HEAD and the mono 2.6 branch. Zoltan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] iltest failures on sparc...
From: Zoltan Varga Date: Tue, 16 Mar 2010 08:24:14 +0100 > I think this is due to a rounding problem on sparc > in the OP_FCONV_TO_I implementation in mini-sparc.c. For integer conversions, the Sparc FPU always rounds towards zero, no matter what is set in the floating point control register. On overflow, if the source operand is non-negative the result written is 2147483647. Else if the source operand is negative the result written is -2147483648. I suspect, like powerpc, that this test should simply be disabled on sparc. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] iltest failures on sparc...
Hi, I think this is due to a rounding problem on sparc in the OP_FCONV_TO_I implementation in mini-sparc.c. I can't debug this right now because our sparc buildbot seems to be down. Zoltan On Tue, Mar 16, 2010 at 8:07 AM, David Miller wrote: > > Zoltan, I noticed you mentioned that some IL parser fixes for > big endian for float constants got made recently. > > I'm still getting iltest.exe failures for testcase test_0_fcont_to_i > > It's the only basic test that fails on the current 2.6 branch on sparc > for me, maybe it's related to that other IL parser endianness issue? > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] iltest failures on sparc...
Zoltan, I noticed you mentioned that some IL parser fixes for big endian for float constants got made recently. I'm still getting iltest.exe failures for testcase test_0_fcont_to_i It's the only basic test that fails on the current 2.6 branch on sparc for me, maybe it's related to that other IL parser endianness issue? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
