Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Max White]

You just gotta build small enough black boxes... That way if shit goes fanward it is only a small piece that needs to be replaced. Engineers have been doing it since they started building motors, you would think we could follow their example.

[Telgin]

...Also what Max said. And like an engineering project, sometimes you'll be stuck working with some seriously funky code and enigmatic documentation written by someone who obviously isn't as skilled as you are.

This includes you 2 months ago...

QFT. As the famous quote goes: "I just spent 15 minutes cursing at code thinking 'What the hell was this idiot doing', and then I found out it was my own code".

So, so many times...

Although I've asked that to myself when reading my manager's code too.  He usually has a good reason for doing something WTF worthy under the hood.  I usually make WTF worthy code because I didn't really think the design through and charged full speed ahead.

I'm maintaining a piece of software I wrote a couple of years ago.  It is just terrible internally.  Small changes take hours and hours to propagate because stuff is done in quadruplicate where it should have been defined once (or even automatically scraped from the database structure or something).  So, so many times, I ask myself, "What was I thinking?  Surely I'll burn in programmer Hell for this..."

[Valid_Dark]

But, I'm not comfortable, in that I've learned even more so that there's no time to really sit and be complacent.  One of the bad things about being a programmer: the field evolves pretty quickly.

I never really noticed that. I mean, there's new languages coming out every day, and new functionality is "invented" or usually reinvented, but programming kind of stays the same: mashing complicated stuff into tiny logical steps.

According to my book c++ used to not have strings,  and also all of the new additions to the c++ standard library that came with c++11 last year.  I'd say it evolves pretty quickly and you have to stay on top of all the new changes.

and in other news:  I just got to string manipulation in my book.  I'm as excited as a kitten with a ball of string.  Any idea as to a program I could make using it?  My book suggests making a pig latin translator.  Which I guess I will if I can't think of anything better.

[MadocComadrin]

...Also what Max said. And like an engineering project, sometimes you'll be stuck working with some seriously funky code and enigmatic documentation written by someone who obviously isn't as skilled as you are.

This includes you 2 months ago...

QFT. As the famous quote goes: "I just spent 15 minutes cursing at code thinking 'What the hell was this idiot doing', and then I found out it was my own code".

Heh, I usually have arguments with myself in comments especially when I have an idea, then reconsider it and think it's stupid, and then it turns out it's exactly what I needed.

[Telgin]

But, I'm not comfortable, in that I've learned even more so that there's no time to really sit and be complacent.  One of the bad things about being a programmer: the field evolves pretty quickly.

I never really noticed that. I mean, there's new languages coming out every day, and new functionality is "invented" or usually reinvented, but programming kind of stays the same: mashing complicated stuff into tiny logical steps.

Well, I won't argue with that.  Once you really understand programming, you can pick up new techniques or languages quickly.  It's sort of a matter of getting it or not.  Once you do, it's sort of like the world is clearer now.

Not that it happens so abruptly, mind you.

Anyway, maybe it's just that I feel like I don't know enough languages, libraries, design patterns, testing strategies and so forth.  I can code pretty solidly, but I always feel like I'm not knowledgeable enough.  That there's always a better solution and that I really should know about it, else I fail eternally as a programmer.  Maybe there isn't, but I'm paranoid like that.

[lordnincompoop]

So, I've been dicking around in Python for a bit. I've written this small snippet to compute some tedious things for me as an exercise, but it doesn't seem to work - the program quits with something like "can't use list as an int" when it tries to run the trajectory code.

I've been straining at this for over an hour, and I still can't seem to understand it - help, anyone?

Code: [Select]

import math

def trajectory(speed, *targets):
    for arg in targets:
        print((0.5*math.asin((32*arg)/(speed^2)))*(180/math.pi))

def main():
    spd = int(input('enter speed value in feet per second'))
    i = 1
    tgts = []
    while i != 0:
        i = int(input('enter a target range in feet. type in 0 to cancel.'))
        tgts.append(i)
        if (i == '0') or (i == 0): break
    trajectory(spd, tgts)

if __name__ == '__main__':
    main()


[fergus]

Code: [Select]

import math

def trajectory(speed, *targets):
    for arg in targets:
        print((0.5*math.asin((32*arg)/(speed^2)))*(180/math.pi))

    [snip]

    trajectory(spd, tgts)


"*targets" turns all remaining inputs into a list and assigns it to the value "targets". Since the only input that can be used for this is a list, targets is equal to a list contain a list containing the values:

Code: [Select]

targets = [
    [a1,a2,a3 ... ]
]
So when you iterate over it you get:

Code: [Select]

arg = [a1,a2,a3 ... ]
NOT

Code: [Select]

arg = a1
arg = a2
arg = a3
...
This errors because of the exact reason stated.

To fix this, replace

Code: [Select]

trajectory(spd, tgts)
with

Code: [Select]

trajectory(spd, *tgts)

OR

replace

Code: [Select]

def trajectory(speed, *targets):
with

Code: [Select]

def trajectory(speed, targets):


[Fayrik]

