Porting C# Application to Java, Different results.

[Berlin Brown]

I am porting a C# application to Java. It is only two classes and the
application runs and I am not getting any errors, but I get different
output from the Java application. I am thinking there is some logic
somewhere I am missing where functionality in C# is not the same in
Java. Here is my code. Sorry, the best place is in SVN, plus you
might be able to run it as well.

http://jvmnotebook.googlecode.com/s...cadder/src/java/org/adder/EquationGenome.java

http://jvmnotebook.googlecode.com/s...er/third-party/adder_csharp/EquationGenome.cs

http://jvmnotebook.googlecode.com/svn/trunk/scala/geneticadder/src/java/org/adder/Population.java

http://jvmnotebook.googlecode.com/s...cadder/third-party/adder_csharp/Population.cs

If you notice, it is almost a line for line match up. Except, there
is something different. If I get time, I will try to compartmentalize
some of the code and break it up more.

Most of the source.

http://jvmnotebook.googlecode.com/svn/trunk/scala/geneticadder/src/java/org/adder/

 

[Mark Space]

Most of the source.

http://jvmnotebook.googlecode.com/svn/trunk/scala/geneticadder/src/java/org/adder/

While this is very good, it would help if you gave us some sample output
for both programs, so we could compare. Without the C# version to
compare against, I'd have no idea what the Java version should produce.

Also, try to point out exactly what you think is incorrect, if it's not
obvious, since we might not focus on the same thing as you.

 

[Mark Space]

lol...

Ever heard of a SSCCE?

The code the OP linked to is complete, just not very short. Under the
circumstances, I think his use of Google code was probably the best.
It's only four classes total.

I already have it compiling and producing output, although I have no
idea what I'm looking at in the output.

p.s. I'm especially impressed that you're asserting copyright ownership
on a code that you yourself admit is a "almost a line for line match up"
to code written by someone else.

Yeah that struck me as odd also. Possibly just the boilerplate he uses.
OTOH, it's also not legally correct, and there's a small chance it
could land one in hot water. I like to make sure my stuff is properly
attributed before I release it anywhere, even here in this group.

 

[Berlin Brown]

Well, first of all, not exactly complete since his problem statement  
requires both C# and Java code, and as near as I can tell, only some of  
the C# code was posted.  But, even as far as the Java code goes, the fact  
that it's merely "complete" and "compilable", but not "short" is precisely  
my point.


Opinions vary I guess, as always.  It's my opinion that since he hasn't  
done anything to actually narrow the problem down enough so that he can  
post a proper SSCCE, his question isn't worth anyone else's time.  After  
all, it's apparently not worth _his_ time.

I infer from your replies that you disagree.  More power to him, I guess.  



Well, as long as you're doing all his legwork for him, why not just  
compile the C# version too?  Then you can diff the output and identify his  
complaint.  It looks to me as though while failed to post the complete C#  
version, there seems to be only two modules missing, both of which should  
be trivial for you to port back to C#, as they are the simplest of the  
bunch ("AdderMain.java" and "Genome.java").

I mean, come on!  Are you serious about doing this guy's work for him or  
aren't you?!  

Pete

Sorry about that. Yea, it is vague and it is short. But I thought
someone might see an example where the C# Java match up is completely
wrong.

------------------


[java] --> ((b^d)~) --> 0.99
[java] --> ((b^(d|(b^b)))~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^(a|d))~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((d^(a|d))~) --> 0.995
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] --> ((b^d)~) --> 0.99
[java] generation #402, Hit the enter key to continue...
[java]

---------------------

C# Example:


