Posts by Rashakil Fol

freemind, ever heard of RSA public key cryptography?

These are simple. Now code multiply to work in O(n log n) time instead of O(n*n) time. Come back when ready ;-)

I have an idea. Try testing the functions.

Yah, it's time to get used to the idea that the natural log is called both "ln" and "log", and that the common logarithm is called "log" and "log10". For extra fun, find a teacher that writes "ln" while speaking "log"!

Bah namespaces. Use std::log instead of log.

Try x/(150*log((double)(pl/1.5))); since log takes a double as its argument.

Surely you meant

x/(150*log(pl/1.5));

I removed the multiplication sign after 'log' (which made it treated like a variable instead of a function name).

Also, as you wrote it, log(pl/1.5) would have been on the top of the fraction, so I added parentheses to put it on the bottom. (Which by your original post's ASCII art I assumed you wanted.)

#include <cmath>

Use the 'log' function (which computes the natural logarithm).

Generally speaking, the more you learn about and think about algorithms (of any kind), the better programmer/problem solver you become. Sorting algorithms are one prevalent example, but in general, it's always a good idea to learn how things work. That way you'll end up thinking, "I need this done, and I can write function X to do it," instead of, "Where can I find function X to do this for me?" (Not that code reuse is bad, just that if I ever see another PHP coder (just to stereotype) ask, "How do I find if a given string is in an array?" I'm going to have to reconsider suicide for the 3rd time.)

To find a duplicate in the array, you have a few options.

One way is, make a for loop, looping the variable I from 0 to N. Then, inside that, make a loop that moves the variable J from I + 1 to N. Inside that, see if the I'th and J'th elements of the array are equal.

With Python questions, you definitely need to use CODE tags.

somthing like this:

#include <iostream>

int main ()
{
    char c[6] = "45678";
    int num[5];
    for (int i = 0; i < 5; i++)
    {
        char temp = c[i];
        num[i] = atoi(&temp);
        std::cout << num[i] << std::endl;
    }
    system("pause");
}

This code is downright dangerous. Suppose I add one line that seems not to affect the outcome:

#include <iostream>

int main ()
{
    char c[6] = "45678";
    int num[5];
    for (int i = 0; i < 5; i++)
    {
        char temp = c[i];
        char khan = '9';
        num[i] = atoi(&temp);
        std::cout << num[i] << std::endl;
    }
}

On my system, I get 49 59 69 79 89 with this code. Why?

This happens because temp is just a single character. You don't know what goes after it. When you pass a pointer of temp to atoi, atoi will expect a pointer to an _array_ of characters. It will read numbers until it gets a nondigit -- a character that is not in the range '0' .. '9'.

When you ran your code, you got lucky. The position in memory next to wherever temp was stored did not have an ASCII digit.

With my code example, you might get different output, since the result is affected by where your compiler puts everything.

Since khan may get stored right next to temp in memory, atoi might think it's the next character in the string, and so it reads 49, 59, and so on.

If you want …

I never see you assign to the your node structure's next pointer. Thus, you are using uninitialized pointers. That's your problem.

On the contrary, you do have problems with the structure of your program. Is it immediately obvious how your program flows? Not to the people who didn't code it. That means there's a problem.

Your main problem is program design. If you designed the structure of your programs better (using subroutines, no gotos), your problems with pointers (and everything else) would diminish. The main reason that you can't maintain this program is that you have designed it for unmaintainability.

The average is 76.4666.

desidude, since your sum and count are modified after the while loop, only the last value of your numbers gets added to sum, and count gets incremented once, from zero to one. And 77 is your last value.

To swap Perl scalars without writing a third variable:

($x, $y) = ($y, $x);

If you want to swap Perl arrays, well, you'd be better off having used array references and swapping those like above.

I guess the real question is speed - whether iterators or array [] type access is faster..

Dereferencing an iterator is faster because a uses one addition operation. But comparing two iterators is slower than checking if an integer is zero. If compiled dumbly, the iterator solution should be slightly faster, but it would not be a very measurable difference.

With compiler optimizations in play, the end result is up for grabs. Trying to solve this problem as efficiently as possible is rarely worth the programmer's time -- there are some more tricks that you could pull, but most comparisons will have unequal lengths or will be decided unequal very early in the loop -- only the equal strings run all the way through.

Here's a version that uses STL iterators. Reverse iterators make the while loop rather elegant. You can also decrement to backup on a regular iterator, but this version uses a reverse iterator instead.

bool are_mirrored(const string &name, const string &name2)
{

	if (name.size() != name2.size()) {
		return false;
	}

	string::const_iterator p = name.begin();
	string::const_reverse_iterator r = name2.rbegin();

	string::const_iterator e = name.end();

	while (p != e) {
		if (*p++ != *r++) {
			return false;
		}
	}

	return true;
}

Because r is a reverse_iterator, it starts at the last character and faces in the opposite direction. It perceives the string backwards.

>Also, size is four characters while length is six.
I find that hard to believe, since length() returns size(). Perhaps you're thinking of capacity(), in which case your suggestion is incorrect because the result of capacity() is largely implementation-dependent.

Four characters as in s-i-z-e. It's easier to code with shorter names.

Here's an ever so minor nitpick.
Now it's nothing much when strings are short, but if such a function were used on something bigger and/or in a large loop, there is quite a bit of waste there. Let's say name is 1000 chars long: let's loop through 1000 chars to the end to find the length. Then later let's loop through 1000 chars to the end again to again find the length. A minor change would be to save the value and only calculate it once.

This inefficiency is not actually the case. The standard library string class usually stores three pointers: One to the beginning of the string's array of characters, one to the end of the string's array, and one to the end of the string. (The string might not use all of its allocated space.) Some implementations might store one pointer and two size_t integers -- but either way, the size() function is guaranteed to be a constant-time operation.

The standard library's size() member function could look something similar to this (never mind that it really gets implemented in the basic_string class):

string::size_type string::size() const
{
    return end_ - beg_;
}

And that would get inlined by a compiler -- making it one extra subtraction operation instead of one thousand-something operations. Only the C library's strlen function has to loop through the string, because C-style strings are simply pointers to arrays of characters that have a zero somewhere at the end.

And note …

Can you tell me why you prefer to use .size instead of .length?

All or almost all other standard library containers use size() exclusively. length() was left in the string class for backwards compatibility with something, according to my current unknowledgeable theory. Also, size is four characters while length is six.

Don't completly understand why you prefer to use this, but, I'll google to see what string::size_type just is :?:

Usually I'll just use size_t (which is an integer type large enough to contain the length of any old array). Using string::size_type just makes for more portable code (but this would have to be some bizarre, Star Trek-like pseudocomputer.) You don't have to use it, and size_t will always work. (The only situation where I imagine using string::size_type could ever actually matter is one where strings are for some reason stored in a different memory space than other objects.)

int is generally fine, too, on 32-bit systems, as long as strings are smaller than 2 million-something characters long.

string::size_type i = name.size()-1;

Has to be -1, otherwise your comparing '\n' ;)

There's no '\n' character in the string. i starts after the end of the string because --i returns the decremented value of i, meaning that the first comparison uses the last character and first character of the respective strings. (Whereas i-- would return the original value of i.)

Unless there's a bug. I have not compiled and run.

if (name[i] != 0 name[j])

Is this right?

I might write it like this:

#include <iostream>
#include <string>

using namespace std;

bool are_mirrored(const string &name, const string &name2);

int main()
{
	string name = "Johan", name2 = "nahoJ";

	bool c = are_mirrored(name, name2);

	if (c) {
		cout << "True!" << endl;
	} else {
		cout << "False!" << endl;
	}

	cout << "Press any key to continue!\n";
	cin.get();

	return 0;
}

bool are_mirrored(const string &name, const string &name2)
{

	if (name.size() != name2.size()) {
		return false;
	}

	string::size_type i = name.size();
	string::size_type j = 0;

	while (i) {
		if (name[--i] != name2[j++]) {
			return false;
		}
	}

	return true;
}

Generally, readability improves when every control structure uses braces and when operators have spaces on them. Also, string::size_type is an integer type that is guaranteed to be larger than any stored string. (It's just an unsigned long int on most systems, though: nothing terribly exciting.)

Also, it's a good idea to only use for loops of the form

for (int i = m; i < n; ++i)

or of the form

for (int i = n; i > m; --i)

Or maybe even:

for (string::iterator i = s.begin(); i != s.end(); ++i)

When you are not looping a single variable through a range of numbers, I consider it better form to use a while loop. You might find this to be the case also.