*dives into the thread panicing*

Okay, so I've just run into something that's totally perplexed me, and this is the only place I can think of to ask this question.
So what's the problem? Unsurprisingly I'm working on a game. (It might go somewhere, it might not. I'd rather not worry about it's future until it's somewhere stable.)
The language I'm working in is C# (Though, this is mainly a logical problem)... It's a 2d game, and because of this I figured I could get away with not having to use OpenTK, SDL, XNA or the horrific "Slim"DX by creating a bitmap buffer and then drawing that strait to the back of a winform. Through some clever research, it worked. The engine runs, and I'm getting a smooth image. I've capped it at 4 frames per second, though I suspect my machine is more than capable of doing this many, many times faster.
Only now that it's working perfectly do have I noticed something that worries me. Writing to a bitmap before pushing to the winform means that the program is writing and destroying many megs of memory four times a second. (Task Manager shows it fluctuating at about 20mb. But Task Manager doesn't update fast enough to show how much it is per frame.)
The size itself isn't the problem. 20mb of RAM these days is a laughable amount, and it's probably not going to go up much from that either. The speed that it's happening however, does worry me.

So, the question. Is writing then destroying large sums of memory dangerous? Or, more fittingly, how dangerous is it?

I've had enough trouble with burned out RAM on this machine before, I sure as heck don't want to end up writing a program that'll make me (or anyone else for that matter) have to deal with all that again.

[Nadaka]

Fayrik: don't worry about it. Ram doesn't really wear out.

[Telgin]

No, you won't wear out the RAM that way.

However, is there any particular reason you're freeing the memory every frame?  My experience with C# is pretty limited, and I'm pretty sure it handles allocations automatically, so maybe you're not actually freeing the memory.  But if you are explicitly doing so, could you find a way to just overwrite the memory instead of freeing and reallocating it?

The C# runtime will probably do an ok job of making this fast anyway, but overwriting instead of freeing and reallocating the memory will almost certainly be faster.  Using the standard new / delete in C++ or malloc / free in C is going to be a lot slower anyway.

Of course, as you say you've got it capped at 4 FPS, so speed isn't your main concern, but something to think about perhaps.

[Fayrik]

Fayrik: don't worry about it. Ram doesn't really wear out.

No, you won't wear out the RAM that way.

Thank Armok for that! Now that I don't have to overhaul the entire program, I might just stand a chance at getting this project somewhere decent.

However, is there any particular reason you're freeing the memory every frame?  My experience with C# is pretty limited, and I'm pretty sure it handles allocations automatically, so maybe you're not actually freeing the memory.  But if you are explicitly doing so, could you find a way to just overwrite the memory instead of freeing and reallocating it?

C# does all the footwork for me. If the object were an integer or such, I could just throw it into obscurity and it'd do the rest for me... But it's an image, so while throwing it into obscurity will get it collected like everything else, it would still leak... It's kind of complicated, but all it means is that I have to call a Bitmap.Dispose() when I'm done with it.
As for overwriting it, that sounds like something I'd like to do, however the Dispose() method may be the key that means this isn't possible, since as mentioned above, it's not the Bitmap object that doesn't get deleted, it's the stuff inside it.
...That said, I've just discovered that I wasn't calling the Dispose() method on the bitmap when I was assigning the new one... And adding the Dispose() method has created no visible changes to the way the program's memory is reacting.

So, after looking into it while writing this, it looks like I can't directly overwrite the memory, though there could be ways around it, they feel to me that they'd be even slower.
(Read: Manually setting every pixel of the bitmap every frame.)
That said, I still can't tell if it's overwriting for me or not. But such is the world of memory management in C#.

As for "real world" performance, the method seems to be quite quick. I can get 40 fps on this machine, and expect that it wouldn't drop far on slower machines.

[Max White]

Protip: c# has an interface called IDisposable. This is really useful because you can use it in what is called a 'using block'
When you declare something in the ehad of a using block, it will be closed once the block is over no matter what. It is really handy. For example

Code: [Select]

            using (Bitmap c = new Bitmap("FileName"))
            {
                //What ever you need the bitmap for
            }

[lordnincompoop]

"*targets" turns all remaining inputs into a list and assigns it to the value "targets". Since the only input that can be used for this is a list, targets is equal to a list contain a list containing the values:

Code: [Select]

targets = [
    [a1,a2,a3 ... ]
]
So when you iterate over it you get:

<snip>

Ah, thank you. It seems to be working as it should!

[Aqizzar]

Goddammit, why does converting the output of math with Doubles into Integers produce totally insane results?  All I want to do is multiply a percentage (less-than-1 double) against another double, then turn the result into an int.  Somehow, this makes [ (4.6 * 70.0) * 0.3378 ] = 9.  What the fuck, C#?

Of course, after posting, I can see where some of the problem is my own mistake.  It's actually passing bad values, but the math is still wrong wrong wrong.  Namely, [ 10 * 0.42 ] = 8 for instance.  Weird.

[Max White]

Can I see the line of code you are using?