We Keep Coding

How does Java compute the sine and cosine functions?

How does Java find sine and cosine? I’m working on trying to make a game that is a simple platformer something like super Mario or Castlevania. I attempted to make a method that would rotate an image for me and then resize the JLabel to fit that image. I found an algorithm that worked and was able to accomplish my goal. However all I did was copy and past the algorithm any one can do that I want to understand the math behind it. So far I have figured everything out except one part. The methods sin and cos in the math class. They work and I can use them but I have no idea how Java get its numbers.
It would seem there is more then one way to solve this problem. For now I’m interested in how Java does it. I looked into the Taylor series but I’m not sure that is how java does it. But if Java does use the Taylor series I would like to know how that algorithm is right all the time (I am aware that it is an approximation). I’ve also heard of the CORDIC algorithm but I don’t know much about it as I do with the Taylor series which I have programmed into Java even though I don’t understand it. If CORDIC is how it's done, I would like to know how that algorithm is always right. It would seem it is also possible that the Java methods are system dependent meaning that the algorithm or code used would differ from system to system. If the methods are system dependent then I would like to know how Windows gets sine and cosine. However if it is the CPU itself that gets the answer I would like to know what algorithm it is using (I run an AMD Turion II Dual-Core Mobile M520 2.29GHz).
I have looked at the score code of the Math class and it points to the StrictMath class. However the StrictMath class only has a comment inside it no code. I have noticed though that the method does use the keyword native. A quick Google search suggest that this keyword enables java to work with other languages and systems supporting the idea that the methods are system dependent. I have looked at the java api for the StrictMath class (http://docs.oracle.com/javase/7/docs/api/java/lang/StrictMath.html) and it mentions something called fdlimb. The link is broken but I was able to Google it (http://www.netlib.org/fdlibm/).
It seems to be some sort of package written in C. while I know Java I have never learned C so I have been having trouble deciphering it. I started looking up some info about the C language in the hopes of getting to bottom of this but it a slow process. Of cores even if did know C I still don’t know what C file Java is using. There seems to be different version of the c methods for different systems and I can’t tell which one is being used. The API suggest it is the "IEEE 754 core function" version (residing in a file whose name begins with the letter e). But I see no sin method in the e files. I have found one that starts with a k which I think is sort for kernel and another that starts with an s which I think is sort for standard. The only e files I found that look similar to sin are e_sinh.c and e_asin.c which I think are different math functions. And that’s the story of my quest to fiend the Java algorithms for sine and cosine.
Somewhere at some point in the line an algorithm is being called upon to get these numbers and I want to know what it is and why it works(there is no way java just gets these numbers out of thin air).

The JDK is not obligated to compute sine and cosine on its own, only to provide you with an interface to some implementation via Math. So the simple answer to your question is: It doesn't; it asks something else to do it, and that something else is platform/JDK/JVM dependent.
All JDKs that I know of pass the burden off to some native code. In your case, you came across a reference to fdlibm, and you'll just have to suck it up and learn to read that code if you want to see the actual implementation there.
Some JVMs can optimize this. I believe HotSpot has the ability to spot Math.cos(), etc. calls and throw in a hardware instruction on systems where it is available, but do not quote me on that.
From the documentation for Math:
By default many of the Math methods simply call the equivalent method in StrictMath for their implementation. Code generators are encouraged to use platform-specific native libraries or microprocessor instructions, where available, to provide higher-performance implementations of Math methods. Such higher-performance implementations still must conform to the specification for Math.
The documentation for StrictMath actually mentions fdlibm (it places the constraint on StrictMath that all functions must produce the same results that fdlibm produces):
To help ensure portability of Java programs, the definitions of some of the numeric functions in this package require that they produce the same results as certain published algorithms. These algorithms are available from the well-known network library netlib as the package "Freely Distributable Math Library," fdlibm. These algorithms, which are written in the C programming language, are then to be understood as executed with all floating-point operations following the rules of Java floating-point arithmetic.
Note, however, that Math is not required to defer to StrictMath. Use StrictMath explicitly in your code if you want to guarantee consistent results across all platforms. Note also that this implies that code generators (e.g. HotSpot) are not given the freedom to optimize StrictMath calls to hardware calls unless the hardware would produce exactly the same results as fdlibm.
In any case, again, Java doesn't have to implement these on its own (it usually doesn't), and this question doesn't have a definitive answer. It depends on the platform, the JDK, and in some cases, the JVM.
As for general computational techniques, there are many; here is a potentially good starting point. C implementations are generally easy to come by. You'll have to search through hardware datasheets and documentation if you want to find out more about the hardware options available on a specific platform (if Java is even using them on that platform).

