Well, I got mine at internic.com and they were charging heavy surcharges over the internic.net fees. Either way, there was a complete lack of options at the time and not many people, including myself, knew better.
I agree with the other AC reply to your post. When I get a resume with 50 languages in it, I toss it immediately, no longer bothering to think, "Well, does this person know any of these well?" You say 'narrow and deep' but I see "wide and shallow." I have worked with dozens of coders in the past, and the ones who are always trying out a new language every week tend to be the worst of the bunch. Sure they have done 50 small projects in 50 languages, but each and every one of those projects is a shitpile and puts strain on future maintainers because they are hacky first attempts at the language. 42 languages reeks of padding and bullshit. Craft you resume to the job and take all the irrelevant stuff out. Or summarize it with "working knowledge of several other languages."
Those are the operative words. And please note, I said 'average user' meaning the general public. By the way, I have been using linux as my main desktop since the days when hanging yourself sometimes seemed like a better option than using linux.
To which the computer science major said "no" because money has been tight ever since his job got shipped off to India.:-/
To which the liberal arts major replied, "If money is tight, why are you here? I make dinner for four on what you just spent on your hamburger and coke, you fat fucking bastard."
My Pentium III test machine with 256Meg of Ram blew away a dual processor Intel system with 1Gig of Ram while parsing a 30Meg XML import/export file.
Heh, a little offtopic but - This is why I hate XML. It's so bloated. You take 1 to 6 hours parsing a 30 megabyte XML file in C? I was just tasked with parsing out some select data from a 37 gigabyte XML file (870 million lines). I tried all sorts of optimizations and parsers upon finding that it might take days to parse. My solution - 50 lines of perl using regular expressions. I run this on a dual processor 3.something with 2 gigs of ram. It takes 5 minutes. If I coded it in C it would probably take 10 seconds but it's not worth the time.
Well, I live in Seattle and on the on demand screen it says "powered by microsoft" and it is pretty buggy. I'll admit it has gotten a bit better, but it is still buggy.
Ah. I see. I still feel a bit vindicated, though; because it still looks as though the proliferation of file formats you are seeing is due to others upstream using a spreadsheet when what they really wanted was a database.
No, not really. The multitudes of software our customers use in reading their arrays always provide an export function. The export options (and mind you this is third party software) is generaly "you pick and name the columns" or "export everything". This is very advantageous to us. As long as their software can export tab delimited text, we can accomidate their data. If their software only allowed MS access or the like, it would be too hard for us to accomadate all the platforms out there. When we are able to tell our customers, "Send us a tab delimited text file of your data, we will figure it out for you" - they love it. We spend a few minutes in OO or Excel (depending on if it as developer or support staff), quickly reformat their file and load it for them. Given the compexity of most bioinformatics software platforms out there, this is like living at the ritz. We strive for excellence in customer service and my initial remark about 32 vs 64 vs 100K lines of data had to do with quick spot checking for quality of our work. If a statisical error exists, we have to solve the problem ASAP. I'll still spot check, but a spread sheet makes it easier and quicker than doing it by hand.
Oh sure, it's only 500Mb. But when you uncompress it and covert it to XML it clocks out at more than 800 MILLION lines. I know I am being snide, but I deal with files from 10 lines to 1 billion lines. What I am talking about is quick analyis of files that range from 10 lines to 100,000 lines. Microsoft and OO cut you off at 64K and 32K respectively. I am just asking for a spreedsheet that accomodates around 100,000 lines.
it sounds to me like you are using your spreadsheet as though it were a database.
No, as I stated, I use the spreadsheet to figure out the file format so I can pump the data into a database. The field I work in, bioinformatics and specifically microarrays, is rife with dozens upon dozens of file formats. Determinining what column holds what quickly leads to a my @data = split/\t/, $line;
my $important_values1 = $data[3]; my $important_values2 = $data[5]; my $important_values3 = $data[16];
then inserting these values into a database. After that complex calculations are performed using the data from the database, not the spreadsheet.
The spreadsheet acts only as a quick way to decifer the file format. My comment about holding 100K+ lines stems from the fact that I would maybe like to calculate the mean from both the db and the spreadsheet only to accompish a crude yet quick data validation method.
Perhaps MS Access or OOo Base is right for you? They should be able to seamlessly import and view a few hundred thousand lines, without requiring you to know about the data in advance.
Well, MS Access is out because I work entirely under linux and I despise any sort of emulators. If I need windows apps, I'll get a windows box. OO base is fairly new...in OO 2.0 beta, right? I might be wrong. But still, being able to open a csv or tab delimited file and quickly perform some basic searching, arithmetic or perhaps something slightly more complicated like a t-test or ANOVA is infinitely easier in a spreadsheet when the data is of unknown format. I greatly prefer a db, but 99 times out of 100, a spreadsheet rules when the sole purpose of the spreadsheet is to determine what the delimiters are and what column holds what piece of data. And once that is known grep, awk and a few other command line tools can beat a db in terms of quick calculations and data verification. I have stacks upon stacks of postits with acc = 3, intensity = 4, quality = 5, cluster = 9, title = 14 on my desk. I even have a chart with BC = 55 for converting column letters to numbers.
Examining the file is the first step towards inserting the data into a database. I work in bioinformatics. I get files from customers which often share only two common characteristics - they hold some data, and they are tab or comma delimited. Other than that, they could be two columns with 50 rows, or 100 columns with 75,000 rows. Opening the file and looking at it is the first step. A spreadsheet is a handy tool for doing that. I'm not sure if you have used a text editor or used "more" or "less" to look at file with 75 columns, but it is pretty hard to decifer it that way. A spreadsheet is also handy for quick check validation of the data. I can't find the median of 75,000 numbers or search for the values of particalur identifier if the spreadsheet only reads in 32,000 lines. Sure, I could write a script to do all the various things, but a spreadsheet that could read in 100,000 lines would really ease my life. And, as I said, it is only the first step towards much more complicated calculations which do, in fact, use a relational database.
In addition, can it open spreadsheets with more than 32,000 lines? I know Excel tops out at 64,000 which for my needs sometimes is not enough. I have searched the prefs in previous versions but can't find any way to open files with that many lines. Well, the open, but the cut off anything after the max line number. I regularly get csv files with 50-75K lines that are of different formats and would like to be able to open them in a spread sheet, especially OO. I usually have to resort to perl or awk to find what I need, but spreadsheets are quicker if you need to perform a bunch of ad hoc searches and calculations.
I am using SeaMonkey 1.0a, and it looks lovely. Did you try one of the many other browsers available for Linux before you had a conniption?
I'm in a karma free fall right now. Let's see how much more I can lose.
No...I used Slashdot's darling browser using one of the most popular linux distros. I suppose I could install some other distros and use some more obscure browsers. But you're right, though...I'm sure they tested the new code on SeaMonkey 1.0a....whatever the hell that is.
Slashdot Mirror
Well, I got mine at internic.com and they were charging heavy surcharges over the internic.net fees. Either way, there was a complete lack of options at the time and not many people, including myself, knew better.
I dream of the old days of one domain registrar
Do you dream of $500 domain names? Cause that's what I paid for my first one.
I agree with the other AC reply to your post. When I get a resume with 50 languages in it, I toss it immediately, no longer bothering to think, "Well, does this person know any of these well?" You say 'narrow and deep' but I see "wide and shallow." I have worked with dozens of coders in the past, and the ones who are always trying out a new language every week tend to be the worst of the bunch. Sure they have done 50 small projects in 50 languages, but each and every one of those projects is a shitpile and puts strain on future maintainers because they are hacky first attempts at the language. 42 languages reeks of padding and bullshit. Craft you resume to the job and take all the irrelevant stuff out. Or summarize it with "working knowledge of several other languages."
I usually rant about it in the spring. In the fall, I really look forward to that extra long Sunday.
The real truth:
a shdot
http://www.encyclopediadramatica.com/index.php/Sl
I mean, they're better, right?
too fragging lazy
Those are the operative words. And please note, I said 'average user' meaning the general public. By the way, I have been using linux as my main desktop since the days when hanging yourself sometimes seemed like a better option than using linux.
From experience, any thing more than 11 steps is not worth it!
And from the average user's perspective, anything more than 0 steps is too many.
For all you perl haters:It's really a statistics problem though.
http://slashdot.org/article.pl?sid=04/07/26/123227 &tid=133&tid=199
Slashdot has an HOF. They should also have an HOS.
To which the computer science major said "no" because money has been tight ever since his job got shipped off to India. :-/
To which the liberal arts major replied, "If money is tight, why are you here? I make dinner for four on what you just spent on your hamburger and coke, you fat fucking bastard."
My Pentium III test machine with 256Meg of Ram blew away a dual processor Intel system with 1Gig of Ram while parsing a 30Meg XML import/export file.
l l_Data.ags.gzg ram/gene2xml/
Heh, a little offtopic but - This is why I hate XML. It's so bloated. You take 1 to 6 hours parsing a 30 megabyte XML file in C? I was just tasked with parsing out some select data from a 37 gigabyte XML file (870 million lines). I tried all sorts of optimizations and parsers upon finding that it might take days to parse. My solution - 50 lines of perl using regular expressions. I run this on a dual processor 3.something with 2 gigs of ram. It takes 5 minutes. If I coded it in C it would probably take 10 seconds but it's not worth the time.
Here's the file and convertor if anyone wants to fuck around with nearly a billion (bloated XML) lines of genetic data:
ftp://ftp.ncbi.nlm.nih.gov/gene/DATA/ASN_BINARY/A
ftp://ftp.ncbi.nlm.nih.gov/asn1-converters/by_pro
But I don't see much difference in the representation of top and down quarks in the panels shown.
Lucky you. I don't see a damn thing because Slashdot has destroyed another unlucky webserver.
Well, I live in Seattle and on the on demand screen it says "powered by microsoft" and it is pretty buggy. I'll admit it has gotten a bit better, but it is still buggy.
(for which Microsoft wrote the software), I wouldn't give it much hope.
How is this different from floppy disk copy restrictions from the 80s? This just prevents fair use by restricting backup copies.
Oh, because the internet grew up and people got used to getting stuff for free.
Telephone surveyors are exempt.
t .htm
http://www.ftc.gov/bcp/conline/pubs/alerts/dncalr
I was going to post a section of my perl script here, just a function which parses a single line from a CSV but the lameness filter got in the way
/$delimiter/, $line;
More complicated than say:
my $delimiter = ','; # or '\t"
open( FH, "<myfile.txt" ) or die $!
while ( defined(my $line = <FH>) ) {
my @data = split
## do some shit
}
close FH;
Ah. I see. I still feel a bit vindicated, though; because it still looks as though the proliferation of file formats you are seeing is due to others upstream using a spreadsheet when what they really wanted was a database.
No, not really. The multitudes of software our customers use in reading their arrays always provide an export function. The export options (and mind you this is third party software) is generaly "you pick and name the columns" or "export everything". This is very advantageous to us. As long as their software can export tab delimited text, we can accomidate their data. If their software only allowed MS access or the like, it would be too hard for us to accomadate all the platforms out there. When we are able to tell our customers, "Send us a tab delimited text file of your data, we will figure it out for you" - they love it. We spend a few minutes in OO or Excel (depending on if it as developer or support staff), quickly reformat their file and load it for them. Given the compexity of most bioinformatics software platforms out there, this is like living at the ritz. We strive for excellence in customer service and my initial remark about 32 vs 64 vs 100K lines of data had to do with quick spot checking for quality of our work. If a statisical error exists, we have to solve the problem ASAP. I'll still spot check, but a spread sheet makes it easier and quicker than doing it by hand.
I know how to deal with large nubmers of rows. In fact I regularly deal with this little file:
l l_Data.ags.gz
ftp://ftp.ncbi.nlm.nih.gov/gene/DATA/ASN_BINARY/A
Oh sure, it's only 500Mb. But when you uncompress it and covert it to XML it clocks out at more than 800 MILLION lines. I know I am being snide, but I deal with files from 10 lines to 1 billion lines. What I am talking about is quick analyis of files that range from 10 lines to 100,000 lines. Microsoft and OO cut you off at 64K and 32K respectively. I am just asking for a spreedsheet that accomodates around 100,000 lines.
it sounds to me like you are using your spreadsheet as though it were a database.
/\t/, $line;
No, as I stated, I use the spreadsheet to figure out the file format so I can pump the data into a database. The field I work in, bioinformatics and specifically microarrays, is rife with dozens upon dozens of file formats. Determinining what column holds what quickly leads to a my @data = split
my $important_values1 = $data[3];
my $important_values2 = $data[5];
my $important_values3 = $data[16];
then inserting these values into a database. After that complex calculations are performed using the data from the database, not the spreadsheet.
The spreadsheet acts only as a quick way to decifer the file format. My comment about holding 100K+ lines stems from the fact that I would maybe like to calculate the mean from both the db and the spreadsheet only to accompish a crude yet quick data validation method.
Perhaps MS Access or OOo Base is right for you? They should be able to seamlessly import and view a few hundred thousand lines, without requiring you to know about the data in advance.
Well, MS Access is out because I work entirely under linux and I despise any sort of emulators. If I need windows apps, I'll get a windows box. OO base is fairly new...in OO 2.0 beta, right? I might be wrong. But still, being able to open a csv or tab delimited file and quickly perform some basic searching, arithmetic or perhaps something slightly more complicated like a t-test or ANOVA is infinitely easier in a spreadsheet when the data is of unknown format. I greatly prefer a db, but 99 times out of 100, a spreadsheet rules when the sole purpose of the spreadsheet is to determine what the delimiters are and what column holds what piece of data. And once that is known grep, awk and a few other command line tools can beat a db in terms of quick calculations and data verification. I have stacks upon stacks of postits with acc = 3, intensity = 4, quality = 5, cluster = 9, title = 14 on my desk. I even have a chart with BC = 55 for converting column letters to numbers.
Dude. Try a relational database.
Examining the file is the first step towards inserting the data into a database. I work in bioinformatics. I get files from customers which often share only two common characteristics - they hold some data, and they are tab or comma delimited. Other than that, they could be two columns with 50 rows, or 100 columns with 75,000 rows. Opening the file and looking at it is the first step. A spreadsheet is a handy tool for doing that. I'm not sure if you have used a text editor or used "more" or "less" to look at file with 75 columns, but it is pretty hard to decifer it that way. A spreadsheet is also handy for quick check validation of the data. I can't find the median of 75,000 numbers or search for the values of particalur identifier if the spreadsheet only reads in 32,000 lines. Sure, I could write a script to do all the various things, but a spreadsheet that could read in 100,000 lines would really ease my life. And, as I said, it is only the first step towards much more complicated calculations which do, in fact, use a relational database.
Does this open MS Office files better?
In addition, can it open spreadsheets with more than 32,000 lines? I know Excel tops out at 64,000 which for my needs sometimes is not enough. I have searched the prefs in previous versions but can't find any way to open files with that many lines. Well, the open, but the cut off anything after the max line number. I regularly get csv files with 50-75K lines that are of different formats and would like to be able to open them in a spread sheet, especially OO. I usually have to resort to perl or awk to find what I need, but spreadsheets are quicker if you need to perform a bunch of ad hoc searches and calculations.
I am using SeaMonkey 1.0a, and it looks lovely. Did you try one of the many other browsers available for Linux before you had a conniption?
I'm in a karma free fall right now. Let's see how much more I can lose.
No...I used Slashdot's darling browser using one of the most popular linux distros. I suppose I could install some other distros and use some more obscure browsers. But you're right, though...I'm sure they tested the new code on SeaMonkey 1.0a....whatever the hell that is.