all good languages. pity i don't speak them. intel's compilers are pretty darn good at optimization (you pretty much get about 10-15% speed up v. gcc with a recompile, more if you're willing to throw more disk space and time at the problem and more still if you link in their math and image libraries). it's not free, but it's cheap enough that it doesn't have to save much time before it's paid for itself.
i suppose that ccured doesn't handle c++. personally, i've got nothing against spending money to get the right tools to solve the problem. whatever gets me from showstopper bugs to running stablely for indefinite amounts of time quickest is the path i'm interested in.
unfortunately valgrind isn't quite finely grained enough to localize stack corruption as it happens. it picks up on obscenely large jumps in the stack pointer, but doesn't detect whether addresses are "correct" relative to the stack frame. of course, how hard that is to do is a function of the abi and the architecture (if you do all your arithmetic on the stack this could be very problematic). it's probably not really tractable, now that i think about it.
i really,/really/ want to avoid the assembly route if at all possible. first, i have a healthy dislike of assembly. but more importanty, analyzing the assembly requires some reverse engineering which has the potential to land me in all sorts of trouble. our collaborators on this particular project are potential competitors on other projects (my company is in a rather small niche), which is why neither of us has the complete code base.
i'm going to try to arrange to send them a set of object files which can then be linked against their stuff into the shared object files which we use to run our system, but other than that i'm out of good ideas... the heisenbugs are particularly frustrating.
i'm using c++, so i guess that means i'm using c too. it's not difficult to avoid about 99.99% of memory bugs in c++ by judicious use of the stl, avoiding dynamic allocation wherever possible, asserting that indices are always in bounds, etc.
unfortunately, the folks supplying the code do not use those techniques and i don't have the luxury of re-educating them.
as for why i'm using c++: implementing about 95% of this particular application in any language that isn't compiled to machine code with a darn good optimizer is pretty much a loss -- the application has to process live video streams in real time. c++ happens to be my weapon of choice in the "compiled to machine code with a darn good optimizer" realm.
systems like these are great when you're engineering things which have known functionality and behave in known ways. so if you've got the business rules you want to implement or the (known correct) control systems, etc. then you're golden. the problem is when you don't know those things (e.g: when you're in the research domain rather than the development domain).
... but it seems pretty obvious to me that there's a pretty reasonable way to solve this in a rational manner with a trade study. obviously, the more money at stake, the more time you'll have to be willing to invest in the trade study. as a rough guide:
1) write down the features you need in an ERP
2) find ERP packages which fit the bill
3) define appropriate metrics (cost of administration, expected amount of down time, etc.) i realize that many of these will be fairly fuzzy, but you can still get a reasonable idea. metrics should include both costs (upfront and maintence / tco type estimates, whether you already have admins to do the job or will you have to hire, etc.) and benefits / utility
4) map out on a matrix how each ERP package performs overall
5) pick the best ERP in terms of cost/benefit
6) if the winning ERP runs on multiple hardware platforms,/then/ ask again whether the iSeries or a windows based solution is better. otherwise, your choice of platform is already made for you.
personally, as i spend more time in industry, i become increasingly agnostic: i don't care if it's linux, os x, solaris, windows, vxworks, etc. — if it's the right tool for the job, then that's what i'll use. which means os x at home, linux for work, and windows for administrivia, time sheets, presentations, etc. in my case.
has (ir)rational purify gotten any easier to use? i showed my boss valgrind (http://valgrind.org/) and he couldn't believe how (relatively) painless it was to use. well, painless in terms of actually using, not painless in terms of how bloody slow things run (but that's kinda to be expected since they're emulating the machine...)
i've reached a point where i run whatever project i'm working on through valgrind at least once every two weeks and usually more often than that (before every non-trivial commit). if there were something splint-like for c++ (but at the same price point), i'd write a clever wrapper script to run that first and then whatever the compiler du jour is.
we have an interesting set of liabilities. we own two autonomous vehicles which we built. it's the insurance on those vehicles that's the expensive bit -- anything we can do to mitigate the damage done should, god forbid, either vehicle be stolen or destroyed is a Very Good Thing (tm) in the eyes of the insurance company. unfortunately, because they're both prototype vehicles, they undergo pretty heavy modifications (both software and hardware wise) pretty often, which is a pain to keep track of and makes the insurance folks nervous. there's pretty much bugger all we can do hardware side (other than remember what's in the vehicles), but cvs is a god send on the software side.
"it is better to ask forgiveness than permission". put in the bug tracking, put in the version control, and if anybody ever asks you why, the answer is simple: you're doing your due diligence as a professional. if you're clever, what you'll do after three or so months is go to the powers that be and explain how you've run a successful pilot program and would like the official go-ahead to make things standard.
if you're a little less bold, call a meeting and pitch it to your boss (and his bosses). estimate how much time (and, as a result, money) the issues you described cost the company. explain how much implementing the stuff you're asking for will cost the company. the key words are: risk management, due diligence, and the potential impact on insurance premiums (you'll have to check into this one, but where i work, the fact that we replicate our cvs server every two hours and have weekly backups for the past three years on-site and for the past several months offsite means that we get quite a pleasant cut in our premiums). if this doesn't work, i think it's time to start shopping your resume around, because it shows that management's head is in completely the wrong place.
... which was founded by a bunch of SAICers. several former object video employees ended up joining shortly after the company was founded because OV had closed its denver offices and was about to lay them off. so far, it's turned out to be a really good thing for all involved (except object video, whom we now compete with).
the only advice i can offer is make sure you're careful about the non-competes and ndas. other than that, it can end up working out well (as it has for folks in my company).
interesting research, but i'm not exactly certain how useful their data are.
first off, the study only speaks to cancer rates in one very small (geographically speaking) portion of the world. the researchers themselves point out the importance of geography, so i'm not quite certain how they arrive at their conclusion that viral infections are linked. i'm not saying it's not possible, i'm just saying that it's a pretty common occurrance when running clustering algorithms to find that you're either converge to different solutions, your clusters actually split "natural" class boundaries, and so on. without seeing their cluster analysis results (and, in particular, what clustering algorithm they used), it's potentially easy to explain away their results as artefacts of the clustering algorithm.
secondly, the article doesn't really go into great detail, but i'm not really convinced that there is a statistically significant variation here (or, rather, i'm not sure what the statistical significance of the variation is). 8% isn't really a whole lot -- certainly not in my line of work. i imagine that when dealing with human beings, most things in that ballpark of 10% can be explained away by looking at the population variance. of course, i am not a doctor, i have no idea what their statistical methodology was, etc. etc. etc.
i think the press game is... dumb, to say the least. i expect you'll see headlines like "dap anklebiter attempts to take on ipod giant in patent suit". i think the best press they can hope for is neutral but they're more likely to open a huge can of worms they'd rather keep shut (i.e. an item by item comparison of the products and related offerings, a comparison of market share, etc. it's almost impossible for creative to come out sounding good)
as for the off chance it might work... my money is on apple's lawyers. it will be really hard for a judge to keep the ipod out of his/her head when making decisions. doubly so for any jury. my gut is that any press that does come from a trial would again be neutral at best for creative. more likely is that creative will get some pretty negative press which will hurt any potential revenue from their patent. also, i'm sure that apple will break out their stash of ip and bury creative up to their eyeballs in counterclaims.
surely apple has several years of prior art in the iPod, which begs the question: why is creative bothering, other than to abuse the legal system in an attempt to get an injunction against iPod sales during a crucial retail season...
given microsoft's behavior in the past, i'd be (pleasantly) surprised if they actually respected their users' privacy by at least giving them a modicum of control over what data is collected and how it may be used. the news here isn't that ms is doing something naughty, but rather that people have figured it out.
thank you. unfortunately, i took a very cirtuitous route to signal processing (my formal training is as a computer scientist with a strong background in computer vision, which necessitated picking up image processing along the way. i'm discovering that my intuition for most things signal processing related isn't nearly as reliable as it is for other things)
urm... dumb question, but isn't amping the signal a no-op in terms of SNR? by amplifying to (say) 20v and using a 24bit ADC you could get the 20 bits minimum to have a hope of finding the signal you're looking for, but you're still going to have to fight the SNR which, if anything, will have decreased (noise added by the amping, which in theory could be largely removed by amping the baseline signal and doing the differential stuff after the amping)
unless (which is quite likely) i'm missing something...
it's hard to really say. i imagine that you have a daq board with high precision A2D converters and sufficient buffering that so long as you can sustain the throughput you're not going to lose any data. (if not, you'd better fix this bit first)
PC side, I'd suggest attention to the IO and memory subsystems if your data is arriving at a sufficiently high rate (of course, this requires your acquisition software to be written to take advantage of the hardware). that said, my suggestion would be: at least 1gb ram (paired modules), separate raid volume for the incoming data (1+0). the rest is dependant on your analysis needs — does your acquisition app do analysis too? would it benefit from multiple cores?
you'll want a vendor with top notch support (so be willing to shell out the extra $whatever for the top end support contract). make sure you explain the importance of your system to them. also, make sure you're going to get support from the software vendor for your acquisition and analysis applications.
other than that, you're pretty much on your own i'm afraid -- you know your application better than i do.
my point was that i believe there is something unexpected in the data and i speculate on a possible explanation. i don't say that the data should be ignored because they don't fit my hypothesized pattern.
your statistics are even more informative when converted to per-capita rates (the uk rate is over 100 times smaller, per capita, than the us rate). that said, i'd be more curious to see how the statistics break down based on geographic and demographic criteria --- i suspect that there's a very small portion of the us population which accounts for an overwhelming majority of the gun related incidents. factoring that portion out, the us and uk end up being on much more even ground. of course, this is pure speculation since i haven't actually looked at the relevant data.
on this particular subject. i believe code complete 2 came out "reasonably recently". that said, were this my task, i'd say the following:
1) document things thoroughly using a tool like doxygen. there is no excuse for interfaces not to be thoroughly documented 2) adopt a standard naming convention. in java, this is easy -- just use the default. in other languages, you'll probably have to make your own up. 3) pick an indentation style. it really doesn't matter which since tools like indent can convert between them almost painlessly. all code that goes into the repository is run through indent to put it into a standard format 4) require that code compile cleanly with no warnings at the most anal retentive compiler settings before it can be checked in unless there are good reasons to ignore the compiler warnings 5) average devs are only able to commit to the "head" fork (or equivalent in your sccs). the code is not committed to the "real" fork until it passes whatever tests you have 6) incorporate tools like valgrind into your testing cycle --- they should come back largely clean. if they don't, things need to be fixed unless there's a really good reason not to. 7) people who check in code which breaks cvs or, upon a code review, are found to not sufficiently adhere to your guidelines owe their dev group donuts.
Slashdot Mirror
all good languages. pity i don't speak them. intel's compilers are pretty darn good at optimization (you pretty much get about 10-15% speed up v. gcc with a recompile, more if you're willing to throw more disk space and time at the problem and more still if you link in their math and image libraries). it's not free, but it's cheap enough that it doesn't have to save much time before it's paid for itself.
i suppose that ccured doesn't handle c++. personally, i've got nothing against spending money to get the right tools to solve the problem. whatever gets me from showstopper bugs to running stablely for indefinite amounts of time quickest is the path i'm interested in.
unfortunately valgrind isn't quite finely grained enough to localize stack corruption as it happens. it picks up on obscenely large jumps in the stack pointer, but doesn't detect whether addresses are "correct" relative to the stack frame. of course, how hard that is to do is a function of the abi and the architecture (if you do all your arithmetic on the stack this could be very problematic). it's probably not really tractable, now that i think about it.
i really, /really/ want to avoid the assembly route if at all possible. first, i have a healthy dislike of assembly. but more importanty, analyzing the assembly requires some reverse engineering which has the potential to land me in all sorts of trouble. our collaborators on this particular project are potential competitors on other projects (my company is in a rather small niche), which is why neither of us has the complete code base.
i'm going to try to arrange to send them a set of object files which can then be linked against their stuff into the shared object files which we use to run our system, but other than that i'm out of good ideas... the heisenbugs are particularly frustrating.
i'm using c++, so i guess that means i'm using c too. it's not difficult to avoid about 99.99% of memory bugs in c++ by judicious use of the stl, avoiding dynamic allocation wherever possible, asserting that indices are always in bounds, etc.
unfortunately, the folks supplying the code do not use those techniques and i don't have the luxury of re-educating them.
as for why i'm using c++: implementing about 95% of this particular application in any language that isn't compiled to machine code with a darn good optimizer is pretty much a loss -- the application has to process live video streams in real time. c++ happens to be my weapon of choice in the "compiled to machine code with a darn good optimizer" realm.
systems like these are great when you're engineering things which have known functionality and behave in known ways. so if you've got the business rules you want to implement or the (known correct) control systems, etc. then you're golden. the problem is when you don't know those things (e.g: when you're in the research domain rather than the development domain).
thankfully no. i'm with the small company on ivst1
... but it seems pretty obvious to me that there's a pretty reasonable way to solve this in a rational manner with a trade study. obviously, the more money at stake, the more time you'll have to be willing to invest in the trade study. as a rough guide:
/then/ ask again whether the iSeries or a windows based solution is better. otherwise, your choice of platform is already made for you.
1) write down the features you need in an ERP
2) find ERP packages which fit the bill
3) define appropriate metrics (cost of administration, expected amount of down time, etc.) i realize that many of these will be fairly fuzzy, but you can still get a reasonable idea. metrics should include both costs (upfront and maintence / tco type estimates, whether you already have admins to do the job or will you have to hire, etc.) and benefits / utility
4) map out on a matrix how each ERP package performs overall
5) pick the best ERP in terms of cost/benefit
6) if the winning ERP runs on multiple hardware platforms,
personally, as i spend more time in industry, i become increasingly agnostic: i don't care if it's linux, os x, solaris, windows, vxworks, etc. — if it's the right tool for the job, then that's what i'll use. which means os x at home, linux for work, and windows for administrivia, time sheets, presentations, etc. in my case.
has (ir)rational purify gotten any easier to use? i showed my boss valgrind (http://valgrind.org/) and he couldn't believe how (relatively) painless it was to use. well, painless in terms of actually using, not painless in terms of how bloody slow things run (but that's kinda to be expected since they're emulating the machine...)
i've reached a point where i run whatever project i'm working on through valgrind at least once every two weeks and usually more often than that (before every non-trivial commit). if there were something splint-like for c++ (but at the same price point), i'd write a clever wrapper script to run that first and then whatever the compiler du jour is.
we have an interesting set of liabilities. we own two autonomous vehicles which we built. it's the insurance on those vehicles that's the expensive bit -- anything we can do to mitigate the damage done should, god forbid, either vehicle be stolen or destroyed is a Very Good Thing (tm) in the eyes of the insurance company. unfortunately, because they're both prototype vehicles, they undergo pretty heavy modifications (both software and hardware wise) pretty often, which is a pain to keep track of and makes the insurance folks nervous. there's pretty much bugger all we can do hardware side (other than remember what's in the vehicles), but cvs is a god send on the software side.
"it is better to ask forgiveness than permission". put in the bug tracking, put in the version control, and if anybody ever asks you why, the answer is simple: you're doing your due diligence as a professional. if you're clever, what you'll do after three or so months is go to the powers that be and explain how you've run a successful pilot program and would like the official go-ahead to make things standard.
if you're a little less bold, call a meeting and pitch it to your boss (and his bosses). estimate how much time (and, as a result, money) the issues you described cost the company. explain how much implementing the stuff you're asking for will cost the company. the key words are: risk management, due diligence, and the potential impact on insurance premiums (you'll have to check into this one, but where i work, the fact that we replicate our cvs server every two hours and have weekly backups for the past three years on-site and for the past several months offsite means that we get quite a pleasant cut in our premiums). if this doesn't work, i think it's time to start shopping your resume around, because it shows that management's head is in completely the wrong place.
... which was founded by a bunch of SAICers. several former object video employees ended up joining shortly after the company was founded because OV had closed its denver offices and was about to lay them off. so far, it's turned out to be a really good thing for all involved (except object video, whom we now compete with).
the only advice i can offer is make sure you're careful about the non-competes and ndas. other than that, it can end up working out well (as it has for folks in my company).
"... is a very good thing."
apparently he never owned a betamax.
interesting research, but i'm not exactly certain how useful their data are.
first off, the study only speaks to cancer rates in one very small (geographically speaking) portion of the world. the researchers themselves point out the importance of geography, so i'm not quite certain how they arrive at their conclusion that viral infections are linked. i'm not saying it's not possible, i'm just saying that it's a pretty common occurrance when running clustering algorithms to find that you're either converge to different solutions, your clusters actually split "natural" class boundaries, and so on. without seeing their cluster analysis results (and, in particular, what clustering algorithm they used), it's potentially easy to explain away their results as artefacts of the clustering algorithm.
secondly, the article doesn't really go into great detail, but i'm not really convinced that there is a statistically significant variation here (or, rather, i'm not sure what the statistical significance of the variation is). 8% isn't really a whole lot -- certainly not in my line of work. i imagine that when dealing with human beings, most things in that ballpark of 10% can be explained away by looking at the population variance. of course, i am not a doctor, i have no idea what their statistical methodology was, etc. etc. etc.
i think the press game is... dumb, to say the least. i expect you'll see headlines like "dap anklebiter attempts to take on ipod giant in patent suit". i think the best press they can hope for is neutral but they're more likely to open a huge can of worms they'd rather keep shut (i.e. an item by item comparison of the products and related offerings, a comparison of market share, etc. it's almost impossible for creative to come out sounding good)
as for the off chance it might work... my money is on apple's lawyers. it will be really hard for a judge to keep the ipod out of his/her head when making decisions. doubly so for any jury. my gut is that any press that does come from a trial would again be neutral at best for creative. more likely is that creative will get some pretty negative press which will hurt any potential revenue from their patent. also, i'm sure that apple will break out their stash of ip and bury creative up to their eyeballs in counterclaims.
but what do i know?
surely apple has several years of prior art in the iPod, which begs the question: why is creative bothering, other than to abuse the legal system in an attempt to get an injunction against iPod sales during a crucial retail season...
it's been a while since i last did much perl, but shouldn't the last line of your sig be:
($world = $world) =~ s/bad/good/g;
otherwise you're making your world better but not ever doing anything with it...
... and then i remembered that this was written by a political 'scientist'. then i went back to not caring.
odds of this guy understanding enough to even begin to appreciate the process involved in creating a game: about 40 billion to 1 against.
odds of this guy understanding his ignorance: about 40 billion to 1 against
odds of this guy understanding that there is more to the game market than gta, halo, etc.: again, about 40 billion to 1 against
given this, what are the odds he should be taken seriously?
given microsoft's behavior in the past, i'd be (pleasantly) surprised if they actually respected their users' privacy by at least giving them a modicum of control over what data is collected and how it may be used. the news here isn't that ms is doing something naughty, but rather that people have figured it out.
thank you. unfortunately, i took a very cirtuitous route to signal processing (my formal training is as a computer scientist with a strong background in computer vision, which necessitated picking up image processing along the way. i'm discovering that my intuition for most things signal processing related isn't nearly as reliable as it is for other things)
urm... dumb question, but isn't amping the signal a no-op in terms of SNR? by amplifying to (say) 20v and using a 24bit ADC you could get the 20 bits minimum to have a hope of finding the signal you're looking for, but you're still going to have to fight the SNR which, if anything, will have decreased (noise added by the amping, which in theory could be largely removed by amping the baseline signal and doing the differential stuff after the amping)
unless (which is quite likely) i'm missing something...
it's hard to really say. i imagine that you have a daq board with high precision A2D converters and sufficient buffering that so long as you can sustain the throughput you're not going to lose any data. (if not, you'd better fix this bit first)
PC side, I'd suggest attention to the IO and memory subsystems if your data is arriving at a sufficiently high rate (of course, this requires your acquisition software to be written to take advantage of the hardware). that said, my suggestion would be: at least 1gb ram (paired modules), separate raid volume for the incoming data (1+0). the rest is dependant on your analysis needs — does your acquisition app do analysis too? would it benefit from multiple cores?
you'll want a vendor with top notch support (so be willing to shell out the extra $whatever for the top end support contract). make sure you explain the importance of your system to them. also, make sure you're going to get support from the software vendor for your acquisition and analysis applications.
other than that, you're pretty much on your own i'm afraid -- you know your application better than i do.
good luck!
my point was that i believe there is something unexpected in the data and i speculate on a possible explanation. i don't say that the data should be ignored because they don't fit my hypothesized pattern.
your statistics are even more informative when converted to per-capita rates (the uk rate is over 100 times smaller, per capita, than the us rate). that said, i'd be more curious to see how the statistics break down based on geographic and demographic criteria --- i suspect that there's a very small portion of the us population which accounts for an overwhelming majority of the gun related incidents. factoring that portion out, the us and uk end up being on much more even ground. of course, this is pure speculation since i haven't actually looked at the relevant data.
on this particular subject. i believe code complete 2 came out "reasonably recently". that said, were this my task, i'd say the following:
1) document things thoroughly using a tool like doxygen. there is no excuse for interfaces not to be thoroughly documented
2) adopt a standard naming convention. in java, this is easy -- just use the default. in other languages, you'll probably have to make your own up.
3) pick an indentation style. it really doesn't matter which since tools like indent can convert between them almost painlessly. all code that goes into the repository is run through indent to put it into a standard format
4) require that code compile cleanly with no warnings at the most anal retentive compiler settings before it can be checked in unless there are good reasons to ignore the compiler warnings
5) average devs are only able to commit to the "head" fork (or equivalent in your sccs). the code is not committed to the "real" fork until it passes whatever tests you have
6) incorporate tools like valgrind into your testing cycle --- they should come back largely clean. if they don't, things need to be fixed unless there's a really good reason not to.
7) people who check in code which breaks cvs or, upon a code review, are found to not sufficiently adhere to your guidelines owe their dev group donuts.