Computing desk
< July 13	<< Jun \| July \| Aug >>	July 15 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

July 14

wikipedia from 50 years ago

I am trying to link to wikipedia from 50 years ago. However I want to do this dynamically, so that on july 12 2013 I want to provide a link to July 12 1963 on August 1 2013 I want to link to August 1 1963. I have a reunion website that I'm trying to show this info - we have a count down till the reunion and a formula that shows each day how many days left. I can change that link to any date I want...so I can use the counter to link to wikipedia; just don't know how to reflect the correct wikipedia link So July 12th is http://wiki.riteme.site/wiki/July_1963#July_12.2C_1963_.28Friday.29 and I want to figure out how to grab that page dynaamically and have it change each day. Thanks Dick — Preceding unsigned comment added by RLR170 (talk • contribs) 04:27, 14 July 2013 (UTC)[reply]

Depending on how your site is written, it's possible. You could prepare the link in a language such as PHP, and that would allow you to alter its contents to suit the day. As far as the actual code for that goes, it'd look something like this:

$year = date('Y')-50;
$month = date('F');
$day = date('j');
$weekday = date("l", mktime(0, 0, 0, date('n'), $day, $year));
echo "<a href='http://wiki.riteme.site/wiki/" . $month . "_" . $year . "#" . $month . "_" . $day . ".2C_" . $year . "_.28" . $weekday . ".29'>LINK TEXT HERE</a>";

That should result in the correct date being provided in link form. I hope this helps! drewmunn talk 07:39, 15 July 2013 (UTC)[reply]

(Second thoughts: this may not work as expected, as it is before the UTC creation threshold. If there is a way to link directly to a date without needing the day of the week, then that would be ideal) drewmunn talk 07:45, 15 July 2013 (UTC)[reply]

And it will act funny on Feb 29, 2012 if you make it 1962. Not sure if it's gonna be undefined, but I'd convert the date to Julian date, then subtract 50*365+13 (or 12, depends on which date you want to match exactly) days, then convert back into normal "YYYY-MM-DD" date.

I hope that's the way you want it to work. - ¡Ouch! (^{hurt me} / _{more pain}) 12:49, 16 July 2013 (UTC)[reply]

what sthe point of classes

How are you supposed to use classes?

When developing your own applciation, what's the point of a class hierarchy, I don't really get it. For example if I have an app that reads from the keyboard and the web cam as well, are these supposed to be different classes? Why?

The way I program now is I just put it all into one file with just Main() and some functions, some global variables. I don't really see a problem with the way Im doing it now --89.132.116.35 (talk) 12:53, 14 July 2013 (UTC)[reply]

Have you read Class or object oriented programming? Dismas|^(talk) 12:58, 14 July 2013 (UTC)[reply]

The first one has a very short Benefits section that I can't apply to the example above. It says "Computer programs usually model aspects of some real or abstract world (the Domain). Because each class models a concept, classes provide a more natural way to create such models." I don't see why it's any more natural than simply including 5 global variables in the file for each aspect of the system. There's nothing 'naturally' divided into classes in the whole system, I would have to add on this abstraction after the fact. I'm open to how this helps. But to be clear, without the class, I can do everything. What do I get out of applying a class structure to it? The second article you link has no Benefits section but does have a section Criticisms, which is far longer than the benefits section of the first article. I'm not trying to argue - I'd like to see how for me and my example, why I should try to do make classes out of this system, and how I would do so. --89.132.116.35 (talk) 13:23, 14 July 2013 (UTC)[reply]

Why should anyone attempt to demonstrate why it is better for "you" or "your example"? And why should it be? Generally it's much better to keep an organized file cabinet inside of an organized office, and if you're running a business, you're almost doomed to fail not doing this; on the other hand, if someone can get by tossing all their paperwork in a drawer, does this somehow make arbitrary the filing system used at giant corporations? Personally, I find it easier to think in terms of classes; I think it makes code more readable since it gives a general framework so you know what to expect; most things do break down into classes; and class structuring does scale well, while it's very hard to be certain random programmer Joe's structure will. Not to mention, going back to the general framework, it does make it easier to collaborate since it provides natural ways to divide up projects and layers of abstraction. However, all of that aside, if you can get by with your own personal system, no one's going to stop you. Finally, is their something specific that you would lose by using classes, do you see some large cost it imposes on what you're doing?Phoenixia1177 (talk) 14:03, 14 July 2013 (UTC)[reply]

