[Mono-dev] Double multiplication
Today was one of the strangest days that I had recently. I woke up today to
discover another way of thinking about numbers ::-)
To cut the long story short let me ask a simple question. Do you know the
result that the following code will produce as a console output:
using System;
namespace MultTest
{
class Program
{
static void Main (string [] args)
{
double d1 = 127.2;
double d2 = 128.2;
double hundred = 100;
Console.WriteLine ({0} * {1} = {2}, d1, hundred, Math.Floor
(d1 * 100));
Console.WriteLine ({0} * {1} = {2}, d2, hundred, Math.Floor
(d2 * 100));
Console.ReadKey ();
}
}
}
Well what I get from it is:
127.2 * 100 = 12720
128.2 * 100 = 12819
Am I the only one that thinks this is wrong? The things are even worse
because I noticed the problem on MS.NET first, and then on Mono and since
Microsoft is very unlikely to care about what I have to say, I decided that
you guys can be a lot more helpful.
Thanks
Vladimir Dimitrov
P.S. I tried it on different machines Core 2 Duo (T7200) and Pentium 4.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Double multiplication
The problem is that in my case I cast to int and then I get this result. It
is the same as:
Console.WriteLine ({0} * {1} = {2}, d1, hundred, (int) (d1 *
100));
plus I am not using anything very special. How can 127.2 give a right
result, and 128.2 not. This is multiplication with a whole number, after
all, so the precision should decrease not increase. Plus 128.1 will give the
right number too ...
-Original Message-
From: Michał Ziemski [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 29, 2007 3:10 PM
To: Vladimir Dimitrov
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Double multiplication
Hi!
Floating point operations have finite precision.
Thus 128.2 * 100 might yield 12819...., which in turn yields
12819 after applying Floor.
I beleve you would get an analogous result from a C program.
Maybe you should try rounding rather than Floor?
Beast regards,
Michał Ziemski
Vladimir Dimitrov pisze:
Today was one of the strangest days that I had recently. I woke up
today to discover another way of thinking about numbers .J
To cut the long story short let me ask a simple question. Do you know
the result that the following code will produce as a console output:
using System;
namespace MultTest
{
class Program
{
static void Main (string [] args)
{
double d1 = 127.2;
double d2 = 128.2;
double hundred = 100;
Console.WriteLine ({0} * {1} = {2}, d1, hundred,
Math.Floor (d1 * 100));
Console.WriteLine ({0} * {1} = {2}, d2, hundred,
Math.Floor (d2 * 100));
Console.ReadKey ();
}
}
}
Well what I get from it is:
127.2 * 100 = 12720
128.2 * 100 = 12819
Am I the only one that thinks this is wrong? The things are even worse
because I noticed the problem on MS.NET first, and then on Mono and
since Microsoft is very unlikely to care about what I have to say, I
decided that you guys can be a lot more helpful.
Thanks
Vladimir Dimitrov
P.S. I tried it on different machines Core 2 Duo (T7200) and Pentium 4.
___
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] Double multiplication
Hi!
Floating point operations have finite precision.
Thus 128.2 * 100 might yield 12819...., which in turn yields
12819 after applying Floor.
I beleve you would get an analogous result from a C program.
Maybe you should try rounding rather than Floor?
Beast regards,
Michał Ziemski
Vladimir Dimitrov pisze:
Today was one of the strangest days that I had recently. I woke up
today to discover another way of thinking about numbers …J
To cut the long story short let me ask a simple question. Do you know
the result that the following code will produce as a console output:
using System;
namespace MultTest
{
class Program
{
static void Main (string [] args)
{
double d1 = 127.2;
double d2 = 128.2;
double hundred = 100;
Console.WriteLine ({0} * {1} = {2}, d1, hundred,
Math.Floor (d1 * 100));
Console.WriteLine ({0} * {1} = {2}, d2, hundred,
Math.Floor (d2 * 100));
Console.ReadKey ();
}
}
}
Well what I get from it is:
127.2 * 100 = 12720
128.2 * 100 = 12819
Am I the only one that thinks this is wrong? The things are even worse
because I noticed the problem on MS.NET first, and then on Mono and
since Microsoft is very unlikely to care about what I have to say, I
decided that you guys can be a lot more helpful.
Thanks
Vladimir Dimitrov
P.S. I tried it on different machines Core 2 Duo (T7200) and Pentium 4.
___
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] Double multiplication
+1
Additionnally, if you need precise calculations without round-off
errors like these you should use System.Decimal type instead of
float/double.
On Nov 29, 2007 2:10 PM, Michał Ziemski [EMAIL PROTECTED] wrote:
Hi!
Floating point operations have finite precision.
Thus 128.2 * 100 might yield 12819...., which in turn yields
12819 after applying Floor.
I beleve you would get an analogous result from a C program.
Maybe you should try rounding rather than Floor?
Beast regards,
Michał Ziemski
Vladimir Dimitrov pisze:
Today was one of the strangest days that I had recently. I woke up
today to discover another way of thinking about numbers …J
To cut the long story short let me ask a simple question. Do you know
the result that the following code will produce as a console output:
using System;
namespace MultTest
{
class Program
{
static void Main (string [] args)
{
double d1 = 127.2;
double d2 = 128.2;
double hundred = 100;
Console.WriteLine ({0} * {1} = {2}, d1, hundred,
Math.Floor (d1 * 100));
Console.WriteLine ({0} * {1} = {2}, d2, hundred,
Math.Floor (d2 * 100));
Console.ReadKey ();
}
}
}
Well what I get from it is:
127.2 * 100 = 12720
128.2 * 100 = 12819
Am I the only one that thinks this is wrong? The things are even worse
because I noticed the problem on MS.NET first, and then on Mono and
since Microsoft is very unlikely to care about what I have to say, I
decided that you guys can be a lot more helpful.
Thanks
Vladimir Dimitrov
P.S. I tried it on different machines Core 2 Duo (T7200) and Pentium 4.
___
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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System changes for SOAP serialization compatibility with .NET
Thank you. I corrected the changes. Please see the attached patch. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Jordan Sent: Tuesday, November 20, 2007 5:19 PM To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] [PATCH] System changes for SOAP serialization compatibility with .NET Hi Arina, Arina Itkes wrote: Hi Please review the changes for SOAP serialization compatibility with .NET. Please assure that historical data serialized with the old version is still consumable by the new version, when possible, i.e. the class is ISerializable. Also, always call base.GetObjectData before accessing the SerializationInfo argument. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list SystemSoapSerializationFix.patch Description: SystemSoapSerializationFix.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Fix for RegEx parser.
Hi, I've added a new set of tests for regular expressions and a correction to the parser.cs for passing the test PerlTest.Trial0990(). Please review the attached patch. Thanks. Regex.patch Description: Regex.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Fix for RegEx parser.
Hi Arina, I've added a new set of tests for regular expressions and a correction to the parser.cs for passing the test PerlTest.Trial0990(). You mention a PerlTest along with regular expressions. This is very interesting. I was under the impression that Microsoft Regexes POSIX Regex Perl Regexes. How do I choose a regular expression language? Or am I limited to Microsoft expressions? Thanks, Vlad smime.p7s Description: S/MIME cryptographic signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Set hash algorithms block size
This fix is twofold: to begin with, I've modified the abstract base classes of all hash algorithms in Sys.Sec.Crypto to include a protected const field called SPEC_BLOKCSIZE and overriden InputBlockSize and OutputBlockSize to return this value. This would modify the public API and so wouldn't be allowable (i assume). You'd have to make those either internal or private as opposed to protected. Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Set hash algorithms block size
Fine for me. The advantage of making the field protected instead of private was allowing derived classes to know about it and so allowing them to remove their redundant (private) fields, but the functionality brought by my patch wouldn't be hindered by making those fields private or internal. So, amendment accepted ^^ Habbit 2007/11/29, Alan McGovern [EMAIL PROTECTED]: This fix is twofold: to begin with, I've modified the abstract base classes of all hash algorithms in Sys.Sec.Crypto to include a protected const field called SPEC_BLOKCSIZE and overriden InputBlockSize and OutputBlockSize to return this value. This would modify the public API and so wouldn't be allowable (i assume). You'd have to make those either internal or private as opposed to protected. Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DateTime unspecified-to-localtime conversions different between mono and .net
Hello,
Avery Pennarun wrote:
Hi all,
I tried the following program in Microsoft .NET 2.0 and 3.5 (same
results both times) and mono 1.2.3 and 1.2.5 (same results both
times).
I see two main differences here:
1) Dates after the Y2.038k bug in 2038 do not calculate daylight
savings time correctly.
2) DateTime.Parse in .NET seems to return a timezone-unspecified
DateTime, such that converting it ToLocalTime() or ToUniversalTime()
will always change the timestamp in one direction or the other. In
mono, it seems to be a timezone-localtime DateTime, so that
ToLocalTime() has no effect.
Should I file a bug with this? I've heard of people having trouble
I'm not sure what the daylight saving time issue is but for this
questoin, the answer is yes :)
signing up for the new bugzilla, is that fixed?
When it works for you, it should not be a real issue.
Atsushi Eno
Thanks,
Avery
Source code:
using System;
public static class Test
{
public static void test(DateTime dt)
{
System.Console.WriteLine({0} -- {1},
dt.ToLocalTime(), dt.ToUniversalTime());
System.Console.WriteLine( {0} -- {1} -- {2},
dt.Ticks, dt.ToLocalTime().Ticks, dt.ToUniversalTime().Ticks);
}
public static void Main()
{
test(DateTime.Parse(2007-09-27 5:14:14));
test(DateTime.Parse(2007-11-27 5:14:14));
test(DateTime.Parse(2039-09-27 5:14:14));
test(DateTime.Parse(2039-11-27 5:14:14));
test(DateTime.Parse(0001-01-01 10:01:02));
}
}
Results in .NET:
9-27-2007 1:14:14 AM -- 9-27-2007 9:14:14 AM
63326466854000 -- 63326452454000 -- 63326481254000
11-27-2007 12:14:14 AM -- 11-27-2007 10:14:14 AM
63331737254000 -- 63331719254000 -- 63331755254000
9-27-2039 1:14:14 AM -- 9-27-2039 9:14:14 AM
64336310054000 -- 64336295654000 -- 64336324454000
11-27-2039 12:14:14 AM -- 11-27-2039 10:14:14 AM
64341580454000 -- 64341562454000 -- 64341598454000
1-1-0001 5:01:02 AM -- 1-1-0001 3:01:02 PM
36062000 -- 18062000 -- 54062000
Results in mono:
27/09/2007 5:14:14 AM -- 27/09/2007 9:14:14 AM
63326466854000 -- 63326466854000 -- 63326481254000
27/11/2007 5:14:14 AM -- 27/11/2007 10:14:14 AM
63331737254000 -- 63331737254000 -- 63331755254000
27/09/2039 5:14:14 AM -- 27/09/2039 10:14:14 AM
64336310054000 -- 64336310054000 -- 64336328054000
27/11/2039 5:14:14 AM -- 27/11/2039 10:14:14 AM
64341580454000 -- 64341580454000 -- 64341598454000
01/01/0001 10:01:02 AM -- 01/01/0001 3:01:02 PM
36062000 -- 36062000 -- 54062000
___
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] [PATCH] SoapHttpClientProtocol Thread Safety fix.
Well, I'm still not sure. Why is the Uri change related to the thread safety issue? I know that your patch had included the change. I was asking for the reason why. Atsushi Eno Arina Itkes wrote: Fix for thread safety had included changes in Url property. It was made with calling to property supported only by net 2.0. Now it supported by net 1.0 too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Atsushi Eno Sent: Tuesday, November 27, 2007 10:13 PM To: mono-devel Subject: Re: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix. Hi, Please explain how come Uri is related to thread safety? Atsushi Eno Arina Itkes wrote: Please review additional fix for Url get property. Now it supported by NET_1_1 too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arina Itkes Sent: Thursday, November 15, 2007 2:57 PM To: mono-devel Subject: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix. Hi all, Please review the attached patch. It contains synchronization fix for the class WebClientAsyncResult and light changes for the class WebClientProtocol that is a base of SoapHttpClientProtocol for thread safety purpose. ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Set hash algorithms block size
Hey, On Thu, 2007-11-29 at 13:10 +0100, Javier Mart� wrote: In all Mono implementations (up to tonight's SVN) of the hash algorithms in [corlib]System.Security.Cryptography, all of them fail to override the InputBlockSize and OutputBlockSize properties, leaving them at 1 byte. Actually they don't *fail* it's the *right*, even if not obvious, value. The meaning isn't all that clear, the [Input|Output]BlockSize is different than the algorithm block size. The former is about what the implementation accept as a valid input, i.e. it's valid to hash a single byte (which doesn't really answer the output block size ;-) This should be mainly harmless, yes it is ;-) but, combined another bug in CryptoStream which makes it ignore the CanTransformMultipleBlocks property of its ICryptoTransform when reading (though not when writing!, brings about this doomsday scenario: reading a 3MB file through a CryptoStream of, say, SHA1, issues about 3 million calls to Buffer.BlockCopy and the same number to HashAlgorithm.TransformBlock. That is, CryptoStream and HashAlgorithm are having fun passing millions of one-byte arrays between them (and copying them). The speed penalty is extreme, as stated below. Please fill a bug into bugzilla.novell.com for this one. This fix is twofold: to begin with, I've modified the abstract base classes of all hash algorithms in Sys.Sec.Crypto to include a protected const field called SPEC_BLOKCSIZE and overriden InputBlockSize and OutputBlockSize to return this value. Ok, even if the [Input|Output]BlockSize was bad (and it's not) you still cannot add new protected methods inside mscorlib (or other most of Mono assemblies). This would make code compiled with Mono incompatible with MS. We have some tools that can help you track if Mono is matching, or not, MS implementation of the framework (check the web site for code completion status pages). In principle, it should be cleaner to just add them to implementations (SHA1Managed instead of SHA1), but the default provided is the one given by the spec defining the algorithm, so most (sane) implementations are going to use it and those who don't because they compute the hash through some other equivalent method can just override the properties again. The results are self-evident: even with the bug in CryptoStream (which I'll try to patch shortly), the 3M calls turn into about 50K (3M / 64) in SHA1 or 25K (3M / 128) in SHA2-512. In terms of time, hashing that 3MB file through CS went down from 2.5s to about 0.5s. Thus, the speedup achieved was about 500%! well you shouldn't be calling any Hash byte-by-byte as they don't do much buffering themselves. Also CryptoStream design isn't very helpful(*) for buffering since it must deal with other stuff (like padding, modes...). In a perfect world (or maybe in Crimson) a real buffering class would be helpful in front of hash algorithms. (*) I personally discourage it's use for hashing alone. The (upcoming) second patch should reduce this number even more in algorithms supporting CanTransformMultipleBlocks, so the number of calls to TransformBlock (and thus buffer allocs copies) would be divided by the size passed to Read. PD: I'm the stalker studend from yesterday Summit session. Sorry I won't be able to attend the rest of the sessions: Boo looked interesting. Oh, sorry I missed the chance to talk to you :( PD2: It's the first time I send a formal diff patch to a project, so sorry if For some reason part of your patch doesn't apply cleanly to SVN (only RIPEMD160 applied, all others were rejected). I missed some format rule - though I tried to replicate the formatting of code around my additions. Also, I've compiled the code (no Ws/Es) and lightly tested it hashing some files. It _seems_ I didn't break anything, While doing your own tests is a good thing to do you should *always* run the unit tests before sending a patch. Mono's crypto code is well tested (so any error will likely get caught there) and you'll also have seen that the [Input|Ouput]BlockSize were meant to be 1 (and not the algorithm block size). Sebastien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch winform resource reader
Hey, On 11/30/07, olivier dufour [EMAIL PROTECTED] wrote: Can someone check it before I commit. Please do not commit this as it is. The code: * doesn't respect the Mono coding conventions, * mixes spaces and tabs all over the place. -- Jb Evain [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch winform resource reader
OK, I have done a small part at work. So I have forget to change the
convention on it.
I have attach the fixed patch.
2007/11/30, Jb Evain [EMAIL PROTECTED] :
Hey,
On 11/30/07, olivier dufour [EMAIL PROTECTED] wrote:
Can someone check it before I commit.
Please do not commit this as it is. The code:
* doesn't respect the Mono coding conventions,
* mixes spaces and tabs all over the place.
--
Jb Evain [EMAIL PROTECTED]
Index: ResXResourceReader.cs
===
--- ResXResourceReader.cs (révision 90372)
+++ ResXResourceReader.cs (copie de travail)
@@ -37,6 +37,7 @@
using System.Resources;
using System.Runtime.Serialization.Formatters.Binary;
using System.Xml;
+using System.Reflection;
namespace System.Resources
{
@@ -48,11 +49,14 @@
private TextReader reader;
private Hashtable hasht;
private ITypeResolutionService typeresolver;
-
private XmlTextReader xmlReader;
+
#if NET_2_0
private string basepath;
+ private bool useResXDataNodes;
+ private AssemblyName [] assemblyNames;
+ private Hashtable hashtm;
#endif
#endregion // Local Variables
@@ -66,7 +70,10 @@
throw new ArgumentException (Stream was not
readable.);
this.stream = stream;
- }
+#if NET_2_0
+ this.useResXDataNodes = false;
+#endif
+}
public ResXResourceReader (Stream stream,
ITypeResolutionService typeresolver)
: this (stream)
@@ -77,7 +84,10 @@
public ResXResourceReader (string fileName)
{
this.fileName = fileName;
- }
+#if NET_2_0
+ this.useResXDataNodes = false;
+#endif
+}
public ResXResourceReader (string fileName,
ITypeResolutionService typeresolver)
: this (fileName)
@@ -88,6 +98,9 @@
public ResXResourceReader (TextReader reader)
{
this.reader = reader;
+#if NET_2_0
+ this.useResXDataNodes = false;
+#endif
}
public ResXResourceReader (TextReader reader,
ITypeResolutionService typeresolver)
@@ -96,6 +109,28 @@
this.typeresolver = typeresolver;
}
+#if NET_2_0
+
+ public ResXResourceReader (Stream stream, AssemblyName []
assemblyNames)
+ : this (stream)
+ {
+ this.assemblyNames = assemblyNames;
+ }
+
+ public ResXResourceReader (string fileName, AssemblyName []
assemblyNames)
+ : this (fileName)
+ {
+ this.assemblyNames = assemblyNames;
+ }
+
+ public ResXResourceReader (TextReader reader, AssemblyName []
assemblyNames)
+ : this (reader)
+ {
+ this.assemblyNames = assemblyNames;
+ }
+
+
+#endif
~ResXResourceReader ()
{
Dispose (false);
@@ -107,11 +142,23 @@
get { return basepath; }
set { basepath = value; }
}
+ public bool UseResXDataNodes {
+ get { return useResXDataNodes; }
+ set {
+ if (xmlReader != null)
+ throw new InvalidOperationException ();
+ useResXDataNodes = value;
+ }
+ }
#endif
#region Private Methods
private void LoadData ()
{
+ hasht = new Hashtable ();
+#if NET_2_0
+ hashtm = new Hashtable ();
+#endif
if (fileName != null) {
stream = File.OpenRead (fileName);
}
@@ -141,8 +188,13 @@
ParseHeaderNode
(header);
break;
case data:
- ParseDataNode ();
+ ParseDataNode (hasht);
break;
+#if NET_2_0
+ case metadata:
+ ParseDataNode (hashtm);
+ break;
+#endif
}
}
#if NET_2_0
