Not entirely a facetious comment... Surely whatever smarts can be evolved in a germ can also be simulated in hardware? Sure DNA computing might be fast and massively parallel - but don't we still have to instruct it, or grow it, to solve useful problems?
Well its been a while since I've worked in a molecular biology lab and studied bioelectronics. My first mentor was a biophysicist and he taught me a lot about the physics behind cell function. Of course I have forgotten all of it. In school I took a lot of bioelectronic courses that delved into studying the electric impulses etc in biologic systems and simulating biologic circuitry with bread boards.
You would be surprised to discover a lot of stuff we do is already done in nature naturally and at a much more microscopic level.
I think the current methods are based on some variant of monte carlo. Basically set up some trials that would penalize things you don't want and optimize for behaviors that you do want. Find a set of normal occurences that behave kind of like what you want and run them thru the trials. So natural selection accelerated.
Of course in lab we also did a lot of DNA replication with bacteria - once you found a gene sequence that behaved like you wanted you would splice this in with DNA of bacteria and use the bacteria machinery to replicate. All very fun stuff - and that was 20 years ago - so I imagine things have gotten more advanced and precise.
Agreed. The article that convinced me of this "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software" http://www.gotw.ca/publications/concurrency-ddj.htm
How will this affect the evolution of the JTS going forward?
Biological/evolutionary computing is certainly fascinating. Seems like it's great at things which are wide but not deep - pattern-matching kinds of things. The sort of thing that humans are good at, actually! I'm not sure sure about very finicky structured problems - like say polygon union! On the other hand, maybe we'll just realize that we're asking the wrong questions...
Good question about JTS... I think the next step is to look at starting to extract parallelism from geometric algorithms, and set them up to run with multiple threads. Java at least makes this not too painful - and I think at least some algorithms parallelize naturally.
The other approach is to just leave JTS alone, and parallelize at a higher level - for instance, executing a DB select query in parallel. That would make my life easier... 8^)
Makes sense.... here's another JTS fantasy: ImmutableGeometry (by analogy with PreparedGeometry). If you could create immutable versions of geometries, then they would be guaranteed thread-safe.
One way to do this would be to have the geometries return defensive copies. That's rather expensive, though.... maybe it would make more sense to provide a read-only accessor. I'll let you know if I work something like that up.
It is actually fairly easy to make geometries 100% immutable. The key is simply to always return copies of unsafe structures, such as Coordinate arrays.
JTS tries to steer a narrow course between the flexibility and performance benefits of having full, deep access to internal structures, and the security of immutability. In general treating Geometry as immutable is STRONGLY encourage - but JTS does give you a little bit of string to hang yourself with if you like. 8^)
Interesting comment about "On the other hand, maybe we'll just realize that we're asking the wrong questions..."
I have observed these days that in solving a lot of my clients problems, I simply restate their questions in the context of questions I already know the answer to. So I'm actually not solving any new problems.
I guess that's the advantage to a pattern oriented system - that it can see embedded patterns in larger ones and restate the larger patterns in the context of the more atomic ones.
Source: Challenges and Strategies for High End Computing, Kathy Yelick
My money is on biological self-assembly to vastly impact computing in the next 10 years.
ReplyDeletehttp://www.spectrum.ieee.org/print/6150
My money is on biological self-assembly to vastly impact computing in the next 10 years.
ReplyDeletehttp://www.spectrum.ieee.org/print/6150
Seems a bit scary to me....
ReplyDeleteAnd how are we going to teach SQL to a germ?
Not entirely a facetious comment... Surely whatever smarts can be evolved in a germ can also be simulated in hardware? Sure DNA computing might be fast and massively parallel - but don't we still have to instruct it, or grow it, to solve useful problems?
Not that I'd bet against this, however.
Well its been a while since I've worked in a molecular biology lab and studied bioelectronics. My first mentor was a biophysicist and he taught me a lot about the physics behind cell function. Of course I have forgotten all of it. In school I took a lot of bioelectronic courses that delved into studying the electric impulses etc in biologic systems and simulating biologic circuitry with bread boards.
ReplyDeleteYou would be surprised to discover a lot of stuff we do is already done in nature naturally and at a much more microscopic level.
I think the current methods are based on some variant of monte carlo. Basically set up some trials that would penalize things you don't want and optimize for behaviors that you do want. Find a set of normal occurences that behave kind of like what you want and run them thru the trials. So natural selection accelerated.
Of course in lab we also did a lot of DNA replication with bacteria - once you found a gene sequence that behaved like you wanted you would splice this in with DNA of bacteria and use the bacteria machinery to replicate. All very fun stuff - and that was 20 years ago - so I imagine things have gotten more advanced and precise.
Yes teaching SQL to germs. Really fun stuff.
Martin,
ReplyDeleteAgreed. The article that convinced me of this
"The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software"
http://www.gotw.ca/publications/concurrency-ddj.htm
How will this affect the evolution of the JTS going forward?
regards,
-Frank
@Regina:
ReplyDeleteBiological/evolutionary computing is certainly fascinating. Seems like it's great at things which are wide but not deep - pattern-matching kinds of things. The sort of thing that humans are good at, actually! I'm not sure sure about very finicky structured problems - like say polygon union! On the other hand, maybe we'll just realize that we're asking the wrong questions...
@Frank
ReplyDeleteGood question about JTS... I think the next step is to look at starting to extract parallelism from geometric algorithms, and set them up to run with multiple threads. Java at least makes this not too painful - and I think at least some algorithms parallelize naturally.
The other approach is to just leave JTS alone, and parallelize at a higher level - for instance, executing a DB select query in parallel. That would make my life easier... 8^)
Martin,
ReplyDeleteMakes sense.... here's another JTS fantasy: ImmutableGeometry (by analogy with PreparedGeometry). If you could create immutable versions of geometries, then they would be guaranteed thread-safe.
One way to do this would be to have the geometries return defensive copies. That's rather expensive, though.... maybe it would make more sense to provide a read-only accessor. I'll let you know if I work something like that up.
regards,
-Frank
It is actually fairly easy to make geometries 100% immutable. The key is simply to always return copies of unsafe structures, such as Coordinate arrays.
ReplyDeleteJTS tries to steer a narrow course between the flexibility and performance benefits of having full, deep access to internal structures, and the security of immutability. In general treating Geometry as immutable is STRONGLY encourage - but JTS does give you a little bit of string to hang yourself with if you like. 8^)
@Martin,
ReplyDeleteInteresting comment about "On the other hand, maybe we'll just realize that we're asking the wrong questions..."
I have observed these days that in solving a lot of my clients problems, I simply restate their questions in the context of questions I already know the answer to. So I'm actually not solving any new problems.
I guess that's the advantage to a pattern oriented system - that it can see embedded patterns in larger ones and restate the larger patterns in the context of the more atomic ones.