Posts by Adak

If you know that all global variables, with no storage class mentioned, are

1) kept until the end of the program.

and

2) available to your program in any function, without using a parameter.

and

3) may be overshadowed or covered, by a local variable with the same name, in that function.

What else is there that you need to know, exactly?

Yes I did, thanks AD.

size_t j = pon - string1[0];

is the index to the first char of string2, within string1.

You need to add curly braces { } whenever you have an expression with multiple lines of sub expressions, or it won't work as you want it to.

if(some test is true {
   first code expression;
   second code expression;
}

Without the braces being in the above, ONLY the first code expression would be conditional to the if statement being true. The second code expression, if the braces were NOT there, would ALWAYS be executed by the program.

Note that the indentation does NOT change the syntax required. It's just to help us humans, not the compiler. In Python, the indentation affects how it's compiled, but not in C.

Still, good indentation is VERY helpful - you should work on yours. Dependent expressions are indented 2 to 4 spaces to the right.

The indentation makes it so much easier to find our errors and fix them fast.

If you want your calculations to be accurate at all, you need to use doubles or floats.

Integer division is especially (spectacularly) diabolical.

And "millage"? Really?

You need to remove the newline char that fgets() always adds to the end of the string it receives.

Nice actually looks like this, when it's the last word in the string: "nice\n\0". And what you are searching for is "nice\0".

So a bit of code for inside the for loop, before the strstr call (say line 23 above).

int len=strlen(string3)-1;
if(string3[len]=='\n')
   string3[len]='\0'; //overwriting the newline char

And try it now!

Note that a string with "nice nice nice" will show only one "nice", because you are only testing the string3 string one time - not until the string has been exhausted by the strstr search.

Line 53, remove the semi-colon from the end of that line. Remove lines 61 and 62. Line 94, put a space before the % in the scanf-- scanf(" %c", &entered_char);

Line 96, you need to surround both logical arguments in your if statement, with parentheseis:

if((argument1) || (argument2))

Line 102, delete the word char in that line. The variable is already declared in your program, you can't /shouldn't re-declare it.

You should be re-compiling your program frequently, to catch any syntax errors before they cause zillions of other errors during compilation.

One concern I have with your code is that x doesn't appear to be reset, so the while loops working with it, are going to go bust.

I don't believe you understood the wisdom of deceptikon's post, right above yours. Your code looks positively PAINFUL. You don't need to work so hard, dude.

On line #9, add

stringnew[i]='\0';

so the end of string char is in place. Now recompile, and see what you get.

If you are adding newname ONLY to the right hand side, then it should work as is. If you are adding newname into the middle portion of a string of text, then you will still need to add another strcat(), to append the right side of the original text, onto the stringnew.

If that fails, be specific what it's showing for a final result.

No there isn't. There is one to search for a string within a larger string, however.

The general logic would be:

#include <string.h>

use strstr() to locate the word you want to replace. Save the position (pointer) it returns when it finds it. From the start of the string, to the one returned, is the leftSide of the string. Everything to the right of the returned pointer, is the rightSide of the string.

You want to work with these strings in a char array with extra length, because you'll need to shift some letters left or right, to make everything fit correctly, if the string being replaced doesn't happen to be the same length as the string being inserted.

Use strlen() to measure the length of the string you want replaced, and the string you want to insert. Subtract them from each other. If the string being added is longer, shift the letters on the rightSide of the string, to the right, that many spaces. If it's shorter, shift them to the left that number of spaces.

Now with the spacing correct, overwrite the left most spaces in the rightSide part of the string, with the string you want to add.

If you've done it correctly, the string will now be correct. Be sure when you are shifting letters, to also shift the end of string char - even though you can't see it.

If a char is >='0' && the char is <= '9', then it must be a digit which is to be interpreted as a number - or at least a part of a number?

Unknown input I always take in as a string with fgets(). Then I know I have the input in my char array[], and I can test it as many different ways as is necessary to get it classified correctly.

Usually, I know before hand what the input will be - integer, string, double, etc.

If I don't know what will be next, I take the data in as a string, using fgets(), into a char array[80]. From there it can be checked with various tests, char by char, to see what the content of it should be.

Your accuracy depends on you knowing your data, very well.

You can perhaps use itoa() or atoi(), but they itoa functions are not standard C - might be in your compiler though, so check it out.

Purpose:
Converts an int, long int, or unsigned long int to a string.

Syntax:
char *_itoa(int value, char *dst, int base);

char *_ltoa(long int value, char *dst, int base);

char *_ultoa(unsigned long int value, char *dst, int base);

Declared in:
<stdlib.h>

Description:
The _itoa, _ltoa, and _ultoa function convertes, respectively, the int, long int, or unsigned long int in value to a character string in the array pointed to by dst (max 33 characters, including the terminating null character). The argument base is a value between 2 and 36 that specifies the desired number base. If base is 10 and value is negative, the first character in dst will be a minus sign.

My compiler adds an underline to the function name (prepends it). Yours may not do that.

The rand() function will repeat the very same numbers, in every run, unless you seed the random number generator ONE TIME, before you use it.

So

#include <time.h>
#include <stdlib.h>

//then
srand(time(0));
//before any call to rand(),

and you'll be all set.

When you get a chance, you'll be miles ahead if you stick with ONE language. You are using headers from C++, and also from C.

Also, the C++ headers are VERY VERY OLD, and now obsolete. OK, they were obsolete 10 years ago, but who's counting. Turbo C/C++ looks like.

Jump over to a modern compiler and IDE like Pelles C, and you will be impressed. If you want C++ though, go with one of the newer C++ compilers and IDE, like Microsoft Express.

I really like Pelles C for Windows. It's NOT C++, but it has an extensive help section, full IDE editor, debugger, profiler, and it's own forum for learning the in's and out's of using it.

There is a learning curve for using it, because it is a Windows program. I use the 64 bit, but actually create 32 bit programs with it, because they're more compatible with older PC's using earlier versions of Windows.

I previously used Turbo C, and one thing I really like about Pelles C is it supports the older headers: especially conio.h, which I had used in a lot of programs from years earlier with TC.

I just click on a box under project --> options tabs, and I can use conio.h functions, just by adding one underline before the regular function name:

gotoxy(), becomes _gotoxy(), getch(), becomes _getche(), etc.

I don't use these much, but some programs require that kind if functionality, and I don't know all the Win32 API's for it.

It also supports the Microsoft extensions, so when I want to run a program that uses Microsoft functions (non-standard), I just click on the "enable Microsoft extensions" box in the very same project --> options window.

A great feature is the way the range is extended for all the different integer and floating point type! You'll love that! That's not strictly a Pelles C feature, but it's still awesome! ;)

Anyway, it has a ton of other stuff, here's the info page on …

Use the PDCurses library for all the console control you could ever want.

I've used UTC in a research program for 16 years. It is used worldwide for this (and many other) computing projects. It works just fine.

The time you receive over the internet, is UTC time, THEN your PC changes that with it's own offsets, to your local time zone.

Set your system (like the rest of the world), to use UTC (aka GMT or Zulu time).

Why? Because UTC is not affected by Daylight Savings Time changes. It doesn't change for it.

[quote]
The switch to daylight saving time does not affect UTC. It refers to time on the zero or Greenwich meridian, which is not adjusted to reflect changes either to or from Daylight Saving Time.

However, you need to know what happens during daylight saving time in the United States. In short, the local time is advanced one hour during daylight saving time. As an example, the Eastern Time zone difference from UTC is -4 hours during daylight saving time rather than -5 hours as it is during standard time.

[/quote]

Post a few lines of the csv (comma separated values):
http://en.wikipedia.org/wiki/Comma-separated_values

that you are having trouble with the input, and your code.

It's best to get into the specifics, and see the actual data and code, rather than work from generalities of either data or code.

Macros are pure substitution, and are handled by the pre-processor, before anything is compiled. Macros will be handled just as if you had entered the substituted code, without the macro. There is no run-time gain.

They are a tool that can help if you sensibly, or hurt if over-used.

OK, but nothing was swapped. A swap of values doesn't mean simply reordering the variables in the print statement.

I like #1 or #3. #1 because it uses bit shifting, which is always fast. The only minus is the subtraction.

I like #3 because it allows full optimization by the compiler - which surely is set up for something as common as multiplication, in unbeatable time.

The #2 I don't like, it has too many operations, in total, that need to be performed.

If you sat down at the desk or table, and was given this string, could YOU find the date digits, inside the string?

How would you do it?

You'd probably start at one end of the string, and look through the string, for the first digit.

When you found the first digit, you'd start counting the next part of the string, and see if that first digit was followed by 7 more digits, to total 8 digits. If you have 8 digits total, then you have the date digits. If not, then you keep moving through the string.

You could use pointers for this, but you can do it without any pointers, very well. Use a while(), or a do while(), or a for() loop, and checking each char as you move through the string.

It's always good to start an unknown algorithm, with the computer mimicking how you would do it. Computers have mad skills we don't, so they can use more efficient techniques many times, but we humans are pretty efficient also most times, given the talents we have.

Try that.

Thanks, AD. Best reason in the world not to code while distracted.

Pelles C also returns "Equal", so sepp2k, you are proven correct!, with the more modern compilers innumerated here.

Which strongly suggests that handling "magic numbers" as constants is in line with common compilers, and probably, in line with the standard, as well.

So congrats sepp2k!

The name of the header is <stdio.h>, not "studio.h", but your program shows it correctly.

So, click on "options" and then on "directories", and check that your stdio.h file is listed as being in the directory that Turbo C++, expects to find it.

It won't go looking all around for these files. You have to get each type of file, into the right directory. And "hello" has no w in it. ;)

The three paragraphs you quote above ALL refer to floating constants, and clearly state that, right at the start of each paragraph.

"Magic numbers" are not mentioned. If it did, I would not hesitate to say you are correct. What you quoted is not what you are asserting, above. Those remarks refer to a sequence of digits IN constants. It says nothing about a sequence of digits which are NOT constants.

You see the part about the "nearest representable value..." being given to the constant.

My contention is that a magic number is simply a series of bytes, and have not yet been rounded by any floating point conversion to the nearest representable value.

Thus the results you see mentioned by the OP of this thread, where "a=5.2", but then a != 5.2.

If the magic number 5.2 WAS already a constant, it would already be perfectly equal to "a".

I used this simple bit of code.

#include <stdio.h>

int main(void) {
   int a=5.2;
   if(a==5.2)
      printf("Equal\n");
   else
      printf("Not Equal\n");

   return 0;
}

Result: Not Equal

The facts in this case, do not agree with your assertion. Perhaps with other compilers, it would. Try it with yours and report what you get.

If the facts agreed with you, I would as well. They don't, however.

Are you saying then, that a "magic number", like 5.2, dropped in as it were from the Underverse (wherever), is made into a floating constant?

Not the variable a, but the value 5.2 itself.

A value like 5.2 is not a floating constant, UNTIL IT'S ASSIGNED to be such. You can't DO ANYTHING with 5.2 until that time, except make comparisons.

But I don't recall what the standard says about "magic numbers", and how they're handled. Any info on that in there?

5.2 is just that: 5.2. Until it is assigned to the data type, it won't be coerced into a double, a float, or anything else.

But 5.2 is not a constant yet - nor a float, nor a double, nor any other data type.

5.2 is just 5.2, until it is assigned to a variable. Nothing else.

The 'a' variable is, but the other 5.2 was never assigned into a variable. It has no data type yet.

Not quite right though, sepp2k.

5.2 is an absolute value - it is NOT the same as the double a which was assigned the value of 5.2 AS A DOUBLE.

5.2000000 != 5.2000001 in your example.

Try this:

double a,b;
a=5.2;
b=5.2;

if(a==b) 
   printf("equal\n");
else if(a<b)
   printf("a is less than b\n");
else 
   printf("b is less than a\n");

Printers have a language that you can control them with. Unfortunately, they don't all use the same langauge!

Unless the printer you want to control is speaking your language, you won't be able to make it do what you want.

Maybe start by reading up on PCL (Printer Control Language):

http://www.google.com/#q=printer+control+language

Read the Wiki article, then dive into the PDF that's listed on the above page, and see a lot more details.

Modems are about the same way. They have a language that many use, but not every modem, uses the same exact one.

In the DOS days you had full freedom as a user, to control all your peripherals, but those days are long gone. Controlling who has the authorization to mess with the peripherals is very important, these days.

So don't skip over the part about getting authorization or all the right control codes you send, will be for naught.

Ok, my idea to solve this problem - which may not be optimal of course - is to accept two hypothesis as true:

1) The answer (which prime < 1 million has the longest consecutive primes summing up to it's value), will be found in the top 100,000 or so primes. Anything below 900,000 can be ignored as the answer.

2) The primes which make up the longer consecutive primes, will be dominated by those primes which have the smaller consecutive primes, included. The smaller primes are the "low hanging fruit" in this problem.

