Develop Reference

Converting a binary string to integer using a basic mathematical operator

Main:
public class Main{
public static void main(String[] args){
System.out.println(Convert.BtoI("10001"));
System.out.println(Convert.BtoI("101010101"));
}
}
Class:
public class Convert{
public static int BtoI(String num){
Integer i= Integer.parseInt(num,2);
return i;
}
}
So I was working on converters, I was struggling as I am new to java and my friend suggested using integer method, which works. However, which method would be most efficient to convert using the basic operators (e.g. logical, arithmetic etc.)

.... my friend suggested using integer method, which works.
Correct:
it works, and
it is the best way.
However, which method would be most efficient to convert using the basic operators (e.g. logical, arithmetic etc.)
If you are new to Java, you should not be obsessing over the efficiency of your code. You don't have the intuition.
You probably shouldn't optimize this it even if you are experienced. In most cases, small scale efficiencies are irrelevant, and you are better off using a profiler to validate your intuition about what is important before you start to optimize.
Even if this is a performance hotspot in your application, the Integer.parseint code has (no doubt) already been well optimized. There is little chance that you could do significantly better using "primitive" operations. (Under the hood, the methods will most likely already be doing the same thing as you would be doing.)
If you are just asking this because you are curious, take a look at the source code for the Integer class.

If you want to use basic arithmetic to convert binary numbers to integers then you can replace the BtoI() method within the class Convert with the following code.
public static int BtoI(String num){
int number = 0; // declare the number to store the result
int power = 0; // declare power variable
// loop from end to start of the binary number
for(int i = num.length()-1; i >= 0; i--)
{
// check if the number encountered is 1
/// if yes then do 2^Power and add to the result
if(num.charAt(i) == '1')
number += Math.pow(2, power);
// increment the power to use in next iteration
power++;
}
// return the number
return number;
}
Normal calculation is performed in above code to get the result. e.g.
101 => 1*2^2 + 0 + 1*2^0 = 5

Testing a function that may produce different outputs every time it is called [duplicate]

This question already has answers here:
Java random numbers using a seed
(7 answers)
Closed 5 years ago.
Given the function:
static boolean chance(int percentage) {
return percentage != 0 && random.nextInt(101) <= percentage;
}
and a test for that function:
#Test
public void chance_AlwaysFalse_Percentage0() {
assertFalse(chance(0));
}
The test does not provide with certainty that chance will always return true. I could change the change function to the following:
static boolean chance(int percentage) {
return random.nextInt(101) <= percentage;
}
and the test would still pass. However, there is a very small chance that random.nextInt(100) will return 0, which would make the function return true, making the test fail.
I could execute this test a billion times as well, but given the nature of random numbers, there is still a minimal chance of failure.
How should I go about testing a function like this? Should it be tested at all? What is a better approach to this problem?

There are some functionalities in java that may serve for repeatable unit tests:
Random numbers: the Random constructor with a seed, for instance new Random(13) will always give the same sequence of random numbers. This already has been exploited to find a random sequence starting with 1, 2, 3, ..., 10. Or the alphabetic letters of someones name.
Time: the new java time functions allow for a faked clock, so "now" is always at a given time. Clock.fixed
And then there are mocking frameworks, that instrument the byte code of arbitrary calls so the return a provided result. Also useful for blending out more complex contexts.

Automated tests can't catch everything. In fact, the first example of your function might also have a bug, in that chance(1) will have a 2% chance instead of a 1% chance of returning true (since it would return true if the random number was either 0 or 1). But if you only test 0 and 100, it would pass those tests 100% of the time. (In fact, 0 and 100 are the only values that will return true the correct percentage of the time; everything else will be off by 1%. The effects of that bug are subtle enough that you may or may not ever notice it, depending on how the function is used.)
You could put your tests in a loop, if you really wanted to. If you ran the chance_AlwaysFalse_Percentage0 test 10,000 times, the odds would be very much in favor of any particular random number being hit. (No, it's not technically guaranteed, but if you calculate the odds, I think you'd be satisfied.) I'm not sure if that's worth doing.

