Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
I am surprised at the quality. Thank God I live in Tokyo; I can catch one of these shows soon (I do assume there will be plenty of them here to catch).
I wanted to see someone walk into the stage and walk through her or something.
On a miscellaneous note, I know one of the singers for Hatsune “Vocaloid” Miku here. She is 15 and sings like crazy. She provides some of the voice samples they use and also does backup singing on-stage when needed.
Hence Miku sounds like a little girl.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
Thank you both.
But actually no I don’t know how well I am playing. I have never studied music or taken piano lessons etc. I learned on my own and have mostly just played for a few friends and family members. And since it is all casual, none of them are going to talk about syncopation, forte dynamics, etc., even if they WERE qualified.
I would assume someone who is talking about all these things must have some credentials, but then again, I play for fun, so who cares?
But I am hoping to make a classical CD. Since I have never been evaluated by anyone except friends and family and I don’t trust them, I’m not sitting on a sack of self-confidence quite large enough to take a blow like that.
But who cares right? I need it. I will take it like a man when it is my turn.
Fabian, maybe my ear is just not as trained as the ears of some others but I did not really see so many problems with your Can You Feel the Love Tonight. Maybe he has a vendetta? If we are comparing against Elton John, I am pretty sure we would all have clear flaws.
Perhaps the flaws are there, but if you had someone who could break it to you a little more easily than that, you could be well on your way to cleaning it up and making yourself into a real pianist (if that is your goal).
Besides I did not see anything posted by Pointless Boy. Perhaps he does not know first-hand how hard it is to play when a camera or recorder is watching you/listening to you.
I am going to keep posting. This is all for fun.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
My Rei Ayanami’s Theme was wrong so I updated it. I had not listened to the original in so long I forgot the tempo on the harp section and practicing it slowly made me end up playing it slowly. I redid the song.
But with critiques like the recent one(s) I am not so sure I want to post anymore.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
When I made a quick stop in America for the first time in 7 years, what did my mother request that I play? Moonlight Sonata? Sonata Pathetique? No! Rei Ayanami’s Theme—the most beautiful song in the world—of course!
I don’t think she realizes it is from an anime, and I don’t have the heart to tell her.
So I did it next.
Rei Ayanami’s Theme from Neon Genesis Evangelion (piano solo, live-recorded).
I may also do a full orchestral version later in an attempt to capture its full beauty.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
Damn damn damn! I made a major mistake with the equalization when recording Moonlight Sonata Adagio Sostenuto (1st Movement). I fixed it and the correct recording is up on the same link. If it is a song you want to keep, please trash that old version and redownload.
Thank you Randil. Nice song. I recently discovered this song:
http://www.youtube.com/watch?v=CJ8OeRocLrk
I think my song is probably somehow inspired by that song because I have had it on my mind a lot and even learned to play it by listening to the video over and over (the girl who does the drawing also wrote that song, and I asked her for the music sheet for that song but she said she has not made it yet).
I may post my rendition of her song soon, though it is already beautiful enough when she plays it.
Thank you Warp.
Yes it was me playing live. All of the piano solos I have posted were, and I also played live all of the tracks in Aeris’ Theme (which is why the harp is so horribly wrong) and Rusty Bucket Bay. Thank you again.
A woman here in Tokyo has been trying to get me to play the 3rd movement of Moonlight Sonata, but I was not really interested until I learned it had status as being one of the hardest. I plan to start on it soon and see how it goes.
I do however play Hungarian Rhapsody No. 2 (my favorite!), and I hope to get a recording up if I can ever relax enough. I still get nervous when I am recording, even when I am alone, and I have to get over that.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
I wasn’t planning to post this at all but I gave it a shot in IRC and it was unexpectedly well received.
This is an original song (was not going to post because I automatically assume all of my original material sucks) I wrote for an adorable Chinese angel who I hope will become my wife someday (who I mentioned in my previous post).
Her name is Yoo and I am hoping this will make her fall in love with me.
Yoo
Planning to add guitar and drums to this later but will keep it as a piano solo also due to the recommendations from IRC.
She has a son named Neo and I wrote a song for him too, but it is not done yet. Hope you enjoy.
Oh and Moonlight Sonata Adagio Sostenuto (1st Movement).
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
0.183 average first time.
0.163 average second time.
This reminds me of the Kirby Super Star mini-game in which two ninjas face off waiting for a flash and the first one to push the button wins, slicing the other in half. Fun days.
L. Spiro
[EDIT]
0.148 on my 6th try.
[/EDIT]
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
I can not rule it out, but, of the 4 64-bit data models I know, none have this quality.
http://www.unix.org/version2/whatsnew/lp64_wp.htmlhttp://en.wikipedia.org/wiki/64-bit#64-bit_data_models
I am really not sure if it exists or not.
But at least my quiz has served its purpose. You are thinking about these special cases now.
Even I had not been thinking about the 16-bit case nor your special case above until now, which means we are all benefiting.
The next time you encounter any of these problems you are going to think about these special cases and make informed decisions.
I actually only meant #8 to point out the quirk in Microsoft Visual Studio, which in itself would help you make decisions next time. But the fact that you are taking it above and beyond that is great.
L. Spiro
[Edit]
I dislike phrasing that somehow comes off as tooting my own horn (see the quote below for the original text).
[/Edit]
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
Yes, all of this headache just for that tiny detail.
Your note about 16-bit platforms is entirely valid and should be taken into consideration by anyone who codes on such a platform.
It is true that I assumed the portability would be only between 32-bit and 64-bit, but the fact is I do not know anyone who codes on 16-bit platforms.
Nintendo DS can run 16-bit thumb code but both of its processors are actually 32 bits. Most mobile development is done with Java, which is a different bag anyway, but the iPhone/iPod touch is also a 32-bit machine. I do not know anyone who codes lower than these.
But if you or a loved one does code on 16-bit beasts, then these extra factors should be taken into account.
I should say that the correct answer is only correct between 32-bit and 64-bit machines.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
Correct!
You have Microsoft to thank for the headaches surrounding #8.
On any compiler besides Microsoft Visual Studio, the order does not matter on 64-bit builds, but Microsoft decided to keep unsigned long at 32 bits for compatibility. Unfortunately, because their compiler is so commonly used (but apparently everywhere not here), their little oddities really should be taken into account.
Your 64-bit type-of-choice goes first, because it is always 64 bits.
Pointers follow because they are always 32 bits, then 64 bits.
The unsigned long goes last because it is usually 32 then 64, but sometimes 32 then 32.
/Me puts up shields.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
Tub wrote:
wow, feels like 1990. I absolutely agree with bisqwit that readability should be preferred (despite his IOCCC entries ;)). If you’re going for total speed, do some profiling first. Then comment the code you’re "improving" so it remains understandable.
Readability is the motive for one of the rules guiding #1. Rather than simply using a constant, express the 1/X value so that people can easily so that this is really a division by X.
Tub wrote:
#3: seeing that kind of type-casting makes me puke. If you’re going for readability, you shouldn’t use the int in the first place. No matter which direction you loop in.
Absolutely correct. The first point of this solution is not to use integers for unsigned loops.
Tub wrote:
Always going top-down isn’t the speedy answer either way, because other factors play a more important role than comparisons against 0. Need to iterate a large array twice? Do the first one top-down, the second one bottom-up. That way you’ll start the second loop with data that’s currently in your CPU cache. Or just stick to the readable code.
Also very valid points.
This should all be taken into consideration before making changes. For the sake of simplicity, we do not want to take too many considerations into consideration[sic], but in the real world you need to use your head at all times and keep an eye out for other factors.
Tub wrote:
#4: again, the correct solution is the builtin, not a top-down-loop.
I am afraid not. Top-down wins here. Especially in Java (barring the changes you need to make to account for the signed type).
Tub wrote:
#5: yeah, the optimization you’re looking for is bool, not unreadable bit-functions. Mapping to fast asm code is the compiler’s job.
I am afraid not.
Point in case: Coding a Nintendo DS game using Metrowerks CodeWarrior.
Being Nintendo DS, you need to take optimization seriously. It is not a powerhouse.
But amazingly, despite this, CodeWarrior does not actually make most of the optimizations you take for granted. Just because your compiler does it does not mean they all do. And if your code is built to run in multi-platform performance-intensive situations then you can expect a significant change in performance across various platforms unless you code in a way that simply leaves the compiler no choice.
Most of my old team were underlings and interns, but even they had no problems figuring out what the bit operations were doing once they saw them. They hadn’t thought of using them before, but after seeing them once they understood the idea fine and starting using them in their own code. Interns!
But you can make your decisions based on what you feel is best for your work style and for those around you.
In other words, although I am giving credit for one specific answer in most cases, I actually want to stress that you need to use your own head and decide for yourself whether the answer is really the best for you.
Tub wrote:
#7: the "solution" isn’t equal, you’re changing iTotal. That sounds like a variable name that may be important. If I need to use iTotal further down the function I get nasty errors. It may (or may not) save a few cycles, nothing worth wasting time on when I change the function later. Heck, I often define those variables const, just to avoid such nasties, i.e.
const int size = <black>;
T *array = new T[size];
Absolutely correct!
Sorry, this was my mistake. Leaving iTotal changed is against the rules for the reasons you gave here. In the past I did not accept this answer for that reason, but somehow I missed it here. I was in a rush or something.
Nonetheless you are right and I should not have accepted that answer. The for-loop I posted is what I wanted. My apologies.
Tub wrote:
#8: using a void * is a sin, but that’s not what you’re after. There’s no need for padding either, since sizeof(SOMESTRUCT) will return the size including any end-of-struct-padding, so that sizeof(SOMESTRUCT[100]) == 100 * sizeof(SOMESTRUCT) and (char *) &arr[1] - (char *) &arr[0] == sizeof(SOMESTRUCT) remains valid at all times.
Maybe you’ll want the pointer first? That way dereferencing the pointer can be done by just dereferencing the struct’s location instead of dereference + add + dereference again?
(only valid if you maintain pointers to instances of the struct, I don’t think it’d save anything for stack variables)
You are right about the padding. The compiler will do that for you (now don’t I sound like a hypocrite? =P ) and at best, if we pad it ourselves, we are just matching the result of what the compiler would do anyway.
You have a good idea for your order, but for this question there is something else to consider.
I think I need to buy a riot shield and have it handy when I release (or confirm) the answer for #8.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
DaTeL237 wrote:
#8 Maybe the pointer should go last so the referenced item can be placed directly adjecent (in memory)?
I am afraid not.
Just a note: The orders of the items are limited so much that simply guessing could land you on the right order. For this question you must also explain why the order is correct.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
Dromiceius wrote:
L-Spiro wrote:
#7 is also based on simplicity,
The answer isn't while(--iTotal >= 0) is it?
Correct!
Though I am not picky on whether you use a for-loop or a while-loop.
The for-loop form looks like:
for ( int I = iTotal; --I >= 0; )
We barrow the idea from #3 to walk backwards down the loop if this is possible (here we assume it is).
But the fact that the value is signed changed the game a bit.
Falling back on an old rule of prefix operators never being slower than and sometimes being faster than postfix operators, we prefer --I over I--. Then we have to change the comparison against 0 to >= from >.
In C/C++, it is rare to encounter a list/array that would not be better off unsigned, but in C# and Java this happens constantly, and that is why the signed version of the backwards loop is important to know.
In Java, this is actually a huge gain over the alternative, as it produces smaller code and considerably faster code at that. This type of loop is an absolute must for embedded development.
All that remains is the evil #8.
Which everyone is going to hate.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
#1:
Correct! At least in concept.
The 100% answer is:
CUtils::CallFunction( (1.0f / 16.0f) * fX, (1.0f / 16.0f) * fY );
Division is up to 25 times slower than multiplication and should be avoided religiously. The subtle points that go into the answer are:
Rule #1: Put the constants to the left of the variable. This guarantees that the compiler will perform the division at compile-time even if you forget the parentheses.
Rule #2: Use parentheses anyway. It makes it clear to viewers that that constant will be evaluated by itself, and ensures no complications with other multiplications or divisions.
Rule #3: Use the long form of 1.0f / 16.0f instead of just using the constant 0.0625f. This allows everyone to easily determine how the constant was derived and allows them to easily reconsider the problem as a division rather than a multiplication of an arbitrary number.
As for compiler optimizations, again they may or may not take place on this exact code, but the point here is the concept, since more complicated expressions are guaranteed not to be optimized away by the compiler.
Compiler optimizations are highly subjective, and the level of optimizations they are willing to perform varies not only by compiler, but by platform. If you plan for your code to be executed on many platforms and compilers, it is best to play safe and do the simple optimizations yourself. Additionally, compiler optimizations may be completely disabled for debugging purposes. Debug builds are not as important, but it is nice if they run at a reasonable speed.
And my final reason for personally not trusting compilers too much: Metrowerks CodeWarrior.
Up to you how you use these answers though. They are just something to consider.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
#7 is indeed not the same as #3 and #4.
But don't pass just yet.
All of these examples (or at least most) could be further optimized if you are willing to rewrite tons of it (such as with loop unrolling) and prefetching/caching better, etc., but this is all about the simple things you can do to write better code.
As such, the answer for #7 is also based on simplicity, and I am at least willing to tell you that it is similar to #3 and #4.
If I give any more hints than that then it may become too simple to solve, so I have to stop there.
As for #8, although I tried to think of questions that would work in multiple languages, we can all tell easily that this one is definitely a C/C++ issue.
You are coming up with some good ideas for this one, but I know at least my compiler-of-choice chokes on 0-sized arrays.
You are thinking quite deep into this one, so let me let you relax a bit and focus just on the order of the items.
And apparently a lot of people are going to hate the solution for this one.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
amaurea:
#2:
Almost.
#4:
Correct!
The answer is the same as for #3. This is just to raise awareness to the fact that there are so many places where you can loop from the top down, and you should when you can. This is not an optimization the compiler can do for you, because there are times when the direction of the loop matters, and you have to be careful before using this solution.
At least we know that the example code will provide the same result in either direction, so it is better to go backwards.
#5:
Both of those are indeed much faster than the given code, but can you do something more?
#6:
Correct!
Bitwise operations are always faster than division and especially modulus. When the right side is a constant that is a power of 2 you should consider using bitwise operations instead.
As mentioned before, the compiler may do this for you. You can decide on your own whether to trust the compiler.
#8:
You are not wrong, but once you see the reason for the answer you will probably groan, turn green, put on purple shorts, and cause havoc.
Bisqwit:
#2:
Correct!
Unfortunately the actual case of this code I saw at work which inspired this example did not compile that way. It was actually in C#, which is why here I am trying to avoid relying on the compiler so much, since, although I use C++ as the basis for these examples, this is actually about concepts that work in any language. I admit that some of them do lean heavily towards C/C++, but this is for fun and I hope that coders of many languages can take away as much as possible.
You get extra points for being the first ever to mention sincos, which, if available, should definitely be used whenever the sine and cosine of a single number are needed.
#5:
Correct!
Of course your previous answer and your rebuff of it are all fine answers too.
#7:
These are all not bad at improving speed, but is there something else you can do? Less duffy.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
#1:
Afraid this is not the solution.
#2:
In this quiz, all of the code produces the desired output. Imagine it this way: You have stepped onto a new project and browsed through the existing code. You spot some of these problems from this quiz and, without knowing why his code is how it is, you can modify his code on-the-spot to provide the same result he is getting, but better.
#3:
Correct!
Your backwards unsigned loop is the best way. Compare against 0 whenever possible (there are so many ways for compilers to optimize a comparison against 0) and you are guaranteed to avoid the case where the limiter is reloaded each iteration (which may involve function calls, pointers, or both). You can also avoid such a situation by storing the limiter in a local, but you have used more stack space and still will not meet the speed you get from just going backwards.
A backwards loop in the format you gave should always be preferred whenever possible.
#4:
We will assume the vector is of unsigned longs since we have no other reason to believe so.
And we will just assume that 0 is the maximum of a 0-length list, simply because that is the result of the existing example.
#5:
That is definitely faster than the existing code, but can you do more to it?
You are allowed to assume that the number will never be out of the valid range enforced by the example code.
That being said, your code IS the best strict replacement for the example code; if we can not assume that the value will always be either 0 or 1, then your code is the best answer. And you are also the only person so far to give that answer.
#6:
The compiler may or may not. We probably can trust the compiler in this case, but I would rather raise awareness. Of course that means raising awareness to the fact that the compiler probably will “fix” this for you. The perfect answer should probably include this notice, but the actual code will be helpful in more situations than just in this one.
#7:
In the other places where I have posted this, this question proved the most difficult and last to be solved.
#8:
You are on the right road, but there is one very tiny consideration that, if taken into account, will lead you to one order that is superior over all others. And you are probably going to hate this one because of that consideration.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
I will post several snippets of code in C++. Most of the problems here have nothing to do with the actual language being used and this is not a syntax/be-sure-everything-was-declared set of questions.
The floating-point numbers are completely arbitrary and have no meaning in this quiz. The integral numbers can be assumed significant to the solutions.
Each of these snippets is wrong.
Your objective is to rewrite them so that they are correct.
In order to relax your minds, I will tell you not to waste your time looking at the subtle details such as using :: scoping on global functions or using UL after numbers to indicate their signs and sizes.
Additionally, you can assume the types of values based on prefixes.
f = float.
st = size_t.
i = int.
d = double.
ul = unsigned long.
#1: Solved first by Bisqwit
CUtils::CallFunction( fX / 16.0f, fY / 16.0f );
#2: Solved first by Bisqwit
vVec.x = ::cos( fA );
vVec.y = -::sin( fA );
vVec.z = ::sin( fA );
#3: Solved first by Bisqwit
for ( int I = static_cast<int>(vVector.size() - 1UL); I >= 0; --I ) {
// Do whatever.
}
#4: Solved first by amaurea
// Our objective here is ONLY to get the maximum value in a vector of unsigned longs.
unsigned long ulMax = 0UL;
for ( size_t I = 0UL; I < vVector.size(); ++I ) {
ulMax = std::max( ulMax, vVector[I] );
}
#5: Solved first by Bisqwit
++ulSwitch;
ulSwitch %= 2UL;
#6: Solved first by amaurea (additional credit to Bisqwit)
ulX = ulIndex % 16UL;
ulY = ulIndex / 16UL;
#7: Solved first by Dromiceius
for ( int I = 0; I < iTotal; ++I ) {
// Do something.
}
More questions may follow.
This quiz is for fun, but you definitely do earn bragging rights for solving all of these problems.
The first person to solve each problem with its 100% answer will have his or her name posted above the problem.
Multiple answers may be correct, or variants of a single answer may be correct. Grading is lenient, so you get credit for an answer that illustrates the correct concept(s) regardless of whether it is syntactically correct or any other insignificant details.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
That would explain the RAM issues and why the graphics were better than Nintendo Entertainment System but worse than Super Nintendo Entertainment System.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
The file has been updated with Mednafen 0.8.A.
The search range is snapped to a bit more than 2 kilobytes (this is Nintendo Entertainment System right?) because I could not find a logical starting point for the emulated RAM. The range I set should cover everything, but if you find that you are no longer finding values you could before then report back and I will update the range.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
I am afraid I have no ROM files to use with this.
You should be able to find it (the range of its emulation RAM) rather easily though.
Simply find something in your game, look at the properties (File/Properties) to see which chunk has that address, and look at the starting address of that chunk.
Put that value into a Pointer Search with Find Only Static checked and you should find one or 2 pointers that can be used to locate the RAM of your game each time it restarts.
With that, just copy one of the other scripts and replace the process name, CRC, and address.
L. Spiro