The smallEST primes may not be included in the answer, but the smallER primes, will surely be there.

Adding up primes is VERY easy, and fast: i.e.:
2,3,5,7,11,13,17,19

can be added up for this problem as:
2 + 3 = 5
5 + 5 = 10
10 + 7 = 17
17 + 11 = 28, etc.

So all that needs to be done, is add the previous sum + the next prime, and we have the next sum of a longer consecutive string. No need to go back to the first prime, and start with it.

(And for some odd reason, this is beginning to smell like a problem easily solved with a fibonacci tree, but I'll continue with a brute force solution for now.)

Using the Sieve of Eratosthenes, we have all the primes in the blink of an eye. This is one implementations:

//Uses the Sieve of …

You've started coding, before you finished thinking about how it should be done.

The array name should be arr[], not array[], correct?

Think of the logic:

make an array prod[] equal in size to arr[]. Do you know how to use malloc()?

Then

for(each value in arr[] except the current value you are on as you traverse through the array of arr[])

multiply all the other values in arr[]
and put that value into prod[i]

end of for loop

Is that what you need to do?

Just strcpy() the string, into your array that you have passed into permute, as a parameter. Note that the *b[100] array is local, and won't exist after the program exits that function. Use your own array, instead.

Welcome to the forum!

We are strongly encouraged to start a NEW thread, instead of adding onto a thread that is more than 6 months old.

So I'd stop posting in this thread, and re-post your code and questions, in a brand new thread. That way you get the attention you deserve.

Salem is not on-line atm, but posts a lot.

Syria has a great need for humanitarian help - US and it's Allies can assist there, (and is) in Jordan.

The civil war in Syria will have to be sorted out by the Syrians (plus any other fighters from Islamic countries that will participate). It will be a huge war, because the Rebels underestimated the strength of Assad's regime, after he started getting help from both Iran, and from Hezbollah, too. Not to mention the assistance from Russia.

Some have mentioned that we owe it to Syria to help the Rebels. No, we don't. A good portion of the rebel militias fighting in Syria, have ties to Al Qaeda. Indeed, some are from the same groups that killed our Ambassador in Libya.

Neither Assad, nor the Rebels, have EVER been friends to the US. Indeed, the Rebels "Free" alliance had a burning Washington Congressional Building photoshopped pic, proudly displayed in the background on their web site.
Assad, of course, has attacked our ally Israel, numerous times over the years. You don't have to be political savant to figure out that we're not anybody's buddy in Syria.

Frankly, if chemical weapons are the problem (and they appear to be), removing them from Assad's AND from the Rebels control, sounds like a great idea - even if it takes a lot more time and effort.

Obama's proposal to fire missiles and such, shows he had bad advice from his cabinet, and advisers. You can't do something like that (especially after you …

Demonstrates the Right Hand Rule maze solving algorithm, with some sweet console colors and text display and erasing, in Windows.

Note that if the Start is moved away from all the walls in the maze, the right hand rule fails, circling endlessly. Also, a similar failure happens if the Start is put onto an "island" part of the walls in the maze. This algorithm will not solve all mazes.

You don't need a check prime function, because you'll be checking the accuracy of the Sieve function, before you run it for Project Euler. I forget what the time requirement is for P.E., but they must have limits.

So no check prime function. Keep it for the "Home Edition", maybe. ;)

Let's talk algorithm for this. (and I've not done this problem on P.E. yet).
Just as I'm sure the longest number of <anything> in greatest prime factors, will be found in a large (not necessarily the largest though), prime, so too, I believe the largest # of prime factors must include many of the lowest primes as factors. They're the low-hanging fruit for this, if you get my meaning.

