Develop Reference

Calculating sin function with JAVA BigDecimal -monomial is going bigger(?)

I'm making sin function with BigDecimal in JAVA, and this is as far as I go:
package taylorSeries;
import java.math.BigDecimal;
public class Sin {
private static final int cutOff = 20;
public static void main(String[] args) {
System.out.println(getSin(new BigDecimal(3.14159265358979323846264), 100));
}
public static BigDecimal getSin(BigDecimal x, int scale) {
BigDecimal sign = new BigDecimal("-1");
BigDecimal divisor = BigDecimal.ONE;
BigDecimal i = BigDecimal.ONE;
BigDecimal num = null;
BigDecimal result = x;
//System.err.println(x);
do {
x = x.abs().multiply(x.abs()).multiply(x).multiply(sign);
i = i.add(BigDecimal.ONE);
divisor = divisor.multiply(i);
i = i.add(BigDecimal.ONE);
divisor = divisor.multiply(i);
num = x.divide(divisor, scale + cutOff, BigDecimal.ROUND_HALF_UP);
result = result.add(num);
//System.out.println("d : " + divisor);
//System.out.println(divisor.compareTo(x.abs()));
System.out.println(num.setScale(9, BigDecimal.ROUND_HALF_UP));
} while(num.abs().compareTo(new BigDecimal("0.1").pow(scale + cutOff)) > 0);
System.err.println(num);
System.err.println(new BigDecimal("0.1").pow(scale + cutOff));
return result.setScale(scale, BigDecimal.ROUND_HALF_UP);
}
}
It uses Taylor series :
picture of the fomular
The monomial x is added every iteration and always negative number.
And the problem is, absolute value of x is getting bigger and bigger, so iteration never ends.
Is there and way to find them or better way to implement it from the first place?
EDIT:
I made this code from scratch with simple interest about trigonometric functions, and now I see lots of childish mistakes.
My intention first was like this:
num is x^(2k+1) / (2k+1)!
divisor is (2k+1)!
i is 2k+1
dividend is x^(2k+1)
So I update divisor and dividend with i and compute num by sign * dividend / divisor and add it to result by result = result.add(num)
so new and good-working code is:
package taylorSeries;
import java.math.BigDecimal;
import java.math.MathContext;
public class Sin {
private static final int cutOff = 20;
private static final BigDecimal PI = Pi.getPi(100);
public static void main(String[] args) {
System.out.println(getSin(Pi.getPi(100).multiply(new BigDecimal("1.5")), 100)); // Should be -1
}
public static BigDecimal getSin(final BigDecimal x, int scale) {
if (x.compareTo(PI.multiply(new BigDecimal(2))) > 0) return getSin(x.remainder(PI.multiply(new BigDecimal(2)), new MathContext(x.precision())), scale);
if (x.compareTo(PI) > 0) return getSin(x.subtract(PI), scale).multiply(new BigDecimal("-1"));
if (x.compareTo(PI.divide(new BigDecimal(2))) > 0) return getSin(PI.subtract(x), scale);
BigDecimal sign = new BigDecimal("-1");
BigDecimal divisor = BigDecimal.ONE;
BigDecimal i = BigDecimal.ONE;
BigDecimal num = null;
BigDecimal dividend = x;
BigDecimal result = dividend;
do {
dividend = dividend.multiply(x).multiply(x).multiply(sign);
i = i.add(BigDecimal.ONE);
divisor = divisor.multiply(i);
i = i.add(BigDecimal.ONE);
divisor = divisor.multiply(i);
num = dividend.divide(divisor, scale + cutOff, BigDecimal.ROUND_HALF_UP);
result = result.add(num);
} while(num.abs().compareTo(new BigDecimal("0.1").pow(scale + cutOff)) > 0);
return result.setScale(scale, BigDecimal.ROUND_HALF_UP);
}
}