Population Size=500 i=473 --> (d^b) --> 1
Population Size=500 i=474 --> (d^b) --> 1
Population Size=500 i=475 --> (d^b) --> 1
Population Size=500 i=476 --> (d^b) --> 1
Population Size=500 i=477 --> (d^b) --> 1
Population Size=500 i=478 --> (d^((a~)|a)) --> 0.995
Population Size=500 i=479 --> (d^b) --> 1
Population Size=500 i=480 --> (d^b) --> 1
Population Size=500 i=481 --> (d^b) --> 1
Population Size=500 i=482 --> (d^b) --> 1
Population Size=500 i=483 --> ((a~)^b) --> 0.995
Population Size=500 i=484 --> (d^((d^d)|b)) --> 1
Population Size=500 i=485 --> (d^((d^d)|b)) --> 1
Population Size=500 i=486 --> (d^b) --> 1
Population Size=500 i=487 --> (d^b) --> 1
Population Size=500 i=488 --> (d^b) --> 1
Population Size=500 i=489 --> (d^b) --> 1
Population Size=500 i=490 --> (d^b) --> 1
Population Size=500 i=491 --> (d^b) --> 1
Population Size=500 i=492 --> (d^b) --> 1
Population Size=500 i=493 --> (d^b) --> 1
Population Size=500 i=494 --> (d^b) --> 1
Population Size=500 i=495 --> (d^b) --> 1
Population Size=500 i=496 --> (d^b) --> 1
Population Size=500 i=497 --> (d^b) --> 1
Population Size=500 i=498 --> (d^b) --> 1
Population Size=500 i=499 --> (d^b) --> 1
Generation #602, Hit the enter key to continue...


In the C# example, the output is a little different and the numbers
converge to one. and in the Java example, they don't.

I think you can run the C# example (see the svn repo) on Win32 and
Mono.

 

[Roedy Green]

I am porting a C# application to Java.

I have only the most rudimentary knowledge of C#, but I'll throw you
these bones to check out yourself.

In Java bytes are SIGNED. The damn things sign extend as soon as you
do any arithmetic on them. I don't know about C#. Since Anders
Hejlsberg Invented C# later than Java, presumably he did not make the
same blunder.

Java has strict naming conventions which you violate. It makes reading
your code like trying to understand someone with a strong Jamaican
accent. See http://mindprod.com/jgloss/codingconventions.html
http://mindprod.com/jgloss/naming.html The IntelliJ Idea IDE is great
for global renaming.
see http://mindprod.com/jgloss/intellij.html


You have a random number generator in there. Unless you use a
constant seed, this implies the output would not even be the same for
two C# runs much less a Java one.
Random numbers are tricky. See
http://mindprod.com/jgloss/pseudorandom.html

Check out the % operator. If is often defined different ways in
different languages. See http://mindprod.com/jgloss/modulus.html

--
Roedy Green Canadian Mind Products
http://mindprod.com

"The universe we observe has precisely the properties we should expect if there is, at bottom, no design, no purpose, no evil, no good, nothing but blind, pitiless indifference."
~ Charles Darwin.

 

[Berlin Brown]

I have only the most rudimentary knowledge of C#, but I'll throw you
these bones to check out yourself.

In Java bytes are SIGNED. The damn things sign extend as soon as you
do any arithmetic on them. I don't know about C#. Since Anders
Hejlsberg Invented C# later than Java, presumably he did not make the
same blunder.

Java has strict naming conventions which you violate. It makes reading
your code like trying to understand someone with a strong Jamaican
accent. Seehttp://mindprod.com/jgloss/codingconventions.htmlhttp://mindprod.com/jgloss/naming.htmlThe IntelliJ Idea IDE is great
for global renaming.
seehttp://mindprod.com/jgloss/intellij.html

You have a random number generator in there. Unless you use a
constant seed, this implies the output would not even be the same for
two C# runs much less a Java one.
Random numbers are tricky. Seehttp://mindprod.com/jgloss/pseudorandom.html

Check out the % operator. If is often defined different ways in
different languages. Seehttp://mindprod.com/jgloss/modulus.html

--
Roedy Green Canadian Mind Productshttp://mindprod.com

"The universe we observe has precisely the properties we should expect if there is, at bottom, no design, no purpose, no evil, no good, nothing but blind, pitiless indifference."
~ Charles Darwin.

Thanks Roedy Green.

That is what I was looking for. I will look at those. On the random
generator, yea, I except the output to be different but the Java
output is wrong. Even though there is randomness in the application.

The signed byte issue may be it.

 

[Mark Space]

Well, as long as you're doing all his legwork for him, why not just
compile the C# version too?

Serious reply: I don't know anything at all about C#, and have no
experience with its tool chain. So that won't happen.

 

[Berlin Brown]

