Learning via osmosis

July 13, 2009 By

Sometimes, I read something even if I’m not interested in the subject. It could be a way to pass the time. Or I have to read it due to work. Or I like the author, because I liked what he wrote before.

So I was wondering, do people often read something even if they’re not interested in the subject? I began examining myself for the motivation behind my readings. And I found that I read to learn other things.

The primary reason I have is, if I only read what I’m familiar with, I’ll stagnate. So I read about other topics. I may not actively seek to read about, say spelunking or the collection of coins. But I will read about other topics in passing whenever they come into my attention. There are secondary benefits to this uncoordinated reading. I read to learn the sentence structure, the “voice” of the author, the presentation of ideas.

There is this article on program run time and big-O notation by Raymond Chen. Frankly speaking, I had no idea what he’s talking about the first time I read it. And it’s fairly long. And I still finished reading it. And I still have no, ok fine, marginal understanding of what he’s saying.

Some of the terms made sense. Big-O notation, hashtables, and ternary trees (wow I thought there are only binary trees!). I can’t quite wrap my head around the subject though. I still read it. I guess the secret wish was I’d slowly and eventually learn whatever he’s talking about via osmosis.

You know, knowledge and understanding flowing from a low concentration of stupidity to a higher concentration of stupidity.

This went for another article I read by Scott Adams on investing. I read it to learn about investing from another view point. And because I had nothing to do then, and I read his blog anyway and the article came into my feed reader…

Basically he presented the idea of cutting out the financial professionals managing your investment portfolio. I have little idea and opinions on the subject, so I’ll leave you to interpret however you want.

Maybe this random sampling of subjects is my default mode…

Filed Under: Curiosita Tagged With: , ,

Too Fast Too Furious (or instantaneous program run time)

July 9, 2009 By

There was this time when a user called me up for help. I recognised the application she needed help on, which I’m maintaining but not very familiar with. For reasons that will be too tedious for me to explain, I couldn’t solve the problem without going to the one computer, which happened to be near my user, that’s running that program. And my user was conveniently located a few floors below mine… I mouthed a silent sigh, and told her I’d be down in a few minutes.

Man in relay race
[image by photosbyjim]

A bit of information on that program first. It’s run once a month, and its purpose is to send a few hundred emails each with an attachment (which is unique to the recipient).

I took my notepad and a pen in case I needed to take down notes, and left for the user’s office. When I arrived, she showed me what she mentioned on the phone. The program ran, but some attachments (and correspondingly some emails) weren’t sent out.

I checked the log file, but there were no error messages, which suggested that the program ran fine. Now the program used a third party DLL to talk to Microsoft Outlook (the email application used), and sends out emails using Outlook. Since the program ran fine (no errors), the only error left would be with that third party DLL or Outlook.

It would be difficult to debug the DLL, so I checked Outlook first. My instincts told me to try sending a test email. It failed. Aha! The error message said something to the effect of “Mailbox full”. I asked the user to archive some of the emails, and she said she didn’t know how. After sighing in my mind, I put on my computer helpdesk hat and proceeded to archive the emails for her.

Then I told her to run the application. She proceeded to go to “Task Scheduler” and I was perplexed, and asked what she’s doing. Turns out that the program was scheduled to run every month on a certain day, and she’s going to reschedule the program to run a few minutes later. The scheduler would run the program a few minutes later, and she would reschedule the program to run at its original schedule. Ai-ya-yai-ya-yai…

Nearing a mental meltdown, I told her as calmly as I could, that she could just double-click on the program to run it.

“Oh really! That should save some time,” she held her hand to her mouth. She went to double-click on the program. And nothing happened. Or so it seemed…

“Nothing happened!” she looked at me.

I went back to Microsoft Outlook, and checked the sent mail folder. Sure enough, the emails to be sent were there. I asked the user to confirm, and she nodded.

“But it’s so fast!” she pointed at the computer screen.

Too slow, and I get complaints. Too fast, and I get complaints. Sometimes, I just can’t win…

Filed Under: Curiosita Tagged With: , , , ,

Those variables on Bezier curve equations are not fixed

July 6, 2009 By

I wrote something on reverse engineering Bezier curves about… *goes to check* woah, 2 years ago! I don’t remember it being that long… (You might want to read that article before proceeding…)

Anyway, I’ve received a few comments and emails about its usefulness. Basically, what I did was to find the 4 control points of a cubic Bezier curve from 4 known points which lie on that Bezier curve. 2 of the known points are to be the end points of the Bezier curve (which automatically makes them control points too). The other 2 known points lie somewhere on the Bezier curve.

Here’s where the confusion sets in. Commenter Yonatan pointed out that there is an infinite number of Bezier curves based on how those 2 known points are defined. And he’s right.

Now, I formed that solution based on the “natural” implicit decision that the 4 points are evenly spread out on the Bezier curve. There is no reason for them to be, and the math never assumed they are. The solution arose from the assumption that the control points were evenly spread out, but in the end, it worked for the general case as well. So long as 0 < u,v < 1 and u not equal to v (and logically speaking, u < v), everything worked fine.