Software random number generators are not random
They are deterministic if they are seeded with the same seed.
I also corrected the comparison logic to be correct in the range check.
Testable Implementation
import javax.annotation.ParametersAreNonnullByDefault;
import java.util.Random;
#ParametersAreNonnullByDefault
public class Q47336122
{
private final Random random;
public Q47336122(final long seed)
{
this.random = new Random(seed);
}
public boolean chance(final int percentage)
{
if (percentage <= 0) { return false; }
else if (percentage >= 100) { return true; }
else
{
final int r = this.random.nextInt(100);
return r > 0 && r <= percentage;
}
}
}
Deterministic Test
import org.junit.Test;
import javax.annotation.ParametersAreNonnullByDefault;
import static org.hamcrest.CoreMatchers.is;
import static org.hamcrest.MatcherAssert.assertThat;
#ParametersAreNonnullByDefault
public class Q47336122Test
{
#Test
public void testChance()
{
final Q47336122 q = new Q47336122(1000L);
/* poor man's code generator */
// for (int i=0; i <= 100; i++) {
// System.out.println(String.format("assertThat(q.chance(%d),is(%s));", i, q.chance(i)));
// }
assertThat(q.chance(0),is(false));
assertThat(q.chance(1),is(false));
assertThat(q.chance(2),is(false));
assertThat(q.chance(3),is(false));
assertThat(q.chance(4),is(false));
assertThat(q.chance(5),is(false));
assertThat(q.chance(6),is(false));
assertThat(q.chance(7),is(false));
assertThat(q.chance(8),is(false));
assertThat(q.chance(9),is(false));
assertThat(q.chance(10),is(false));
assertThat(q.chance(11),is(false));
assertThat(q.chance(12),is(false));
assertThat(q.chance(13),is(false));
assertThat(q.chance(14),is(false));
assertThat(q.chance(15),is(false));
assertThat(q.chance(16),is(false));
assertThat(q.chance(17),is(false));
assertThat(q.chance(18),is(true));
assertThat(q.chance(19),is(false));
assertThat(q.chance(20),is(false));
assertThat(q.chance(21),is(false));
assertThat(q.chance(22),is(false));
assertThat(q.chance(23),is(false));
assertThat(q.chance(24),is(true));
assertThat(q.chance(25),is(false));
assertThat(q.chance(26),is(false));
assertThat(q.chance(27),is(false));
assertThat(q.chance(28),is(false));
assertThat(q.chance(29),is(false));
assertThat(q.chance(30),is(false));
assertThat(q.chance(31),is(false));
assertThat(q.chance(32),is(false));
assertThat(q.chance(33),is(false));
assertThat(q.chance(34),is(false));
assertThat(q.chance(35),is(false));
assertThat(q.chance(36),is(true));
assertThat(q.chance(37),is(false));
assertThat(q.chance(38),is(true));
assertThat(q.chance(39),is(false));
assertThat(q.chance(40),is(true));
assertThat(q.chance(41),is(false));
assertThat(q.chance(42),is(true));
assertThat(q.chance(43),is(false));
assertThat(q.chance(44),is(false));
assertThat(q.chance(45),is(false));
assertThat(q.chance(46),is(false));
assertThat(q.chance(47),is(false));
assertThat(q.chance(48),is(false));
assertThat(q.chance(49),is(false));
assertThat(q.chance(50),is(true));
assertThat(q.chance(51),is(true));
assertThat(q.chance(52),is(false));
assertThat(q.chance(53),is(true));
assertThat(q.chance(54),is(false));
assertThat(q.chance(55),is(true));
assertThat(q.chance(56),is(false));
assertThat(q.chance(57),is(true));
assertThat(q.chance(58),is(false));
assertThat(q.chance(59),is(false));
assertThat(q.chance(60),is(true));
assertThat(q.chance(61),is(false));
assertThat(q.chance(62),is(false));
assertThat(q.chance(63),is(true));
assertThat(q.chance(64),is(true));
assertThat(q.chance(65),is(true));
assertThat(q.chance(66),is(true));
assertThat(q.chance(67),is(true));
assertThat(q.chance(68),is(true));
assertThat(q.chance(69),is(false));
assertThat(q.chance(70),is(false));
assertThat(q.chance(71),is(true));
assertThat(q.chance(72),is(true));
assertThat(q.chance(73),is(true));
assertThat(q.chance(74),is(true));
assertThat(q.chance(75),is(false));
assertThat(q.chance(76),is(true));
assertThat(q.chance(77),is(true));
assertThat(q.chance(78),is(true));
assertThat(q.chance(79),is(false));
assertThat(q.chance(80),is(true));
assertThat(q.chance(81),is(false));
assertThat(q.chance(82),is(true));
assertThat(q.chance(83),is(true));
assertThat(q.chance(84),is(true));
assertThat(q.chance(85),is(true));
assertThat(q.chance(86),is(true));
assertThat(q.chance(87),is(true));
assertThat(q.chance(88),is(true));
assertThat(q.chance(89),is(true));
assertThat(q.chance(90),is(true));
assertThat(q.chance(91),is(true));
assertThat(q.chance(92),is(true));
assertThat(q.chance(93),is(true));
assertThat(q.chance(94),is(true));
assertThat(q.chance(95),is(true));
assertThat(q.chance(96),is(true));
assertThat(q.chance(97),is(true));
assertThat(q.chance(98),is(true));
assertThat(q.chance(99),is(true));
assertThat(q.chance(100),is(true));
}
}
No matter how many times you run this test it will always pass.
It is a trivial exercise for the reader to expand this to test for thousands or millions of inputs. As long as the seed is the same as when the test data is generated, it will pass when tested.
An injectable random number generator instance would be a better design and would make testing even easier in cases where the random number source is actually not deterministic.
static methods are an anti-pattern and is the crux of your problem with testing as it stands, there is nothing here that can not be fixed with some simple refactoring to get rid of the static stuff and make it deterministic and testable as my code shows.

