competitive programming and input - java

I'm practicing for a competitive tournament that will be in my faculty in a few weeks, and thus I encountered a small problem.
The competition restricted the use of java.io.* (except IOException...)
I need to read (from stdin) input, each test case is separated with a blank line. end of test cases - when EOF is found.
I need to find a way to get data from IO, without using java.io
so far, I got this (which works) - it returns a string containing each test case, and null when I'm out of test cases.
public static String getInput() throws IOException {
int curr=0;
int prev=0;
StringBuilder sb = new StringBuilder();
while (true) {
curr = System.in.read();
if (curr == -1) {
return null; //end of data
}
if (curr == '\r') {
curr = System.in.read();
}
if (curr == prev && curr == '\n') {
return sb.toString(); //end of test case
} //else:
sb = sb.append((char)curr);
prev = curr;
}
}
performance (for the IO) is neglected, so I don't care I read only one byte every time.
Question: Is there a more elegant (shorter and faster to code) way to achieve the same thing?

In fact, there are a few ways that you can process input in Java in competitive programming.
Approach 1: Using java.util.Scanner
This is the simplest way to read input, and it is also really straightforward to use. It can be slow if you have a huge amount of input. If your program keeps getting TLE (Time Limit Exceeded), but your program has the correct time complexity, try reading input with the second or third approach.
Initialization Scanner sc = new Scanner(System.in);
Reading an integer: int n = sc.nextInt();
Approach 2: Using java.io.BufferedReader
Use this one if there is a huge amount of input, and when the time limit of the problem is strict. It does require some more work, involving splitting the input by spaces, or using Integer.parseInt(str); to extract integers from the input.
You can find a speed comparison here https://www.cpe.ku.ac.th/~jim/java-io.html
Initialization: BufferedReader reader = new BufferedReader(System.in);
Reading an integer: int n = Integer.parseInt(reader.readLine());
Approach 3: Reading directly from FileDescriptor using custom reader
This approach is the fastest approach possible in Java. It does require a lot of work, including implementing the reader, as well as debugging should any problems arise. Use this approach if the time limit is strict and if you are allowed to bring code into the competition. This method is tested to be much faster than the second approach, but it would not usually provide you with an advantage since it is only about 2x the speed of the BufferedReader approach.
This is one implementation of such an approach written by my friend:
https://github.com/jackyliao123/contest-programming/blob/master/Utils/FastScanner.java
The usage of the reader really depends on your implementation of the reader. It is suggested to maintain one copy of the reader that is somewhat guaranteed to work, because the last thing you want in a contest is having a non-functional reader and debugging the rest of your program, thinking there are some bugs there.
Hope this helps and best wishes on your competition!

You could try the following and make it efficient by wrapping the System.in.
public static String readLine() throws IOException {
StringBuilder sb = new StringBuilder();
for (int ch; (ch = System.in.read()) > 0;)
if (ch == '\r') continue;
else if (ch == '\n') break;
else sb.append(ch);
return sb.toString();
}
EDIT: On Oracle JVM, System.in is a BufferedInputStream which wraps a FileInputStream which wraps a FileDescriptor. All these are in java.io.

You can try using the java.util.Scanner class if java.util is allowed. It has useful methods for reading in a line, a token or even a number as needed. But it is slower than BufferedReader and possibly slower than using System.in.read() directly.
Since System.in implements the InputStream interface, it might also be some speedup to use System.in.read(byte[] b) to read in the input. This way you can read in a bunch of bytes at a time instead of just the one, which should be faster. But the added complexity of having to code and debug it during the contest might not be worth it.
Edit:
Searching the web I found someone discussing using System.in.read(byte[] b) in the UVa forum back when UVa had terrible Java support.

You can use a scanner
import java.util.Scanner;//put this above the class
Scanner scanner = new Scanner(System.in); //this creates the scanner
int input = scanner.nextInt();
.nextInt() takes integers
.nextLine() takes strings

Related

Why would someone structure a while loop like this?

