Posts by mike_2000_17

The most usual storage is in RGBA (usually the default in many places) and sometimes you see BGRA (used in TGA image formats, and some Mac or Adobe formats). As for big-endian versus little-endian, it doesn't really matter when you are getting the data from a file. In a file format, the endianness is fixed by the file format standard, but of course, you have to read it correctly based on the endianness of the running platform. And usually, when you read the data off the file, you'll end up with either RGBA or BGRA, or some other format that you'll have to convert or deal with differently (e.g. palettes). I don't think that OpenGL supports ARGB, so you probably would have to manually convert that to RGBA if you have some weird image format that actually requires ARGB. You can also try the unofficial extension called GL_ARGB_EXT which you can place in the format argument of glTexImage2D functions, if your platform supports it, some do.

Also, you should use a fixed-length integer type for that argb field in the union. The type unsigned int is not guaranteed to be 32bit, and often won't be on most 64bit architectures. You should use the stdint.h header file (from C standard) and the unsigned integer type uint32_t.

As for the texture size (width height), you cannot do like you did with w * dx and h * dy. Think about it, how are textures stored in memory? Usually, they'll be stored as …

It's not very clear what you are looking for, but here are a few suggestions that might be in the ball-park of what you are looking for:

You can ask the compiler to produce an "assembly listing" (assembly listings are text-form assembly code, like the snippets that you posted) instead of the actual executable or along with it. For GCC, you can follow these instructions. For Visual C++, here are some instructions for that, or with the command-line options.

Otherwise, you can use a disassembler to take the executable and turn it back into assembly listings. This is a bit hardcore, and if you have the source code, you should get the compiler to generate the assembly listing instead of disassembling it.

The model-view matrix will always be applied to the vertices, so it makes no difference (speed-wise) whether the transformation is the identity matrix or whether it has any transformations accumulated in it (rotations and translations).

OpenGL is given a model-view matrix and a set of vertices, and it will apply the matrix to all the vertices to transform them to screen coordinates.

You could do this yourself, that is, you leave the model-view matrix to identity and then transform the set of vertices yourself before giving them to OpenGL. However, that will never be faster nor easier than letting OpenGL do it for you. Not only does it save you the coding (traversing the vertices and applying the transformation), but it is also much more efficient because the GPU is a processor that was designed to do this 4D matrix-vector multiplication very fast.

Of course, in the case of a particle system, you are rendering a small and simple thing (sprite) at many different places. You probably shouldn't change the model-view matrix for each particle in your particle system, because there is some overhead in changing the model-view matrix, and doing so for each particle might be too much. Because each particle is only translated, it might be just as easy to add the translation to the few vertices directly. But this just a special case, under most circumstances (when the ratio of vertices rendered per changes to the model-view matrix is a bit higher), you are better off using …

Look into pipes in *nix systems.

English please.

$ sudo mount -t ntfs -o defaults /dev/sda5 /mnt/my_drive

where /dev/sda5 must be replaced by your hard-drives name, and /mnt/my_drive must be replace by whichever folder you which to mount the hard-drive into.

divine proportion -> women

I'm an atheist, and have always been. My mother was born a catholic but was pushed away from it due to the horrible and discusting actions of the catholic church in the 50s, 60s and 70s, and once she left and stop being reinforced in the belief in God, the belief just disappears. My father was born into a very religious lutheran family, but he went on to study philosophy / sociology / psychology at the university level and soon realized that secular morality, ethics and humanism completely dwarf any moral "teachings" of the bible or any other ancient dogma, and once "religion as a source of morality" was clearly refuted (making God pretty much useless in human affairs) there was no point for him to stay in any such sectarian organisation. Personally, I've got the whole package: agnostic, atheist, and anti-theist.

Spinoza's God is not a literal one in any meaningful sense. In his philosophy of ethics, he used this term to appeal to a transcendental magnificence of the Universe. So, I guess that "believing in Spinoza's God" is really a question of whether one believes the universe to be transcendentally magnificent. From a philosophical stand-point it might be a comforting thought, but I don't see much purpose for this, even if it were true (no afterlife, no answering of prayers, no destiny for individuals (just for the cosmos), etc., it's not because there is somekind of order or plan to the universe that you are necessarily an important …