Performance difference between assignment and conditional test

This question is specifically geared towards the Java language, but I would not mind feedback about this being a general concept if so. I would like to know which operation might be faster, or if there is no difference between assigning a variable a value and performing tests for values. For this issue we could have a large series of Boolean values that will have many requests for changes. I would like to know if testing for the need to change a value would be considered a waste when weighed against the speed of simply changing the value during every request.
public static void main(String[] args){
Boolean array[] = new Boolean[veryLargeValue];
for(int i = 0; i < array.length; i++) {
array[i] = randomTrueFalseAssignment;
}
for(int i = 400; i < array.length - 400; i++) {
testAndChange(array, i);
}
for(int i = 400; i < array.length - 400; i++) {
justChange(array, i);
}
}
This could be the testAndChange method
public static void testAndChange(Boolean[] pArray, int ind) {
if(pArray)
pArray[ind] = false;
}
This could be the justChange method
public static void justChange(Boolean[] pArray, int ind) {
pArray[ind] = false;
}
If we were to end up with the very rare case that every value within the range supplied to the methods were false, would there be a point where one method would eventually become slower than the other? Is there a best practice for issues similar to this?
Edit: I wanted to add this to help clarify this question a bit more. I realize that the data type can be factored into the answer as larger or more efficient datatypes can be utilized. I am more focused on the task itself. Is the task of a test "if(aConditionalTest)" is slower, faster, or indeterminable without additional informaiton (such as data type) than the task of an assignment "x=avalue".

As #TrippKinetics points out, there is a semantical difference between the two methods. Because you use Boolean instead of boolean, it is possible that one of the values is a null reference. In that case the first method (with the if-statement) will throw an exception while the second, simply assigns values to all the elements in the array.
Assuming you use boolean[] instead of Boolean[]. Optimization is an undecidable problem. There are very rare cases where adding an if-statement could result in better performance. For instance most processors use cache and the if-statement can result in the fact that the executed code is stored exactly on two cache-pages where without an if on more resulting in cache faults. Perhaps you think you will save an assignment instruction but at the cost of a fetch instruction and a conditional instruction (which breaks the CPU pipeline). Assigning has more or less the same cost as fetching a value.
In general however, one can assume that adding an if statement is useless and will nearly always result in slower code. So you can quite safely state that the if statement will slow down your code always.
More specifically on your question, there are faster ways to set a range to false. For instance using bitvectors like:
long[] data = new long[(veryLargeValue+0x3f)>>0x06];//a long has 64 bits
//assign random values
int low = 400>>0x06;
int high = (veryLargeValue-400)>>0x06;
data[low] &= 0xffffffffffffffff<<(0x3f-(400&0x3f));
for(int i = low+0x01; i < high; i++) {
data[i] = 0x00;
}
data[high] &= 0xffffffffffffffff>>(veryLargeValue-400)&0x3f));
The advantage is that a processor can perform operations on 32- or 64-bits at once. Since a boolean is one bit, by storing bits into a long or int, operations are done in parallel.