What is the difference between Agitar and Quickcheck property based testing?

A number of years ago a Java testing tool called Agitar was popular. It appeared to do something like property based testing.
Nowadays - property based testing based on Haskell's Quickcheck is popular. There are a number of ports to Java including:
quickcheck
jcheck
junit-quickcheck
My question is: What is the difference between Agitar and Quickcheck property based testing?

To me, the key features of Haskell QuickCheck are:
It generates random data for testing
If a test fails, it repeatedly "shrinks" the data (e.g., changing numbers to zero,
reducing the size of a list) until it finds the simplest test case that still fails. This is very useful, because when you see the simplest test case, you often know exactly where the bug is and how to fix it.
It starts testing with simple data, and gradually moves on to more complex data. This is useful because it means that tests fail more quickly. Also, it ensures that edge cases (e.g., empty lists, zeroes) are properly tested.
Quickcheck for Java supports (1), but not (2) or (3). I don't know what features are supported by Agitar, but it would be useful to check.
Additionally, you might look into ScalaCheck. Since Scala is interoperable with Java, you could use it to test your Java code. I haven't used it, so I don't know which features it has, but I suspect it has more features than Java Quickcheck.

Its worth noting that as of version 0.6, junit-quickcheck now supports shrinking:
http://pholser.github.io/junit-quickcheck/site/0.6-alpha-3-SNAPSHOT/usage/shrinking.html
quickcheck doesn't look to have had any new releases since 2011:
https://bitbucket.org/blob79/quickcheck

How to call Z3 properly from Java program?

I want to integrate Z3 to my security tool developed in Java. At the moment, I'm outputting the formula to check into a file, and then call Z3. May I ask how stable the Java API is?
When I look at the Java API example distributed with Z3, it seems there are two ways to solve a formula. The first one is to create a solver:
Solver solver = ctx.MkSolver();
for (BoolExpr a : g.Formulas())
solver.Assert(a);
if (solver.Check() != Status.SATISFIABLE)
throw new TestFailedException();
Another way is to use Tactic. There are examples of using with tactic "simplify" and "smt"
ApplyResult ar = ApplyTactic(ctx, ctx.MkTactic("simplify"), g);
if (ar.NumSubgoals() == 1
&& (ar.Subgoals()[0].IsDecidedSat() || ar.Subgoals()[0]
.IsDecidedUnsat()))
throw new TestFailedException();
My question is: which is the more efficient way to call z3? the first or the second one. And which tactic is good for which problem? And the tactic "smt" is for SMT-LIB1 or SMT-LIB2?
Thanks.

The Z3 Java API is stable in the sense that it will not change any function/structure names until the next release. There may of course be bugfixes and perhaps some added functionality.
Whether it makes more sense to use solvers or tactics entirely depends on the application. However, since you currently use the file-based interface, using the solver-based interface is likely to be sufficient. When this is used, solver.Check() will use a default tactic (which may depend on the logic used) to solve problems.
For more information about tactics, please see the strategies tutorial, which shows how to use goals and tactics from the SMT-LIB file based interface. The same applies for the Java API, and the names of tactics are the same. The "smt" tactic is the SMT solver wrapped in a tactic; this is independent of the input language (SMT1 or SMT2), and is essentially the same as using the default Solver object constructed via ctx.MkSolver().