The new BigDecimal(double) constructor is not something you generally want to be using; the whole reason BigDecimal exists in the first place is that double is wonky: There are almost 2^64 unique values that a double can represent, but that's it - (almost) 2^64 distinct values, smeared out logarithmically, with about a quarter of all available numbers between 0 and 1, a quarter from 1 to infinity, and the other half the same but as negative numbers. 3.14159265358979323846264 is not one of the blessed numbers. Use the string constructor instead - just toss " symbols around it.
every loop, sign should switch, well, sign. You're not doing that.
In the first loop, you overwrite x with x = x.abs().multiply(x.abs()).multiply(x).multiply(sign);, so now the 'x' value is actually -x^3, and the original x value is gone. Next loop, you repeat this process, and thus you definitely are nowhere near the desired effect. The solution - don't overwrite x. You need x, throughout the calculation. Make it final (getSin(final BigDecimal x) to help yourself.
Make another BigDecimal value and call it accumulator or what not. It starts out as a copy of x.
Every loop, you multiply x to it twice then toggle the sign. That way, the first time in the loop the accumulator is -x^3. The second time, it is x^5. The third time it is -x^7, and so on.
There is more wrong, but at some point I'm just feeding you your homework on a golden spoon.
I strongly suggest you learn to debug. Debugging is simple! All you really do, is follow along with the computer. You calculate by hand and double check that what you get (be it the result of an expression, or whether a while loop loops or not), matches what the computer gets. Check by using a debugger, or if you don't know how to do that, learn, and if you don't want to, add a ton of System.out.println statements as debugging aids. There where your expectations mismatch what the computer is doing? You found a bug. Probably one of many.
Then consider splicing parts of your code up so you can more easily check the computer's work.
For example, here, num is supposed to reflect:
before first loop: x
first loop: x - x^3/3!
second loop: x - x^3/3! + x^5/5!
etcetera. But for debugging it'd be so much simpler if you have those parts separated out. You optimally want:
first loop: 3 separated concepts: -1, x^3, and 3!.
second loop: +1, x^5, and 5!.
That debugs so much simpler.
It also leads to cleaner code, generally, so I suggest you make these separate concepts as variables, describe them, write a loop and test that they are doing what you want (e.g. you use sysouts or a debugger to actually observe the power accumulator value hopping from x to x^3 to x^5 - this is easily checked), and finally put it all together.
This is a much better way to write code than to just 'write it all, run it, realize it doesn't work, shrug, raise an eyebrow, head over to stack overflow, and pray someone's crystal ball is having a good day and they see my question'.

The fact that the terms are all negative is not the problem (though you must make it alternate to get the correct series).
The term magnitude is x^(2k+1) / (2k+1)!. The numerator is indeed growing, but so is the denominator, and past k = x, the denominator starts to "win" and the series always converges.
Anyway, you should limit yourself to small xs, otherwise the computation will be extremely lengthy, with very large products.
For the computation of the sine, always begin by reducing the argument to the range [0,π]. Even better, if you jointly develop a cosine function, you can reduce to [0,π/2].

method is performing incorrect calculations on double argument

firstly, im sorry if this is a trivial question. I am a beginner and have been stuck on this for hours.
Below I have tried to create a unitizer method which has a series of if else statements. They are written in descending order, each time checking if a value can be divided by a given number, and if so, performing a division, rounding the value and adding an appropriate unit to the result.
in this question I have attempted to remove all unnecessary code, thus what i am presenting here is only a fragment of the unitizer method.
why is the unitizer method outputting values in hours, when the value should be in seconds?
For clarification, the expected value is ~ 4 seconds.
public class simplified
{
public static void main(String[] args)
{
int i = 5;
double n = Math.pow(2, (double) i);
System.out.println(a6(n)); // correctly displays the expected value.
System.out.println(unitizer(a6(n)));
}
public static double a6 (double n)
{
return Math.pow(2, n); // this value is in nanoseconds.
}
public static String unitizer (double x)
{
String time = "";
if (x/(60*60*1000*1000*1000) >= 1)
{
x = Math.round(x/(60*60*1000*1000*1000) * 100.0) / 100.0;
time = x + "hr ";
}
return time;
}
}
console output:
4.294967296E9
5.25hr