Java Recursion - Did I do this right? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My job is to write a recursive version to this method. From what I understand Recursion is starting with a base call (if something then return) followed by an else which unwinds back to the original base. Like starting with a deck, adding on to the deck then removing cards from the deck until you are back to the original deck.
With that in mind here it is.
public static long fact(int n)
{
long result = 1;
while(n > 0)
{
result = result * n;
n = n - 1;
}
return result;
}
//my recursive version:
public static void recFact(int n)
{
if(n==0)
{
return n; // ir 0 it really doesn't matter right?
}
else
{
return recFact(n-1);
}
}
This is just an example test problem for an exam I have coming up, just want to make sure I have a handle on recursion. Did I do this right? If not what am I missing? please no answers in questions, just tell me what I did wrong and maybe some advice on better ways to understand it.
Thanks.

No, this recursive solution is not correct.
For every positive n, you're just return rectFact(n-1), which will recourse until you reach 0, at which point it will return. In other words, your function will always return 0. You're missing the part where you multiply the current n with rectFact(n-1). Additionally, note that 0! is 1, not 0:
public static int recFact(int n)
{
if(n==0)
{
return 1;
}
else
{
return n * recFact(n-1);
}
}
And finally, since the if clause returns, the else is somewhat redundant. This doesn't affect the method's correctness, of course, but IMHO the code looks cleaner without it:
public static int recFact(int n)
{
if(n==0)
{
return 1;
}
return n * recFact(n-1);
}

Your recursive version does no multiplication, and it will return zero for any input. So no, you didn't do it right.
But, the recursive version DOES recurse, so you have that going for you! To understand what's going wrong, walk through a very simple case.
Client calls recFact(3)
This will return to client recFact(2)
Which will return to above recFact(1)
Which will return to above recFact(0)
Which will return to above 0.
There are two major things going wrong:
Your base case is wrong (zero is too low)
You're not doing any multiplication
Good attitude about not wanting the solution handed to you! Hopefully these pointers wil help you figure it out.
EDIT: Apparently I misunderstood your grammar and you did want the solution.

Any recursive function needs three things:
The terminating condition: This tells the function when to stop calling itself. This is very important to avoid infinite recursion and avoid stack overflow exceptions.
The actual processing: You need to run the actual processing within each function. In your non recursive case, this was result = result * n. This is missing from your recursive version!
A collector/agggregator variable: You need some way to store the partial result of the recursive calls below you. So you need some way to return the result of recFact so that you can include it in processing higher up in the call chain. Note that you say return recFact(n - 1) but in the definition recFact returns void. That should probably be an int.

Based from your example you are missing the return type of your recFact which is int
Also recFact will always return 0 because you are not multiplying n each time to the recursion call of the method.

There are two ways to write recursive routines. One is the "standard" way that we all are taught. This is one entry point that must first check to see if the recursive chain is at an end (the escape clause). If so, it returns the "end of chain" value and ends the recursion. If not at the end, it performs whatever calculation it needs to get a partial value according to the level and then calls itself passing a value the next increment closer to the end of the chain.
private final int InitialValue = 15;
System.out.println( "Fact(" + InitialValue + ") = " + recFact( InitialValue ) );
public int recFact( int val ){
if( val < 2 ){
return 1;
}
else{
return recFact( val - 1 ) * val; // recursive call
}
}
//Output: "Fact(15) = 2004310016"
In regular recursion, a partial answer is maintained at each level which is used to supplement the answer from the next level. In the code above, the partial answer is val. When first called, this value is 15. It takes this value and multiplies it by the answer from Fact(14) to supply the complete answer to Fact(15). Fact(14) got its answer by multiplying 14 by the answer it got from Fact(13) and so on.
There is another type of recursion called tail recursion. This differs in that partial answers are passed to the next level instead of maintained at each level. This sounds complicated but in actuality, make the recursion process much simpler. Another difference is that there are two routines, one is non recursive and sets up the recursive routine. This is to maintain the standard API to users who only want to see (and should only have to see)
answer = routine( parameter );
The non-recursive routines provides this. It is also a convenient place to put one-time code such as error checking. Notice in the standard routine above, if the user passed in -15 instead of 15, the routine could bomb out. That means that in production code, such a test must be made. But this test will be performed every time the routine is entered which means the test will be made needlessly for all but the very first time. Also, as this must return an integer value, it cannot handle an initial value greater than 19 as that will result in a value that will overflow the 32-bit integer container.
public static final int MaxFactorialSeq = 20;
private final int InitialValue = 15;
System.out.println( "Fact(" + InitialValue + ") = " + recFact( InitialValue ) );
public int recFact( int value ){
if( value < 0 || value > MaxFactorialSeq ){
throw new IllegalArgumentException(
"Factorial sequence value " + value + " is out of range." );
}
return recFact( value, 1 ); // initial invocation
}
private int recFact( int val, int acc ){
if( val < 2 ){
return acc;
}
else{
return recFact( val - 1, acc * val ); // recursive call
}
}
//Output: "Fact(15) = 2004310016"
Notice the public entry point contains range checking code. This is executed only once and the recursive routine does not have to make this check. It then calls the recursive version with an initial "seed" of 1.
The recursive routine, as before, checks to see if it is at the end of the chain. If so, it returns, not 1 as before, but the accumulator which at this point has the complete answer. The call chain then just rewinds back to the initial entry point in the non-recursive routine. There are no further calculations to be made as the answer is calculated on the way down rather than on the way up.
If you walk though it, the answer with standard recursion was reached by the sequence 15*14*13*...*2*1. With tail recursion, the answer was reached by the sequence 1*15*14*...*3*2. The final answer is, of course, the same. However, in my test with an initial value of 15, the standard recursion method took an average of 0.044 msecs and the tail recursion method took an average of 0.030 msecs. However, almost all that time difference is accounted for by the fact that I have the bounds checking in my standard recursion routine. Without it, the timing is much closer (0.036 to 0.030) but, of course, then you don't have error checking.
Not all recursive routines can use tail recursion. But then, not all recursive routines should be. It is a truism that any recursive function can be written using a loop. And generally should be. But a Factorial function like the ones above can never exceed 19 levels so they can be added to the lucky few.

