Sometimes I wonder if the reason I name my variables relatively verbosely (e.g. rowIndex, pDataBuffer) is an automatic knee-jerk reaction to seeing variables named stuff like mpzhq, ii, hyp.
Even in context, it is not immediately obvious what they are...
Meh, you should be naming all your variables after superheroes and religious figures.
Sometimes I wonder if the reason I name my variables relatively verbosely (e.g. rowIndex, pDataBuffer) is an automatic knee-jerk reaction to seeing variables named stuff like mpzhq, ii, hyp.
Even in context, it is not immediately obvious what they are...
Meh, you should be naming all your variables after superheroes and religious figures.
We only need a couple of simple reports so far, but I was hoping there'd be a gem that generates pages for Form/Run Report/View Report. Like how Rails generates Edit/Update and New/Create actions auto-magically.
Sometimes I wonder if the reason I name my variables relatively verbosely (e.g. rowIndex, pDataBuffer) is an automatic knee-jerk reaction to seeing variables named stuff like mpzhq, ii, hyp.
Even in context, it is not immediately obvious what they are...
Meh, you should be naming all your variables after superheroes and religious figures.
Funny, my initial reaction to mpzhq was Mister Mxyzptlk.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
At my first job, I worked on a pretty old C++ project. Among many baffling things that this old program did, my favorite was the 8000+ case switch statement.
It went something like this:
topFunctionId = functionId % 1000;
switch topFunctionId
{
case 0:
int middleFunctionId = topFunctionId % 100;
switch middleFunctionId
{
case 0:
int lowerFunctionId = middleFunctionId % 10;
switch lowerFunctionId
{
case 0:
doFunction1(param1, param2);
break;
case 1:
doFunction2(param1, param2);
break;
case 2:
doFunction3(param1, param2);
break;
...
}
case 1:
case 2:
...
}
break;
case 1:
case 2:
...
}
That sure was fun to maintain. We eventually got the go ahead to rewrite it into something that was much more useable and sane to read. a dictionary of <int, function pointer>! Who've thought?
I would have though an array of function pointers, with the functionId is the index ( if the range of ids is fairly continuos ). Any no-op functions would be replaced with a function pointer to an error function.
Edit: Don't post before you finish your first coffee of the day.
Got ZERO sleep last night. I kept dreaming about work... Waking up and thinking "Okay stop dreaming about work dream about something else" and it was the same thing. As soon as work crept in I woke up.
Jesus mother of fuck. Fuck migrations. Fuck databases. Fuck versioning.
I've got to ask what problems you're running into. I probably don't have a good solution, but db migration gotchas are something I'm always on the lookout for. Especially now that we're doing more multiple backend dev per project stuff.
Jesus mother of fuck. Fuck migrations. Fuck databases. Fuck versioning.
I've got to ask what problems you're running into. I probably don't have a good solution, but db migration gotchas are something I'm always on the lookout for. Especially now that we're doing more multiple backend dev per project stuff.
It's primarily related to cleanerversions that we're using in django. If I have to convert a field from something like "models.ManyToManyField()" to "VersionedManyToMany()" it always takes like 45 minutes to get it back to a stable state. On top of that I have to drop the table and then recreate it.
Got ZERO sleep last night. I kept dreaming about work... Waking up and thinking "Okay stop dreaming about work dream about something else" and it was the same thing. As soon as work crept in I woke up.
I dreamed that there was 4 relatively large meteors that were hitting in my general area.
They hit every building around me but mine.
I was still tasked with working on this stupid program.
Dreams.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
At my first job, I worked on a pretty old C++ project. Among many baffling things that this old program did, my favorite was the 8000+ case switch statement.
It went something like this:
topFunctionId = functionId % 1000;
switch topFunctionId
{
case 0:
int middleFunctionId = topFunctionId % 100;
switch middleFunctionId
{
case 0:
int lowerFunctionId = middleFunctionId % 10;
switch lowerFunctionId
{
case 0:
doFunction1(param1, param2);
break;
case 1:
doFunction2(param1, param2);
break;
case 2:
doFunction3(param1, param2);
break;
...
}
case 1:
case 2:
...
}
break;
case 1:
case 2:
...
}
That sure was fun to maintain. We eventually got the go ahead to rewrite it into something that was much more useable and sane to read. a dictionary of <int, function pointer>! Who've thought?
I would have though an array of function pointers, with the functionId is the index ( if the range of ids is fairly continuos ). Any no-op functions would be replaced with a function pointer to an error function.
Edit: Don't post before you finish your first coffee of the day.
Honestly, it looks like a good reason to break out the GOTO statement....
At my first job, I worked on a pretty old C++ project. Among many baffling things that this old program did, my favorite was the 8000+ case switch statement.
It went something like this:
topFunctionId = functionId % 1000;
switch topFunctionId
{
case 0:
int middleFunctionId = topFunctionId % 100;
switch middleFunctionId
{
case 0:
int lowerFunctionId = middleFunctionId % 10;
switch lowerFunctionId
{
case 0:
doFunction1(param1, param2);
break;
case 1:
doFunction2(param1, param2);
break;
case 2:
doFunction3(param1, param2);
break;
...
}
case 1:
case 2:
...
}
break;
case 1:
case 2:
...
}
That sure was fun to maintain. We eventually got the go ahead to rewrite it into something that was much more useable and sane to read. a dictionary of <int, function pointer>! Who've thought?
I would have though an array of function pointers, with the functionId is the index ( if the range of ids is fairly continuos ). Any no-op functions would be replaced with a function pointer to an error function.
Edit: Don't post before you finish your first coffee of the day.
Honestly, it looks like a good reason to break out the GOTO statement....
At my first job, I worked on a pretty old C++ project. Among many baffling things that this old program did, my favorite was the 8000+ case switch statement.
It went something like this:
topFunctionId = functionId % 1000;
switch topFunctionId
{
case 0:
int middleFunctionId = topFunctionId % 100;
switch middleFunctionId
{
case 0:
int lowerFunctionId = middleFunctionId % 10;
switch lowerFunctionId
{
case 0:
doFunction1(param1, param2);
break;
case 1:
doFunction2(param1, param2);
break;
case 2:
doFunction3(param1, param2);
break;
...
}
case 1:
case 2:
...
}
break;
case 1:
case 2:
...
}
That sure was fun to maintain. We eventually got the go ahead to rewrite it into something that was much more useable and sane to read. a dictionary of <int, function pointer>! Who've thought?
I would have though an array of function pointers, with the functionId is the index ( if the range of ids is fairly continuos ). Any no-op functions would be replaced with a function pointer to an error function.
Edit: Don't post before you finish your first coffee of the day.
Honestly, it looks like a good reason to break out the GOTO statement....
Burn the evil! Clease it with fire and deletes!
it results in a cleaner implementation better than nested switch statements. which, was probably implemented to alleviate a tangle of nested if's.
goto's have their (limited) uses, and this is one of them.
I imagined if you used an array of function pointers the result would look something like:
int topFunctionId = functionId % 1000;
int middleFunctionId = topFunctionId % 100;
int lowerFunctionId = middleFunctionId % 10;
lowerFunctionPointers[lowerFunctionId](param1, param2);
middleFunctionPointers[middleFunctionId](param3, param2);
topFunctionPointers[topFunctionId](param4, param3);
That's basically what we did when we got the go ahead to rework it. Except there was no longer a need for all those MODed ids. I was told it had been done that way to make it run faster? I'm not quite sure how a switch statements work in runtime. Is it more like a huge if/else block where it has to hit each case statement, evaluate it, then move on to the next one until it finds the match? Or is it like an array where it can pretty much immediately access the block it needs?
It's like a binary search / radix sort.
If you have a switch with 1000 items, it goes from top to bottom until it hits the conditional that matches.
If you have a switch first on the leading digit (id / 1000, say) then you have only 10 conditionals to exhaust and bam, you're in the correct set of 100.
Repeat and you get a final switch of 10.
If you have switch 0 ... 999, it can't assume as much and optimize this. So if I have id = 998, that is 998 failed comparisons it does until it gets there. O(n) growth on indexing functions as the number of functions increase.
Instead I can do the first switch of 10. Look for my leading 9, ... nope, nope, nope... ahh there it is. Next look in another switch of 10 for the next 9. Done. Switch and look for the 8. In this worse case I did 9 + 9 + 8 = 28 comparisons to find the right branch with my function.
With functions being added, I still only look at constant-size switches of 10 options. I only add another layer of switches when my functions increase ten-fold. O(log N) growth on indexing.
Since this lookup is entirely about indexing, taking the O(log N) one makes sense.
Now, as mentioned, this is similar to radix sorting. Best thing to do (because this is humongous to implement as switch statements and terribad) is to use a data structure that hashes and organizes this way instead, and store function pointers in it. Anything that provides O(log N) access.
eg. If you don't have sparse index numbers, just use an array and get O(1) lookup! :rotate:
And depending on the level of sparseness you can have dummy function pointers for empty entries. The upside for having 3 arrays of function pointers is that it allows for some level of sparseness too.
0
gavindelThe reason all your softwareis brokenRegistered Userregular
I missed the meeting Tuesday and missed the assignment of work for the next two weeks.
I am now writing out the seventy two test cases for our system test plan.
It is a truth of the universe: whoever misses the meeting gets the scut work.
No language would cache that unless they have a way to designate functions as deterministic (a given parameter always returns the same value).
This is not the case with the majority of code, since you usually aren't talking about functions in the mathematical sense but in the "check this string, whooops not deterministic" or have any kind of side effect that changes state.
No language would cache that unless they have a way to designate functions as deterministic (a given parameter always returns the same value).
This is not the case with the majority of code, since you usually aren't talking about functions in the mathematical sense but in the "check this string, whooops not deterministic" or have any kind of side effect that changes state.
Use a variable.
From what I recall, most of the prediction and caching seems to happen along control structures and loops.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Posts
Meh, you should be naming all your variables after superheroes and religious figures.
Like
?
Ecco: "Man, I can't tell if this memory dump actually contains measured data from our ADCs, or just random memory corrupted garbage."
An hour of frustrated debugging later getting nowhere...
Ecco: "Oh, hang on, I can send in a known pattern into the signal to easily tell the different between corrupted data and actual measurements."
We only need a couple of simple reports so far, but I was hoping there'd be a gem that generates pages for Form/Run Report/View Report. Like how Rails generates Edit/Update and New/Create actions auto-magically.
Funny, my initial reaction to mpzhq was Mister Mxyzptlk.
I would have though an array of function pointers, with the functionId is the index ( if the range of ids is fairly continuos ). Any no-op functions would be replaced with a function pointer to an error function.
Edit: Don't post before you finish your first coffee of the day.
Email? Didn't see em until this morning.
Sorry honky. :hydra:
It doesn't help that my back is having some major problems right now.
Nintendo ID: Incindium
PSN: IncindiumX
I've got to ask what problems you're running into. I probably don't have a good solution, but db migration gotchas are something I'm always on the lookout for. Especially now that we're doing more multiple backend dev per project stuff.
It's primarily related to cleanerversions that we're using in django. If I have to convert a field from something like "models.ManyToManyField()" to "VersionedManyToMany()" it always takes like 45 minutes to get it back to a stable state. On top of that I have to drop the table and then recreate it.
I dreamed that there was 4 relatively large meteors that were hitting in my general area.
They hit every building around me but mine.
I was still tasked with working on this stupid program.
Dreams.
So I couldn't even be youtube cool.
Honestly, it looks like a good reason to break out the GOTO statement....
Joe's Stream.
Burn the evil! Clease it with fire and deletes!
3DS: 0473-8507-2652
Switch: SW-5185-4991-5118
PSN: AbEntropy
it results in a cleaner implementation better than nested switch statements. which, was probably implemented to alleviate a tangle of nested if's.
goto's have their (limited) uses, and this is one of them.
Joe's Stream.
That's ice cold.
http://i.imgur.com/G5NdxmZ.gif
It's like a binary search / radix sort.
If you have a switch with 1000 items, it goes from top to bottom until it hits the conditional that matches.
If you have a switch first on the leading digit (id / 1000, say) then you have only 10 conditionals to exhaust and bam, you're in the correct set of 100.
Repeat and you get a final switch of 10.
If you have switch 0 ... 999, it can't assume as much and optimize this. So if I have id = 998, that is 998 failed comparisons it does until it gets there. O(n) growth on indexing functions as the number of functions increase.
Instead I can do the first switch of 10. Look for my leading 9, ... nope, nope, nope... ahh there it is. Next look in another switch of 10 for the next 9. Done. Switch and look for the 8. In this worse case I did 9 + 9 + 8 = 28 comparisons to find the right branch with my function.
With functions being added, I still only look at constant-size switches of 10 options. I only add another layer of switches when my functions increase ten-fold. O(log N) growth on indexing.
Since this lookup is entirely about indexing, taking the O(log N) one makes sense.
Now, as mentioned, this is similar to radix sorting. Best thing to do (because this is humongous to implement as switch statements and terribad) is to use a data structure that hashes and organizes this way instead, and store function pointers in it. Anything that provides O(log N) access.
And depending on the level of sparseness you can have dummy function pointers for empty entries. The upside for having 3 arrays of function pointers is that it allows for some level of sparseness too.
I am now writing out the seventy two test cases for our system test plan.
It is a truth of the universe: whoever misses the meeting gets the scut work.
Code's compiling.
zzzzzzzzz-*snort*huh, nnng? ouuhhh.. uh, yeah. ...Um, compiling. Ahem.
*assorted chair squeaks and creaks before more snoring*
string poopy = "buttsbuttsbuttsbutts"; if(poopy.find("butts")) { print(poopy.find("butts")); } else { print(poopy.find("butts") + 1); }Does the (any/some/most?) compiler see all those identical calls to find and just put them in a variable to use as needed or does it do it each time?It depends on the language, but I don't think I've ever really seen them cache stuff like that.
This is not the case with the majority of code, since you usually aren't talking about functions in the mathematical sense but in the "check this string, whooops not deterministic" or have any kind of side effect that changes state.
Use a variable.
From what I recall, most of the prediction and caching seems to happen along control structures and loops.