Definitely, store them by value in the list, i.e. as list<FileInfo>. One advantage of linked-lists is that it almost never has to copy elements of the list (when inserting / deleting). So, you won't get any real penalty for storing a fairly large object by value in the list, if fact, that's the intended use.

Your AddAfter function is somewhat problematic. In the case where k is beyond the length of the list, you print an error message and keep on going. There is one major problem with that. Because Student_ptr is NULL, whatever happens to execute afterwards will likely crash, either you get on to the next iteration and try to get the value of Student_ptr->next which will cause a crash, or you get to the code after the loop and get a crash then. So, one naive solution would be to simply return from the function at that point (inside the if-statement). However, this will cause a memory leak because you fail to add the new node to the list (because you have no valid place to put it) but you have already created that node (with new) and thus, will never be able to delete it. So, you could delete that new node before returning, but a much simpler solution is to just create the new node after the loop, since you don't need it before finishing the loop anyways. As so:

Student* AddAfter(const string& aName, double aGPA, int k) {
   Student* Student_ptr = head;
   for (int i = 0; i < k; i++) {
      Student_ptr = Student_ptr->next;
      if (Student_ptr == NULL) {
         cout << "\nThere are less than " << k << " students in the list." << endl;
         return NULL;
      }
   }
   Student* newStudent = new Student;
   newStudent->name = aName;
   newStudent->gpa = aGPA;
   newStudent->next = Student_ptr->next;
   Student_ptr->next = newStudent;
   return …

Using a forward-declaration. A forward-declaration is a way to declare a class or function before its full declaration or definition can be written. There are restrictions on how you can use the class or function before its actual declaration or definition appears. In case of a forward-declared class, because the compiler doesn't know what that class is, but only that the class exists (with the promise of a declaration to come), this means that you can only declare pointers or references to that class (i.e. no objects of that class) and you cannot address any of its members. Here is a typical FooBar example:

class Foo; // forward-declaration.

class Bar {
  public:
    void do_something(const Foo& f) const; // use the forward-declared class Foo, but only as a reference.
};

// now, provide the actual declaration of Foo:
class Foo {
  public:
    void do_something(const Bar& b) const;
};

//now that Foo is declared, you can define the member function of Bar:
void Bar::do_something(const Foo& f) const {
  f.do_something(*this); // call the member function of Foo.
};

Typically, you can use this trick for so-called circular dependencies, like in the above where the definition of Bar depends on the definition of Foo and vice versa. Usually, you put the forward-declaration and declaration of Bar in the header file for Bar (e.g. Bar.h), then you put the declaration of Foo in its own header file (e.g. Foo.h), and finally put the definition of the members of Bar in the source file for …

You load the model, which usually includes values for the vertex coordinates, the normal vectors, the texture coordinates, and the color values, associate to each vertex. Then, you load the texture corresponding to the model, and you apply both. You never hard-code anything, you write code to load everything from files and apply them (usually with vertex-buffer functions).

This means you have to create a second array of the same size as the one to be sorted, and pass that second array as the "temp" parameter to the merge sort function.

here

You open the terminal window and issue this command:

$ sudo apt-get install flashrom upx

That's all.

First of all, to add anything to the iso, you of course have to be able to open it and edit it. I assume you know how to do that. One other option is to create a bootable USB stick from the ISO, and then add your stuff to that USB stick, and use it for your install(s).

If you inspect the content of the CD, you will see a few folders. Most of the things in there are scripts which are not very difficult to more or less understand. Here are a few main ones:

• /boot/grub/loopback.cfg: which contains the grub configuration file (the menu items in grub).
• /preseed/ubuntu.seed: which is a simple script that launches the installer.
• /dists/jaunty/main/binary-i386: which contains a gz-compressed file which lists all the packages to be installed by the installer. The package list point to a .deb file on the CD for each package.
• /pool/main: is a folder that contains sub-folders with all the .deb files which appear in the package list.

So, if you want to add more package to the installer, I would presume that all you need to do is download all the required .deb packages from launchpad.com, then put them in the /pool/main folder, and finally add them to the list of packages (presumably the /dists/jaunty/main/binary-i386/Packages.gz file).

Another alternative is to simply create a script that you would manually run once you are done with the installation:

#!/bin/bash
sudo apt-get install flashrom upx dmidecode

That's not too hard is …

1.When we do transformations (translate, rotate, scale), we only move the whole scene, but the camera always stays in the same place, right?

In the real world, when you walk around, how do you know that you are moving? Couldn't it be that the entire world is moving around you?

This may sound like a philosophical question but it is true. A moving camera is indistinguishable from a moving world (moving in reverse). Usually, renderers for computer games will separate the camera transformations from the world coordinate transformations, but this is merely a conceptual distinction, at the end, they are the same. Often people will accumulate some transformations in a camera object, that is, a transformation from world coordinates to camera coordinates. Then, they will accumulate transformations for each visible object, from world coordinates to local object coordinates (in which the 3D model vertices are expressed). Finally, when it gets to rendering all the scene, they will first apply the inverse of the camera transformation (i.e. transforming the world coordinates in reverse of how the camera is "moved") and then apply the per-object transformations before rendering them.

2.In the tutorial that we were talking about, i tilted the scene, did everything i needed, reverted everything back and yet when i run the program i increase or decrease Tilt and it looks like we are moving around even though its rotation should be 0. I get why translation remains in effect, but not rotation.

Only the transformations …

procedural -> recursive

@AD: The docx format is not really a binary format, it is just a zipped xml file. You can decompress it with a standard zip library and then read / write it with any decent xml library, plenty of those are available in C/C++.

Assembly, C and C++ are by far the most prevalent in that matter. I don't think there is any OS that is written with any other language. By far, it is dominated by C. Some lower-level details might be done in Assembly, and some higher-level parts might be done in C++, by the bulk is usually in C.

As for what is possible, then you first need a programming language that is compiled into native code (that rules out any interpreted or JIT-compiled language), then you need a programming language with no required runtime environment (that rules out many higher-level languages like Java or C#), and you need a programming language that allows you to manipulate low-level things like registers, hardware interrupts, and of course, physical addresses. And you probably want a language that is widely supported for different hardware architectures, and you probably want the code that is produced to be reliable (reliable compilers) and fast. Conclusion: use C, and possibly some C++ (or even a lot of C++). There aren't that many other programming languages who fit the bill, and that aren't antiquated languages. If you look at all working operating systems today, they are all programmed with a core in C (with some assembly) and some higher-level stuff in C++ or Objective-C (Mac). There might be some hobby operating systems whose core is in C++ or something else (like Ada).

I have never programmed an OS, but I have programmed on platforms without an operating system (e.g. …

Does anyone like to use Linux over the Microsoft XP or System 7/8.

Everyone that I know who has ever tried to use Linux for any substantial amount of time (usually compelled to do so because of job, or just out of curiosity) and who is the least bit competent with computers (e.g. not mortally scared of a terminal window), they have all expressed strong preferrence for Linux (and I've never heard of someone familiar with Linux who preferred Windows). I'm no exception. One of the reasons for me is just the sheer difference I feel when I boot into Windows after having spent some time using Linux, I feel the weight of the Windows system crushing me:

• it takes forever to boot up, and everything I do seems to take forever.
• it constantly nags you for updates which are always tedious to install (next, next, I agree, next, next,... restart now!) (as opposed to almost always automatic and most of time reboot-free, under Linux).
• the lack of integration (and inter-operability) of software packages makes it so that every time you have a little task to do, like converting video formats or reading a particular type of file, you have to either dig in dark corners of the internet for freeware tools for that particular job, or pull out your wallet for some big professional software that you don't really need. Either way, you end up with a system that is bloated with a huge amount of …

The Translation will come first and the Rotation second, in reverse order.

All this confusion about things being applied in reverse order or not, is just a matter of perspective. People interpret coordinate transformations differently, one way leads to the conclusion that things are applied in reverse order, the other leads to the conclusion that things are applied in the order they appear. In some sense, both interpretations are correct, but from a different point of view. Most of confusion stems from the fact that people don't know that their interpretation is relative to their point of view, and thus, not universally correct.

Point of view #1: "Transformations are applied in reverse order than they appear."

This interpretation comes from the point of view of starting with a set of vertices (or a polygon, or a mesh) drawn (e.g. with glBegin/glEnd). If one looks at the transformations that this polygon will go through before it gets to be drawn on the screen, then one will have to proceed in reverse order of the transformations. For instance, with the transformations you posted, you take the polygon, tilt and rotate it by a reverse angle, then move it some distance along the x-axis, then rotate it back to the original orientation, and finally move it back some (by "zoom") such that it appears at a reasonable distance. Obviously, this makes sense, the reverse order of transformations makes sense.

Point of view #2: "Transformation are applied in the order that they …

In a for-loop, you must have two semi-colon (not one, not three, two!). The first slot is for initializing statements, the second slot is for a condition (logic expression), and the last slot is for a per-iteration operation (executed at the end of an iteration, before evaluating the condition).

The first and last slot can contain multiple expressions or declarations, but you separate them with a comma. In other words, you can have a for-loop like this for example:

int i, j;
for( i = 0, j = 1 ; j < N ; ++i, ++j ) {
  /* .. */
};

The problem with declaring multiple variables in the initializing statement is that C/C++ allows this type of syntax in normal code:

int i, j;  // notice the comma separation.

Whenever a type appears first, the compiler interprets this as a variable declaration (possibly also a function declaration), and then, if a comma appears after one variable declaration, then the compiler assumes the next thing will be another variable declaration of the same type. This means that you can write this:

for(int i = 0, j = 1; j < N; ++i, ++j) {
  /* .. */
};

But not this:

for(int i = 0, double f = 1.0; i < N; ++i) { /* */ };

because the compile will reject the second declaration just like it would if it appeared elsewhere like this:

int i, double f;  // ERROR

So, the basic …

Basically, the star-loop contains values of an angle and a distance. In other words, these are polar coordinates for the object. So, the purpose of this sequence of one rotation and one translation has the effect of rotating such that the x-axis is pointing on a particular direction (given by the angle), and then the object is moved along that x-axis by a certain distance. Once you have done that motion, if you want to restore the original orientation of the axes, you have to undo the rotations (in reverse order that they were applied). So, the whole purpose of the rotations, translation, and inverse rotations is just to realign the axis is some direction and then move in that direction and finally restoring the axis alignment (but the translation remains in effect). Basically, this allows you not to have to compute the resulting translation yourself (i.e. the translation resulting from a displacement in a particular direction). That's all it does.

Put simply, this code just computes a translation given by the distance and angle about the center of a tilted plane.

Try to render a cube right after the last glTranslate() call above. Then, move that cube rendering to after the last rotation. And see the difference it makes.

Rendering Bezier patches or NURBS surfaces isn't hard at all in OpenGL, not any harder than rendering a vertex buffer (the procedure is similar, you hand over the points to OpenGL and you call a render function on it). I suggest you look into it.

I think the guy in the tutorial made a mistake. What he is describing does not correspond to a rotation about the x axis. It seems to correspond to a rotation about the y axis (vertical).

If you apply a rotation of -90 degrees about the y axis, you will get, as described, where the x axis is pointing out of the screen and the z axis is pointing towards the left of the screen. And, of course, you have to understand a very important concept, that is, the rotations of world are the inverse of the rotation of the camera, meaning that when you apply a -90 degree rotation (of the world), it appears as if the camera rotated by +90 degrees. This is simply a consequence of rotating the entire world in one direction has the same visible effect as rotating the camera in the opposite direction (usually, in 3D engines, the camera transformations are applied in reverse for that reason).

3D rotation transformations are very special and often counter-intuitive. It is very important to understand it well because it might cause you a lot of problems going further. Take the time to understand the math and play around with rotations and sequences of rotations (in various order) to make sure you know how it works. Seriously, I know graduate students who stumbled on problems involving 3D rotations and had disastrous results because they didn't take that topic seriously.

P.S why do even need to shift everything …

Line 38 should be outside of the while loop, as so:

        while (Student_ptr->next) {
            Student_ptr = Student_ptr->next;
        }
        Student_ptr->next = newStudent;

In other words, the loop iterates to the end of the linked-list and appends the new student at the end of the list. This error was the reason why the nodes were never added to the list.

And your display loop should have this condition instead:

while (Display_ptr) {

Otherwise, it will not display the last element.

What should the constructor of a linked list look like?

Let me just put your code into a simple class to illustrate how this is done. Notice that the code is essentially your code (with the above fixes):

#include "../../std_lib_facilities.h"

class Student {
public:

   string name;
   double gpa;
   Student *next;
};


// Here is a simple class for the linked-list:
class StudentList {
  private:
    Student* head; 

  public:
    // constructor: (same as initialization code at the start of your main function)
    StudentList() {
      head = NULL;   // start with an empty list.
    };

    // function to add a node (same as within your for-loop)
    Student* AppendNewStudent(const string& aName, double aGPA) {

      Student* newStudent = new Student;
      newStudent->name = aName;
      newStudent->gpa = aGPA;
      newStudent->next = NULL;

      if (!head) {
        head = newStudent;
      } else {
        Student* Student_ptr = head;
        while (Student_ptr->next) {
          Student_ptr = Student_ptr->next;
        }
        Student_ptr->next = newStudent;
      }

      return newStudent;
    };

    // function to display the entire list (same as the last part of your main function) …

I think that line 130 should be:

for (int j=n-1;j>=pass;j--)   // notice 'n-1' instead of 'n-j'.

We're not going to do your homework for you. You need to show some efforts of your own towards solving this problem.

Btw, the function you need for sorting an array is std::sort. And your multiple sorting criteria is called a lexicographic ordering (e.g. alphabetical ordering is a kind of lexicographic ordering).

A lot of things are wrong with your code.

First of all, you have things that are just useless, like these types of things:

                    if(min->NEXT != NULL)
                        i->NEXT = min->NEXT;
                    else
                        i->NEXT = NULL;

Tell me how that is different from this:

                    i->NEXT = min->NEXT;

??? (rhetorical)

Second, your code to do the swapping is not correct, it is a weird and incomplete mix of extraction and insertion with something else. I get the strong feeling you just copied code that does an extraction-and-insertion into that loop as if it does the same as swapping, without putting any more thoughts of your own into it. I know, you PMed me about insertion-sort, and I gave you an illustrative example of code to do extraction and insertion, and you copied it into your selection-sort algorithm. I'm trying to detect the presence of an intelligent life-form behind your user account, one who can understand the difference between illustrating an idea and writing real code, between insertion and swapping, one who can think for himself and develop an understanding of the problem and construct a path to a solution. Histrungalot is showing you how to solve a problem, by outputting the intermediate steps and figuring out what is happening versus what should happen (from the theoretical algorithm).

Start by going step by step, with pen and paper, through your algorithm, with the aid of the print-out that histrungalot has posted and figure out exactly what is happening. I ask …

Below is the one example that I can half way understand well enough to even start asking questions about linked lists.

If that is the best example code you could find on linked-lists, then you're either very unlucky in your research, or half-blind. This code is crap.

Why is "struct" being used instead of "class" to introduce the linked list nodes? Is it a preference for not having to declare the lines public if "class" is used?

You're right. The use of struct here is just to avoid writing class Node { public: /* .. */ };.

I understand that "num" is the data value held in the node and that "link" is the pointer to the next node. What is "p"? The author explained that "link" points to "p" and that "p" points to the next node. I don't follow that logic. What is the need to create a pointer that is outside the list node?

"p" is a global variable which is a pointer to a node. Don't try to understand the reason for that variable to exist, there is none, besides the inadequacy of the programmer who wrote the code.

I do NOT follow how setting the value of "link" equal to "pP and having "root" point to "link" and then having "p" take on the value of "root" accomplishes that. It seems to me that "root" ends up pointing back at itself.

That's normal, this makes no sense.

First of all, there is no point in using the volatile keyword on a variable that is not shared between more than one thread. The whole idea of a volatile variable is to tell the compiler that this variable could change value at anytime, in parallel to the thread of execution (e.g. by another thread or process). If that is never going to happen (e.g. the variable is local to the thread or its stack-frame), then there is absolutely no point in using that keyword, it would be a pessimization (contrary to optimization). And stand assured, it will make absolutely no difference behavior-wise (e.g. on the results) except for the longer execution time.

So, the effect of the volatile keyword is that if you have, in a function, two lines that invoke the given variable (e.g. read its value), the compiler is not allowed to assume that both invocations of the variable will result in the same value being read (which would normally always be the case if, in that function, nothing modifies the value, and if there is no other thread or process that could modify the value).

So, assume you have a global variable (or something similar) which could be accessed and modified by multiple threads concurrently. In this case, it would make sense to have it declared volatile. However, the story doesn't end there. For it to make sense to use volatile, you also need the variable to have atomic operations. This means that any read / …

You should probably start by reading the instructions: "use a class with 3 member functions named InputMatrix, Calculate, and OutMatrix. ... no global variables allowed."

You have some problems with your code, but they will be solved if you follow those highlighted instructions. This tutorial might help you.

If you want to improve performance, you need to implement this as a ring buffer.

Also, your indentation scheme looks a little weird.

And, obviously, you shouldn't use global variables. Learn to create classes and use objects.

Finally, you include a header std_lib_facilities.hpp, I assume this header includes a number of standard C++ libraries and issues a using namespace std;. Both of these things are pretty bad. You should only include headers that you need, not all headers you could possibly need. Learn to use a minimal number of headers. And issuing a using namespace std; in the global scope is not recommended, learn to avoid doing that.

I would try with negative Z values. Without rotations applied, the Z-axis points towards you (from the screen and out), with the zero being at the screen. This means that anything you draw in the positive-Z area is not going to appear on the screen (it is "behind" the camera). So, first thing, try making the Z coordinates in the negative.

Also, as sfuo said, very often when you try to draw stuff and nothing appears, it is usually because you set the perspective or model-view transformations wrong. Make sure that part is correct.

partner -> ship

Your random generation function is wrong. First, you should not seed the random number generator every time you query for a number. You should only seed it once at the start of the main() function.

Also, your range computation in it is also wrong. You had this:

double ranDec(int start, int end, bool floater) {//by defult will return value between 0 and 1000
    srand (time(NULL)+rand());//creates random seed based off current time
    double num;
    if(!end) {//end=0 and or start=0
        num = rand()+start;
    } else {//no 0's passed or start=0
        num = (rand() % end + start);
    }
    if(floater) {
        num = num + (rand()/(static_cast<double>(RAND_MAX) + 1.0));
    }
    return num;
}

But you should have this:

double ranDec(int start, int end, bool floater) {//by defult will return value between 0 and 1000
    double num;
    if(end == start) { 
        num = rand() % 1000 + start;   // default of 1000 in range.
    } else {
        num = (rand() % (end - start) + start);  // this is correct.
    }
    if(floater) {  // ??? what is this?
        num = num + (rand()/(static_cast<double>(RAND_MAX) + 1.0));
    }
    return num;
}

Also, in your robot constructor, you should call the random numbers as so:

        this->x = (int)ranDec(1,screenX-2,false);  // this will always generate an in-bound value.
        this->y = (int)ranDec(1,screenY-2,false);

Other than that, I don't know what the crash is about, maybe you should investigate further (print out values of the variables around the point of crash) and identify the exact point of the crash. …

Declaring the variable as volatile might help.

My professor asked me to search why this is happening

"searching" and "asking" is not the same thing. If he wants you to investigate the matter, then you should investigate the matter, not just ask someone else for the answer.

Let me elaborate:

1. Boot with a live or rescue CD/DVD/USB drive.
   I think this is pretty straight forward, you find Live-CD from any distribution of Linux (or install CD), and when you boot from it, you don't go through installation (if available) but instead boot from the CD.

2. Login as root.
   All LiveCDs will allow you to login as "root" (and refer to their website for the password, probably something like "root" or blank).

3. Edit the drive partition table with the fdisk command (fdisk /dev/sda) and create a new linux partition.
   Once logged in, you open a terminal window (menu: System Tools -> Terminal). Then, you can run the command fdisk -l which will list the available hard-drives and partitions on the computer. Usually, the internal hard-drive will be called /dev/sda (and sdb, sdc, etc.). For each physical hard-drive, its partitions will be listed as /dev/sda1, /dev/sda2, etc. Now that you have this information, you can locate your harddrive and the partitions you wish to work with (delete, create, etc.). Note that information down (or copy-paste) for later reference. Then, you can launch fdisk /dev/sda to edit to partitions of the hard-drive /dev/sda (or whatever you identified as the correct hard-drive to edit). Then, you follow the on-screen instructions and possibly internet tutorials on using fdisk.

4. Create a file system on that partition, such as ext3 or ext4, and give it a label such as "newdata-1".
   This is also part of the things you would do …

If you can't get to grub, then you can't boot in terminal or start a terminal because the operating system has not started yet. The bootloader is the small program that executes in order to start the operating system. If that program cannot start the operating system, then there is no terminal to access.

So, if you can't make it up to the grub menu, then there is nothing you can do. Your copy of the CD or USB device must not have been setup correctly, or your computer couldn't boot it for some reason, etc.

If you can make it to the grub menu but attempting to boot the operating system fails, then you have two choices.

Most of the time (depending on your distro), there is a "recovery" or "terminal mode" or "fail safe mode" for booting the operating system. Most of the time, that boot mode will be a terminal-only boot of the operating system (i.e. it won't start the desktop manager and X server, and all that, only a basic terminal windows will appear). If that cannot boot, and it is a liveCD, I would consider changing to another Linux distribution, because not being able to boot even in recovery mode is really bad, it probably means the distro / kernel is deeply incompatible with your computer (which would be very surprising).

The other choice is to launch the Grub command-line environment. This is an expert-level thing that you probably don't really want to delve into, …

Yes, in a few different ways.

First, if C derives from B, then it is also derived from A, through the fact that B is derived from A. In other words, derived classes inherit from their base class(es) and all their base class(es).

Second, C++ also permits multiple inheritance, meaning that a class can derive from multiple base classes. They are declared as class C : public A, public B { /* .. */ };. However, this can creates some awkward situations in the case for example that B derives from A, then it means that C inherits twice from the base class A. In fact, C will indeed inherit twice from A (in formal jargon, we say that C has two inherited sub-objects of class A).

Finally, to use multiple inheritance while not getting duplicated base classes, you have to use virtual inheritance. That is, if you declare class B : public virtual A { }; and then do class C : public virtual A, public B { };, then the result is that C will inherit only one base-class A (i.e. as opposed to two in the previous method).

Read more about it here.

If there are any scandinavians around, you'll like this medieval tech support (also with english sub-titles):
http://www.youtube.com/watch?v=CQOf20Xrd1o

And here's a joke:
A pastor takes a stroll in the public market on a sunday afternoon. He sees a boy standing next to a wooden box, so he walks up, and sees a bunch of puppies in the box, so, he says "what a cute bunch of puppies you have there". The boy replies "Yeah, they're christian puppies.". "Huu, how nice.." replies the pastor, and continues on his way.
The next sunday, the pastor is in the market again, now with his wife. He sees the same boy with the box, so he says "come honey, I want you to meet this delightful young man". They walk up, pet the puppies, and the wife says "what a cute bunch of puppies you have there". The boy replies "Yeah, they're atheist puppies.". "What!" cries the pastor, "they were christian puppies last week!". The boy says "Yeah, but now they're old enough to open their eyes".

structure -> tree

For the actual theory, this SO thread is a good starting point. Convolutions are never actually calculated like it appears in theoretical equations. As the SO thread says, you either perform the multiplication in Fourier space (instead of a convolution in the original space), or you separate the filter in each dimension and traverse each linearly.

As for further improving performance, you should also start to grasp the concept of "locality of reference". It's often more important than the theoretical complexity of an algorithm.

Well the link is describing the book. You can find it in an online bookstore, in a real-world bookstore, probably in any science library near you (e.g. college), or perhaps in a regular city library. Don't tell me that after knowing the title of the book, the authors' names, and everything else about it (like ISBN), you cannot manage to find a way to get it either on loan or purchase. I don't know where you live or what you're means are, how am I supposed to help you "find" the book?

You should use exactly the inner loop that I posted before, yours is incorrect.

About this: "in which case it has to predecessor to update", it was a typo, I meant to write "in which case it has NO predecessor to update". I think that makes more sense, doesn't it?

Your outer loop should probably start in a fashion like this:

node* before_i = NULL;
for(node* i = HEAD; i->NEXT != NULL; i = i->NEXT) {

  //.. the code..

  //.. at the end of the iteration:
  before_i = i;
};

This will make sure that you keep track of the node that comes before i.

Then, the swapping (after the inner-loop), should have this kind of structure of if-statements:

if( before_min != NULL ) {   // if a swap is required.

  if( i == before_min ) {   // if i comes just before the min node.

    if( i == HEAD ) {    // if i is at the head, it has no predecessor, but HEAD needs to be updated.

      // put min at the head, and order the next pointers such that min --> i --> (min->NEXT)

    } else {             // otherwise, there is at least one node before i (i.e. before_i != NULL).

      // swap the nodes as you did before in the bubble-sort algorithm (swap nodes i and min, with before_i being their predecessor).

    };
  } else {                  // otherwise, i and min are separated by at least one node.

    if( i == HEAD ) {    // …

First part is simple, my name is mike. The second part is an enigma for you guys. 2000 taken to the power 17 is about the total mass of the observable universe measured in grams. No, actually 2000 bitshifted 17 times writes FA00000 in hex which is cool. I'm kidding, seriously, 2000 and 17 is the longitude and lattitude of this private island that I own. Muhuahaha, you'll never figure out what it means!

Also python (the animal) is spelled pyton in Finnish.

Yeah, when a finnish colleague of mine proposed to use "pyton" for a project we had, said in the finnish pronounciation, it took me a while to realize he was talking about Python. Minä rakastan Suomi, mutta se on mahdotonta oppia suomea!

Forgive AD, he's getting a bit senile ;)

From your last thread, you do know how to swap two nodes that are next to each other, right? Well, you should, because I told you how.

The problem with swapping two adjacent nodes is that you also needed to keep track of the node before that pair of nodes such that you could update its NEXT pointer. Here, you have the same problem, but twice. If you want to swap two nodes that are possibly far from each other in the list, you need to keep track of the nodes that preceed both nodes that you are about to swap. In other words, you would need node* before_i; and node* before_min;.

To keep track of those nodes is not hard, this would do the trick for before_min:

node* min = i;
node* before_min = NULL;
for(node* j = i; j->NEXT != NULL; j = j->NEXT) {
  if( j->NEXT->DATA < min->DATA ) {
    before_min = j;
    min = j->NEXT;
  };
};

and you can do something similar for the outer loop.

After the inner-loop, if before_min is still NULL, then you don't have to swap anything.

Then, for the actual swap, you have to check if i is the HEAD node in which case it has to predecessor to update, but the value of HEAD has to be changed to the new node that will become the head. If i is not the head and i != min, then you swap …

If you have "learned" all those basic stuff that you listed, then it might be a good time to go through the FAQ Lite by Marshall Cline to fill in any holes that might remain (the devil is in the details) and to learn a number of basic coding guidelines.

As for books following that, Scott Meyers is surely a good source, although somewhat outdated. "Accelerated C++" by Barbara Moo and Andrew Koenig (who sporadically shows up on this forum) is also a fan-favorite with its less pedantic but more practical approach. From looking just at the table of contents, the new edition of "Professional C++" by Gregoire, Solter and Kleper, seems very nice, and would probably suite you very well if you are already quite familiar with the more basic syntax elements. Usually you can tell which C++ programming books are good and which are crap just by looking at the table of contents, if it doesn't start to delve into the STL containers and algorithms by the middle of the book at the latest, if it doesn't dedicate a good amount of pages to exceptions, and if it doesn't ever get to at least some basic introduction to templates, then it is crap, not really a book about C++.

Once past one or two of those books, the next set of books to aim for is the "C++ In-depth Series". The "C++ Coding Standards" by Herb Sutter and …

up -> and atom!