There is an int overflow at the expression 60*60*1000*1000*1000. This means, that the actual result 3,600,000,000,000 is too large to be stored as an int value and is therefore 'reduced' (mod 2^31) to 817,405,952.
This can be fixed by evaluating said expression in a 'larger' arithmetic, e.g. long. There is a nice little modifier, that will force exactly that:
60L*60*1000*1000*1000
^
In particular, it hints the compiler to interpret the preceding literal 60 as a long value and in consequence the whole calculation will be done in long arithmetic.
This modifier is by the way case-insensitive; however I prefer an upper-case L, because the lower-case letter l can easily be mistaken by the number 1.
With this change, the code will not enter the if-statement, because the value x is not larger than one hour. Most probably the omitted code of unitizer will deal with this case.
On a last side note, java has an in-built TimeUnit enum, which can do these conversions, too. However, it does so in long arithmetic and not in double arithmetic as it is required for this specific question.

Java decimal point in method

I am little bit lost with double decimal point at the moment.
I have basically two methods, which will set the values for double amount and double receive. Then another integer variable where I would like to set the (receive - amount) * 100.
For example if I have two double values and I want to set their difference to an int value, then would it be possible?
My problem is that if I try to find the difference between two values, then e.g. (10.0- 9.40), then it will be 0.599999999. How can I get 0.60 out of it inside the method and use it? I know how to use NumberFormat or DecimalFormat. Should I use one inside the method to set the number of decimal points?

you can round off the value im using a decimalformat to round off the number. You can pass a double variable inside the method and this will return a number rounded off to 2 decimal points.
double RoundTo2Decimals(double val) {
DecimalFormat df2 = new DecimalFormat("###.##");
return Double.valueOf(df2.format(val));
}

You can use BigDecimal to perform the rounding, or you can use maths like this. It basically multiplies by 100, rounds and divides by 100.
/**
* Performs a round which is accurate to within 1 ulp. i.e. for values very close to 0.5 it
* might be rounded up or down. This is a pragmatic choice for performance reasons as it is
* assumed you are not working on the edge of the precision of double.
*
* #param d value to round
* #return rounded value
*/
public static double round2(double d) {
final double factor = 1e2;
return d > WHOLE_NUMBER / factor || d < -WHOLE_NUMBER / factor ? d :
(long) (d < 0 ? d * factor - 0.5 : d * factor + 0.5) / factor;
}

Easiest solution could be below. Modifications and improvements are welcomed.
double x =10.0;
double y =9.40;
int xy =0;
DecimalFormat df = new DecimalFormat("#.##");
xy = (int) (Double.valueOf(df.format(x-y))*100);
System.out.println(xy);

