I am try to solve a prob in one of the Programming contests.The actual prob is sort a given list of numbers.I am using a algorithm with complexity(nlog n) and that is the maximum level of optimization I can do with the algorithm.Now from the forum I understood that I need a faster I/O for which I should create a new reader class.I/O are from and to the standard I/O.
I want to know how to create a reader class (insted of other standard Reader classes)?
Thanks in Advance!
This question really seems like a "barking up the wrong tree" kind of question. I find it unlikely that you'd be able to subclass Reader and make it run faster, given that you don't know how to do it. If there was an obvious way, wouldn't it already be in java?
If I/O speed is the problem, perhaps it's the method you're using. There are several different types of Readers, and several algorithms to use them. For example, do you read the whole file at once then parse it, or do you read one line at a time? Some of these options may not even be possible depending on the type of file, size of the file, and other conditions.
If you're trying to solve a problem for a programming contest, solving the actual problem should be all that's required. You shouldn't have to create your own Reader class unless that's a part of the problem being described. Besides, you mention that you're getting your direction from a forum. How do you know they even know what they're talking about?
So, I feel like you're doing something wrong here that's outside the scope of the question you asked.
Related
I'm trying to find out, what are the methods mark() and reset() of BufferedReader really useful for?
I understand what they are doing, but for going back and forth in some text I never used them - usually I solve this problem by reading either a sequence of chars or the whole line in an array or StringBuilder and go back and forth through it.
I believe there must be some reason why these methods are present in the BufferedReader and other Reader implementations supporting it but I'm unable to make an assumption why.
Does the usage of mark() & reset provide some benefit compared to reading the data in our own array and navigating through it?
I've searched through the codebase of one of my large projects I'm working on (mainly Java backend using Spring Boot), with lots of dependencies on the classpath and the only thing for which the mark & reset methods were used (in only very few libraries) was skipping an optional BOM character at the beginning of a text file. And even for this simple use case, I find it a bit contrived to do it that way.
Also, I was searching for other tutorials and on Stackoverflow (e.g. What are mark and reset in BufferedReader?) and couldn't find any explanation why to actually solve these kinds of problems using mark & reset. All code examples only explain what the methods are doing on "hello world" examples (jumping from one position in the stream back to a previous position for no particular reason). Nowhere I could find any explanation why someone should actually use it among other ways which sound more elegant and aren't really of worse performance.
I haven't used them myself, but a case that springs to mind is where you want to copy the data into a structure that needs to be sized correctly.
When reading streams and copying data into a target data structure (perhaps after parsing it), you always have the problem that you don't know how big to make your target in advance. The mark/rewind feature lets you mark, read the stream, parse it quickly to calculate the size, reset, allocate the memory, and then re-parse copying the data this time. There are of course other ways of doing it (e.g., using your own dynamic buffer), but if your code is already centered around the Reader concept then mark/reset lets you stay with that.
That said, even BufferedReader's own readLine method doesn't use this technique (it creates a StringBuffer internally).
I am currently just started writing my very own java client for accumulo.
I am able to write and read records, I now want to modify some existing keys using the TransformingIterator class (https://accumulo.apache.org/1.6/apidocs/org/apache/accumulo/core/iterators/user/TransformingIterator.html#TransformingIterator())
Since it was a while since I coded in java last time, I don't really understand how to use this class and I'm not able to find any good examples or explanations on this.
Does someone know how to use it?
Thanks.
I'd caution you against trying to use this class on your own. It has a lot of caveats that make it tricky to get correct (not to mention Iterators being tricky already on their own).
Unless you have a very large amount of data (terabytes), it is likely going to be easier to transform your data using some batch-processing tool (e.g. MapReduce) instead of trying to use the TransformingIterator.
I want to write a program to do this, based on Soot's build-in Reaching-Definition analysis. Now I'm wondering is this the correct approach? I searched and found nobody seems to ever be interested in this direction.
Any suggestions?
What you probably want to do is combine a set of ranges using an iterative data flow solver. You want to combine range-values from inputs into range-values for the set of definitions that cross basic blocks.
For this you generally need a control flow graph and the transfer functions across the basic blocks. I suppose you can treat the reaching-definitions graph in a similar way.
You'll then need interprocedural range propagation to push the ranges across the code.
This is a really generic problem you are stating. Reaching Definitions does not have much to do with this. Global Value Numbering is more what you apparently want but it's too hard to tell from your description. Try the Soot mailing list with a more detailed problem statement.
I am using hibernate to store and retrieve data from a MySQL database. I was using a byte array but came across the SerialBlob class. I can use the class successfully but I cant seem to find any difference between using the SerialBlob and a byte array. Does anyone know the basic differences or possible situations you wish to use a SerialBlob inlue of a byte[] are?
You are right that the SerialBlob is just a thin abstraction around a byte[], but:
Are you working in a team?
Do you sometimes make mistakes?
Are you lazy with writing comments?
Do you sometimes forget what your code from a year ago actually does?
If you anwsered any of the above questions with a yes, you should probably use SerialBlob.
It's basically the same with any other abstraction around a simple data structure (think ByteBuffer, for example) or another class. You want to use it over byte[], because:
It's more descriptive. A byte[] could be some sort of cache, it could be a circular buffer, it could be some sort of integrity checking mechanism gone wrong. But if you use SerialBlob, it's obvious that this is just a blob of binary data from the database / to be stored in the database.
Instead of manual array handling, you use methods on the class, which is, again, easier to read if you don't know the code. Even trivial array manipulation must be comprehended by the reader of your code. A method with a good name is self-descriptive.
This is helpful for your teammates and also for you when you'll read this code in a year.
It's more error proof. Every time you write any new code, there's a good chance you had made a bug in it. It may be not visible at first, but it is probably in there. The SerialBlob code has been tested by thousands of people around the world and it's safe to say that you won't get any bugs associated to it.
Even if you're sure you got your byte array handling right, because it's so straightforward, what if somebody else finds your code in half a year and starts "optimizing" things? What if he reuses an old blob, or messes up with your magic array padding? Every single off-by-one error in index manipulating will corrupt your data and that might not be detected right away (You are writing unit tests, aren't you?).
It restricts you to only a handful of possible interactions. This might actually look like a demerit, but it's not! It ensures you won't be using your blob as a local temporary variable after you're done with it. It ensures you won't try to make a String out of it or anything silly. It makes sure you'll only use it as a blob. Again, clarity and safety.
It's already written and always looks the same. You don't have to write a new implementation for every project, or read ten different implementations in ten different projects. If you'll ever see a SerialBlob in anyone's project, the usage will be clear to you. Everyone uses the same one.
TL; DR: A few years ago (or maybe still in C), using a byte[] would be ok. In Java (and OOP in general), try to use a specific class designed for the job instead of a primitive (low level) structure as it more clearly describes your intents, produces less errors and reduces the length of your code in the long run.
I am sorry if this is a duplicate but I was not able to find a definitive answer to what is the best practice for each type.
I would like to know what the appropriate conditions are that define when to use BufferedReader vs FileReader or BufferedInput/OutputStream vs FileInput/OutputStream? Is there a formula of sorts that will always tell you what is appropriate?
Should I just always used buffered?
Thanks
Use a buffer if the stream is going to have lots of small access. Use unbuffered if you are going to have relatively few, relatively large accesses.
The only time you should use unbuffered I/O is when the delay and aggregation imposed by buffering is inappropriate to your application.
" Is there a formula of sorts that will always tell you what is appropriate?"
If there was, it would already be in the libraries and would not be a design decision that you would have to make.
Since there's no pat answer, you have to make the design decision, you have to actually think about it.
Or, you can try both options and see which is "better" based on your unique problem and your unique criteria.
Most standard I/O libraries are buffered. That's a hint that most I/O benefits from buffering. But not all. Games, for instance, need unbuffered access to the game controls.
Keep in mind also that the BufferedReader provides you with a convenience readLine() method that allows you to read your content one line at a time.
I suggest you use Buffered* if this makes your application go faster, otherwise I wouldn't bother with it. i.e. try it with realistic data for see whether it helps.