The Big Programming Thread - Page 338

Prev 1 336 337 338 339 340 1032 Next

Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks.

Ilikestarcraft

Korea (South)17743 Posts

August 09 2013 16:20 GMT

#6741

Ah thanks, makes sense now.

Deleted User 101379

4849 Posts

August 09 2013 16:42 GMT

#6742

-- ignore, i was wrong --

spinesheath

Germany8679 Posts

August 09 2013 16:50 GMT

#6743

On August 10 2013 01:08 Ilikestarcraft wrote:
Have a quick question

In this code

while (*s++ = *t++);

I know that its copying a string but what confuses me is how does the loop actually work without what it seems to me a test condition?

As a sidenote: Don't write code like that. It's not readable and prone to mistakes.

This works in C/C++ because everything can and will be implicitly casted to bool. 0 => false, everything else => true. I doubt C++ would still support this if it wasn't for compatability (with C) reasons. NULL is defined as

#define NULL 0

and personally I don't like using NULL anyways, 0 does the job and doesn't have to worry about #define shenanigans.

It wouldn't work in languages with stricter typing, where you typically don't have this implicit cast to bool.

gedatsu

1286 Posts

August 09 2013 16:52 GMT

#6744

On August 10 2013 01:08 Ilikestarcraft wrote:
Have a quick question

In this code

while (*s++ = *t++);

I know that its copying a string but what confuses me is how does the loop actually work without what it seems to me a test condition?

A statement like "a = b" will set the variable a to b, and then return the (new) value of a. The while test interprets 0 as false, and anything else as true. So when you reach the terminating '\0' of t, it will set *s to '\0', and then return '\0'=0 to the while statement which interprets it as false and stops.

The code is susceptible to a buffer overflow attack, you shouldn't use it.

doubleupgradeobbies!

Australia1353 Posts

August 09 2013 16:56 GMT

#6745

On August 10 2013 01:08 Ilikestarcraft wrote:
Have a quick question

In this code

while (*s++ = *t++);

I know that its copying a string but what confuses me is how does the loop actually work without what it seems to me a test condition?

Just aside from what others have said, it's often important to know what the return value of functions/operators are, because c will use them as implicit bool values.

As spine said, try not to program like this, it's difficult to read and forces people to memorize alot of return values especially when you start putting functions in there. Some of them are common/intuitive and arn't a big problem, but it's a slippery slope for putting more obscure functions into your while/if statements and it becomes a pain to read for even experienced programmers.

That said, it is important to know that return values can be used in that fashion, because people do this all the time, it's even pretty common in textbooks. So that at least you will know to look up return values when you see something like that.

Basically don't do it yourself, but be prepared to deal with having to read it :D

nunez

Norway4003 Posts

August 09 2013 18:04 GMT

#6746

On August 10 2013 01:50 spinesheath wrote:

Show nested quote +

On August 10 2013 01:08 Ilikestarcraft wrote:
Have a quick question

In this code

while (*s++ = *t++);

I know that its copying a string but what confuses me is how does the loop actually work without what it seems to me a test condition?

#define NULL 0

we have nullptr now! :>

spinesheath

Germany8679 Posts

August 09 2013 18:22 GMT

#6747

On August 10 2013 03:04 nunez wrote:

Show nested quote +

On August 10 2013 01:50 spinesheath wrote:

On August 10 2013 01:08 Ilikestarcraft wrote:
Have a quick question

In this code

while (*s++ = *t++);

I know that its copying a string but what confuses me is how does the loop actually work without what it seems to me a test condition?

#define NULL 0

we have nullptr now! :>

Yeah, I just didn't actually code any C++ lately so I haven't gotten a chance to use it and forgot to mention it. It's a lot better than the previous solution as it has much better type safety. NULL should be considered obsolete imo (even if the definition is changed to nullptr, though I wonder how many compilers would actually do that since it might break existing hackish code).

Kambing

United States1176 Posts

August 09 2013 18:25 GMT

#6748

On August 10 2013 03:22 spinesheath wrote:

Show nested quote +

The standard defines conversions from nullptr to NULL (and other pre-C++11 null types), so there's no concern of breaking existing code.

Rannasha

Netherlands2398 Posts

August 09 2013 18:31 GMT

#6749

On August 09 2013 03:34 Millitron wrote:

Show nested quote +

On August 08 2013 14:18 Rannasha wrote:

On August 08 2013 13:16 Millitron wrote:
Alright, my google-fu has failed me, I'm pretty stumped on this one.

I'm trying to use Java to create a simple coordinate plane in an image file. Basically I want a jpeg that looks like graph paper.

