This question already has answers here:
Long float-number output shows letters
(5 answers)
Closed 2 years ago.
I'm working on creating a workbench for testing the performance of sorting algorithms. For some of my performance stats, it appears that the results aren't being returned correctly. Larger values are being stored as decimals with an E towards the end for example 1.2497388E7 instead of an 8 digit whole number. I'm just wondering if anyone knows what might be causing this.
Results from Running sorting algorithm for various sizes of arrays
Thanks
This is common mathematical notation to show that the number is what is displayed x10^ what's after E :)
For example:
1.24E5 = 124000 (1.24*10^5).
In other words: It's just a really big number
I don't think that this is a problem with the data itself (that should be stored correctly); it's probably more to do with how you are outputting it.
When your number is over a certain threshold of size, it is common to notate it in a compressed fashion using E. This is used to denote standard form, which is where a number is written in the form number x 10^n.
If you are using the standard System.out functions for the console, it is probably being formatted that way automatically due to size.
If you want to prevent this, use System.out.printf with the %f flag for formatting.
For example:
double number = 10.5;
System.out.printf("Value at double is: %f\n", number);
For more info, see the format documentation
Related
I'm trying to convert some AS400/RPG code into Java.
I was able to find an example online that mirrored what I am seeing in the code:
d elevensix s 11 6 inz(26285.88991)
d seventwo s 7 2
c eval(h) seventwo = elevensix
c eval *inlr = *on
I have written code in Java and I am finding that the results of the rounding I see in the RPG code, it is not matching the type of rounding I see in Java. Here is a sample of the rounding I am doing in Java:
private Long roundAmount(Double amount) {
return Math.round(amount);
}
In practice my code generates results that match up to the results from the RPG code however I am finding examples which are inconsistent in the logic; some which round up as expected and others that don't.
I have worked heavily with Java; this is my first foray into RPG. I'm honestly not even sure where to begin. For example, in the RPG code above; how exactly is it working? I see the results of the operation being put into a variable marked with 2 decimal places; is the rounding implicit? Searching online I find the following definition for how Java handles rounding:
The Math.round() method in Java is used to round a number to its​
closest integer. This is done by adding 1/2 to the number,
taking the floor of the result, and casting the result to an integer
data type.
Honestly this is clear and concise. I have not found a comparable explanation for how it works in RPG; to be clear this is programming on an AS400 which uses RPG, but a much older version than what I believe the current standard is. However an explanation even for the modern implementation would be a start.
The RPG code you posted does a different thing than your Java code.
The Java code transform a Double to a Long, while the RPG code is rounding a number with 6 decimals to a number with 2 decimals.
In particular, elevensix is a number with 11 digits which 6 of them are for the decimal part and 5 of them for the integer part; seventwo is a number with 7 digits which 2 of them are for the decimal part and 5 of them for the integer part.
eval(h) is copying the value of elevensix into seventwo and rounding it to 2 decimal digits with "half-adjust" logic (that's what the "h" stand for, without it the decimals would be truncated).
From the RPG documentation (that you can find also in PDF format) and in particular here:
Half-adjusting is done by adding 5 (-5 if the field is negative) one
position to the right of the last specified decimal position in the
result field.
Which to me seems similar to what Math.round does, but generalized to any decimal position.
Also it would correspond to the Java Math RoundingMode.HALF_UP.
Since you didn't provide some actual examples that generate the inconcistencies it's difficult to give you a definitive solution.
Anyway, that RPG code in Java could be replicated with BigDecimals with the method setScale like this:
double result = new BigDecimal(amount.toString())
.setScale(2, RoundingMode.HALF_UP)
.doubleValue();
You might also consider to use Apache Commons Math method round which, looking at the implementation, does pretty much the same thing.
Your problem could also be caused by the limited precision of Double and in that case you should just use BigDecimals, see Double vs. BigDecimal?.
I am writing a basic neural network in Java and I am writing the activation functions (currently I have just written the sigmoid function). I am trying to use doubles (as apposed to BigDecimal) with hopes that training will actually take a reasonable amount of time. However, I've noticed that the function doesn't work with larger inputs. Currently my function is:
public static double sigmoid(double t){
return (1 / (1 + Math.pow(Math.E, -t)));
}
This function returns pretty precise values all the way down to when t = -100, but when t >= 37 the function returns 1.0. In a typical neural network when the input is normalized is this fine? Will a neuron ever get inputs summing over ~37? If the size of the sum of inputs fed into the activation function vary from NN to NN, what are some of the factors the affect it? Also, is there any way to make this function more precise? Is there an alternative that is more precise and/or faster?
Yes, in a normalized network double is fine to use. But this depend on your input, if your input layer is bigger, your input sum will be bigger of course.
I have encountered the same problem using C++, after t become big, the compiler/rte does not even take into account E^-t and returns plain 1, as it only calculates the 1/1 part. I tried to divide the already normalized input by 1000-1000000 and it worked sometimes, but sometimes it did not as I was using a randomized input for the first epoch and my input layer was a matrix 784x784. Nevertheless, if your input layer is small, and your input is normalized this will help you
The surprising answer is that double is actually more precision than you need. This blog article by Pete Warden claims that even 8 bits are enough precision. And not just an academic idea: NVidia's new Pascal chips emphasize their single-precision performance above everything else, because that is what matters for deep learning training.
You should be normalizing your input neuron values. If extreme values still happen, it is fine to set them to -1 or +1. In fact, this answer shows doing that explicitly. (Other answers on that question are also interesting - the suggestion to just pre-calculate 100 or so values, and not use Math.exp() or Math.pow() at all!)
This question already has answers here:
How to round a number to n decimal places in Java
(39 answers)
Closed 6 years ago.
I am doing this Java question :
Jalaj purchased a table for Rs.200.4 and due to some scratches on its
top he had to sell it for Rs.176.5. Find his loss and loss%.
LOSS : Cost Price - Selling Price
LOSS% : (LOSS/Cost Price)*100
a. Declare four double variables i.e. costprice, sellingPrice, loss,
lossPercentage
b. Assign 200.4 to costPrice and 176.5 to sellingPrice.
c. Print loss and lossPercentage according to the given formulas like:
823.67 8.23 d.
For printing upto two decimal places use
System.out.printf("%.2f\n", loss);
Note:
output for both should be upto two decimal places
Output should be displayed in two different lines
My code:
/*Write your code here */
import java.util.Scanner;
class bkws{
public static void main(String args[]){
double costPrice,sellingPrice,loss,lossPercentage;
costPrice=200.4;
sellingPrice=176.5;
loss=costPrice-sellingPrice;
lossPercentage=(loss/costPrice)*100;
System.out.print("%.2f",loss);
System.out.println("%.2f",lossPercentage);
}
}
Now I am thinking of using Math.round but for rounding off to 2 decimal places it should be:
Math.round(number*100)/100;
But it is giving error and I also want to know that if there is any easy way to round off to n decimal places without using Math.round in Java.
double costPrice,sellingPrice,loss,lossPercentage;
costPrice=200.4;
sellingPrice=176.5;
loss=costPrice-sellingPrice;
lossPercentage=(loss/costPrice)*100;
System.out.println(String.format("%.2f", loss));
System.out.println(String.format("%.2f", lossPercentage));
OR
double costPrice,sellingPrice,loss,lossPercentage;
costPrice=200.4;
sellingPrice=176.5;
loss=costPrice-sellingPrice;
lossPercentage=(loss/costPrice)*100;
loss = (int)Math.round(loss * 100)/(double)100;
lossPercentage = (int)Math.round(lossPercentage * 100)/(double)100;
System.out.println(loss);
System.out.println(lossPercentage);
printf with an f for format at the end is a different method to print or println
For printing upto two decimal places use
System.out.printf("%.2f\n", loss);
BTW: Using %n inside a format string is a better choice than \n as %n is platform independent.
You don't need to round the result if you using rounding in the format.
The real lesson to be learned here: all of the things you need are clearly documented.
You can start here to learn about System.out; to then go forward and understand how such PrintStreams work in general.
You will also find nice explanations there how those "format" patterns actually work.
In other words: the one big thing about using Java is that A) there is a library method for almost everything and B) all of that is documented with extraordinary quality. There is no need to speculate; and heck: not even a need to ask other folks for such information. It is all there, waiting for you.
This question already has answers here:
Why are floating point numbers inaccurate?
(5 answers)
Closed 6 years ago.
2.333333333333333 - 1.666666666666667 It appends 1 in the last, increasing one bit. How to resolve it.
In the answer its giving, 0.6666666....1, but it should be 0.66666....6
I am going to guess you meant.6666...7 but it should be .6666...6 if you plan on programming I would strongly recommend that you learn how software interacts with the hardware. When a computer stores memory it cannot save the same amount of positive numbers as negative numbers. The reason being that the computer uses somthing of the format like,
10000001111
For (this is in binary) negative numbers where the one in front indicates that it is negative while,
00000001111
is the positive version of the same number (the absolute value for all you math nerds). Seeing this you should realize that you can store more positive numbers than negative numbers, so you need to be careful with whatever type you are using. However since your question is not 100% clear I cannot guarantee this will 100% answer your question. Good luck...
Well I am working on a big dataset and after some calculations I am getting values for the features like 4.4E-5. I read it somewhere those values means 0.000044 that is ten to the power minus 5. So my question is whenever I want to use them for further processing will these values behave same as float works or do I need some other data type?
Yes, it is an extended notation presenting the same binary floating point data type.
Both 4.4E-5 and 0.00044 are the same. And that value only approximates 0.000044 with a sum of powers of 2: 2^-18 + ...
Multiplying lots of small numbers leads to underflow. Take the log and add. This technique is universal in computer science. Many of the Google hits for "underflow log" are useful, including SO hits, other techniques for dealing with it, etc.