So the whole point of this article is this: u doesn’t have to be 1/3, and v doesn’t have to be 2/3. You are supposed to know or decide what value they take. Once you’ve decided, the other control points will be uniquely determined. Let me illustrate:

Same Bezier curve with different control points

Now the 2 Bezier curves are exactly the same (I would know, I copied and pasted them…). Suppose I define u and v such that f and g lie on certain points on one Bezier curve, and they lie on different other points on the other Bezier curve. What happens is that the control points p1 and p2 are different for the 2 Bezier curves, even though the curves are exactly the same!

Disclaimer: I haven’t worked out an example such that it is true (other than the trivial case of a straight line), that a Bezier curve can be drawn with 2 different sets of control points. As in exactly the same. However, based on the math, I can say that 4 points lying on a Bezier curve can be drawn with 2 different sets of control points. The resulting curves might (actually they should) differ slightly, a twitch of a pixel here, a slight upward gradient there. But the 4 points would be exactly positioned as calculated. It’s meant to be a, what’s the word, sensational example. So there.

I can’t tell you what u and v are, although 1/3 and 2/3 should work fine. I gave you the theory and the solution. It’s up to you to decide how to use it. Depending on your context, you might decide on different values for u and v, which will influence how your control points are calculated.

My original intent was to produce a camera path flying in 3D. I didn’t care about the “correctness” of its path, only that there is one. As such, u=1/3 and v=2/3 worked excellently for me.

You might find that 1/3 and 2/3 don’t work for you. That’s fine. u and v are variables. By definition, they’re not fixed. Choose whatever value works for you. Depending on context, you might even want to come up with a simple formula (based on your situation) to calculate u and v dynamically.

Filed Under: Mathematics Tagged With: , ,

Moving backgrounds, different speeds

July 2, 2009 By

Back when I was younger (which is an obtuse way of saying “I haven’t the friggin’ idea exactly when”), I dabbled a bit in game development. There was a period when I was studying side scroller games. Remember those? The classic Super Mario Brothers was one of them.

I also noticed that in some of the games, the backgrounds moved. Yes, backgrounds, plural. I could understand forming a background “tile” made up of hills, clouds, trees, grass, flowers, rocks and whatever suited the game as background. But there was something, else, moving in the (for lack of a better word) background.

There was another background layer, moving at a different speed. Wait. Oh, it’s moving at a slower speed.

When I moved that little sprite (that’s representing my sole means of interacting with the game) on the screen to the right, the flowers and trees and rocks sped past to the left. But that faraway mountain was moving to the left at a slower speed. And the overall effect was a realistic simulation of 3D, a semblance of depth in an essentially 2D game.

Now that I think about it, I have one question. How do you calculate how slow the other background should be? I searched high and low, though I found what this effect is called (parallax scrolling), I found no trace of any suggestion to the relative speeds between the 2 backgrounds.

So I did a little thinking. And drawing. I was trying to work out mathematically the slower speed, given the “distance” between the background layers (there’s practically no distance in implementation. Maybe 0.01 units…) and the speed of the background that’s “in front”.

It didn’t make sense, because no matter how I pivot the movement, the calculations don’t work out.

Parallax scrolling backgrounds

L1 and L2 are the “distances” between the respective layers. d1 and d2 are the distances from the objects in question to the perpendicular line formed by the sprite position. v1 and v2 are the velocities of the respective layers moving to the left (or right, depending on how you view this whole thing and how you define the direction… never mind).

The layers aren’t really separate. There is a tiny distance between the layers, say 0.01 units. If you’re in a fully 2D environment, then the farthest layer is drawn, then the next closest layer is drawn, subject to transparency to allow elements from the farthest layer to be shown, and then the playing layer is drawn (where our sprite and other objects are). There’s no distance (between the layers) to speak of in a true 2D rendering environment.

I started with the “don’t move the focus, move everything else” approach, keeping the sprite in place, and moving both backgrounds to the left. This meant pivoting around the sprite. The objects drawn on the other two layers are what our sprite would see in a straight line towards somewhere forward. Those objects should coincide at the “perpendicular” line together.

Since the distances d1 and d2 are obviously different, therefore the velocity (or speed. I’m just trying to be scientifically correct here) of the two objects moving to the left must be different. There lies my problem. It meant the farthest object had to travel faster, contradicting our original observation.

What if we pivoted around the object in the “front” layer? The sprite moves to the right, and the object on the “back” layer moves to the left, and all three line up in a perpendicular line (perpendicular to the layers anyway). Too troublesome. Same with pivoting around the farthest object.

I toyed with the idea of pivoting around the vanishing point. At this point (no pun intended), I decided to give up.

So I assumed that the background image(s) in the “back” layer are appropriately sized with respect to the “front” layer. I decided a simple ratio probably worked best. Thus we have
v2 = v1 / (L1 + L2)
which should give an appropriately slowed velocity.

And now, finally, I’m telling you this. It might not matter. What matters is that you test the velocities, and if the 2 background layers scroll at a pleasing velocity, then there you have it. Ultimately, we’re just trying to simulate a 3D perspective given a 2D environment. If it’s believable, then that’s the correct velocity.

Filed Under: Curiosita Tagged With: , , ,
Newer Posts »