Do calculus in java

I am trying to implement a neural network in java (small one) and I'm using back propogation for the learning algorithm. This requires to find general derivatives. How do I find general derivatives in java?

Try Helmut Dersch's Jasymca 2 http://webuser.hs-furtwangen.de/~dersch/jasymca2/. It's a Java API providing GNU Octave/Matlab-like capabilities. It includes symbolic math.
Jasymca has been recently worked on. The documentation is from March 2009 and it requires Java 1.5+.
CAVEAT: Jasymca is GPL so consult a lawyer before using it in a commercial product.

Depends on whether you have continuous or discrete data. I'm guessing that you have discrete data, since we're talking about neural nets.
Finite differences are one way to approximate derivatives. Another approach might be to do a fit of some kind and differentiate the fitting function, assuming that it's a well-known function with an easy-to-calculate derivative (e.g., polynomials).
How many independent variables for your data? Functions of one variable are easy; two or more are harder because you need partial derivatives.

You should try to hardcode it
double derivative = (f(x+h) - f(x-h)) / (2*h);

I'm pretty certain java does not have built in library for calculus functionality. However, it could range anywhere from trivial to quite challenging to implement differentiation by yourself.
If you already have the ability to store and analyze functions, then getting derivatives is as simple as programming the (quite limited) number of differentiation rules.
However if you are looking at differentiation based on DATAsets (not abstract functions), then you can use various approximation techniques, such as simpsons rule.

If you can make HTTP requests to the world wide web, you can create a SaturnAPI integration script.
Disclosure: I worked on SaturnAPI

If it comes to java, look at the DMelt math program. It free. In the manual, you can find how to take the derivations.

Okay, if you are doing neural networks most likely you will NOT need to take just a general derivative of some arbitrary function. Which is what you would need a general Calculus library for. Backprop requires you to use the derivative of your activation function. USUALLY, your activation function is going to be the sigmoid function or the hyperbolic tan function. Both of which you can just get the derivative of from Wikipedia and simply provide that function to your neural network training. You do not need to actually solve the derivative each time.
There are other common activation functions, but there is really only a handful that is actually used. Just look up the derivative and make use of which one you want. Most neural network frameworks just build the regular activation function and derivative into some sort of a base class you use. Here are some of the most common ones:
https://web.archive.org/web/20101105231126/http://www.heatonresearch.com/online/programming-neural-networks-encog-java/chapter-3/page2.html

are there any potential issues with obfuscating an application?

I am building a spring mvc web application.
I plan on using hibernate.
I don't have much experience with obfuscating etc.
What are the potential downsides to obfuscating an application?
I understand that there might be issues with debugging the app, and recovering lost source code is also an issue.
Are there any known issues with the actually running of the application? Can bugs be introduced?
Since this is an area I am looking for general guidance, please feel free to open up any issues that I should be aware of.

There are certainly some potential performance/maintenance issues, but a good obfuscator will let you get round at least some of them. Things to look out for:
an obvious one: if your code calls methods by reflection or dynamically loads classes, then this is liable to fail if the class/method names are obfuscated; a good obfuscator will let you select class/method names not to obfuscate to get round this problem;
a similar issue can occur if not all of your application is compiled at the same time;
if it deals directly at the bytecode level, an obfuscator can create code that in principle a Java compiler cannot create (e.g. it can insert arbitrary GOTO instructions, whereas from Java these can only be created as part of a loop)-- this may be a bit theoretical, but if I were writing a JVM, I'd optimise performance for sequences of bytecodes that a Java compiler can create, not ones that it can't...
the obfuscator is liable to make other subtle changes to performance if it significantly alters the number of bytecodes in a method, or in some way changes whether a given method/piece of code hits thresholds for certain JVM optimisations (e.g. "inline methods with fewer than X bytecodes").
But as you can see, some of these effects are a little subtle and theoretical-- so to some extent what you need to do is soak-test your application after obfuscation, just as you would with any other major change.
You should also be careful not to assume that obfuscation hides your code/algorithm (if that is your intention) as much as you want it to-- use a decompiler to have a look at the contents of the resulting obfuscated classes.

