I guess I was talking about fission/fusion reactions, although I have to say that I hadn't really considered radiation damage.
The extent of my knowledge on this is that I spent a summer working on supercomputing at Los Alamos, and this was the explanation I heard for why simulating nuclear explosions was necessary.
Not having a security clearance, I didn't get any more details than that. But, I have to agree with the original post. At least in terms of how the research grants are justified, nuclear simulation (due to restrictions from the test ban treaty) and weather/climate modeling are two major applications for supercomputing.
I didn't pursue the field at the time, because I wasn't really interested in either of those applications. So, I would be very interested to hear more about other applications that you know of for supercomputing. (I'm talking about high-end massively parallel number-crunching...I would put things like computational genetics in a different category, because they are really more of a database problem)
I'd also imagine that there are applications that are not tractable now, but will be when the horsepower is increased. What are these applications of tomorrow?
What's interesting about this is that it becomes more of a problem over time. If you look at the amount of "missing" hard drive space as a percentage, it goes up as the drives get bigger.
It becomes more noticeable at the TeraByte, PetaByte range than it was in the KiloByte range.
I used to work for a medical database software company (4 years ago) that provided it's source code to it's customers, and encouraged them to work with it and customize/modify it themselves.
I don't know the details of their license agreement, but I know that all of the source code was viewable and could be modified on each customer's system. In fact, this is how we sometimes did customization for them (edit the source of a few routines on their installation) It kind of made a headache for the release team, though (:
The beauty of this arrangement was that sometimes they would get customers to send in improvements, which we would then roll into the next release. We would still have to review the changes, but you get some testing/debugging work done for free!
So, my point is that this type of arrangement can work out, and it can be mutually beneficial for both the software company and the customer.
Last I checked the company appears to still be doing very well.
Re:Itterative Development/Refactoring
on
Agile Modeling
·
· Score: 1
what the hell are you talking about?
Refactoring does not have to do with "pruning" your design (which I'm interpreting as making complicated designs simpler). It's actually the exact opposite -- It has to do with making a simple design more complicated, as needed.
The whole idea is that you start off with simple designs (i.e. underkill) and then rely on refactoring to add in additional features later instead of trying to predict the future and making a too-complicated design at the start.
Yes, maybe they could implement something that would prevent deep linking (like checking the referrer page), but they probably figure it's only a matter of time until someone finds away around that and deep links anyway.
This might lead to something reminiscent of the coding wars between AOL and MS over the Instant Messenger client.
The point is: they are trying to establish their right to assert a _policy_. This is why you would go through legal channels. Once you have established that as a right, then you could implement measures to prevent deep linking. This way, circumventing those measures would already be established as unlawful.
This is odd. I thought that OO was faster, since the db has references to the objects you link to in foreign tables. This makes it a O(1) to join rather than O(log n).
That may be true for viewing the data (SELECT), but the converse is true for modifying data(DELETE,UPDATE) In that case, it would take more time in an OO Db to update all the references you are keeping around.
Slashdot Mirror
I guess I was talking about fission/fusion reactions, although I have to say that I hadn't really considered radiation damage.
The extent of my knowledge on this is that I spent a summer working on supercomputing at Los Alamos, and this was the explanation I heard for why simulating nuclear explosions was necessary.
Not having a security clearance, I didn't get any more details than that. But, I have to agree with the original post. At least in terms of how the research grants are justified, nuclear simulation (due to restrictions from the test ban treaty) and weather/climate modeling are two major applications for supercomputing.
I didn't pursue the field at the time, because I wasn't really interested in either of those applications. So, I would be very interested to hear more about other applications that you know of for supercomputing. (I'm talking about high-end massively parallel number-crunching...I would put things like computational genetics in a different category, because they are really more of a database problem)
I'd also imagine that there are applications that are not tractable now, but will be when the horsepower is increased. What are these applications of tomorrow?
The reason for simulating nuclear reactions instead of directly observing the effects is because of things like the nuclear test ban treaty.
What's interesting about this is that it becomes more of a problem over time. If you look at the amount of "missing" hard drive space as a percentage, it goes up as the drives get bigger.
It becomes more noticeable at the TeraByte, PetaByte range than it was in the KiloByte range.
2.34% KB
4.63% MB
6.87% GB
9.05% TB
11.18% PB
I used to work for a medical database software company (4 years ago) that provided it's source code to it's customers, and encouraged them to work with it and customize/modify it themselves.
I don't know the details of their license agreement, but I know that all of the source code was viewable and could be modified on each customer's system. In fact, this is how we sometimes did customization for them (edit the source of a few routines on their installation) It kind of made a headache for the release team, though (:
The beauty of this arrangement was that sometimes they would get customers to send in improvements, which we would then roll into the next release. We would still have to review the changes, but you get some testing/debugging work done for free!
So, my point is that this type of arrangement can work out, and it can be mutually beneficial for both the software company and the customer.
Last I checked the company appears to still be doing very well.
what the hell are you talking about?
Refactoring does not have to do with "pruning" your design (which I'm interpreting as making complicated designs simpler). It's actually the exact opposite -- It has to do with making a simple design more complicated, as needed.
The whole idea is that you start off with simple designs (i.e. underkill) and then rely on refactoring to add in additional features later instead of trying to predict the future and making a too-complicated design at the start.
Yes, maybe they could implement something that would prevent deep linking (like checking the referrer page), but they probably figure it's only a matter of time until someone finds away around that and deep links anyway.
This might lead to something reminiscent of the coding wars between AOL and MS over the Instant Messenger client.
The point is: they are trying to establish their right to assert a _policy_. This is why you would go through legal channels. Once you have established that as a right, then you could implement measures to prevent deep linking. This way, circumventing those measures would already be established as unlawful.
This is odd. I thought that OO was faster, since the db has references to the objects you link to in foreign tables. This makes it a O(1) to join rather than O(log n).
That may be true for viewing the data (SELECT), but the converse is true for modifying data(DELETE,UPDATE) In that case, it would take more time in an OO Db to update all the references you are keeping around.