I'm reading a book on Java, and we're on reading from a channel into a ByteBuffer. I found the way the author was structuring the while loop odd:
try (FileChannel inCh = (FileChannel) Files.newByteChannel(file)) {
ByteBuffer lengthBuf = ByteBuffer.allocate(8);
int strLength = 0;
ByteBuffer[] buffers = { null, ByteBuffer.allocate(8) };
while(true) {
if(inCh.read(lengthBuf) == -1)
break;
lengthBuf.flip();
strLength = (int)lengthBuf.getDouble();
buffers[0] = ByteBuffer.allocate(2*strLength);
if(inCh.read(buffers) == -1) {
System.err.println("EOF found reading ht eprime string.");
break;
}
System.out.printf("String length: %3s String: %-12s Binary Value: %3d%n", strLength,
((ByteBuffer) (buffers[0].flip())).asCharBuffer().toString(),
((ByteBuffer)buffers[1].flip()).getLong());
lengthBuf.clear();
buffers[1].clear();
}
System.out.println("\nEOF reached.");
} catch (IOException e) {
I tried it like this:
while(inCh.read(lengthBuf) != -1) {
and it works the same. Would there be a practical or code clarity reason the author would write it like he did?
It is clear that your version of the loop is semantically identical. However, that's not the only thing to consider.
Notice that further down the while loop there is a second condition that breaks out of the loop. I suspect that this is what has motivated the author to use while (true).
By writing it as while (true) you alert the reader to the fact that there must be one or more breaks inside the while. The reader is going to have to look inside the loop for breaks, and will hopefully find them both.
Written your way, the casual reader might scan the top of the code and assume that the while condition was the only way for the loop to terminate.
Another point to consider is that of symmetry, or balance. As written by the original author, the loop terminations are all of the same form. Namely breaks from within the loop. Your version feels asymmetrical. One termination point in the while test, and a further termination point, of a different nature, inside the loop.
The author has two exit points, one of which prints out an error before exiting the loop. Just makes the code a little more verbose in that case. It can be written in a number of different ways of course.

Keep Looping until inputs are available in java

If I don't know the input size already, what is the the way to keep iterating in a loop until it is available, in JAVA. In C++ it can be done as following.
int main(){
int val;
while(cin >> val){
//do stuff
}
}
What is the way to do similar thing(as above) in java
Thanks in Advance.
Shantanu
You should try the following thing.
long val;
Scanner sc = new Scanner(System.in).useDelimiter("\n");
while (sc.hasNext()) {
String temp = sc.next().trim();
val = Long.parseLong(temp);
// do stuff
}
One way is to use Scanner.
long val;
Scanner sc=new Scanner(System.in);
while (sc.hasNextLong() ) {
val = sc.nextLong();
// do stuff
}
This is equivalent to the cpp code you provided. But not exactly what you asked for. It will loop as long as there are legal inputs in the read string.
Depending on your specific requirement use the methods in the Scanner class. This one reads an entire line. Which means user have to press enter in most systems.
public static void main(String[] args)
{
String str=new Scanner(System.in).nextLine();
}
Do not implement busy loops. You will probably prefer to use streams. Method read() of stream is blocked until the data arrives, so your code will be simple without busy loops and work exactly as you want:
while ( in.read() != -1) {
// do your stuff
}
or even better using buffers:
byte[] buf = new buf[MAX_SIZE]
while ( in.read(buf) != -1) {
// do your stuff
}
i believe the best way to serve your purpose is via multithreading where one thread will wait for the input from user and let the other thread know when it receives one. In the mean time the other thread will keep iterating through the loop.

An alternative to reading input from Java's System.in

I’m working on the UVa Online Judge problem set archive as a way to practice Java, and as a way to practice data structures and algorithms in general.
They give an example input file to submit to the online judge to use as a starting point (it’s the solution to problem 100).
Input from the standard input stream (java.lang.System.in) is required as part of any solution on this site, but I can’t understand the implementation of reading from System.in they give in their example solution. It’s true that the input file could consist of any variation of integers, strings, etc, but every solution program requires reading basic lines of text input from System.in, one line at a time. There has to be a better (simpler and more robust) method of gathering data from the standard input stream in Java than this:
public static String readLn(int maxLg) {
byte lin[] = new byte[maxLg];
int lg = 0, car = -1;
String line = “”;
try {
while (lg < maxLg) {
car = System.in.read();
if ((car < 0) || (car == ‘\n’)) {
break;
}
lin[lg++] += car;
}
} catch (java.io.IOException e) {
return (null);
}
if ((car < 0) && (lg == 0)) {
return (null); // eof
}
return (new String(lin, 0, lg));
}
I’m really surprised by this. It looks like something pulled directly from K&R’s “C Programming Language” (a great book regardless), minus the access level modifer and exception handling, etc. Even though I understand the implementation, it just seems like it was written by a C programmer and bypasses most of Java’s object oriented nature. Isn’t there a better way to do this, using the StringTokenizer class or maybe using the split method of String or the java.util.regex package instead?
You definitely don't have to read one byte at a time (you don't in C either, that's what fgets is for). Depending on what you're doing, you might use BufferedReader or Scanner:
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
Scanner sc = new Scanner(System.in);
BufferedReader has a readLine method, while Scanner has a variety of useful methods, including nextLine, nextInt, nextDouble, etc. which handle conversions for you. It also has a regex-based delimiter for reading arbitrary tokens.
One thing to understand about Java is that it has a very clear distinction between binary data (Streams) and character data (Readers and Writers). There are default decoders and encoders (as used above), but you always have the flexibility to choose the encoding.

a query controlled loop in java

how can i write a query controlled loop that will continue to input int values from the user,adding each to the value sum,and then ask if the user has another value to input,until the user says that there are no more values
double sum = 0;
while (user.hasMoreInput()) {
double += user.mostRecentInput();
}
where you implement hasMoreInput and mostRecentInput to your likening.
This is how I write such a loop. I shouldn't be writing your homework for you, but I would nevertheless like to demonstrate my favorite style for this kind of loop.
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
while (true) {
System.out.print("> prompt ");
String str = in.readLine();
if (str == null) break;
process(str);
}
Some people may not like
while (true) - it looks like an infinite loop because it is! It's as infinite as the user's patience in typing input.
Single-line if - some people would prefer to make this a fully bracketed 3-liner. But I don't see any use in that; it doesn't become more readable as a result.
break in mid-loop. That's what break is for! It's your escape hatch from otherwise infinite loops.
If you're used to reading Java code, this is idiomatic and legible. Advantages:
It shows steps happening in exactly the sequence they happen;
It limits the scope of str to exactly where it's needed;
It's very explicit about the termination condition;
It's very concise. Fewer lines = fewer bugs, I always say.
There are a few pieces you need to handle. First, you need to know how to receive input from the user. The Java Developer's Almanac example (http://www.exampledepot.com/egs/java.io/ReadFromStdIn.html) that I found looks like this:
try {
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
String str = "";
while (str != null) {
System.out.print("> prompt ");
str = in.readLine();
process(str);
}
} catch (IOException e) {
}
You might replace "> prompt" with something more descriptive. You'd also like to have a better way for the user to quit than entering a blank line, so maybe ask them to enter a 'q' if they are done. Then, change the comparison in the while loop to something like !str.toLowerCase().equals("q"). Then, you need to implement the process function to convert the string to an integer. Integer.parseInt(String) will return the integer value of a String that correctly represents an integer (ie, "3" or "49" but not "7e") and will throw a NumberFormatException otherwise. Because you don't want your application to fail with an exception on bad input, I think that process could just return 0 in the event of a non-Integer String (ie, when you catch a NumberFormatException).
Finally, you will want to have a sum variable initialized before your main loop, and you could add the result of process during each iteration. Then when the loop is over, you can print the result of process to the screen using System.out.println.
I purposely left out most of the code because this does sound like homework, but if you can understand all this enough to put it together I think you'll have learned it well enough to do it on your own.
This is how I typically do it. as little code as possible :).
String s;
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
while((s = in.readLine()) != null)
process(s);
The Java Developer's Almanac is always a good source of basic examples such as yours.
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
String str = "";
while (str != null) {
System.out.print("> prompt ");
str = in.readLine();
process(str);
}
Edit: Apparently some people think that a demonstration of the essentials of some technique should have error-checking. Perhaps I should also have commented the code, and provided a spec. Next time, I'll also develop some custom annotations to express pre and post conditions, or draft an implementation in Eiffel.

Most efficient idiom to read one integer only from a file?

In trying to resolve Facebook's Puzzle "Hoppity Hop", http://www.facebook.com/careers/puzzles.php?puzzle_id=7, I'm reading one integer only from a file. I'm wondering if this is the most efficient mechanism to do this?
private static int readSoleInteger(String path) throws IOException {
BufferedReader buffer = null;
int integer = 0;
try {
String integerAsString = null;
buffer = new BufferedReader(new FileReader(path));
// Read the first line only.
integerAsString = buffer.readLine();
// Remove any surplus whitespace.
integerAsString = integerAsString.trim();
integer = Integer.parseInt(integerAsString);
} finally {
buffer.close();
}
return integer;
}
I have seen How do I create a Java string from the contents of a file?, but I don't know the efficiency of the idiom which answers that question.
Looking at my code, it seems like a lot of lines of code and Objects for a trivial problem...
The shortest method would be with a Scanner:
private static int readSoleInteger(String path) {
Scanner s = new Scanner(new File(path));
int ret = s.nextInt();
s.close();
return ret;
}
Note that Scanner swallows any IOExceptions, so that simplifies things a lot.
As for "most efficient"... well, the simple act of opening a file from the disk is likely to be the slowest part of any method you write for this. Don't worry too much about efficiency in this case.
Edit: I hadn't realized that the integer can have whitespace on either side of it. My code does not account for this currently, but it's easy to make the Scanner skip things. I've added the line
s.skip("\\s+");
to correct this.
Edit 2: Never mind, Scanner ignores whitespace when it's trying to parse numbers:
The strings that can be parsed as numbers by an instance of this class are specified in terms of the following regular-expression grammar:
(regexes snipped)
Whitespace is not significant in the above regular expressions.
I would use the Scanner class:
Scanner sc = new Scanner(new File("my_file"));
int some_int = sc.nextInt();

Categories