Surprised no one has mentioned speed - in general, more obfuscated = slower-running code
[Edit] I can't believe this has -2. It is a correct answer.
Shortening identifiers and removing unused methods will decrease the file-size, but have 0 impact on the running speed (other than the few nanoseconds shaved off the loading time). In the meanwhile, most of the obfuscation of the program comes from added code:
Breaking 1 method into 5; interleaving methods; merging classes [aggregation transformations]
Splitting 1 arithmetic expression into 10; jumbling the control-flow [computation transformations]
And adding chunks of code that do nothing [opaque predicates]
are all common obfuscation techniques that cause a program to run slower.

You may want to look at some of the comments here, to decide if obfuscating makes sense:
https://stackoverflow.com/questions/1988451/net-obfuscation
You may want to express why you want to obfuscate. IMO the best reasons are mainly to have a smaller application, as you can get rid of classes that aren't being used in your project, while obfuscating.
I have never seen bugs introduced, as long as you aren't using reflection, assuming you can find something, as private methods for example will have their names changed.

The biggest problem centers around that fact that obfuscating programs generally make a guarantee of not changing the behavior of their target program. In some cases it proves to be very hard to do this -- for example, imagine a program which checks the value of certain private fields via reflection from a string array. An obfuscator may not be able to tell that this string also needs to be updated correspondingly, and the result will be unexpected access errors that pop up at runtime.
Worse still, it may not be obvious that the behavior of a program has changed subtly -- then you may not know that there's a problem at all, until your customer finds it first and gets upset.
Generally, professional-grade obfuscation products are sophisticated enough to catch some kinds of problems and prevent them, but ultimately it can be challenging to cover all the bases. The best defense is to run unit tests against the obfuscated result and make sure that all your expected behavior continues to hold true.

1 free one you might want to check out is Babel. It is designed to be used on the command line (like many other obfuscators), there is a Reflector addin that will provide a UI for you.
When it comes to obfuscation, you really need to analyze what your goal is. In your case - if you have a web application (mvc) are you planning on selling it as a canned downloadable application? (if not and you keep the source on your web servers then you don't need it).
You might look at the components and pick only certain parts to obfuscate ... not the whole thing. In general ASP.Net apps break pretty easy when you try to add obfuscation after you developed them due to all the reflection used.
Pretty much everything mentioned above is true ... it all depends on how many features you turn on to make it hard to reverse your code:
Renaming of members (fields/methods/events/properties) is most common (comes in different flavors: simple renaming of methods from something like GetId() to a() all the way to unreadable characters and removal of namespaces). BTW: This is where reflection usually breaks. Your assembly file may end up being smaller due to smaller strings being used too.
String encryption: this makes it harder to reverse your static strings used in your code. BTW: this paired with renaming makes it difficult for you to debug your renaming problems ... so you might turn it on after you have that working. This also will have to add code to decrypt the string right before it is used in IL
Code mangling ... this is what BlueRaja was refering to. It makes your code look like spagetti code - to make it harder for someone to figure out. The CLR does not like this ... it can't optimize things as easy and your final code will mostlikely proccess slower due to the additional branching and something not being inlined due to the IL rewriting used for this option. BTW: this option really does raise the bar on what it takes to reverse you source code, but may come with a performance hit.
Removal of unused code. Some obfuscators offer you the option to trim any code that it finds not being used. This may make your assembly a little smaller if you have alot of dead code hanging around ... but it is just a free benefit obfuscators throw in.
My advice is to only use it if you know why you are using it and design with that end in mind ... don't try to add it after you've finished your code (I've done that and it's not fun)