• RandomUser423689 (unregistered) in reply to SW
    SW:
    RandomUser423689:
    Homer:
    ...
    Ike:
    ...
    Sadly, those days will never be over (as I'm sure you know, noting the sarcasm). Economic factors will always push large amounts of work with as low a barrier to entry as "coding", onto the untrained and the self-taught. The only (obvious) thing that might stop it would be wide-spread unionization of such work, but all I can say is, "good luck with that." An old discussion for the regulars here, but I figured I'd mention it for the passers-by.
    Oh Yea because union = quality Riiight.
    Hmm... Apparently it was too easy to infer things I wasn't trying to say. And "union" may or may not have been the right word. The concept here is some form of professional organization that business owners are either mandated or strongly incentivized to hire from, for the purposes of "coding".

    No; such organizations do not automatically equal quality. However, they can, if they choose, mandate that their members have a certain level of training.

    Enough of that alters the balance of trained and untrained workers. Although, at that point, you still have to come up with solutions to address trained workers who do crap work out of laziness or malice.

  • Anonymouse (unregistered) in reply to Anon
    Anon:
    Mcoder:
    Rounding 5s up inserts a bias into your data

    No, it doesn't.

    If you are rounding 0.x then:

    ...

    Notice that for half the values of x, it rounds to 0, for the other half, it rounds to 1. That is unbiased.

    That is not what is meant by bias. If you have lots of 5s in your dataset, they will all be rounded up. This introduces a statistical bias. Look it up. It can cause problems.

  • Double-Oh Five (unregistered) in reply to Anon

    http://en.wikipedia.org/wiki/Rounding#Round_half_to_even

  • anon (unregistered) in reply to Anonymouse
    Anonymouse:
    Anon:
    Mcoder:
    Rounding 5s up inserts a bias into your data

    No, it doesn't.

    If you are rounding 0.x then:

    ...

    Notice that for half the values of x, it rounds to 0, for the other half, it rounds to 1. That is unbiased.

    That is not what is meant by bias. If you have lots of 5s in your dataset, they will all be rounded up. This introduces a statistical bias. Look it up. It can cause problems.

    If you have "a lot of fives in your data" you've already got a bias. If your last significant digit is 5 for significantly more than 1 in 10 data items, your data is suspect. Probably someone's feeding you their income taxes.

  • Patrick (unregistered)

    If it's just a terminal application written in C, I don't see why porting it to Windows directly from the original source would be that hard. I can't imagine that a program that just crunches numbers relies too heavily on the OS's API rather than just the stuff available in the C Standard Library.

  • coyo (unregistered) in reply to Patrick
    Patrick:
    If it's just a terminal application written in C, I don't see why porting it to Windows directly from the original source would be that hard. I can't imagine that a program that just crunches numbers relies too heavily on the OS's API rather than just the stuff available in the C Standard Library.

    You should be right, but the new team was full of 'Windows is better' ferver, as well as 'we can write this by scratch' and 'Visual Basic is so cool'.

    But of course, nothing is simple. The original was in Fortran, C, C++ and even a little pascal.

    People here can criticize it all they want, but millions were made using the software.

  • swedish tard (unregistered) in reply to Ike
    Ike:
    Homer:
    Back in the 90's, you didn't need to study computer science to write code. These were simpler and hopeful times where you could raise millions of dollars in investment capital just by prepending an ancient idea with the letter e. Code didn't need to be regression tested, or even show that it could perform its intended task in any way.

    The culmination of this philosophy, of course, came with Windows ME.

    Thank goodness those days are over. Now, of course, only those who have passed a rigorous certification process are allowed to write code. The end result? Windows Vista.

    While I dotn use Vista nor recommend it to anyone I know, it is by far a better OS than ME. I mean, you could be forced to install ME 15-20 times before it ended up NOT BSODing on the first boot. >.< I had a girlfriend with a stupid father that insisted that ME was the best thing since fire. The stupid fucker also tried to install a pirate version of ME over my very carefully configured and installed windows 2000 because the drivers for some fucking printer/scanner didnt work for 2000. At least he couldnt install them. I had made bloody fucking sure he couldnt since he had spent the better part of half a year to get every bloody spam and malware in existance installed on purpose, then blaming his kids, specifically my GF. Whom I am pretty sure he actually raped but noone dared tell me since I'd have killed the motherfucker. Instead he ended up being stabbed in the chest by her.

    </rant>

    TLDR: Vista better than ME. Just not good.

  • (cs) in reply to Anon
    Anon:
    Jaime:
    Anon:

    0.59 0.51 0.501 0.500000000000000000000000001

    VB round all of those to 1. It only rounds exactly 0.5 down to 0.

    You missed the point. The value you see is 0.5, unless you know that it really is exactly 0.5, it could just as easily been any of the values above, and therefore should be rounded up.

    YOU missed the point. First of all, if the value of what you see is 0.5, then 0.59 should not have given a 1-sig-fig 0.5. Second, you're completely missing that 0.5 could just as easily be representing 0.49999999..., etc.

  • Max (unregistered) in reply to Anon
    Anon:
    Mcoder:
    Rounding 5s up inserts a bias into your data

    No, it doesn't.

    If you are rounding 0.x then:

    0.0 -> 0 0.1 -> 0 0.2 -> 0 0.3 -> 0 0.4 -> 0 0.5 -> 1 0.6 -> 1 0.7 -> 1 0.8 -> 1 0.9 -> 1

    Notice that for half the values of x, it rounds to 0, for the other half, it rounds to 1. That is unbiased.

    You must remove the 0.0 -> 0 line (or add a 1.0 -> 1 line), otherwise it's cheating.

  • RC (unregistered)

    Give an honorary WTF award to several of the suggestions here.

    In the NT days (mid 90s) computer resources were slim, very few emulators were around, and if you found one, it would probably run like a dog on your high-end 200MHz PII with 16MBs of RAM. Cygwin/MinGW was unheard-of, and even if it wasn't, the interface is going to be either curses, hard-coded XYZ which you need an emulator for, or X11, for which not many Windows implementations existed.

    And for the record, the WTF in the story is managers selling this solution to their superiors as replacing the "legacy" application.

  • chunder thunder (unregistered) in reply to Anon
    Anon:
    Mcoder:
    Rounding 5s up inserts a bias into your data

    No, it doesn't.

    If you are rounding 0.x then:

    0.0 -> 0 0.1 -> 0 0.2 -> 0 0.3 -> 0 0.4 -> 0 0.5 -> 1 0.6 -> 1 0.7 -> 1 0.8 -> 1 0.9 -> 1

    Notice that for half the values of x, it rounds to 0, for the other half, it rounds to 1. That is unbiased. But the point about not round prematurely is absolutely true. The computer has no problem dealing with large numbers of decimal places, even if most of them are meaningless.

    See the other responses above, but you are not understanding "bias" correctly and here's one way to see it. Take your data above, and compute the average before and after rounding.

    Before: ( 0 + 0.1 + ... + 0.9 ) / 10 = 0.45 After: ( 0 + 0 + 0 + 0 + 0 + 1 + 1 + 1 + 1 + 1 ) / 10 = 0.50

    You've increased the average by rounding. That is bias. That is bad. You've got to do something about it. How you remove it depends on the characteristics of the data you've got. If you have many different whole numbers, then the round-even approach works.

    You're also incorrect about assuming that 0.5 necessarily represents a number as big or bigger than 0.5. You really need some specific knowledge about where the number came from to say for sure, but in general, if it came from the analog world, it involved a measurement. Thus, 0.5 normally represents the range (0.5-epsilon, 0.5+epsilon) where epsilon is half your resolution. You can make the case equally well for rounding either way.

  • Buddy (unregistered) in reply to Anon
    Anon:

    No, it doesn't. ... That is unbiased.

    Note adjustments required to round up or down:

    0.0 -> 0 -> 0.0 0.1 -> 0 -> -0.1 0.2 -> 0 -> -0.2 0.3 -> 0 -> -0.3 0.4 -> 0 -> -0.4 0.5 -> 1 -> +0.5 0.6 -> 1 -> +0.4 0.7 -> 1 -> +0.3 0.8 -> 1 -> +0.2 0.9 -> 1 -> +0.1

    Add them all and the total is +0.5. That means on average, using this algorithm, each rounding operation will introduce +0.5/10 or +0.05 bias. For that reason, 0.5 is rounded up or down +/- 0.5. This will correct the bias.

    On another note, implementing banker's rounding correctly, like really correctly, is a major pain in the ass, so most people just ignore the bias and use int(x + 0.5). I won't tell if you don't tell.

  • (cs) in reply to Anon
    Anon:
    Jaime:
    Anon:

    0.59 0.51 0.501 0.500000000000000000000000001

    VB round all of those to 1. It only rounds exactly 0.5 down to 0.

    You missed the point. The value you see is 0.5, unless you know that it really is exactly 0.5, it could just as easily been any of the values above, and therefore should be rounded up.

    I didn't miss the point. I opened VB and made it round 0.501. It rounded to 1. The problem you described does not exist, unless you are rounding a value very near the maximum precision of the underlying type.

  • tego (unregistered) in reply to Anon
    Anon:
    Mcoder:
    Rounding 5s up inserts a bias into your data

    No, it doesn't.

    If you are rounding 0.x then:

    0.0 -> 0 0.1 -> 0 0.2 -> 0 0.3 -> 0 0.4 -> 0 0.5 -> 1 0.6 -> 1 0.7 -> 1 0.8 -> 1 0.9 -> 1

    Notice that for half the values of x, it rounds to 0, for the other half, it rounds to 1. That is unbiased. But the point about not round prematurely is absolutely true. The computer has no problem dealing with large numbers of decimal places, even if most of them are meaningless.

    0.0000 -> 0 0.0001 -> 0 0.0010 -> 0 0.0011 -> 0 0.0100 -> 0 0.0101 -> 1 0.0110 -> 1 0.0111 -> 1 0.1000 -> 1 0.1001 -> 1

    Rounding up is a lot harder to calculate in binary

  • Quirkafleeg (unregistered) in reply to tego
    tego:
    0.0000 -> 0 […] 0.0100 -> 0 0.0101 -> 1 […] Rounding up is a lot harder to calculate in binary
    … however, deliberately getting it wrong is easy.
  • WWWillem (unregistered)

    All the commenters assume that the original program was written in C or Fortran, but could it be that it was written in HP Basic -- pretty popular at the time -- and that therefore those engineers tried to port the application to VB?

  • Luis Espinal (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    Broken Sarcasm Detector:
    Buddy:
    When I saw the specs, I immediately thought to write an interface to access the application remotely. Glad to see they (eventually) came to the same conclusion. Hope they hide those HP-UX boxes somewhere safe and secure with a good UPS. Everyone's happy.

    Let's have a vote:

    Who else endorses this solution?

    Me. They could have still done something "enterprisey" without creating a total WTF, by adding an RPC layer on top of the old application, and having a lightweight front end communicating with it from the engineers' desktop machines.

    Ditto. Sometimes people forget that a re-write does not have to be a all-or-nothing affair. Number crunching apps - specially those written by engineers (that are not software engineers), aren't amicable for rewrite.

    Furthermore, many of those apps simply work well for what they are supposed to do. If it ain't broke, don't touch it. That's a good software engineering principle. Put a pretty face on them, and voila.

    Now, we could even run the simulation software on an emulator (possibly local to the engineer) - pretty Windows face communicating with RPC with the simulator hosted in an emulator. Voila again, now you can get rid of the old HP-UX servers.

    Then, when there is enough funds and enough software building know-how, and only when this setup doesn't work anymore for future needs, then you look into rewriting the hole thing.

    ps... on a sad note, some of my work involves dealing with an abomination like the one the senior engineers attempted to build. Unfortunately, no one pulled the plug before the monster metastasized into existence.

  • The Bytemaster (unregistered)

    I just realized that half of the rounding arguments in the comments are confising display values with storage values.

    You would only want to round for display while storing the original number in a lot of cases. Look back at your own arguments and see if the person you are arguing with is arguing from the opposite point of view (for display as opposed to for calculation)

  • (cs) in reply to The Bytemaster
    The Bytemaster:
    I just realized that half of the rounding arguments in the comments are confising display values with storage values.

    You would only want to round for display while storing the original number in a lot of cases. Look back at your own arguments and see if the person you are arguing with is arguing from the opposite point of view (for display as opposed to for calculation)

    I mentioned both in the same post. People don't get it because most of the population isn't good at statistics.

  • (cs) in reply to JP
    There's a reason many of us who work with legacy code in VB won't put it on our resumes - because without fail, *EVERY* VB project we've been put on is an unbridled mess. No reason to attract more mess - there is no such thing as elegant VB code.

    +1

  • Henrik Rune Jakobsen (unregistered) in reply to Homer

    Hey... I liked Windows ME. Worked like a charm on my machine.

    Ducking for incoming missiles ;)

  • Shinobu (unregistered) in reply to coyo

    Considering this was a scientific number crunching program in the nineties I'd wager the actual number cruncher was coded in Fortran, so I would probably (given the original time span, not the emergency oh-shit-our-developers-fucked-up emergency deadline) have recompiled the Fortran program as a DLL and written a front-end in VB (tutorial is here: http://support.microsoft.com/kb/123841).

    coyo:
    1: DIM X as variant 2: DIM Y as variant 3: X = true; 4: Y = false; 5: if( val(X) = val(Y) ) THEN 6: MSGBOX("Visual Basic is AWSOME") 7: END
    3: Syntax error 4: Syntax error 8: Block If without End If Also, everyone knows Val parses a string containing a number. No booleans, no dates, they're all 0. (And yes, VB has safe string parsing routines that raise errors when you feed them crap they can't handle. And CBool for parsing things containing a boolean.) Furthermore, some of your braces don't do what you think they do. At least understand a language before criticising it.
    coyo:
    It could not handle more then 64k/module. This occasionally meant stripping out comments and formatting whitespace.
    I sincerely hope I'll never have to debug anything you wrote, regardless of the language.

    As for the rounding issue, I was reminded several times during the measurement and data analysis physics class to round to even to avoid quantification bias.

  • eric bloedow (unregistered)

    this reminds me of a story where someone had the bright idea of passing information from one workstation to another by inserting it into the WINDOWS SYSTEM REGISTRY!

  • eric bloedow (unregistered) in reply to Anonymous

    oh, you missed the last line: "the only question was when management would retire the legacy code." in other words, their managers won't let them use the new system,they are forcing them to keep using the old system! THAT's the real WTF!

Leave a comment on “A Terminal Condition”

Log In or post as a guest

Replying to comment #494865:

« Return to Article