Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Reelya]

I'd recommend using a quadtree* arrangement. Sort into 4 "buckets" based on the highest bit, then in each of those buckets, sort into 4 more buckets based on the next highest bit. Obviously, this needs to be a sparse tree, either lock it off at some specific level, and do a linear comparision of things in a region, or have a dynamic scenario where buckets are added or deleted depending on whether there's anything down that branch.

* for 2D data. To store sorted 1D data, it's a binary tree (e.g., a heap. but heap balancing won't work in 2D), and for 3D it's an octree. Either way it's largely the same algorithm.

[Gatleos]

You can't use a hash to store coordinates (or any other data for that matter) because different inputs can result in the same hash.  You can start with a value and get its hash, and thus compare if a hash and value are equivalent.  But you can't start with a hash and walk backwards to get the value that created it.

The point wasn't to only store the hash, it was to use it as comparison criteria for a tree structure. The object itself stores its own coordinate, as well as the coordinate's hash.

I'd recommend using a quadtree* arrangement. Sort into 4 "buckets" based on the highest bit, then in each of those buckets, sort into 4 more buckets based on the next highest bit. Obviously, this needs to be a sparse tree, either lock it off at some specific level, and do a linear comparision of things in a region, or have a dynamic scenario where buckets are added or deleted depending on whether there's anything down that branch.

* for 2D data. To store sorted 1D data, it's a binary tree (e.g., a heap. but heap balancing won't work in 2D), and for 3D it's an octree. Either way it's largely the same algorithm.

Wow, that's not something I thought of until now. I guess that would definitely prevent any collisions between coordinates that aren't actually equivalent. I'll need to think of how I could implement that.

[Emma]

I've decided that it's time for me to learn either C or C++ as well as Python. Wish me luck! And if any of you have tips then I'd be grateful to receive them.

[Reelya]

I'm a C++ guy myself, so feel free to shoot any questions you have my way.

As for where to start, I'm thinking the best place to start is in how you arrange your .cpp and .h files. You should think of the .h files as a table of contents and the .cpp files hold the actual stuff. The .h files are an index of what resources are available, and each resource is defined inside a single .cpp module.

It helps to know how compilation actually works:

 What happens is that each .cpp file becomes one module, and any #include statements are removed, and replaced by the contents of the text file you #included. It's literal cut and paste, so there's no deeper semantics at work here. This can cause problems when you #include the same .h file in two .cpp files. Anything in the .h file is replicated, so if you have a variable "int money" in a .h file, then each .cpp file now has a separate variable called "int money", as far as the compiler is concerned. And since two global variables cannot have the same name, this causes a compiler error. Similar with functions bodies in a .h file, they are replicated for each .cpp file that references them. To get around this, you add extern to variable names in a .h file, and have the actual variable itself in a .cpp file. extern just means that it's an reference to a variable which exists in a different module.

extern int money;

For functions, you just make the function header in the .h file, then make the full thing somewhere else. This also speeds up compilation, because any change to a .cpp file only recompiles that one .cpp file, whereas changes to a .h file affect all .cpp files which reference it. So you want to localize anything you might work on.

Another thing is for book-keeping. Set up your header files like this:

#ifndef WHATEVA
#define WHATEVA
//
// actual .h stuff goes in the middle
//
#endif

WHATEVA should be different in each .h file. This tells the compiler to skip the code if it's already been included in that one .cpp module. e.g. if you had a vector library that was #included by many other .h files, then it might get added in two or more times for the same module, which also causes an error. The #define macros prevent that ever being an issue.

[Orange Wizard]

C or C++ as well as Python.

Cython all the way

[Reelya]

What about Jython and Lython?

[Putnam]

IronPython's a thing too

[Orange Wizard]

Most of those don't have a noticeable increase in performance AFAIK so I don't care about them

[Putnam]

you can write kerbal space program mods in ironpython

i have actually done it

EDIT: wait no i didn't lol (it was Boo) but it is possible afaik

[Orange Wizard]

Oh that's cool, actually

[Bumber]

It helps to know how compilation actually works: ...

Technically that's linking.

Compiling, IIRC, is syntax checking and converting each file into assembly instructions. Then that's assembled into binary. Linking comes after that, copy-pasting the binaries.

[Reelya]

The #include part, which my post is mainly about, is the pre-processor, it's the input into the compiler. Keywords like extern do actually change what's spat out of the compiler stage, so that's the mere set-up for the later linking stage, it's not the linking itself. And the tips about inter-file dependencies, which cab speed up compilation, do actually speed up the compilation stage, they don't speed up the linking stage at all.

And the second part of the post:

#ifndef WHATEVA
#define WHATEVA
// header file here
#endif

... that's also the preprocessor, which is normally lumped in with the compiler, not linker.

[Emma]

This is probably going to sound stupid but if I'm creating a constant variable in C++ should I use:

const int example = 5

Or should I use:

#define example 5

[Telgin]

In C++ you'd want to use const in almost all cases.  #define is a relic from before C supported true constant variables, and C++ was originally derived from C.

C probably supports the const keyword these days too, but I'm not sure.

To expand on why, #define can do a lot of things you don't expect it to.  It largely behaves as a text replace in your code, so if you did this:

Code: [Select]

#define something 5

int somethingElse = 5;

You'd get a compilation error.  Why?  Because the compiler would see this:

Code: [Select]

int 5else = 5;

So it's annoying and bad for that reason.  My guess is that this is why traditionally programmers make #defined things in UPPER_CASE, but you can still have this occur if you're not careful.  Another thing is that if you use const modifiers on your variables, you can inspect them in debuggers as real variables.  The values will always be what you defined them as, but a lot of debuggers won't tell you what a #defined value is.

[Reelya]

const also allows indirection, whereas a #define does not:

"header.h"
extern const int aValue;

So it's just better all around as your programs get more complex