requinix

HTML 5's spec is a little better. The fun part is in the "Mutate action URL" behavior (which is what happens with method=get), but it has a flaw where the "parsed action" is undefined. However I think it's clear that the intention is to replace the parsed form action's query with the encoded form data, thus discarding whatever may be there already. So, 1. Switch to POST method? That's a matter for whether GET or POST is more appropriate for the action - the data and technical behavior of form submission are irrelevant. Given that it sounds like a "view"-type of action, GET seems more appropriate to me. 2. Keep GET? If you do then you simply put the arg1 and arg2 in the form as hidden inputs.

Speaking of doing things, For what purpose? How are you going to use it? When will this value be more useful than having just the individual components?

It's pure coincidence that you can check for numbers > 3112 - if there was a 13th month with 30 days then >3013 wouldn't work. In principle you can only do comparisons like that if you have the data arranged in decreasing order of magnitude: MMDD. Go ahead and use 3112 but you still need checkdate(). By the way, what are you going to do about 2902?

As maxxd pointed out, it sounds like regular Active Record: you have a class with properties corresponding to all the columns in the table it represents. So besides those three somePrimaryKey* fields you'd have stuff for everything else in the table. With that then, short of indexing and searching, a composite key isn't really anything special - it's just the knowledge that it takes more than one column/property to uniquely identify a record. You might not even have to do anything about it in the code.

The same (basic) way the database does it? if ($obj->somePrimaryKey1 == $primaryValue1 && $obj->somePrimaryKey2 == $primaryValue2) {But this isn't making any sense to me either. The index (composite key) in the database is all about searching - are you trying to do a search in code? Oh, and "collection" is less an OOP thing and more a term that fits the usage well. Like in the real world there's rock collections and car collections and bug collections and so on, so sometimes people use it in programming too. For example, .NET uses that word with many of its classes.

Do you already have rewriting rules for /events/page1 and so on? Because those don't look like regular files. I sure hope they aren't. If so then you should modify those to use (or at least support) your desired /events/pageN/MMDD scheme. [edit] Whatever the answer, the first part of the RewriteRule will look something like RewriteRule ^/?events/page(\d+)/(\d\d\d\d)$which would allow for dates like 9876, but it's really not worth trying to handle that here (and not just because of the complexity).

Browser? Are you using IIS to run it?

So there's that question: Does the file need to be (should it be) human-readable and editable? INIs are easier for that. And at only four values you can just use some simple scheme like ginerjm's simple text file.

Does PHP have access to that file? Can you filesize() it and such without problems? What if you put the file somewhere else?

Use forward slashes (backslashes are fine too but you have to escape them in strings) and no "file://" stuff. What's your code?

I assume a database is out of the question? JSON is easier to write out again. Associative arrays and objects are the same thing when exported so it only matters how you want to deal with them in the code.

If you use mysql_error() to get the error message then it will hopefully clue you into those trailing commas. Also, the mysql extension is really old and it's bad and you need to move to PDO or mysqli instead. Learn about them now and start using them before you write too much code and make it difficult to fix later. You also need to learn about prepared statements because any naive hacker could break that code and make Bad Things happen to your site. PDO and mysqli both support prepared statements.

May have been a hiccup on the server. Maybe the host was doing something that interrupted service. I'd ask them if they are aware of any issues at that time.

Cloning websites is copyright infringement. I'll be locking any other threads I see about this.

Remember this? expected profit = bet * odds of losing / odds of winningLet's revise that a little bit to be more clear what it means. (It was late night when I wrote that and it made sense to me.) expected profit = bet * (odds of not winning - house edge) / odds of winningIf you predict 88 then your high roll must be within 89-99 to win. That's 99 - 88 = 11 out of 100 (or 100% - 88% - 1% = 11%). Not winning would thus be 89%. If you wager 5 and the house gets 0.96% then expected profit = 5 * (89 - 0.96) / 11 = 40.01818Look familiar? I imagine that logic is buried somewhere in the Javascript, though it looks like they're using an alternative form that calculates gross and not net winnings. Same difference.

Well then, good luck. I'm sure you'll eventually arrive at the formula I told you. [edit] Maybe you're getting thrown off because your numbers are wrong? When I enter 5/88 on their site I get 40/0.625. Not the 40.01818/0.62727 in your screenshot. I don't know how you got those but they're wrong. It's also possible you didn't notice that the random number range is 0-99 and your choice must be 1-98; that's where the house advantage comes in. [edit 2] And one more thing: the odds of winning/losing in the formula do not include the... I don't know what it's called, but they don't include the number that you automatically lose with. Since you always lose only on your own number, odds of winning + odds of losing = 99%. Yeah, math.

Those aren't the numbers I'm seeing. It should be basic gambling math: expected profit = bet * odds of losing / odds of winning.

That's only partial so "/???/SHOP/SHOPITEM/PRICE_VAT" $???->SHOPITEM->PRICE_VAT

You can also do plain -> and loops on SimpleXMLElement objects. Exactly what you do depends on the structure of the XML.

Well yeah: you're only grouping the data per employee. If you want it broken down by week then you'll need to group by the week too.

Ungreedy will help but it will still crash on large enough inputs (that is, a long enough distance between the BEGIN and END). The problem is you're putting the quantifier on a capturing group, and the PCRE library will smash the stack trying to remember everything. 1. If you don't need to capture what's in there, don't use a capturing group. 2. Alternating .|\n is like using the /s flag but worse. '/(?

You need PHP 5.4+ for short array syntax. Upgrade. 5.3 is dead. 5.4 is dead. Even 5.5 will be dead in a couple weeks.

Then penalty.php can get the value from $_POST by itself. Like you're doing in whatever that file you posted is. You don't need to do this "send a php variable" stuff.

Making the href span multiple lines like that is not a good idea. Could cause problems. Where is $angle supposed to be coming from? Either it's set in this script, or if it comes from POST data then your script doesn't do anything and just keeps that form (and penalty.php gets the value from $_POST).

What's your HTML?