I can't simply grab one off google images because I don't know exactly what size I need yet or how big each grid will be, and I'd like to be able to change these easily.

My current code is as follows:

import java.awt.image.*;
import java.io.File;
import java.io.IOException;
import javax.imageio.ImageIO;
import java.awt.Color;


public class BlankMapBuilder {

	/**
	 * @param args
	 * @throws IOException 
	 */
	public static void main(String[] args) throws IOException 
	{
		File mapfile = new File("blankmap.bmp");
		BufferedImage image = ImageIO.read(mapfile);
		Color c = Color.BLACK;
		for (int i = 1; i < 2000; i++)
		{
			for (int j = 1; j < 2000; j++)
			{
				if((j % 10 == 0) || (i % 10 == 0))
				{
					System.out.println("j: " + j + "i: " + i);
					image.setRGB(j, i, c.getRGB());
				}
			}
		}
	}
}

I've got a blank bitmap image of the right size and name in the package in eclipse, and the print statement triggers exactly as it should. I get no exceptions thrown or anything like that. But the image is still blank after I run the code. "image.setRGB()" doesn't seem to be doing anything.

Unless this isn't your entire code, you're not writing the image to a file. You create an empty .bmp, read it in, then manipulate the image in memory and then... nothing.

Instead, try creating the image object, manipulate it and then write it to a file.

edit: Changing your loops to

for (int i = 10; i < 2000; i += 10)

(and similar for j) will reduce the number of iterations by a factor 100 and allows you to also remove the if-statement, giving an additional small speedup.

Thanks. I got it to work, though I couldn't do your idea for the for-loops. That only colored the corners of every, it did not draw the edges. I don't mind the minor efficiency cost. I doubt the images will ever be much bigger than 2000x2000, and they're not used in anything time-critical.

Ah yes, you're right. I didn't think it through long enough.

What would work is something like:

for (int i = 10; i < 2000; i+= 10)
{
    for (int j = 1; j < 2000; j++)
    {
        DoSomethingWithPixel(i, j);
        DoSomethingWithPixel(j, i);
    }
}

bangsholt

Denmark138 Posts

August 10 2013 18:20 GMT

#6750

But why would you do that You'll just take the runtime from "not very long" to "a bit less than not very long", and now it is not obvious why you are skipping it

Unless the run time is a problem, you should not optimize. If you do optimize, run a profiler and figure out where you should optimize. You are almost always wrong in your guesses with where to optimize.

Clearness of code is as important if not more important than speed, as it's hard to achieve better speed if you do not know what is going on.

Shield

Bulgaria4824 Posts

August 10 2013 19:38 GMT

#6751

On August 11 2013 03:20 bangsholt wrote:
But why would you do that You'll just take the runtime from "not very long" to "a bit less than not very long", and now it is not obvious why you are skipping it

Any "a bit less than not very long" is better than "not very long". If something isn't clear, you always have /* comments */, right? I don't really agree with your thinking. After all, one of Software Engineering's goals is efficiency, in particular not to waste system resources.

Blisse

Canada3710 Posts

August 10 2013 20:09 GMT

#6752

I believe bangsholt meant if you're sacrificing readability in your code, as in your code isn't as self-documenting as it is before, the change you made is covering up another issue. Your comments should explain, this-and-that does X function, and if someone reads your code, they should very easily understand what's going on. Ideally you shouldn't be explaining why you did X optimization. X optimization should just be intuitive.

In this case, it's decently intuitive, so I don't think bangsholt's point stands (I would say the loops are still a bit unclear in their intent (for example using x and y instead of i and j, etc)), but the idea is okay.

In an ideal world, when you optimize, you shouldn't be writing little hacky its to get X marginally faster. Instead, you should be focusing on why your original code wasn't as fast as it could've been before. (Some exceptions may apply).

Small hackish behavior should feel very dirty because the premise is that all software problems can be resolved to much smaller, simpler problems, so when you use little "tricks" to gain an edge, it means the solution to your original problem wasn't optimal, and you could've found a more elegant solution that doesn't require this quirky, unclear optimization.

waxypants

United States479 Posts

August 10 2013 21:03 GMT

#6753

On August 10 2013 01:08 Ilikestarcraft wrote:
Have a quick question

In this code

while (*s++ = *t++);

I know that its copying a string but what confuses me is how does the loop actually work without what it seems to me a test condition?

Question was eventually addressed adequately I think, but there seems to be a lot of misunderstanding about NULL. NULL is meant for pointers. NULL actually has nothing to do with this problem. The conditional takes the value of "*s" after it has been assigned and will evaluate to false if it was 0 and true otherwise. At the end of the string is the null character ('\0', 0x00, etc). This is not the same as NULL, which is the null pointer. So, after "*s" is set to the null character, the while statement evaluates to false and then breaks out. As a side note, in C NULL can be defined as