Three examples from my own life. Last year I made a really laughable ray tracer, inheritance was really useful when it came dealing with various shapes; I think it would've been a nightmare to deal with it differently. I wrote a piece of image processing software that analyzed batches of input images and applied filters according to its logic; the end result was about 45,000 lines of code, being able to hide away chunks of code dedicated to reading files and sorting batches made everything a lot more manageable (since those things aren't really related to images). Finally, a few years back, my friend made some graphics and we ripped off Final Fantasy Tactics and remade the battle engine ourselves (it was more fun than chess); being able to logically organize things on the basis of if they were game data, or graphics data, or etc. and how they all fit together made natural sense when viewed as objects; I don't think that project would have ever gotten off the ground if we didn't have a simple, and clear, way to translate the abstract components into code components. You may disagree and not see the merit in any of this, and that's fine, but it is a useful system for many.Phoenixia1177 (talk) 14:25, 14 July 2013 (UTC)[reply]

You never need classes, just as you never need functions, or useful variable names, or types - these are all conveniences that allow you to fit a complicated program into your head, and to communicate it with other programmers. Simple examples of why classes are useful can be hard to come by, as simple programs are easy enough to fit into your head without breaking stuff up into classes. Instead of your keyboard+webcam app, let's say you were writing Robot Attack, a game where lots of robots live in a spaceship and kill foolish human interlopers. You'd probably have a big list of robots, and each tick of the game you check what each robot should do, and perform that action. Call each individual robot an instance. In a full featured game, there's a kinds of different robots: maintenance robots, patrol, security, battle, cargo transport, etc. Each kind (a class) has special behaviours (only patrol, battle, and security can fight, only cargo can move boxes, only maintenance can fix other robots that are damaged). But you notice that they all have some things in common - they can all pathfind around the spaceship, they can all open doors. So rather than replicating the movement and door code for each, you factor out that into a base class "robot". Now all the individual classes of robot are subclasses of that base class; and the code for the maintenance robot class only has the specialisation to do with specifically doing maintenance things (finding broken robots, fixing them, fleeing if it's attacked). We might look again at our simple class heirarchy of robots and decide that the fighting robots have common behaviour (they look for enemies and move to a firing position), so rather than repeating that code in the patrol, security, and battle robots we factor that out into an intermediate class. Now our class heirarchy looks like this:

  class Robot :: class FightingRobot :: class PatrolRobot
                                     :: class SecurityRobot
                                     :: class BattleRobot
              :: class MaintenanceRobot
              :: class CargoRobot

Now we can construct instances (specific robots) of a given class, and we need only specify the class to get all the behaviour associated with that class, e.g.:

  Robot nigel = new PatrolRobot(name="Nigel", health="low", patrolRoute="room1;room3;room5;room1")

...and the "nigel" bot will have all the characteristics of a PatrolRobot, and because all PatrolRobots are FightingRobots, he gets those characteristics and behaviours too, and because that class is in turn a subclass of Robot, he gets the basic movement stuff that's implemented there too. In addition to behaviour, each class can have attributes (data). So say all robot instances have a "model" attribute, which is the little 3d model to use when drawing that robot. Subclasses can override these attributes (so PatrolRobots get a different model than a generic FightingRobot). And individual instances (specific named robots) can override these too. So you might create the spaceship's guardroom like this:

 // create a couple of generic battle robots with the default settings
 Robot battle1 = new BattleRobot()
 Robot battle2 = new BattleRobot()
 // and the boss
 Robot boss = new BattleRobot(name="Evil Boss", model="evil_boss.model", health="hellatoomuch")

What we've done in deciding this class heirarchy is the crux of your question. We've a) analysed all the things in the program, b) identified common behavior and attributes between classes of things, and c) structured our code to abstract commonality to baser classes and special characteristics to "leaf" classes or to instances. For real programs that's often a complex task, as it involves understanding all of what's going on. And there's usually multiple ways to do it. Looking for a "benefits" and "criticisms" section in some text is beside the point; classes are like the bolts and girders an engineer uses to build a bridge - the engineer has to understand the problem he's solving and understand the characteristics of the components he has available to build it. -- Finlay McWalterჷTalk 14:38, 14 July 2013 (UTC)[reply]

Fast direct access and SSDs

This is a three-part question.

The problem: I have several large files that I need to access directly to get a small amount of data each time. This will be done many times, so access time is very important. The files are too big to hold in the computer's RAM and a hard drive is too slow.

1. Because access time is very important, I think the way to go is with a SSD. Is this the best way to go?

2. Reading about SSDs, the ones using RAM have much better access times than ones using flash memory, right? (It is OK if it is volatile memory because I can reload the files from HD if needed.)

