Friday, August 8, 2014

Worshipping complexity

Frankenstein tells the story of a monster created by technology.  The story is popular because it is prophetic.  There are no literal Frankenstein monsters but I don't think many people recognize the real, runaway Frankenstein monster we've created.  A few weeks ago, in a fit of temper, I smashed my netbook.  My shoulder is still sore from it.  But in retrospect, I'm glad I destroyed that machine because I'm certain it was spying on me.  Why else would I be offered such a convenient device with such impressive specifications--dual, 1.66 GHz processors, 1 gigabyte of RAM, 160 gigabytes of hard-disk space--for so little money?  Twenty years ago, that was super-computer territory.  That also happens to be equipped with a microphone and a low-light video-camera.  In the wake of Edward Snowden, I don't think we need to ask the question.  It also explains why, despite it's impressive technical specifications, the machine was so damn slow.

There's no question in my mind that in twenty years or so, there won't even be any human beings behind the spying, that is, assuming the computers even let us live.  Most if not all of the elements are in place for a complete take-over of our world by the machines.  Assuming it hasn't happened already.  Yes, this our Frankenstein monster: runaway technology.  It no longer serves us, we serve it.  And it has caused considerable damage to the natural world like the tar sands in Northern Alberta.

But these elements of complexity are beyond my means to tackle, so I'd like to focus on those that are within reach: inside my own computer code. Recently I wrote an answer on Quora about why so many people seem to hate C++.

The purpose of using a more expressive language is to simplify things: to accomplish more with less, but the more I consider it, the more I'm beginning to suspect that C++ actually does the opposite. It actually encourages you to make your code more complex.  Take this class definition, presented in it's entirety, for a sparse matrix:

namespace libpetey {
  namespace libsparse {

    //forward declaration of sparse_el:
    template class sparse_el;

    typedef int32_t ind_t;

    #define EPS 5.96e-8         //this is actually pretty big... (?)

    template
    class sparse:public matrix_base {
      //friend void conj_grad_norm(sparse *, data_t *, data_t *, data_t, long);
      //friend double * irreg2reg(double **xmat, long m, double *y, long n, double **grids, long *ngrid);
      private:
        //since all the "constructors" do the same thing, we have one private
        //routine to do them all:
        void copy(const sparse &other);
        void convert(sparse_array &other, data_t neps=EPS);

      protected:
        sparse_el *matrix;

        //dimensions:
        index_t m;
        index_t n;

        //number of nonzero elements:           (these types should depend on index_t
        long nel;                               //i.e. index_t = int32_t, then use int64_t)

        //index of last element searched:
        long last_search;

        //size of array
        long array_size;

        //update flag:
        //0=matrix needs updating
        //1=matrix is fully updated
        //2=matrix is sorted but has zero elements
        char update_flag;

        //"zero" tolerance:
        float eps;

        FILE *sparse_log;


      public:
        //initializers:
        sparse();
        sparse(data_t neps);
        sparse(index_t min, index_t nin, data_t neps=EPS);
        sparse(data_t **non, index_t min, index_t nin, data_t neps=EPS);
        virtual ~sparse();

        //create the identity matrix with existing dimensions:
        void identity();
        //create the identity matrix with specified dimensions:
        void identity(index_t mn, index_t nn);

        sparse(matrix_base *other);
        sparse(const sparse &other);
        sparse(sparse_array &other);
        sparse(full_matrix &other, data_t neps=EPS);

        void from_full(data_t **non, index_t min, index_t nin, data_t neps=EPS);

        //storage manipulation:
        void update();          //update matrix
        void remove_zeros();    //remove insignificant elements
        //remove elemnts of less than specified magnitude:
        void remove_zeros(data_t minmag);
        //clear matrix, but do not change storage:
        void reset(index_t mnew=0, index_t nnew=0);
        //clear matrix, deallocate storage:
        void clear(index_t mnew=0, index_t nnew=0);
        //extend storage by specified amount:
        void extend(long size);

        //add and access matrix elements:
        //add or change an element:
        long add_el(data_t val, index_t i, index_t j);
        //change existing element or insert new:
        virtual long cel(data_t val, index_t i, index_t j);