Well, I'm fairly experienced in C# (Microsoft C# "MVP"), but have no
interest in messing around with lengthy code examples and vague problem
descriptions.

I wonder if Berlin will find someone with both the will and knowledge
required to help him.

Pete

When did 500-800 lines of code, 2 core classes become so complicated.

Don't get me wrong, I don't have a solution either. Short of breaking
down the Java application unit by unit to resolve the issue. I think
Roedy was on the right track. There are differences in signed/
unsigned nature between a primitive in Java and a primitive in C#. I
will look at that. Also, I wrote my own removeRange/compareTo/
Random.nextInt methods to clone the functionality in C#. I hope my
versions work the same.

 

[Lew]

When did 500-800 lines of code, 2 core classes become so complicated.

When it involved arbitrary and non-type-safe use of ints and bytes
with obscure semantics in an undocumented problem domain relating to
an unexplained misbehavior in an unspecified part of the incomplete
code base that employs opaque manipulations of arrays according to
secret rules.

 

[Larry K. Wollensham]

When it was presented as part of a vague question, asking little more
than "why is this different"?

By the way, I don't see what your post of the output added to the
question. Every single line is different between the Java and C#
versions, making any cursory comparison impossible. Even trying to
compensate for differences that appear inconsequential, the two outputs
don't appear to be from the same input (Java says "generation 402", C#
says "generation 602", for example, the general pattern of the output is
also different, and there aren't even the same number of lines between
the two).


Shocking. You might actually have to apply conventional debugging
techniques to the problem, instead of asking someone else to do it? It
must be awful just _considering_ the thought.

I'm fairly sure that a lot of these sorts of questions have a purpose
that boils down to: "Before I put a shitload of effort into creating an
SSSCE or whatever-the-hell-it-was and all of that stuff, I'd first like
to know if there's anything really obvious I'm missing, or a common
gotcha I've probably tripped over." In this instance, an obvious
difference in arithmetic behavior between C# and Java, with the
byte-signedness thing turning out to be a likely culprit.

There should probably be some allowance made for this, with a standard
way for someone to say "No SSSCE yet -- is there any likely/obvious
gotcha here, or a known bug that causes this pattern of symptoms, or
whatever? If not, I'll post back with an SSSCE later, but if there is,
just point me to the appropriate documentation and I'll be on my way."

 

[Berlin Brown]

There is already.

When someone posts a question without an SSCCE, if the answer has obvious
elements those tend to get posted here right away.  If not, people respond
with, "Please provide an SSCCE."  At that point it is up to the OP to back up
and follow that advice, rather than snarkily asking (without even a question
mark), "When did 500-800 lines of code, 2 core classes become so complicated."

"I'm fairly sure that a lot of these sorts of questions have a purpose
that boils down to: "Before I put a shitload of effort into creating
an
SSSCE or whatever-the-hell-it-was and all of that stuff, I'd first
like
to know if there's anything really obvious I'm missing, or a common
gotcha I've probably tripped over." In this instance, an obvious
difference in arithmetic behavior between C# and Java, with the
byte-signedness thing turning out to be a likely culprit. "

Thanks Larry. That was the intention. I am not 100% on the domain
(Genetic Algorithms) or the original C# application. I didn't get a
chance to run the C# application and haven't written or compiled a C#
until recently. But I was interested in the original C# code and I
rewrote the Java application in a couple of hours or so and got
unexpected output. So, I thought I would ask the community and see
what would happen. I got a lot of useful advice and narrowing down on
the issue. There was a problem with my compareTo method and my C#
port of removeRange. There were also primitive conversion issues. In
the C# code, the developer explicitly cast the double to int and I
went ahead and used double for most of the core operations in Java as
opposed to dealing with the loss in precision with a cast.

It was wrong on my part but I thought I would try before completely
rewriting the application with unit tests and compartmentalizing where
the issue is.

 

[Lew]

In the C# code, the developer explicitly cast the double to int and I
went ahead and used double for most of the core operations in Java as
opposed to dealing with the loss in precision with a cast.

That right there could explain the differences completely.

 

[zarfishan]

There is a tool available at http://codeporting.com/ where you can convert your c# or .net code to java its getting good comments from users who have used it so i would recommend it also.