I think I figured it out by using Math.round().
I will just ask whether my solution is a good or a bad idea to use? I am not just so familiar with BigDecimal. Long story short about the code. Example inputs are as: a = 9.40 and b = 10.0
private int difference;
private double amountDue;
private double receive;
public void setAmount(double a) {
amountDue = a;
}
public void receive(double b) {
receive = b;
difference = (int)Math.round(100 * (receive - amount));
I just needed to get int difference as 0.60 * 100 = 60, but as I mentioned before then just calculating the difference caused 0.59999999.
Just an extra question. Is it ok for me to initialize int balance variable inside one method as I have done?

Java - Costum Classes, code not working

For some reason when I run the file the answer seems to be 0. I'm still fairly new to Java so could someone explain to me what I've done wrong.. It all seems fine to me.
public class bus {
public static void main(String[] args) {
bus fivePM = new bus(23, 120);
bus elevenAM = new bus(27, 140);
System.out.println(fivePM.gallonsUsed());
System.out.println(elevenAM.gallonsUsed());
}
private int mpg;
private int milesTravelled;
private double used;
public bus(int mpg, int milesTravelled){
this.mpg = mpg;
this.milesTravelled = milesTravelled;
}
public double gallonsUsed(){
this.used = this.mpg/this.milesTravelled;
return this.used;
}
}

In both of your instantiated bus objects, milesTravelled is less than mpg.
When you divide an int by an int, you get an int.
this.mpg/this.milesTravelled;
This will return 0 because the digits after the decimal point don't matter if it's an int.
To make them not ints, you could do things like:
this.mpg * 1.0 / this.milesTravelled
or
this.mpg/((double) this.milesTravelled)

As mentioned, diving ints gives an integer number. You can change type types of mpg and milesTravelled to double. Also you should be inverting the answer. m/g divided by m = m/mg = 1/g, not g. For example, at 10mpg traving 20m would use 2 gallons, but your calculation would give 1/2 gallon.

Use double instead of int or just carefully convert your int into a double before doing any division. This is a common problem for Java novices. Take a look at this and this. Try this out:
private double mpg;
private double milesTravelled;
private double used;
public bus(double mpg, double milesTravelled){
this.mpg = mpg;
this.milesTravelled = milesTravelled;
}
NOTE 1: When you do the division, make sure you check to see if milesTravelled is equal to 0 or not. If it is, then you will get an Exception.
NOTE 2: Change bus to Bus in the header definition of bus (which then means you will use Bus instead of bus). Using the capital letter in the beginning of a custom Object's name is a relatively common standard.

Metric Convertions Algorithm without "if-else" or "switch-case"

I want to write a program which can converts one unit to another unit. Let's say I have 2 methods.First method can do metric conversions, second method can do weight conversitons. For example;
1. long km=metricConvLength(long mil,Enum.mil,Enum.km);//first method
2. long agirlik=metricConvWeight(long kg,Enum.mil,Enum.km);//second method
I want to use Enum struct for these variables.
My program can convert these things and opposites;
sea mile-km
sea mile-mile
feet- km
feet- mil
pound- kg
ons- gr
inc - cm
yard - m
knot- km
My Question: I don't want to use if-else or switch-case structs for conversions.(Because if I use if-else struct,my code looks like so bad, much easy and slow.And I need more then 50 if-else struct when if I use these struct.This is grind.)
Can I write an algorithm for these conversions without using if-else or switch-case.
My purpose is less code, more work. Any tips about algorithm?

You do not need an if-then-else - in fact, you do not need control statements in your program. All you need is a lookup table - a Map that translates your unit enum to a double conversion factor, such that multiplying the measure in units by the conversion factor you get meters for units of space, and kilos for units of weight. Conversely, dividing meters by that factor gives you the desired units.
With this map in hand, you can do conversions for all pairs of units:
Look up the conversion factor Cs for the source units
Look up the conversion factor Cd for the destination units
Return value * Cs / Cd as your result.
For example, let's say that you want to deal with meters, yards, inches, and feet. Your map would look like this:
m - 1.0
y - 0.9144
in - 0.0254
ft - 0.3048
Now let's say you want to convert 7.5 yards to feet:
Look up Cs = 0.9144
Look up Cd = 0.3048
Compute and return Res = 7.5 * 0.9144 / 0.3048 = 22.5

I would suggest to introduce a type "MetricValue". The history of software engineering is full of projects where programmers forgot the units of the values they used. The resulting desasters are wellknown.
Moreover, I would propose an immutable class as it makes many design aspects more simple.
Defining a base unit helps you a lot as you first convert all values to it and then convert the value to your target unit. You could also apply a matrix but then you would need to precalculate the values. The size of your matrix will have the size of n^2 while the conversion from and to the base unit remains only n values. If you use complicated conversion formulas which are resource-consuming, then it makes sense. Otherwise, the benefit will be (too) small regarding the efforts.
What about this code?
public class MetricValue {
public static enum Unit {
m(1.0d), y(0.9144d), in(0.0254d), ft(0.3048d);
final static Unit baseUnit = m;
final double perBaseUnit;
private Unit(double inM) {
this.perBaseUnit = inM;
}
public double fromBaseUnit(double value) {
return value / perBaseUnit;
}
public double toBaseUnit(double value) {
return value * perBaseUnit;
}
}
final double value;
final Unit unit;
public MetricValue(double value, Unit unit) {
super();
this.value = value;
this.unit = unit;
}
public MetricValue to(Unit newUnit) {
Unit oldUnit = this.unit;
return new MetricValue(newUnit.fromBaseUnit(oldUnit.toBaseUnit(value)),
newUnit);
}
#Override
public String toString() {
return value + " " + unit.name();
}
public static void main(String[] args) {
MetricValue distanceInM = new MetricValue(1, Unit.m);
MetricValue distanceInFt = new MetricValue(6, Unit.ft);
System.out.println(distanceInM);
System.out.println(distanceInM.to(Unit.y));
System.out.println(distanceInM.to(Unit.y).to(Unit.m));
System.out.println(distanceInM.to(Unit.y).to(Unit.ft));
System.out.println(distanceInFt.to(Unit.m));
}
}
You can use the raw value and create a new metric value when you calculate. You could also add operations for basic or sophisticated arithmetic operations.
The getters were omitted here.

Associate their relative value to variables in your Enums (I guess you have one for distances, one for weights) like enum Distances { CM(100), M(100*1000), IN(254) },... and then you just have to get the ratio of the values provided, multiply by the first param, and you have your result. Use a base 100 or 1000 for the smallest unit if you want a decent precision.

In your Enum you could implement a fromString method on an enum type, Lets say your Enum name is 'Distances'
private static final Map<String,Distances> stringToEnum = new HashMap<String,Distances>;
Initialize the map:
static{
for(Distances distance: values()) {
stringToEnum.put(distance.toString(),distance);
}
}
Return enumType for String:
public static Distances getDistance(String stringValue){
return stringToEnum.get(stringValue);
}
In your methods you could just pass in:
Distance.getDistance("feet").getCalculatedDistance()

Choose one of the units to be the "base" unit (one for weight, e.g., gr; and one for distance, e.g., m). Then add methods toBaseUnit and fromBaseUnit to your enum using conversion ratios for each of your values.
No "ifs" involved, and your conversion methods will look like this:
ResultingUnit.fromBaseUnit(originalUnit.toBaseUnit(value));
Sample enum:
public enum Distance {
METER(new BigDecimal("1.0")), // Base Unit is METER
KM(new BigDecimal("1E3")),
CM(new BigDecimal("1E-2"));
private final static MathContext MC =
new MathContext(30, RoundingMode.HALF_EVEN);
private final BigDecimal conversionRatio;
Distance(BigDecimal conversionRatio) {
this.conversionRatio = conversionRatio;
}
long fromBaseUnit(BigDecimal baseUnit) {
return baseUnit.divide(conversionRatio, MC).longValue();
}
// returns BigDecimal to avoid rounding two times
// and possible division by zero
BigDecimal toBaseUnit(long originalUnit) {
return BigDecimal.valueOf(originalUnit).multiply(conversionRatio);
}
}
And the adapted conversion method:
public long metricConvLength(long value, Distance orgUnit, Distance resultUnit) {
return resultUnit.fromBaseUnit(orgUnit.toBaseUnit(value));
}
Besides being slightly faster (by avoiding Map lookups and looping through the enum values), the major advantage of this approach is that if you ever need more complex conversion operations (say, a Temperature enum with Celsius, Farenheit and Kelvin) you can override fromBaseUnit and toBaseUnit in the enum value body.
Working Example.
I've used BigDecimal for the conversion ratio and internal calculations in order to have greater control over precision and rounding behavior.