        //return value of element:
        virtual data_t operator ( ) (index_t i, index_t j);

        //access rows:
        virtual data_t *operator ( ) (index_t i);
        virtual void get_row(index_t i, data_t *row);
        //ratio of amount of storage to equivalent full:
        float storage_ratio();
        //approx. ratio of performance (for matrix multiply) to equivalent full:
        float performance_ratio();

        //I/O:
        virtual size_t read(FILE *fptr);                //binary read
        virtual size_t write(FILE *ptr);                //binary write
        virtual void print(FILE *ptr);          //print (ascii) to file
        virtual int scan(FILE *ptr);            //read from (ascii) file
        void print_raw(FILE *ptr);

        //the "canonical" versions:
        virtual matrix_base * mat_mult(
                    matrix_base *cand);
        virtual matrix_base * add(matrix_base *b);

        virtual data_t * vect_mult(data_t *cand);
        virtual void scal_mult(data_t m);
        virtual data_t * left_mult(data_t *cor);

        virtual matrix_base & operator = (full_matrix &other);
        virtual matrix_base & operator = (sparse &other);
        virtual matrix_base & operator = (sparse_array &other);

        virtual data_t norm();

        virtual matrix_base * clone();

       //sparse & operator = (matrix_base &other);

/*
        virtual operator sparse& ();
        virtual operator sparse_array& ();
        virtual operator full_matrix& ();
*/

    };

    template
    inline long sparse::size() {
      return nel;
    }

    template
    inline void sparse::remove_zeros() {
      remove_zeros(eps);
    }

    typedef sparse sparse_matrix;

  }  //end namespace libsparse
}    //end namespace libpetey

Hmmmm....  it doesn't look that simple.  (Hopefully you didn't read through all of it.)  Notice how I've thrown in everything but the kitchen sink: well, templates allow us to use the class with different data types, so why don't we throw them in?  Namespaces prevent collision between symbols in different libraries and they define modules, so why don't we throw them in as well?  And so on.

Why don't we start over, and this time work in C?  

typedef float scalar;
typedef integer int32_t;

struct sparse_element {
  integer i;
  integer j;
  real value;
}

This is how we could define the data structure. To create an instantiation of it, just make an array:

sparse_element sparse_matrix[nel+1];

The first element could hold the dimensions of the matrix:

sparse_matrix[0].i=m;
sparse_matrix[0].j=n;

This type of doubling up on variables is often discouraged, but does have the nice side effect of making code a little simpler and less cluttered.  The number of data elements could be either stored in a separate variables (common with arrays in C), stored in the value field or an extra element that serves as an end marker tacked on to the end of the array, much like C strings.  This is not as mad as it sounds: most functions will operate on the whole list, iterating through each element one-by-one.  One thing we lose is the ability to add new elements easily, but on the other hand it is more efficient to have some idea how big your data structure will be ahead of time and to allocate space accordingly.

This doesn't include all the operators which of course will all need be set down.  But we've also left out the templates and the namespaces.  Sure, it's nice to be able to use the matrix class with different scalar data types and with different integer types for index locations, but are we really ever going to use, at the same time, multiple sparse matrices comprised of different elementary types?  Probably not.  A typedef works just as well and is far simpler.

But even if we need generic programming, this can be done quite easily in C.  Take this prototype for a sort function, for instance:

void heapsort(void **data, int n, int (* comp)(void *, void *));

Where data are the data elements (any type) and func is the comparison function.  Want polymorphism as well?  This isn't too hard either, and it occurs where it should: as far outside of the basic definitions as possible.  It's not built in from the very beginning.  Lets say we have two data types:

struct child1 {
  ...
};

struct child2 {
...
}

And they both have an operator called do_something:

int do_something1(child1 *);
int do_something2(child2 *);

But we need a more general operator that works on either type:

struct parent {
  int type;
  union data {
    child1 *a;
    child2 *b;
  }
};