#define NULL ((void*)0)

which makes its intention more clear. Setting a pointer to 0 rather than NULL sucks because then you lose the ability to look at the assignment statement and immediately tell if you are dealing with a pointer or an integer type.

CecilSunkure

United States2829 Posts

August 10 2013 21:06 GMT

#6754

On August 11 2013 06:03 waxypants wrote:


#define NULL ((void*)0)

It doesn't matter so much, as both (void *)0 and 0 are the same bit configuration underneath. The only difference between the two is compiler semantics.

waxypants

United States479 Posts

August 10 2013 21:28 GMT

#6755

On August 11 2013 06:06 CecilSunkure wrote:

Show nested quote +

On August 11 2013 06:03 waxypants wrote:


#define NULL ((void*)0)

It doesn't matter so much, as both (void *)0 and 0 are the same bit configuration underneath. The only difference between the two is compiler semantics.

I'm a bit confused as I don't even see how your point relates to my point, or even how even the rest of your statement implies "It doesn't matter so much". Additionally, they are not even necessarily the same "bit configuration underneath" (edit: As assigned to pointers, they are, but not in general).

Shenghi

167 Posts

August 10 2013 21:38 GMT

#6756

On August 11 2013 04:38 darkness wrote:

Show nested quote +

If something isn't clear, you ought to rewrite it so that it is clear rather than using comments to explain the unclear code. Furthermore, "a bit less long" is really only better than "not very long" if we're talking about orders of magnitude. The minor optimization discussed here is turning an algorithm from O(N^2) to O(N^2), losing a bunch of readability in the process. So you're really giving up something important and hardly gain anything in return.

Deleted User 101379

4849 Posts

August 10 2013 22:35 GMT

#6757

On August 11 2013 06:38 Shenghi wrote:
The minor optimization discussed here is turning an algorithm from O(N^2) to O(N^2), losing a bunch of readability in the process.

The O(N^2) is a notation of complexity, not performance.

for (i = 0; i < 1000;++i)

for (i = 0; i < 100; ++i)

Both are O(1) but the second is still preferrable whenever possible. Just because they are both O(1) doesn't mean that one can't be better than the other. The code being discussed makes the execution 10 times faster, so that is not a minor optimization. Depending on the context it can be a huge difference for a really, really, really tiny loss of readability.

CecilSunkure

United States2829 Posts

August 10 2013 22:38 GMT

#6758

On August 11 2013 07:35 Morfildur wrote:

Show nested quote +

The O(N^2) is a notation of complexity, not performance.

for (i = 0; i < 1000;++i)

for (i = 0; i < 100; ++i)

That's O(N)

N is 1000, then 100.

Deleted User 101379

4849 Posts

August 10 2013 22:44 GMT

#6759

On August 11 2013 07:38 CecilSunkure wrote:

Show nested quote +

On August 11 2013 07:35 Morfildur wrote:

On August 11 2013 06:38 Shenghi wrote:
The minor optimization discussed here is turning an algorithm from O(N^2) to O(N^2), losing a bunch of readability in the process.

The O(N^2) is a notation of complexity, not performance.

for (i = 0; i < 1000;++i)

for (i = 0; i < 100; ++i)

That's O(N)

N is 1000, then 100.

Depends. The 1000 is a constant, it never changes. Constant execution time is O(1). If the 1000 was passed in via a variable, it would be O(N), i.e. scales linarly. The 100 is not related to the 1000 before, so it's in itself O(1) as well.

In the case of

void foo(int x)
{
  for (int i = 0; i < x; ++i)  {  }
}

foo(1000);
foo(100);

it would be O(N)

Then again, that is just my interpretation. Might be that comp sci people disagree with it. I never cared much about the theory of that stuff since it has no connection to real programming anyways.

Shield

Bulgaria4824 Posts

August 10 2013 22:46 GMT

#6760


for (int i = 10; i < 2000; i+= 10)
{
    for (int j = 1; j < 2000; j++)
    {
        DoSomethingWithPixel(i, j);
        DoSomethingWithPixel(j, i);
    }
}

How is this not O(N^2)? As far as I remember, nested loop is O(N^2) or O(N^3) if you have 3 loops inside each other. I'm 99% sure this is the case, but regardless if I'm right, I still need to refresh my Big O notation knowledge.

Prev 1 336 337 338 339 340 1032 Next

Please or register to reply.

The Big Programming Thread - Page 338

Completed

Ongoing

Upcoming