So I have a wild idea for this, but I need to tinker with it a bit. The idea being to not have to factor all the top N primes, which was my first thought on this.

Describe your algorithm. I'm not clear what it is by looking at the code (so far).

When you were gone for a bit, I thought you'd left, and stopped thinking/working on this topic.

I'll get back to it, since you're here.

This is what I use for Sieve of Eratosthenes.

//Uses the Sieve of Eratosthenes algorithm
int getPrimes(void) {
   int root,i,j;

   a[0]=0;a[1]=0;

   root = sqrt(MAX)+1; 
   for(i=2;i<root;i++) {
      if(a[i]) {
         for(j=i*i;j<MAX;j+=i) {
            a[j]=0;
         }
      }
   }
   //print out the primes, 10 per row
   for(i=0,j=0;i<MAX;i++) {
      if(a[i]) {
         primes[j]=i;
         printf("%7d ",primes[j]);
         ++j;
      }
   }

   printf("\n\ncount: %d \n\n",j);
   return j; //j is the count
}

OK, here's the test. Set your MAX for 102. Now see if you have 2 as your first prime number, and 101 as your last one. If you have that, and 26 prime numbers in total, then you're on the right track.

In the for loop you start at line #30, in your code above, I would put either all the prime numbers, or the last 1,000 prime numbers, so the highest 1,000 primes can be checked for the number of consecutive primes that go into them evenly.