int do_something(parent *c) {
  switch (c->type) {
    case(1):
      do_something1(c->data->a);
      break;
    case(2):
      do_something2(c->data->a);
      break;
    default:
      fprintf(stderr, "do_something: type undefined\n");
      exit(-1);
}

In this case, yes, the alternative in C is more complicated and "less elegant" whatever that might mean, but it has two features that I like.  First, the branch logic is explicitly written out, not hidden or implicit in the definitions.  Second, the more basic operations are defined completely independently.  There is no need to rough out the larger structure first.

Another thing I like about C, or any pure procedural language, is that processes and data are always strictly separate.  There is no need to mash them together, whether such an alliance is holy or not.  At least C++ gives you the choice; languages like Smalltalk do not.  Another thing I can't stand is forced data-hiding.

Unfortunately, I still haven't mastered these techniques myself.  I got into C++ programming early, just as it was first coming out and haven't switched since.  Actually I had to write a simulation of a chaotic scattering system: essentially a simple ray-tracing program. I started in Pascal because that's what I had learned in highschool.  I had a Turbo-Pascal compiler which had all the bells and whistles, including O-O.  Since I was curious about object-oriented programming and it was another new thing, I coded the problem in this style and it was a very good "fit".  Later on I wanted to learn C and C++ because, like objects, they were also considered "cool" at the time.  So I translated this program into C++: it was almost trivial because the object-oriented aspects of each language were so similar.

Minimalist Coding

I wanted to call it, "extreme programming" but that's taken already and besides, the term is a bit cliche anyway.  But I am going to borrow some ideas from extreme sports, in particular alpinism.  Don't ask me how I got interested in mountaineering.  Heights scare the shit out of me.  I figured if I could overcome this one fear, it would help me with more mundane fears like job interviews or asking a girl out.  I'm not convinced the idea was all that sound.  I never got much further than conquering the easiest routes of the bouldering wall at the local climbing gym.

I also bought and read Extreme Alpinism by Mark Twight.  There are two broad styles of climbing: expedition style and "alpine" style.  In expedition climbing, you take a big company with lots of gear, lay out camps and hang lots of fixed rope.  By being well equipped you are more protected.  On the other hand, you move a lot slower.  In alpine climbing, you take as little gear as possible and try to be self-sufficient.  You can move a lot faster and you're more flexible.

I was most interested in the most extreme style: climbing without rope or protection.  Consider, every-time you insert a chock or other protection, you are distracting yourself from the main task at hand: getting up the mountain.  Also, if your protection is sloppily placed it may be little better than no protection at all.  Why not focus all your energy on the most important thing: making sure you have the best holds and that your hand and foot placement is secure?  Because you aren't carrying all this hardware, you're a lot lighter.  I think you can see where I'm going with this.

So we leave out range checking and don't make any attempt to catch or correct errors.  It's considered normal for a subroutine to return an error code but if every time after calling a subroutine we check for an error condition and the stack is four levels deep, that's an awful lot of extra code and worse, clutter.  When I first started learning computer science, the term GIGO was thrown around a lot: garbage in, garbage out.  Instead of spending so much effort testing for errors, why not spend that effort making sure your inputs are correct?  If your code is also correct, that will guarantee that your output is ultimately error free.

We apply the same minimalism to documentation: keep documentation to a minimum and keep variable names short.  Ideally, the code should be self-explanatory: because we have now reduced the clutter by a large percent, the program is easier to interpret and it's easier to find things.  Naturally, this style works a lot better for scientific programming than more user-oriented problems.  One place where your code almost always has to be fault-tolerant is when importing large amounts of data.  Other people's data is notoriously unreliable. Often, however, large chunks of it can be ignored or thrown away without any ill effects, but we need to catch the bad apples first so as not to spoil the rest.

I confess I am a bit miffed at just how un-portable C and C++ are.  (Though it actually took me a while to realize that integer types may be different sizes on different machines and compilers, actually about the time I started working on 64 bit computers.)  But not miffed enough to use a configure script.  I recently inspected the configure script for an early C++ version of NetCDF: it's over 17000 lines long!  Meanwhile, the wrapper classes that comprise the body of the library are just over 4000 lines.  This is not a recipe for portability.  It's easier to debug a 200 line make file than a 10000 line configure script.  Some time ago I had the privilege of doing so, and the code looked pretty hacked together.

Rising from the ashes

This is me and my foundation rising from the ashes...

Sunday, July 13, 2014

Multi-borders software: reflections

It's been several weeks since I released the "multi-borders" multi-class classification software.  Along with the software, I also submitted this paper to the Journal of Machine Learning Research: Machine Learning Open-Source Software (JMLR-MLOSS) stream but sadly it was rejected.

Actually I'm quite glad that the paper was rejected as there are issues with the software, not least of which is the fact that it's not as accurate as it could be.  This is actually discussed in the paper: the eight-class test case returns an accuracy of about 56% for AGF without borders training, 54% using the "hierarchical" method (essentially a decision tree) and only 52% using the "non-hierarchical" method.  It's the non-hierarchical method that's the most interesting and that I'll be discussing here.  This uses a matrix inversion (least squares, actually) to solve for the conditional probabilities based on the "raw" probabilities from each of the binary classifiers.  That is, if P are the conditional probabilities for each of the classes and R are the differences between the conditional probabilities from the binary classifiers, then there will be a mapping, A, from one to the other and we solve the following equation in a least squares sense:

  A*P=R                    (1)

At first I thought that errors are accumulating from the estimates of the conditional probabilities, which themselves are not all that accurate.  This may not be the case.

On the other hand, you can also solve for the class through "voting" which is how most other multi-class methods work.  Arithmetically, this can be expressed by multiplying the transpose of the mapping with the "raw" classes of each of the binary classifiers, where the class is expressed as one of {-1, 1}.  This method is more accurate even when we use the difference in conditional probabilities in place of the class.  That is, we have:

  c=arg max A^T*R    (2)

where c is the class of the test point.  Unfortunately, this provides poor knowledge of the final conditional probabilities, which in the first method are very accurate. An obvious solution is to constrain (1) so that it always agrees with (2).  The least squares should probably be constrained anyway to keep the each element of P between 0 and 1 and to ensure that the sum is always 1.

In principle this doesn't look that hard: if different sets of constraints (from 1 to N, where N is the number of classes) represent sub-spaces, then it would be a matter of solving the minimization problem within progressively smaller sub-spaces until we find one that satisfies the original constraints, all the while judiciously pruning eligible sub-spaces as we go along.  Adding the new constraint brought on by the "voting" solution would complicate this procedure somewhat.  In practice, it is easy to re-normalize the results from solving (1), so they have so far been left untouched and I doubt the constrained solution would be significantly more accurate than the unconstrained.

I find it really interesting that by basicly flipping the whole equation around, we end up with something that works out about the same:

arg max A^T*R ~= arg max A^(-1)*P

No question this is related to the properties of the matrix itself and should suggest better methods of solving it.

Of perhaps even more concern is that for all the multi-class problems I've tried so far, LIBSVM has handily outperformed libAGF.  At first I thought this makes sense since AGF borders approximates a curved class border from a piece-wise collection of linear borders, while a support vector machine actually analytically warps the space so that a curved boundary is not even necessary.  But this difference is persisting even using the "raw" AGF with no borders training.  I may need to go back to the beginning to optimize the estimation of conditional probabilities.

I confess, I have been somewhat lax in testing this library.  Initially, I was content to try it on the synthetic dataset I had composed and on the particular problems I was trying to solve (discrete retrieval of humidity from satellite data and surface classification of Landsat images) because the speed advantage was just so astronomical--it seemed to make up for any other potential shortcomings such as less than ideal accuracy.  In the problems I was working on often either LIBSVM wouldn't converge or the time it took to classify the test data was so enormous as to just not be worth it.  Of course for small training datasets the speed advantage of AGF evaporates.

The LIBSVM page itself has a very nice collection of datasets. I've messed around with a few of the binary datasets in the past and in retrospect I should've documented the results more thoroughly.  That should be the rule for just about every scientific project, even casual testing.  The ones I'm currently working on are "segment" and "satimage."

Another thing to note about SVM is that it optimizes the classification error.  As you know, AGF generates estimates of the conditional probabilities.  Interestingly, the conditional probability represents the maximum possible accuracy for estimates at that particular location in the feature space.  I used this property very early on to validate the conditional probability estimates by first binning them and then comparing the actual accuracies with the averages in each bin.  Thus, in theory, classifications based on the conditional probabilities are optimally accurate, but that assumes that the estimates themselves are accurate.  Unfortunately, AGF probability estimates are are not optimized, at least not in any way that takes into account error rates.  This is something else I've been working on, mainly for probability density estimation.

Tuesday, June 24, 2014

How to work towards your own enslavement

By now I hope everyone's familiar with the privacy issues related to Google, Facebook and other internet companies.  Here is an interesting talk about it:


The most important point: what are they doing with your data?  They are building electronic models of you so that they can predict your behaviour.

If it is not yet a theorem that prediction implies control, then it should be.  This has been shown for simple systems: assuming we have good knowledge of the system dynamics, small perturbations of a chaotic system can be used to control it .  In one position I was working with the "singular vectors" of weather systems.  These are based on the integrated tangent vector and tell you in which direction, approximately, you have to perturb the system to get the biggest result.  The intended use was for prediction, but I have a bigger idea: use them to control the weather.  If I don't get to this, someone else will eventually.  We set up heat pumps and fans/turbines in strategic locations and use those to drive the system to its desired state.  Hell, they probably already use all the wind farms in Europe for this purpose.

If prediction implies control in physical systems, it is even more so in human affairs.  When I was a kid I used to play a game with my brother called, "Stratego."  It is a bit like chess, but with the conceit that the rank of all the pieces are hidden from the opposing player.  Often I feel like this is my position in life: my hand is open--I am playing chess, while the elites are playing poker.

The models they make for humans are actually a lot less sophisticated.  Mainly these are statistical models.  Statistical models that could be built, for instance, from my libAGF software.  It occurs to me I have also applied the software to the observation side of things, namely retrieving data from satellites.  Recently a fellow e-mailed me asking for help with the software.  It turns out he was rewriting the whole thing in Matlab so his company could use it without any copyright issues.  Since requesting a donation from either him or his company, I haven't heard back.

There are still so many improvements I can make on this software and at times I work daily on it.  In fact the work never ends.  At the moment I am not getting a penny for it and I'm not sure I ever did so directly.  I suspect this is part of the elite's plan as well: encourage the development of "open systems" so that they can have as much free software (and plenty of other stuff) to steal as they need.  Software that will ultimately be used for extortion, repressiong and control.  Sure, if I'm not willing to do it, there are two dozen others willing to step in to my shoes.  Sure there are already dozens, probably hundreds of other pieces of software that will do the same thing just as well.  LIBSVM and LVQ/SOMPAK are just two examples.  But I don't think I'm willing anymore to personally help brick in the walls of my own penitentiary.

Sunday, June 8, 2014

A rational ethical theory: first take

I've already mentioned my interest in ethical philosophy.  This is my first attempt to come up with a rational ethical theory:

1. An ethical statement is a statement that something is either right or wrong, good or bad.
2. An ethical system is a series of such statements.

By this definition the Ten Commandments comprise an ethical system.  The question becomes how we validate such a system, that is how do we determine its truth or falsity?  I've always been partial to the utilitarian philosophy: the greatest good for the greatest number.  In Ethics: Twelve Lectures on the Philosophy of Morality, David Wiggins makes some very pointed criticisms of utilitarianism.  For instance, imagine a situation where everyone can live well and find happiness, but at a cost: one person is excluded and lives in an extended hell.  (hmmmm... this sounds strangely familiar.)  Despite the lone sucker's nasty predicament, this would seem to fit the definition.

Apparently U.S. states with the least difference between rich and poor, people are also better off in general and this points us towards a refinement to the utilitarian principle.  Imagine happiness lying along a distribution with the x-axis being happiness and the y-axis being number of people.  The narrower and further right this distribution lies, the better.  But most important, the further right the left-most non-zero point, the better.  In other words, we need to look at the happiness of the most unhappy person.

At the time I came up with the first part, my solution was much simpler.  I tried to create an ethical system comprised of only one statement that was its own validation system.  Namely: that which increases joy is good.  Joy I decided, was synonymous with good.

The problem here is ambivalence.  We are often drawn in two directions at once.  My first, concrete example, cigarette smoking, works but it's a bit weak.  So at the risk of revealing a bit too much about myself, I was fortunate enough to have had a girlfriend who gave me a much stronger example.  A large part of human laws and taboos revolve around sex and perhaps this example will illustrate why.  (Or as Foucault puts it in The History of Sexuality, human sexuality is a particularly dense set of power relations.)  It is interesting, and perhaps a bit ironic, that I first codified the above, rather simple idea of morality while staying at a hostel in Edinburgh after having first gotten together with this woman.  Fast forward to our break-up after about a year-and-a-half of on-again off-again bickering, I found myself staying at the apartment of and even sleeping in the same bed with this woman even as she was dating a new man.  At one point, as she was about to go on a date with this fellow she started getting frisky.  On the one hand, it's hard for me to imagine anything more arousing.  On the other, I really wanted to kill this guy with my bare hands.  I cannot imagine a deeper level of ambivalence.

So this, to me, needs to be the central aspect of ethics and morality: ambivalence.  Without ambivalence, if we are always certain of the rightness of our actions and their ultimate outcome, then there is no need for ethics.

On a more general level: I would very much like to do good in the world and to leave behind something better for future generations.  I am also ambitious: I would like to be successful and to achieve many great things.  Such achievement is often quite resource-intensive and can damage the environment.  This is the crisis facing our world today.  And it should be obvious to those of us with clearer heads that the elites have mortgaged the future of our grandchildren for wealth and success today.

As the above statement suggests, there is a tendency to preference desire and pleasures.  The concept of ambivalence suggests that all desires are equal: none is higher or lower.  I know I tend to rank them into more base, "animal" desires: food, sex, personal power and prestige, revenge; and higher, more "spiritual desires": searching for truth and knowledge, fighting for justice, helping others, enjoying nature.  Ranking our desires of course is one way of resolving ambivalence.

The cancer of the Earth

Two Fridays ago I was chatting with an older fellow--a hard luck case--who had worked in the oil fields as a youth. He said some things to me that I found upsetting, not because I disagreed with them, but because I've been thinking along the same lines for some time. He said that the planet is dying and the only way out is to find another planet to kill. Oil is the blood of the planet and we a cancer upon it. The only way that we can create is by first destroying. Well, I'm not sure about oil being the blood of the Earth. Certainly it goes against much of the current scientific paradigm. One could see how it might be: the centre of the Earth is very hot and it has an iron core. Is the Earth a living thing that gains power from burning the iron in its core and oil serves as a primer? Keep in mind that Mars has a heavily oxidized surface. Is it a now "dead" planet? Shortly after he said this to me it occurred to me that scientists still don't have a very good understanding of fire and it is actually a very distinct phase of matter. As living things, we actually have more in common with flame than we do with more inert forms of matter. And a large part of what separates us from other animals is our ability to harness fire: particularly in the internal combustion engine. This, of course, is the legend of Prometheus. This fellow worked on the oil fields: perhaps he saw things that others are not privy to. I know very little about the chemistry and geology of the Earth's surface. I suspect am certain that the scientific community knows a lot less than they let on. There was a Doctor Who episode in which a group of humans on a space ship discovered that their ship was actually a giant "space whale" and to keep it moving, it was being constantly tortured. Is this the state of our modern industrial society? In the Doctor Who episode the elites were simply ignorant of the facts. Our elite, of course, would have no issue with simply lying through their teeth to cover up the facts. But I digress. Perhaps he is right about finding other planets. This might be the only way out of our current predicament. But not for the reasons you might imagine. Assuming that we don't simply send people in suspended animation or send out a spore, building a space ship to travel to another planet (and by implication another star system) would require creating, in miniature, a self-sustaining ecosystem. If we could do this inside a space ship, surely we could apply the lessons learned to make society down here on Earth more self-sustaining? I am reminded of the movie W.A.L.L.Y. The movie doesn't really work except as reductio ad absurdum. In the movie, humans have polluted the Earth to such an extent that they move out into space. The problem is, they continue in their wasteful ways while on their ship. Of course, had they continued to generate garbage at the same rate (as it shows in the movie) there would soon be nothing left of their ship. If our wasteful ways are destructive down here on Earth, the same goes out in space, only far more so.

Tuesday, April 15, 2014

How to build a super-efficient motor-assisted bicycle

The moral philosophy is a weighty topic.  Sexual politics even more so.  So here is some lighter fair about how to build a better motor-assisted bicycle.  I have already written an article about how current products are rubbish and how they are hobbled by brain-dead regulations.

An under-powered vehicle needs a lot of gears to help it adapt to different terrain and driving conditions.  Modern bicycles with derailleur gears typically have a minimum of 16 gears while hub-gear bicycles will have seven (7) or more.  Transport trucks have 12 or more gears and vehicles designed for off-road use will usually have a special gear reducer that effectively doubles the number of gears.  Contrast this with personal automobiles, which in the past, could make do with as few as three and even now rarely have more than six (6).

A lot of motor conversion kits for bicycles have a very crude transmission set-up.  One older system involved simply dropping a rubber wheel onto the front tire, but newer chain drives often aren't much better: there is only one gear and the pedals are only useful to kick-start the engine.  On the one hand, transmission requirements for human versus gasoline power are very different because the former is high-torque, low RPM (revolutions per minute) and can produce generous torque at rest, while the latter is low-torque, high RPM and cannot produce any torque at rest.  On the other hand, to save weight, the transmission ought to be shared between the two.

This is the solution I'm currently working on.  First the engine.  I found this 2 hp gasoline engine, complete with magneto ignition:
The engine can drive the rear wheel through a standard bicycle derailleur gear by connecting to this Shimano front-freewheeling chainwheel from the 1980s:

Through a ratchet mechanism, the chainwheel is allowed to spin in a clockwise direction even when your feet aren't moving.  What's missing is how to connect the engine to the chainwheel but seems obvious from the photos: just chain it directly from the small sprocket mounted on the end of the engine crankshaft to the larger of the two chainrings.

There's at least three problems with this solution.  The first is that the engine achieves its horsepower peak at around 10000 rpm.  In top gear a human will have to pedal at roughly 100 rpm to travel at a speed of 50 km/h.  This implies a gear reduction of roughly 100:1!  It's not quite that bad since you don't have to be in top gear when the engine is pushing the bike at top speed.  There are multiple chainrings: potentially you could use just one very small one when the engine is engaged as long as there is still a reasonable spread.

With this in mind, notice that the chainwheels has been drilled out twice: first with a large spacing to accept this monster, 60 tooth chainring shown left and again with a smaller spacing to accept a standard 24-30 tooth "granny" ring shown at right.
The cog on the engine is 14 teeth so even using the largest rear sprocket (roughly 1:1 ratio), you get a final drive ratio of 60:14=4.29.  At maximum rpm the rear wheel will still be turning at over 2300 rpm which translates to a maximum speed of 297 km/h!

The second problem is that the engine actually spins counter-clockwise, which hints at a solution to the first problem: just have the speed reducer in one with the reverse gear.  Two gears with a tooth ratio of about 20:1 (a compound gear might be better for such a large ratio), 17:1 in combination with the giant 60 tooth ring or 14:1 with the little granny should do the trick.  If both are employed, the ratio could be as low as 10:1.

Such large ratios suggest the use of worm gears but this makes it impossible to kick or jump-start the engine with foot power or momentum and a starter motor adds unnecessary weight.  And third, we still haven't addressed the issue of engaging and disengaging the engine.  In the setup described above, the engine is always engaged making it impossible to use the pedals except for starting the engine or possibly assisting it.  This would only be acceptable for the earliest prototypes.

As a more mature, practical solution, I envision the motor being mounted beside the seat-tube with the crankshaft running perpendicular to the bottom-bracket (pedal-crank) axle rather than parallel.  Two bevel gears connect the two: a small one at the end of the crankshaft and a very large one on the outside of the chainwheel.  The engine is engaged and disengaged with a lever either by making the engine crankshaft extensible or through a pair of movable idler gears.

Another obvious essential feature of the final version will be a hand-operated clutch (foolishly illegal in the Ontario Traffic Act's definition of a moped).  Note that this will likely need to be separate from the engagement/disengagement mechanism as we don't want any extra gears or hardware connecting the pedals and creating drag while using only leg power.

If this project interests you, you can make a donation to the Peteysoft Foundation here.