Forgot your password?
typodupeerror

Comment: Re:Your Results Will Vary (Score 1) 241

by tomxor (#47488227) Attached to: Math, Programming, and Language Learning

In contrast, web development doesn't really require any of these. However, they all involve "programming", and the people writing the software can all be called "programmers", even if one's writing a website (no math) and another is doing a fluid dynamics simulation (lots of math).

I don't entirely disagree... but :P i am a web developer, who also happens to like lots of vector math, writing physics engines and in particular: writing SPH fluid dynamics simulations and other n-body simulations.

I would agree that some of my understanding of slightly above basic math is not necessary in most of the more common web development work in my job, but i do find it helps me be a better programmer in general... so perhaps the point is that math can make you a better programmer. Id also argue that it makes you better at engineering software rather than just "programming" it, but perhaps that has more to do with the experience of programming complex tasks that also require complex math.

Comment: Pissing in the wind (Score 1) 708

by tomxor (#47466313) Attached to: People Who Claim To Worry About Climate Change Don't Cut Energy Use

That's why people with any sense know that "cutting down" is futile.

If you don't want lung cancer the answer is to not smoke... not just drop from 100 a day to 99 a day... if everyone saves 1% of their energy usage, it will add up globally to whopping... 1% reduction, in combination with the global population growth rate that is utterly pointless.

Change in energy production is the answer, and for that it's not quite as easy for everyone to "do their bit". Trying to justify quantity is impossible, because there is no line to draw, and ultimately not existing is the answer to solving the problem using quantity as the only variable.

Comment: I Play Piano on a Computer Keyboard (Score 1) 57

by tomxor (#47314021) Attached to: Programming On a Piano Keyboard

:P It lacks certain subtleties of a proper midi keyboard such as velocity, but with 2-3 stacked octaves it's possible to play quite a lot. Learning a different arrangement isn't all that hard, it's just like playing a slightly different instrument. I actually find certain types of playing like monotone arpeggios easier with the supper light action laptop style keyboards, i guess it's also not that dissimilar to using a programmable midi pad.

My most fun tune to play this way yet has to be "The Halls of Science" by Mike Morasky (from portal), as a pure sine wave of course :D and what more appropriate way than performing on a computer keyboard.

Comment: Learn Game Programming - Not C*!# (Score 1) 254

by tomxor (#47287971) Attached to: Ask Slashdot: Best Way to Learn C# For Game Programming?

You have a more important problem than which language to chose. The most striking thing about your post is it sounds like you have grand designs for a game (your first game) and that's a bad thing. What you are doing is what almost every new game developer attempts to do... or at least thinks about: going in too big, running before you can walk, building a supersonic jet before you've built your first paper plane etc etc...

Sure you have programming experience and sound design and 3D modeling experience. But when you made your first 3D model did you create a masterpiece with immense detail? or just randomly poke around vertices of an abstract nurb? It's easy to get carried away having big plans for a big game, but you are one person, and you haven't? made your first game yet. You will fail in one way or another, so fail on something small first, then build up to your big idea (which will almost definitely change after you get your feet wet and get a sense of how practical the original ideas were).

Even just pick a small part of the big game that you envision... something so small that it should not take long to build (but it will take longer than you think), don't flesh it out, don't get carried away with detail, focus on a basic concept and see how far you get, this is how you learn: iterate. Wanting to have everything you imagine in your game is easy, deciding what you can have and what is more important is what you will learn.

Also something that might bias your choice of language, is that you will have to decide how much you want to build from scratch and how much 3rd party code you want to use, i.e in terms of engines. If you have very little interest in the physics engines and graphics engines behind games then you will have the task of choosing from the vast range of readily available ones. Not only does that sway your choice of language but it also sets you on a different path of learning, you have to learn how to use someone elses engine rather than learn how to write your own. Using someone else will give you more capability but less creative freedom and insight into how things really work, and could limit you to particular languages.

Comment: Re:RTFA (Score 1) 173

by tomxor (#47239809) Attached to: Dell Exec Calls HP's New 'Machine' Architecture 'Laughable'

...The only difference I see between a traditional machine and this one is that the separation between transient state and persistent state is physical in a traditional machine - DRAM is transient, disk drives are persistent (and writes onto disk are commits to the persistent state), while this new machine would most likely enforce a logical separation...

The separation is not supposed to be that clean cut, otherwise the obvious solution is something like a dynamically sized swap file for system memory, or a harder physical allocation for contiguity, at which point the difference in operation would be small...

One of the biggest advantages (second to the physical performance improvement) of this concept is supposed to be the absence of unnecessarily duplicating persistent data into system memory, this is also mentioned in the article. This is what makes the logical separation far less clear, which is why i think the possibility for overlap and corruption of persistent data via running state is a reasonable concern.

Comment: RTFA (Score 4, Informative) 173

by tomxor (#47236337) Attached to: Dell Exec Calls HP's New 'Machine' Architecture 'Laughable'

"With persistent memory, the machine state gets messed up, you are so screwed."

Uh, have you looked into your computer recently? I believe you'll find either this little device called "an HDD" or this other little device called "an SSD". And people with those seldom get screwed.

If you read the article from the previous slashdot story about HP's "The Machine", you will find that they are not simply trying to use memsistors to replace main memory, but that they are also trying to consolidate the storage memory and working memory into a single piece of memory, this is why it is considered to be substantially different memory architecture which also requires the OS to work a little differently too... if you are old enough think "Ram Disk"

The difference being that usually any stored data to be used by the processor has to first be loaded into working memory from the large slow storage memory... as i'm sure you are aware, which is why SSDs are so popular... but even NAND is many times slower than SDRAM, so the separation remains.

The idea is that if a sufficiently fast, dense, persistent and cheap type of memory can be found then the best of both can be consolidated into one. The concern of the OP is that issues affecting running state could affect the traditionally less dynamic stored state... Working memory is usually treated as volatile and disposable, and your block device is not, but the line is now blurred.

I think it's a reasonable concern, but one that is likely to be addressed by the OS, a less physical separation between what is running state and what is not would need to be implemented, but at the same time the advantages of not "loading" data need to be retained... making everything that goes into the running state duplicate would bring back the "loading" problem slightly.

Comment: Reduced to a linear problem (Score 1) 57

by tomxor (#47235135) Attached to: 545-Person Programming War Declares a Winner

Anyone else find it odd that he used a distance squared force for a 2D problem? The surface of a circle depends linearly on the radius.

Linearly being the key word... take it one step at a time (before looking at what geometry inverse square law could represent). The rule is derived entirely from distance... Distance reduces the number of spacial dimensions into one, it doesn't matter how many spacial dimensions you have so long as you can find a scalar distance between two points.

For a less abstract explanation think of a 2D simulation as a geometrical subset of a 3D simulation (that subset doesn't have to be axis aligned), a 2D simulation could exist within a plane at any orientation in a 3D simulation...

So a 2D simulation will behave in the same way for distance based rules as a 3D simulation restricted to a plane would. what you do with that scalar distance is up to you (inverse square law just happens to describe lots of nice things like gravity and magnetism etc), there are also other rules that describe other forces based upon distance such as inter molecular forces (known as potentials in molecular dynamics). However all of these rules are compatible with both 2D and 3D simulation.

Comment: OS X (Score 1) 611

by tomxor (#47111519) Attached to: Which desktop environment do you like the best?

It's never perfect but.. OS X's ui is probably about the most pleasant, polished and consistent thing out there right now, but i feel like once more projects like gnome 3 with a unified design approach emerge then various major linux distros and some BSDs i hope... Minix3 if i'm lucky... will become more palatable to a desktop user.

Gnome 3 is not for everyone because it's a relatively big and highly opinionated paradigm shift from the linux DEs before it... But as far as UI design goes they got some very important fundamental things right compared to the others before it:

Consistency and unified design approach and... Minimal configurability! I know a ton of linux users will disagree with me but they aren't UI designers... the responsibility of finding the optimal possible UI layout is on the UI designer, NOT the user... if it makes you feel better you can look at this from the point of view of efficiency and not "design", UI design shouldn't be about making pretty interfaces, it should be about making efficient interfaces, the beauty of the interface should emerge from the consistently and thoughtfully chosen functionality.

If the user has to spend hours formulating the optimal UI layout for their "workflow" then the functionality is too fragmented, as a result the workflow turns into a massive combinatorial mess and the UI has no chance of being concise thoughtful and usable. Gnome 3 got this right in concept... i wish many app UI designers also understood this.

Comment: Re: OS X History (Score 1) 611

by tomxor (#47111093) Attached to: Which desktop environment do you like the best?

In that it is like UNIX (from which it actually does descend, Darwin is actually an implementation of Mach)

I don't want to join in the argument of how to pronounce an ambiguous acronym. Just popping my head in and doing my usual historical correction here...

Darwin is not a descendent of UNIX. However it could be called a descendent (mainly) of FreeBSD + Mach. The difference being that FreeBSD and co are all derived from 4.4BSD-Lite which contains no proprietary AT&T code (UNIX). UNIX on the other hand contains plenty of code from the various BSDs (note the direction of code inheritance).

Darwin is however POSIX compliant meaning that it can use the UNIX trademark. All that means is it complies to the spec, not that it shares code with UNIX the OS... so the argument of the relationship between the use of X and the UNIX name is valid.

"If truth is beauty, how come no one has their hair done in the library?" -- Lily Tomlin

Working...