I chose 1,000 of the highest primes arbitrarily - that number may need to be adjusted. Clearly, I don't expect to find the longest string of (anything), to be in the lowest bunch of primes. Larger prime numbers mean longer consecutive primes, viewed as a group. That's my thinking, anyway.

First, this is the C forum, and I don't program in C++, so code it in C, not C++.

Second, you can't create a very large array inside a function, (like you tried to do in main(). Why? Because the memory available inside any function is limited to a small portion of memory.

If you want a million int's, you will probably need to get the memory for it from the heap - that's where the BIG amount of memory is kept. You can get it by declaring your array outside and before main(), OR you can create a dynamically allocated array using malloc() or calloc() (include memory.h or stdlib.h to get the macros it needs).

One correction (my error): make the variable root +1 more. Why? Because root is an int, and sqrt() will be floating point, so root will be rounded down by one, frequently - making it short by one, otherwise.

And remember, C! (saving your file with a dot c file name extension, should do it).

Yes, but I'm not going to rob you of the fun of discovering/verifying, what I've claimed.

This is the pseudo code:

Input: an integer n > 1

Let A be an array of Boolean values, indexed by integers 2 to n,
initially all set to true.

 for i = 2, 3, 4, ..., not exceeding √n: (sqrt of n)
  if A[i] is true:
    for j = i2, i2+i, i2+2i, ..., not exceeding n :
      A[j] := false

