Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
1
Proposals / Re: Difficult!!!
« on: March 03, 2009, 04:40:21 pm »
Or you could thank IsmAvatar for allowing us to use LateralGM at all. ENIGMA isn't on final release, we make no guarantees about usability until that point.
2
Off-Topic / Re: Just saying hi
« on: February 28, 2009, 08:10:48 pm »
Welcome aboard the ENIGMA forums. ENIGMA, when in the target state, will be a great way to learn C++. EDL, the language used in GM, will allow many C++-like constructions. For example, if you want to define a variable that doesn't need decimal places, int variable_name; is available. For this specific example, using that integer would be about 300 times faster than using a variable in GM. Using GM-like variables in ENIGMA is approximately 50 times faster than in GM.
3
Off-Topic / Re: These numbers took 1.3 gigs of RAM to generate
« on: February 20, 2009, 12:34:39 pm »
I already explained the small practical application in the first post. Any two Zobrist hashes differing by 3 or less keys used to hash them are guaranteed to be different. So my board game hashes are less collision prone.
Also, anything to do with XOR is automatically cool.
Also, anything to do with XOR is automatically cool.
4
Off-Topic / Re: These numbers took 1.3 gigs of RAM to generate
« on: February 20, 2009, 12:13:07 pm »
I didn't toss it into a giant array. I tossed it into a giant C++ set. Also, a harddrive based version of the algorithm would be harder to design, and take quite a bit longer. This way it took minutes to code, and I just had to find someone with monstrous RAM.
5
Off-Topic / These numbers took 1.3 gigs of RAM to generate
« on: February 20, 2009, 11:01:45 am »
Probably because my implementation was suspect, but still. Big calculation.
ChIkEn's computer ran the calculation, the best computer in my house only had a gig of ram.
They consist of 640 keys, of which every combination of 3 keys has a unique XOR. As well, every combination of 2 keys also has a unique XOR. Essentially what this means is that if you take Elements A, B, C and xor them, they will never equal Elements D, E, F xor'd. (unless the keys in A B C are the exact same as in D E F).
The numbers (in the form of a C++ array):
http://willhostforfood.com/users/C/ChIkEn/results.txt
One of the 11 arrays is completely blank, because its just there for spacing reasons.
Now, practical reasons for this? I thought they'd be good for Zobrist hashing (which forms hashes based on xor combinations of preset keys).
Ensuring every xor combination of 4 elements is unique is probably possible, but would take about 320 times as much RAM, and thousand-folds more running time.
ChIkEn's computer ran the calculation, the best computer in my house only had a gig of ram.
They consist of 640 keys, of which every combination of 3 keys has a unique XOR. As well, every combination of 2 keys also has a unique XOR. Essentially what this means is that if you take Elements A, B, C and xor them, they will never equal Elements D, E, F xor'd. (unless the keys in A B C are the exact same as in D E F).
The numbers (in the form of a C++ array):
http://willhostforfood.com/users/C/ChIkEn/results.txt
One of the 11 arrays is completely blank, because its just there for spacing reasons.
Now, practical reasons for this? I thought they'd be good for Zobrist hashing (which forms hashes based on xor combinations of preset keys).
Ensuring every xor combination of 4 elements is unique is probably possible, but would take about 320 times as much RAM, and thousand-folds more running time.
6
Off-Topic / Re: How not to comment code.
« on: February 19, 2009, 06:26:30 pm »Code: [Select]
variable = 3/*sets a variable with name "variable" equal to three*/ //comments the code to explain to the user that "variable = 3" sets a variable with name "variable" equal to three
7
Issues Help Desk / Re: How do we use our own CPP library files?
« on: February 17, 2009, 08:33:06 pm »
What Josh said is the best current way. In the future special headers that automatically add function names would be a good feature (maybe a special comment syntax at the start of the header to indicate function names in such a way that it is ignored when trying to compile in normal C++ IDEs).
8
Issues Help Desk / Re: Help a noobie.
« on: February 17, 2009, 08:29:55 pm »
Just to clarify, boolean variables don't take 4 bytes in typical C++, they take one byte (which is still 7 bits of waste, but not as dramatic as Josh thought).
9
Tips, Tutorials, Examples / Re: Alternate to move_snap
« on: December 02, 2008, 02:05:04 pm »
Or:
x-=x%argument0;
y-=y%argument1;
x-=x%argument0;
y-=y%argument1;
10
Proposals / Re: Some things just have to be deprecated
« on: November 30, 2008, 01:05:38 pm »
Just as good would be if localv int Counter = 0; was placed in the constructor - that is, the variable was initialized in the constructor instead of the code piece.
11
Announcements / Re: ENIGMA -- srs bizness
« on: November 27, 2008, 05:24:20 pm »
Hach-que: You miss the point, in order to show errors there needs to be constant checking whether an error has occurred or not. This slows down the game.
12
Proposals / Re: Some things just have to be deprecated
« on: November 27, 2008, 04:23:15 pm »
Deprecated means discouraged but still supported; alternatives will be preferred, and you need to specify that you want to turn deprecation warnings off, and then you can GM all you want. However, you might accidentally do something like attach an interpreter to your executable (how else will josh do execute_string?).
13
Proposals / Re: Some things just have to be deprecated
« on: November 25, 2008, 04:41:00 pm »
EDL design is an issue that only ENIGMA Einsteins can discuss, duh.
14
Proposals / Re: Some things just have to be deprecated
« on: November 24, 2008, 08:53:30 pm »
Don't you mean:
cpp{static int counter;}
cpp{static int counter;}
15
Announcements / Re: ENIGMA -- srs bizness
« on: November 24, 2008, 04:06:40 pm »
Automatic declarations have been implemented since forever.