comma separated String conversion

[NickPick]

I get a comma separated string from yahoo finance which I want to
convert. The first column is the date, the second the stock price and
the rest is irrelevant. How can I extract the second column into
separate Integer when the String looks as follows:

2004-01-02,27.58,28.83,27.26,27.65,63635800,23.18

thanks

 

[Mark Space]

http://java.sun.com/javase/6/docs/api/java/lang/String.html#split(java.lang.String)
seems like a reasonably straightforward and convenenient way to
accomplish that.

Note: the second column in your string looks more like a
decimal/floating-point value than an Integer to me.

Yes, and consider he said "stock price" I think a BigDecimal would be
better than a double.

 

[Roedy Green]

I get a comma separated string from yahoo finance which I want to
convert. The first column is the date, the second the stock price and
the rest is irrelevant. How can I extract the second column into
separate Integer when the String looks as follows:

2004-01-02,27.58,28.83,27.26,27.65,63635800,23.18

see http://mindprod.com/jgloss/csv.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Learning is not compulsory... neither is survival."
~ Dr. W. (William) Edwards Deming (born: 1900-10-14 died: 1993-12-20 at age: 93))

 

[Owen Jacobson]

http://java.sun.com/javase/6/docs/api/java/lang/String.html#split(java.lang.String)
seems like a reasonably straightforward and convenenient way to
accomplish that.

Note: the second column in your string looks more like a
decimal/floating-point value than an Integer to me.

Using String.split to parse CSVs is fraught with peril. Consider the
following record:

a," b ,",c

Take Roedy's suggestion instead.

-o

 

[Roedy Green]

The OP didn't stipulate that he had an actual CSV-format file. He
provided an example of the input data that is presumably representative,
and for which String.split() will work fine.

If he goes that route and it turn out there is one of the pathological
values eventually shows up, the whole program will explode, and he
will have to start over, using CSV.

The CSV route takes about the same amount of code (if you use a CSV
package), and it is immune to screwy data or file format changes that
have commas, quotes, spaces etc inside your data fields.

Reading a CSV file is much more complicated that you would ever
imagine. It uses a finite state automaton with quite a few states.

On my todo list is to have a look at
http://mindprod.com/products1.html#CSV
and see if the code to read CSVs can be speeded up.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Learning is not compulsory... neither is survival."
~ Dr. W. (William) Edwards Deming (born: 1900-10-14 died: 1993-12-20 at age: 93))

 

[Roedy Green]

If he implements a CSV-parsing solution without an explicit contract from
the web site that it's actually _providing_ CSV-compliant formatting, it
could "explode" just as easily if the web site transmits some
non-CSV-compliant string, and he will have to start over, without CSV.

IF the file was written to CSV format, it is only a temporary
fortunate accident if only a subset of the format is currently being
used.

If you set yourself up to handle the full format, any change will
require only a minor mod to the program. If you go the split route,
you have to start over from scratch.

It is highly unlikely a CSV format file would evolve into a
non-compliant variant.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Learning is not compulsory... neither is survival."
~ Dr. W. (William) Edwards Deming (born: 1900-10-14 died: 1993-12-20 at age: 93))

 

[Arne Vajhøj]

If he goes that route and it turn out there is one of the pathological
values eventually shows up, the whole program will explode, and he
will have to start over, using CSV.

The CSV route takes about the same amount of code (if you use a CSV
package), and it is immune to screwy data or file format changes that
have commas, quotes, spaces etc inside your data fields.

If he use a CSV package with a built in mind reader that can
automatically adjust CSV format, then you are correct.

But with ordinary plain Java code, then if the format change
then you either change your split code or you change your CSV
package calls.

It is not obvious to me the last should be faster than the
first.

Arne

 

[Arne Vajhøj]

IF the file was written to CSV format, it is only a temporary
fortunate accident if only a subset of the format is currently being
used.

The problem is not that a subset is used - the problem is that
CSV is not *a* format but a group of formats - there are not
magic that makes a CSV reader understand any CSV format.

If you set yourself up to handle the full format, any change will
require only a minor mod to the program.

If it is well written - yes.

If you go the split route,
you have to start over from scratch.

Why ?

You change the code to meet the new requirements - I can not imagine
deleting the parsing code and start from scratch.

It is highly unlikely a CSV format file would evolve into a
non-compliant variant.

It is not likely to evolve into a non-supported CSV format.

But it could very easily evolve into a non-CSV format.

Switching from CSV to XML is a likely change.

Arne