Now all i such that A[i] is true are prime.

To see a graphic of it in action, and read more about it:
http://en.wikipedia.org/wiki/Sieve_of_Eratosthenes

At the buttom of the article, other sieves are mentioned as better/faster. Ignore them. In my testing at least, they were all slower.

Obviously, in the for loop, you want to avoid re-calculating the sqrt() of n, over and over. Calculate it one time, before the loop starts, and then save it as a variable, and use it instead.

Here's how I'd do it:

1) Use the Sieve of Erathothenes to get a list of all primes, less than 1,000,000. This is WAY faster than using trial by division or modulo. It will knock your socks off!

2) Then do your calculations to find the greatest number of consecutive primes, and their sum.

Sum has to be recalculated for each prime, because each prime has a different string of primes which, when added up, equal it.

Yes, many of the primes will have repeated primes which make it up, but ignore that. Each string of these lesser primes will sum up to it, will have some differences, that must be accounted for in sum.

The prime has to be less than 1,000,000, but adding up the sum must be redone for every prime - but the program doesn't reset sum to zero, when it starts working on a new prime number.

Not &test with fscanf, just test.

char arrays don't require an ampersand, like numeric variables do

If you have other problems, specify what they are.

Note that gets(), while it's very convenient, is totally unsafe from buffer overflow, and has been removed from the accepted C standard.