The problem with recursion is that to understand recursion you must first understand recursion.
A recursive function is a function which calls itself, or calls a function which ultimately calls the first function again.
You have the recursion part right, since your function calls itself, and you have an "escape" clause so you don't get infinite recursion (a reason for the function not to call itself).
What you are lacking from your example though is the actual operation you are performing.
Also, instead of passing a counter, you need to pass your counter and the value you are multiplying, and then you need to return said multiplied value.
public static long recFact(int n, long val)
{
if(n==1)
{
return val;
}
else
{
return recFact(n-1, val) * n;
}
}

proper way to store large numbers in a variable

I would like to play around with numbers and however elementary, Ive been writing algorithms for the fibonacci sequence and a brute force path for finding prime numbers!
Im not a programmer, just a math guy.
However, a problem I run into quiet often is that a long long, double and floats often run out of room.
If I wanted to continue to work in JAVA, in what way can I create my own data type so that I dont run out of room.
Conceptually, I thought to put 3 doubles together like so,
public class run {
static double a = 0;
static double b = 0;
//static double c = 0;
static void bignumber(boolean x) {
if (x == true && a < 999999999) {
++a;
} else if (x == true && a == 999999999) {
++b;
a = 0;
}
System.out.print(b + "." + a + " \n");
}
public static void main(String[] args) {
while(true) {
bignumber(true);
}
}
}
is there a better way to do this,
I would like to one day be able to say
mydataType X = 18476997032117414743068356202001644030185493386634
10171471785774910651696711161249859337684305435744
58561606154457179405222971773252466096064694607124
96237204420222697567566873784275623895087646784409
33285157496578843415088475528298186726451339863364
93190808467199043187438128336350279547028265329780
29349161558118810498449083195450098483937752272570
52578591944993870073695755688436933812779613089230
39256969525326162082367649031603655137144791393234
7169566988069
or any other number found on this site
I have also tried
package main;
import java.math.BigInteger;
public class run {
BigDecimal a = 184769970321174147430683562020019566988069;
public static void main(String[] args) {
}
}
But it still seems to be out of range

Use BigDecimal (instead of double), and BigInteger (instead of int, long) for that purpose, But you can only work with them by their methods. No operators, can be used.
Used like this:
BigInteger big = new BigInteger("4019832895734985478385764387592") // Strings...
big.add(new BigInteger("452872468924972568924762458767527");
Same with BigDecimal

BigDecimal is the class used in java where you need to represent very large or very small numbers, and maintain precision. The drawbacks are that it is not a primitive, so you can't use the normal math operators (+/-/*/etc), and that it can be a little processor/memory intensive.

You can store large numbers like this:
length
digits[]
and implement your math for them. This is not very complicated. As a hint, to make everything more simple you can store the digits in reverse order. This will make your math simpler to implement - you always add nr[k] with nr[k] and have room for transport for any length numbers, just remember to fill with 0 the shorter one.
In Knuth Seminumeric Algorithms book you can find a very nice implementation for all operations.