Thesis Ideas
This document represents some ramblings I just feel I _have_ to put down on
paper. (Not that anyone will ever print this out.) Some of it has been
done before, and some of it I just don't know how to do. But here they
are, maybe you might want to pursue some of them.
Multithreaded CPUs
Apr 1997:
The CPU would have to duplicate all the registers between pipeline
stages so that two instruction streams are handled at a time, but the
logic in the stages themselves would only be used by one of the
instruction streams at a time. When one of the streams has to stall
for a cache miss or something, the other stream starts up.
Caching Proxies for http
Apr 1997:
So I figure that the corelation between my netscape cache and Bill's must
be about 50%. Why not use a proxy which acts as a joint cache. Since Bill
and I share the same machine, that means some of the stuff we're interested
in out there in net-land must be the same. The proxy would cache it when
I go to get it, and Bill would get a cached copy much faster.
Also, the Netscape cache is really slow when it gets to be about 20 Megs
or so. A better caching strategy must be available for large documents.
Some Stewart guy just did a Masters in CS on caching for cellular web clients.
Maybe I could look at stuff there.
Complexity Management
Dec 1996:
Computer software is getting big. Larger and more difficult problems
are being tackled. Could Knuth's "Literate" programming be a step to
management of this complexity? Can this be used to generate higher and
higher levels of abstraction for the software design process?
Solve the million-dollar problem -- for under $20K
Dec 1996:
Computers are getting big and fast. The new 64 bit computers can
address 18,446,744,073,709,551,616 (yes, that's 1.8*10^19) memory
locations. I think that 18 billion billion is even more than the US
national debt. Clock rates are up around 300MHz, and will probably be
around 500MHz by the turn of the century. (Gosh, that's getting close
too!).
What did we used to think was unsolveable on a 1MHz multi-million
dollar mainframe 20 years ago, that we should consider solving now? A
plethora of opportunity awaits the optimization world.
Distributed Objects
Dec 1996:
Well, industry's already working on CORBA and the like, and Sun beat me
to my dreamy masters project of doing RMI for Java. Unless I can think
of anything really novel to do with distributed objects, this topic is
dead for me.
Human-Computer Interface
Dec 1996:
So, we've got these big networks and big computers. You've got
tera-byte upon tera-byte of data at your fingertips. Is this the best
place for it to be?
What about the Scientific American article I read years back of the
stock brokers standing back and looking over a computer generated wheat
field. He notices a ripple in the field over to his right. He moves
in for a closer look and sees what is going on. So, they had this
computer looking at reams of data (coming from the stock market, in
this case) and grabbing your attention when an anomaly was noticed.
If I could also get some funky multi-media type stuff using sound and
colour to garner the attention of the operator when appropriate.
Assertive Programming
Dec 1996:
I don't know if this is the right word for it but...
Eiffel has pre-conditions and post-conditions that have to be satisfied
by all methods. Eiffel is more than a programming language, it's a
programming method. The source and the specification are one. Pre and
post-conditions are checked at runtime.
This gives me a warm fuzzy feeling, as your program is proven, if your
pre and post-conditions are correct. Perhaps some research in how to
methodically arrive at correct pre and post-conditions would result in
more reliable software.
Distributed Database Builder
Dec 1996:
Ok, so the web's getting kinda big and burly and full of useless junk.
It's also getting so big that undexing it is becoming a nightmare.
What's the bottleneck to indexing it? Probably bandwidth. So, why not
set up a distributed database builder. Big companies like IBM, Digital,
and the like have computer centres all over the world. Each node of the
database builder could index sites local to it. You can use traceroute
or whatever to figure out how far things away are from you. Then you'd
have to periodically merge all the newly collected data into one big
database. Also, the nodes could know where each other are, so that when
node A finds a link to somewhere near node B the link would be indexed
by B, not A.
Then, I could use the output of this as input for...
Massive Information-base Visualization Tool
Dec 1996:
There's gotta be a head-shinker or two over in psychology who's bored
of running rats through a maze. They could come up with a discription
of what catches people's attention fast. Then I could come up with
some way of pouring through reams of data and presenting it. There could
be some sort of stack of your past topics that still gets updated after
you moved past that. Some stuff might come up fast and you can look
there right away. Then, while you are reading that stuff, it keeps on
looking for more stuff which you can look at out the corner of your eye
in case anything better comes along.
Distributed, Fault-Tolerant Optimization Package for Integer Programs
Dec 1996:
Since finding optimal solutions for integer programs is just a search through
a big search tree, it is a good candidate for distribution. Let's think up
a way to also do this with fault-tolerance so that the failure of one or more
nodes in the system can be handled gracefully. This will involve some sort
of distributed checking in/out of the branches in the search tree. Since we
don't want a single point of failure, we'll want the search tree itself to
be distributed. We should also expect a fairly good speedup on these very
long running problems. It would also make for some fairly easy load balancing.
If the load on a machine gets to big, the process(es) there just checkpoint
and blow themselves away.
Investigation into the application of new programming languages to
Simulation
Dec 1996:
Some of the new languages like Sather were designed with optimization in
mind. They also give much better support for object oriented design than
traditional languages like C and C++. How about trying out the usefulness
of these languages for writing simulations.
Mark Frazer -- mjfrazer@gmail.com