Nope. ;)

argv is a 2D char array. You can have 2D char arrrays written as *name[], (like argv is), or name[size1][size2]. They aren't EXACTLY the same, but they're so close, you can consider them to be the same thing, for now.

So when you call a function, you don't use myFunction(&argv). That would send the address of an address, of a 2D array - and the compiler will error out on it. Remember that the name of the char array IS the address of the array.

You want myFunction(argv) - if you want to send the entire array to myFunction, and myFunction(argv[n]) if you want to send one string from the *argv[number] array.

The fopen(f[0],f[1]) - I've used a char array for the filename, but never used it for the file mode. If you have the syntax right, it should work fine, however: "r" (remembering the " ").

What I'd recommend is first, get your program to compile - then print out *argv[1], and *argv[2], and see EXACTLY what you have.

If you get stuck, post back.

No. That means your programs will start in main() (at least appear to start to us), in C. In fact, C programs may not start in C, (Pelles C doesn't), but in thinking about where the program starts in C, "it starts in main() in C".

Usually, it's best to pass variables from main() to the functions that need them. If the variables will be changed, then pass them by using the & (address of) operator:
myFunction(&someIntVariable)

or by creating a pointer to the variable, and then passing the pointer:

int *pointer=&numberVariable;
myFunction(pointer);

or

char myCharArray[30];
myFunction(myCharArray); //the name of the char array servers as a
//constant pointer to the base of the array.

The way to work with functions is to use them to handle one part (and only one part), of the programs. For example, you might typically want functions for:

input (getting the data)
processing (more than one function will be needed, usually)
output (to the screen, to a file, perhaps to a printer)

By breaking the program down into smaller functions, you make it easier to program, and MUCH easier to debug and modify, later on.

It depends, but I have had some defines written by others, that just brought the work to a screeching halt, while we figured out WTH these defines were doing.

clever cute defines - I hate them, and pray to the gods to strike them down to hell! ;)

No, it saves time and work, because those global variables are the cause of a great deal of bugs in the program, usually because global variables get "covered over" by local function variables with the same name - which happens more than you'd think it should, believe me.

In C, the ideal is to have smallish size functions, that do just one thing, clearly and efficiently. We can't always do that, but that's the ideal, and it makes trouble shooting a bug in the code, MUCH easier.

You need to put some work into your query. Tell us what input gives you what for the error.

Also, tell us what function the problem is in. That's easy baby steps to fixing programs, and thats a skill you will have to develop, in any language you work with.

Give us specific data, with specific input and errors, and practice some basic de-bugging skills. Nobody knows your program any better than you do, at this point, and everyone's time is valuable. Help us help you.

Even a basic added line which prints the questionable variable, along with a getchar() so you can stop to read it during program execution, will be enough to help pinpoint the error.

Of course, if you step through the program, watching the suspect variables values, you'll have an easier time of it.