• Archimedes Trajano (unregistered) in reply to Taki
    Taki:
    Just for fun:

    double result = Double.parseDouble( amount ) / 10;

    The result is actually wrong, they need to divide by 100. Also, you really need to avoid using doubles when dealing with money otherwise you may lose precision. You should use BigDecimal, which may be a bit slower, but would at least guarantee that your number never loses precision.

    new BigDecimal(amount).divide(new BigDecimal( 100))

  • Archimedes Trajano (unregistered) in reply to Archimedes Trajano

    Better example

    new BigDecimal(amount).movePointLeft(2)

  • (cs) in reply to Helio
    Helio:
    To be fair, this is a slightly tricky example, in that you have to care about several special cases (null string, empty string, string with spaces, (non-)zero fractional part, etc). Still, you got to wander how many rocket scientists are needed to get to something like this:

    String convert(String amount) { if (amount == null) return amount;

    String trimmed = amount.trim(); if ("".equals(trimmed)) return amount;

    int value = Integer.parseInt(trimmed); int integer = value / 100; int fraction = value % 100; return integer + "." + (fraction < 9 ? "0" : "") + fraction; }

    Granted, still no pinnacle of perfection, but a lot better, don't you think?

    Much better, but I really think it could use some XML processing, dno't you think?

  • iToad (unregistered)

    Commented-out debugging code in a production system is a big red flag also. Usually, this feature appears in code written by someone who had to use a hammer to beat the code into shape, instead of code written by someone who could do it right the first time.

  • (cs) in reply to andy brons
    andy brons:
    The biggest WTF is fixed length data files. Who writes these things? They are the biggest pain in @ss. I just don't understood the reasoning for them.

    Pain in the ass? Tell me, what is easier than reading a known-length string from a file? Using delimiters that need to be escaped? Writing an XML parser and a DTD for your file format?

    Don't get me wrong, fixed length data files certainly have issues, the most obvious being that the fields are limited in length, have no context for human conversion, and are difficult to extend.

    But if anything, they are easy as sin to parse. Whatever (reasonable) language you are using, it can read a fixed-length string and parse it some other basic data type. Does your language give you an XML parser? What about CSV? Which of these formats does your favorite RDBMS use to store its data?

    So, in short, the reasoning is that, limitations aside, fixed length data files are easier than other formats to write and to parse by such an order of magnitude that, for general use, they are the only viable option.

  • AdT (unregistered) in reply to who?
    who?:
    The guy responsible for it here also has a nifty date handling function that is at least as bad. To make matters worse, he doesn't get the concept of re-usable code. I did a quick check one day and found 123 instances of his crappy date function in 1 package.

    Hey! He copied & pasted this thing into 122 different places. If that isn't heavy reuse, I don't know what is. :-)

    He even reused the bugs.

  • (cs) in reply to andy brons
    andy brons:
    Jno:
    andy brons:
    The biggest WTF is fixed length data files. Who writes these things? They are the biggest pain in @ss. I just don't understood the reasoning for them.

    Too young to remember COBOL and PIC statements, then? Once upon a time, when unicorns still roamed free, you had to make your data look like it came on a Hollerith card. I'm still working with a system which gets multimegabyte feeder files in a fixed width format and those files get fed to a COBOL suite.

    Yes, I know that in a land far away and a long time ago this was the way. I am working with relatively recent software and still have to deal with them. It's ridiculous.
    I deal with financial data w.r.t. mortgages, securities, stocks, etc., and much of the daily, weekly, monthly, quarterly and annual analytics comes in the form of fixed width dump-files; most likely out of some mainframe COBOL-PIC clause. It's annoying, but it's trivial to write a very simple parser to snarf it into some OO equivalent, and it's forgotten.

  • (cs) in reply to sjs
    sjs:
    amount = "000000028000" amount = sprintf("%0.2f", amount.to_f / 100)

    (ruby)

    amount = "000000028000"; amount = String.format("%0.2f", Integer.parseInt(amount)*1e-2);

    (java)

  • anonymous (unregistered) in reply to scott2718281828
    scott2718281828:
    I have gotten comma-delimited files with commas in the data fields. I have gotten quote-qualified data files with unescaped quotes in the data fields. Some people don't see any problem with tabs, pipes or carriage returns in their data fields. And I've usually gotten blank uncomprehending stares when trying to explain why these are problems.
    Good point. I wonder if they made this code because some wacked out data blew up the convert function? I've seen character-to-numeric conversion functions make a whole damn application go t*ts-up over a wacked out value that was numeric for 5 years + and suddenly there was some effed up data that wasn't numeric one day.
  • JGM (unregistered) in reply to I hate you all so very, very much
    I hate you all so very:
    captcha: NEXT MORON THAT TELLS ME WHAT THEIR CAPTCHA WAS I SLAUGHTER 10,000 POODLE PUPPIES.

    ..

    captcha: ninjas ... which is Apropó because that's exactly what I'm going to send to your house the next time you tell me what your captcha was.

    Good, I hate poodles!

    captcha: scooter

  • (cs)

    Since I have nothing noteworthy to comment about, such as "the REAL wtf is..." or what captcha I had to type in, I'll just agree with the author that this code is indeed invaluable.

  • (cs) in reply to mav
    mav:
    Thank god google knows everything.
    I do hope that was sarcasm. But I find that the prevailing attitude is that 'google knows everything', which is just not true. For example, I did an MSDN and Google search to find out how to programmatically determine the My Documents folder. Solutions proposed by Google? Open the folder "C:\Documents and Settings\" + CurrentUsersName + "\My Documents". Or from the marginally smarter people: SystemDrive + "Documents and Settings\" + CurrentUsersName + "\My Documents". That was all I could find. I knew it was wrong as my own "My Documents" folder wasn't there. So I had to go spelunking in the registry for a possible answer. Later, quite by accident while searching for something else, I stumbled onto SHGetSpecialFolderPath and the CSIDL_PERSONAL enum value. I quickly replaced a 50 line function with the 1 line GetSpecialFolderPath.

    Yes, Google knows alright. Definitly.

  • (cs) in reply to Malfist
    Malfist:
    Why has noone said anything about the break; at the end of the for loop? What uses is it? I couldn't find any!

    Thank you, you pointed it out to me. Without this break, the code will actually get stuck in an infinite loop continually adding additional characters to the string until it overflows.

  • Dick for brains (unregistered)

    First year java students could figure this out. Especially Lazy ones. This must have been written by someone with Java as a second or 18th language.

  • (cs) in reply to Helio
    return integer + "." + (fraction < 9 ? "0" : "") + fraction;

    Man, I hate that operator.

  • Old Timer (unregistered) in reply to RevEng
    RevEng:
    Pain in the ass? Tell me, what is easier than reading a known-length string from a file? Using delimiters that need to be escaped? Writing an XML parser and a DTD for your file format?

    So, in short, the reasoning is that, limitations aside, fixed length data files are easier than other formats to write and to parse by such an order of magnitude that, for general use, they are the only viable option.

    Amen!

  • andy brons (unregistered) in reply to RevEng

    I don't know XML and am not that interested in it at the moment.

    My main tool for getting files into our RDBMS is SQL Server DTS. Using delimited files is easier. When not using DTS I use looping and dynamic array(s) and or collections in VB. This way I don't have to hard code anything.

  • no name (unregistered) in reply to Erzengel
    Erzengel:
    mav:
    Thank god google knows everything.
    I do hope that was sarcasm. But I find that the prevailing attitude is that 'google knows everything', which is just not true. For example, I did an MSDN and Google search to find out how to programmatically determine the My Documents folder. Solutions proposed by Google? Open the folder "C:\Documents and Settings\" + CurrentUsersName + "\My Documents". Or from the marginally smarter people: SystemDrive + "Documents and Settings\" + CurrentUsersName + "\My Documents". That was all I could find. I knew it was wrong as my own "My Documents" folder wasn't there. So I had to go spelunking in the registry for a possible answer. Later, quite by accident while searching for something else, I stumbled onto SHGetSpecialFolderPath and the CSIDL_PERSONAL enum value. I quickly replaced a 50 line function with the 1 line GetSpecialFolderPath.

    Yes, Google knows alright. Definitly.

    Google knows. You just have to know how to ask.

    I searched for "MFC windows profile special folders".

    There were at least 3 articles in the top ten (including the first), that would have lead you on the right path. They weren't perfect matches, but they at least mentioned SHGetSpecialFolderPath.

    That was my fist try, better search terms might have given better results.

  • iMalc (unregistered)

    Surely you can't simply use Integer.parseInt because before it is divided by 100, the number is too large. 12 digits...

  • DoOver (unregistered)

    Now let's see all your examples rewritten to accommodate the case everyone missed...

    if (amount.substring(i).endsWith("00"))

    captcha: bling. I win.

  • (cs) in reply to RevEng
    RevEng:
    Pain in the ass? Tell me, what is easier than reading a known-length string from a file? Using delimiters that need to be escaped? Writing an XML parser and a DTD for your file format?
    If you're a real developer as opposed to a short-sighted cowboy coder, you know that you will, without fail, have to change the format, add hierarchical data, and debug problems with garbled data.

    And how bad does your case of "not invented here" have to be that you write your own XML parser when there's a dozen to choose from for every remotely popular language?

    Fixed-length fields are such an incredible pain in the ass to deal with for anything but the most primitively simple applications, that anyone suggesting their use for a new, non-trivial application should never be allowed to make any kind of design decisions.

  • no name (unregistered) in reply to brazzy
    brazzy:
    RevEng:
    Pain in the ass? Tell me, what is easier than reading a known-length string from a file? Using delimiters that need to be escaped? Writing an XML parser and a DTD for your file format?
    If you're a real developer as opposed to a short-sighted cowboy coder, you know that you will, without fail, have to change the format, add hierarchical data, and debug problems with garbled data.

    And how bad does your case of "not invented here" have to be that you write your own XML parser when there's a dozen to choose from for every remotely popular language?

    Fixed-length fields are such an incredible pain in the ass to deal with for anything but the most primitively simple applications, that anyone suggesting their use for a new, non-trivial application should never be allowed to make any kind of design decisions.

    My someone's full of themselves. Guess what? Sometimes the best tool for the job, is the best tool for the job. Imagine that.

    Fixed-length is good because it's light weight, trivial to parse, and let's you skip records without reading and discarding them. If it's sorted you can even do binary searches etc.

    On the downside forwards/backwards compatibility is a pain, and you have to be careful to make sure your lengths are sufficient.

    But when it's the best fit, it's a powerful tool. Any "real developer" will know both the advantages and disadvantages of his tools, and how those apply to the problem at hand.

    Sometimes the XML swiss army knife isn't the best tool for the job. Imagine that.

  • Tom (unregistered) in reply to Old Timer

    Why?

    Using Perl's split function makes delimited quite straightforward.

  • Helio (unregistered) in reply to iMalc

    Yes, but only if you're going to use all those twelve digits. Integer.parseInt has no problem with long numeric strings where the higher level digits are all zeros -- for example, Integer.parseInt("000000028007") will correctly yield (int) 28007. Then again, I guess we shouldn't take such risks -- if the space is there, it may well be used someday -- so it would be safer to use Long.parseLong(), which will easily handle 12-digit long integers.

    There is, of course, a more generic way to deal with this problem, that would allow processing of arbitrary length strings as well as avoiding possible parser crashes: use regular expressions. With them, my earlier snippet could easily be rewritten as:

    import java.util.regex.Pattern; import java.util.regex.Matcher;

    String convert(String amount) { Pattern pattern = Pattern.compile("0*([0-9]+)([0-9]{2})");

    Matcher matcher = pattern.matcher(amount);
    if (matcher.matches())
    	return matcher.group(1) + "." + matcher.group(2);
    else
    	return amount;
    

    }

  • Helio (unregistered) in reply to DoOver

    Actually, no. Most examples seen here will work with this case, including mine.

  • slamb (unregistered) in reply to Hit
    Hit:
    Oh boy. Get ready for the 100s of comments saying inane crap like "JAVA DOES HAVE A FUNCTION TO CONVERT A STRING TO A NUMBER YOU IDIOT".

    Because no matter how many of these articles people will read on this site, they STILL will not get the concept of "Sarcasm."

    I've got it! A "sarcasm quiz" required to post or register, replacing the captcha!

  • slamb (unregistered) in reply to Helio
    Helio:
    There is, of course, a more generic way to deal with this problem, that would allow processing of arbitrary length strings as well as avoiding possible parser crashes: use regular expressions.

    If you later want to do something more sophisticated than divide by 100, you'll want to use a different way that handles arbitrary-length strings: java.math.BigInteger or java.math.BigDecimal.

    With [regular expressions], my earlier snippet could easily be rewritten as:

    import java.util.regex.Pattern; import java.util.regex.Matcher;

    String convert(String amount) { Pattern pattern = Pattern.compile("0*([0-9]+)([0-9]{2})");

    Matcher matcher = pattern.matcher(amount); if (matcher.matches()) return matcher.group(1) + "." + matcher.group(2); else return amount; }

    That's a WTF. If convert("400") should return "4", I doubt convert("4") should as well. You probably at least want to be throwing an exception if the regexp doesn't match...

  • Helio (unregistered) in reply to slamb
    slamb:
    If you later want to do something more sophisticated than divide by 100, you'll want to use a different way that handles arbitrary-length strings: java.math.BigInteger or java.math.BigDecimal.

    Then again, maybe not. It all depends on what, exactly, that "something more sophisticated" is. For the task at hand - reformating a numeric string - regular expressions will do nicely.

    slamb:
    That's a WTF. If convert("400") should return "4", I doubt convert("4") should as well. You probably at least want to be throwing an exception if the regexp doesn't match...

    Of course I didn't mean that code to be production ready... you'll notice my first snippet suffers from the same problem. I just meant to illustrate a non-WTF way to reformat a numeric string, without bothering much about error conditions.

  • (cs) in reply to Erzengel
    Erzengel:
    mav:
    Thank god google knows everything.
    I do hope that was sarcasm. But I find that the prevailing attitude is that 'google knows everything', which is just not true. For example, I did an MSDN and Google search to find out how to programmatically determine the My Documents folder. Solutions proposed by Google? Open the folder "C:\Documents and Settings\" + CurrentUsersName + "\My Documents". Or from the marginally smarter people: SystemDrive + "Documents and Settings\" + CurrentUsersName + "\My Documents". That was all I could find. I knew it was wrong as my own "My Documents" folder wasn't there. So I had to go spelunking in the registry for a possible answer. Later, quite by accident while searching for something else, I stumbled onto SHGetSpecialFolderPath and the CSIDL_PERSONAL enum value. I quickly replaced a 50 line function with the 1 line GetSpecialFolderPath.

    Yes, Google knows alright. Definitly.

    So what you are saying is you didn't ask Google the right question?

  • Bitboy (unregistered) in reply to Chris

    Well, of course !c==0. c = 186282.2 miles per second.

    So there.

    captcha = "doom". Kind of what I felt when reading today's WTF

  • (cs) in reply to no name
    no name:
    Google knows. You just have to know how to ask.

    I searched for "MFC windows profile special folders".

    There were at least 3 articles in the top ten (including the first), that would have lead you on the right path. They weren't perfect matches, but they at least mentioned SHGetSpecialFolderPath.

    That was my fist try, better search terms might have given better results.

    How in the world would someone have divined that question to ask? Ask it something sensible, like "obtaining My Documents in C++"

    chrismcb:
    So what you are saying is you didn't ask Google the right question?
    I asked it dozens of questions, none of which came up with anything remotely useful. It's not like I gave up after one search, I just couldn't divine the magic words necessary to make Google give me useful information. That's always a problem with indexing systems, from dictionaries to MSDN, you have to already know what you're looking for to find what you're looking for.
  • (cs) in reply to Erzengel
    Erzengel:
    no name:
    Google knows. You just have to know how to ask.

    I searched for "MFC windows profile special folders".

    There were at least 3 articles in the top ten (including the first), that would have lead you on the right path. They weren't perfect matches, but they at least mentioned SHGetSpecialFolderPath.

    That was my fist try, better search terms might have given better results.

    How in the world would someone have divined that question to ask? Ask it something sensible, like "obtaining My Documents in C++"

    chrismcb:
    So what you are saying is you didn't ask Google the right question?
    I asked it dozens of questions, none of which came up with anything remotely useful. It's not like I gave up after one search, I just couldn't divine the magic words necessary to make Google give me useful information. That's always a problem with indexing systems, from dictionaries to MSDN, you have to already know what you're looking for to find what you're looking for.

    How about '"my documents" programmatically' (Three words taken directly from your original post) Second hit led to a forum of someone asking that very question. Skimming through it, turns out the forum was a .net forum. But someone said "well here is how to do it the old way..."

    You are right, you have to know how to ask the question. Thats true no matter who you are talking to (whether its an expert in the field, or an dumb index) Granted an expert in the field may figure out what you mean, and answer the question you really wanted to ask.

  • (cs) in reply to brazzy
    brazzy:
    RevEng:
    Pain in the ass? Tell me, what is easier than reading a known-length string from a file? Using delimiters that need to be escaped? Writing an XML parser and a DTD for your file format?
    If you're a real developer as opposed to a short-sighted cowboy coder, you know that you will, without fail, have to change the format, add hierarchical data, and debug problems with garbled data.

    And how bad does your case of "not invented here" have to be that you write your own XML parser when there's a dozen to choose from for every remotely popular language?

    Fixed-length fields are such an incredible pain in the ass to deal with for anything but the most primitively simple applications, that anyone suggesting their use for a new, non-trivial application should never be allowed to make any kind of design decisions.

    Ohhh so you read me spec? You KNOW that I will need hierarchical data? You KNOW the my 4 digit year field will need to be 4 digits (Yeah... Uhm I'll let someone else worry about the 10K issue)

    I'll agree that the biggest problem with fixed width data is forward compatibilty. But that isn't to say the answer is to NEVER use them.

    I love that some people think XML is the greates thing since the zero was invented. They fail to realize that its just a freaking file format.

  • Rubyist (unregistered) in reply to sjs

    Um how about...

    amount = "000000028000" amount = amount.to_i * 0.01

    Simpler is usually better.

  • Rubyist (unregistered) in reply to Rubyist
    Rubyist:
    Um how about...

    amount = "000000028000" amount = amount.to_i * 0.01

    Simpler is usually better.

    Woops, forgot a to_s

    amount = "000000028000" amount = (amount.to_i * 0.01).to_s

  • Darron (unregistered) in reply to strcmp
    strcmp:
    Inserting the dot first simplifies things (and you don't lose precision by converting to anything). In perl:

    substr($_, -2, 0) = '.'; s/^0+//;

    Anything that can't be captured in one line of Perl...can be done in one line of APL.

    s/^0*([0-9]*)([0-9]{2})$/$1.$2/;

  • (cs) in reply to andy brons
    andy brons:
    Jno:
    andy brons:
    The biggest WTF is fixed length data files. Who writes these things? They are the biggest pain in @ss. I just don't understood the reasoning for them.

    Too young to remember COBOL and PIC statements, then? Once upon a time, when unicorns still roamed free, you had to make your data look like it came on a Hollerith card. I'm still working with a system which gets multimegabyte feeder files in a fixed width format and those files get fed to a COBOL suite.

    Yes, I know that in a land far away and a long time ago this was the way. I am working with relatively recent software and still have to deal with them. It's ridiculous.

    ahh yes. I forgot the mantra is XML, XML, XML

    Turn that multimegabyte feeder into multigigabytes.

    Nothing wrong with fixed length input. Try finding record (n) in an XML file, or even csv for that matter. At least in fixed length you can seek to (recordlength * n) in one statement.

    Parsing fixed length isn't hard either.

    But I guess this is modern times, and the simple solutions aren't enterprisey enough. Let's surround that flat data with bloated cruft.

  • brendan (unregistered) in reply to andy brons
    andy brons:
    The biggest WTF is fixed length data files. Who writes these things? They are the biggest pain in @ss. I just don't understood the reasoning for them.

    One of the reasons they had fixed width fields was so that, it as easy to find records with just an index (i.e to find the nth record was a simple matter of seeking to n*record byte.

    Anyway what's the problem with converting string to an integer(or double, if need to preform floating point) and the convert back to a string with the approperate format?

  • (cs) in reply to chrismcb
    chrismcb:
    Ohhh so you read me spec? You KNOW that I will need hierarchical data? You KNOW the my 4 digit year field will need to be 4 digits (Yeah... Uhm I'll let someone else worry about the 10K issue)
    I know that requirements tend to change and expand in any but the most simple applications, and that the most simple applications sometimes unexpectedly grow into complex ones.
    I love that some people think XML is the greates thing since the zero was invented. They fail to realize that its just a freaking file format.
    It's a standardized, flexible file/data format, with parsers readily available for most languages, and relatively easy to read and debug by humans.

    IMO these are such massive advantages that there need to be grave, specific reasons for me to use anything else for storing or transmitting data between differen systems.

    Sure, there are cases where it's the wrong tool and it can be horribly abused. But I can think of very few cases where fixed-length fields would be a better alternative.

  • My Name (unregistered) in reply to Erzengel
    Erzengel:
    no name:
    Google knows. You just have to know how to ask.

    I searched for "MFC windows profile special folders".

    There were at least 3 articles in the top ten (including the first), that would have lead you on the right path. They weren't perfect matches, but they at least mentioned SHGetSpecialFolderPath.

    That was my fist try, better search terms might have given better results.

    How in the world would someone have divined that question to ask? Ask it something sensible, like "obtaining My Documents in C++"

    chrismcb:
    So what you are saying is you didn't ask Google the right question?
    I asked it dozens of questions, none of which came up with anything remotely useful. It's not like I gave up after one search, I just couldn't divine the magic words necessary to make Google give me useful information. That's always a problem with indexing systems, from dictionaries to MSDN, you have to already know what you're looking for to find what you're looking for.

    Well...

    You pretty much always know what you are looking for when you are lookingf or something. To look for something without knowing what you are looking for, uhm? Do you do that often? Roam about looking for something, not knowing what you are looking for? Sounds like a mental disorder to me, perhaps altzheimers?

  • Reinder (unregistered) in reply to Erzengel
    Erzengel:
    no name:
    Google knows. You just have to know how to ask.

    I searched for "MFC windows profile special folders".

    There were at least 3 articles in the top ten (including the first), that would have lead you on the right path. They weren't perfect matches, but they at least mentioned SHGetSpecialFolderPath.

    That was my fist try, better search terms might have given better results.

    How in the world would someone have divined that question to ask? Ask it something sensible, like "obtaining My Documents in C++"

    chrismcb:
    So what you are saying is you didn't ask Google the right question?
    I asked it dozens of questions, none of which came up with anything remotely useful. It's not like I gave up after one search, I just couldn't divine the magic words necessary to make Google give me useful information. That's always a problem with indexing systems, from dictionaries to MSDN, you have to already know what you're looking for to find what you're looking for.

    I tried, and "windows special folder path" was my first try. Top hit was http://support.microsoft.com/kb/194702 "How to locate Windows special folder locations".

    Searching is easy, finding things can be hard. In this case, I showed how good I am at finding things/was lucky.

  • (cs) in reply to mav
    I'm always amazed at what people will churn out rather than doing a quick google search to find the right answer. Thank god google knows everything.

    I'm always amazed at the number of people that will do a quick google search or, worse, join experts exchange, rather than actually know anything.

  • (cs) in reply to I hate you all so very, very much

    Covert string? No quack!

    I hate you all so very:
    captcha: NEXT MORON THAT TELLS ME WHAT THEIR CAPTCHA WAS I SLAUGHTER 10,000 POODLE PUPPIES.

    ..

    captcha: ninjas ... which is Apropó because that's exactly what I'm going to send to your house the next time you tell me what your captcha was.

    To help get rid of those mutant poodle puppies: CAPTCHA = ... uh, I'm a member so I don't get one :(:( can you kill them anyway?
  • (cs) in reply to brazzy
    brazzy:
    I love that some people think XML is the greates thing since the zero was invented. They fail to realize that its just a freaking file format.
    It's a standardized, flexible file/data format, with parsers readily available for most languages, and relatively easy to read and debug by humans.

    IMO these are such massive advantages that there need to be grave, specific reasons for me to use anything else for storing or transmitting data between differen systems.

    Sure, there are cases where it's the wrong tool and it can be horribly abused. But I can think of very few cases where fixed-length fields would be a better alternative.

    Don't forget that it takes 100 times as much memory and 100 times as much CPU to deal with XML as opposed to fixed width formats. If you are dealing with small payloads, XML is great. When you start dealing with larger payloads you start feeling pain very quickly. Try performing an XSLT transformation on a 600 MB XML file someday. It isn't pretty. I've been there, got the t-shirt, and never want to deal with it again.

    Fixed format feeds have the singular advantage of being able to scale larger than delimited and much much much larger than XML. If you think that there is no place for fixed, you probably have not been working on domains that deal with large data problems.

  • (cs) in reply to Diego
    Diego:
    remember: never use float and double for currency data

    But what if I take the rounding errors and transfer them to my own account?

  • (cs) in reply to RevMike
    RevMike:
    Don't forget that it takes 100 times as much memory and 100 times as much CPU to deal with XML as opposed to fixed width formats. If you are dealing with small payloads, XML is great. When you start dealing with larger payloads you start feeling pain very quickly. Try performing an XSLT transformation on a 600 MB XML file someday. It isn't pretty.
    XSLT is a whole different scope that just parsing. And independantly of the paylod size, whether the XML parsing overhead makes any difference depends mainly on how much else (other than parsing) you're actually doing with the data.

    Besides, there are quite lean XML parsers (stream parsers like SAX - there's even a stream-based variant of XSLT called STX) that don't have nearly as much overhead as you say. Admittedly they require mone manual work as well, but still scale much better to more complex data structures than fixed-length fields.

  • Dustin (unregistered)

    Java does let you turn a string into an int or a double, you just have to use the wrapper classes, Integer, or Double.

    each has a constructor that takes in a String and converts it, then you can change it to a primitive data type with the intValue, or doubleValue methods.

    of course this will change the string "000000028000" to 28000, (the constructors ignore leading zeros.) you can modify the number after you get its respective Integer, or Double, depending on what the string is like (whatever your rules are.).

  • Sgeo (unregistered) in reply to sootzoo

    Of course, there's no way that ratdump could possibly be being sarcastic himself..

  • (cs)

    Ooooouch - that gave me a headache.
    thanks a lot...

  • Kuba (unregistered) in reply to jtl
    jtl:
    float f = Float.parseFloat("123.4");

    No shit?!

    Couldn't resist. Yes, this is wholly superfluous. But I needed to make it personal. jtl needs to learn. Fast!

Leave a comment on “The Longest Way to Zero”

Log In or post as a guest

Replying to comment #:

« Return to Article