3. Hardware issues. The target computer is a Windows desktop with USB3, eSATA, an extra 5.25" SATA-2, and extra PCI slots. The RAM SSDs I've seen are 2.5" form factor instead of USB3. Are there any USB3 RAM SSD? Is there an adapter to put them in a 5.25" place? Are there any for eSATA? There also seem to be mSATA which look like they plug into PCI, but they say that they need to connect to the SATA data, and they look like they are for laptops - will that work?

TIA. Bubba73 ^{You talkin' to me?} 17:17, 14 July 2013 (UTC)[reply]

1. If you only care about read times, probably yes.

2. If a drive contains RAM and a non-volatile store, the RAM is a cache. RAM doesn't get cheaper because it's in a hard disk - if you can't afford to buy system RAM big enough to hold these files, you can't afford to buy a drive with that same RAM in it either.

3. If you really care about performance, a PCI-express SSD, which cuts out the translation to a bus like USB or SATA, is what you want. But those are darn expensive. Regarding 2.5" SSDs: most consumer SSDs are this size, even those that go into desktops (because flash is so dense, and there's no need for motors and arms and stuff, that form factor is plenty big enough). -- Finlay McWalterჷTalk 17:35, 14 July 2013 (UTC)[reply]

Thank you, #1 - yes, direct access read time is the crucial factor. #2 - the computer is already maxed out at 16GB, which isn't enough for the files. #3 - I'll look for PCI ones. Bubba73 ^{You talkin' to me?} 17:54, 14 July 2013 (UTC)[reply]

I've been looking at the PCIe SSDs - I didn't know about those until you told me. It looks like a 120GB one of those is the way to go for my needs. Thank you! Bubba73 ^{You talkin' to me?} 20:05, 14 July 2013 (UTC)[reply]

Make sure the one you choose has a driver for your version of Windows; some only have drivers for Windows Server. -- Finlay McWalterჷTalk 21:19, 14 July 2013 (UTC)[reply]

I'm looking at some by OCZ, and someone said that it didn't work with their Linux system but it did with W8, which is what I have.

There are some very fast ones out there, but they are very expensive. Bubba73 ^{You talkin' to me?} 01:48, 15 July 2013 (UTC)[reply]

IOPS and RAM

IOPS has some good example data for hard drives and SSDs. Roughly what is a comparible number for RAM? Bubba73 ^{You talkin' to me?} 23:56, 14 July 2013 (UTC)[reply]

Memory speeds depend on more factors than most people want to be bothered with; modern DRAM is really really complicated. In the aggregate, you can average the data transfer speed; a table is included as part of our article on CAS latency, section Memory Timing. Surprisingly, the performance of modern RAM technology actually depends on the cadence and timing of data access; and it also depends on what data addresses are accessed; in other words, the "random access" in RAM is not a very apt descriptive term. Just like hard disk drives, RAM data access is faster if you make use of spatial locality. Nimur (talk) 01:11, 15 July 2013 (UTC)[reply]

Spatial locality is a factor because it increases the cache hit rate, not because of any "seek time" inherent in the RAM. Pentium-class machines cache 16 bytes at a time, even if you only read one. Bobmath (talk) 16:05, 15 July 2013 (UTC)[reply]

Of course caches external to the RAM are also improved by spatial locality. But, because of the way that RAM works, spatial locality is a factor in the RAM itself: because column-addressed DRAM returns (e.g.) 8 words nearly as fast as it returns one word. If you don't need the latter seven words, you wasted a column select control signal; you've already spent that time to query those data, and they're available on the data out port. Have a read at control signals for SDRAM. Few people use the term "seek time" to describe RAM, but it is actually a very apt description. Nimur (talk) 18:34, 15 July 2013 (UTC)[reply]

I'm wondering about the time to get 50-100 continuous bytes from memory on a modern Windows desktop, using DDR2 or DDR3, when the information is almost certainly not in the cache. Bubba73 ^{You talkin' to me?} 01:41, 16 July 2013 (UTC)[reply]

The answer to that question - in isolation from all other details - is "less than a microsecond" - counting round-trip time to the RAM, plus all the control signal "details." Accessing data in main memory - with something modern like DDR3 SDRAM - requires on the order of tens of nanoseconds per transaction - as fast as cache memory was, just a few years ago! This is why all the ugly details matter: when you are reading only 50 or 100 bytes from memory, your total time is not dominated by the average performance of the RAM, because your statistical sample is so small. If you are only reading 100 bytes, your total execution time is probably dominated by when the operating system chooses to schedule your program. Nimur (talk) 13:42, 16 July 2013 (UTC)[reply]

Resolved

Thank you (I will be reading ~50 bytes from memory many, many times). Bubba73 ^{You talkin' to me?} 01:26, 19 July 2013 (UTC)[reply]