|
dandy72 wrote: vssadmin at an elevated prompt.
Wow, I tried that out. I've been using Windows since version 3.0 and I've never heard of that tool.
I'm sure it wasn't in Windows 3.0 though.
Anyways, I ran the tool but don't know exactly what it even means.
I guess what I'm learning is :
Windows eats up your hard drive and that is all there is to say about that.j
"All in the name of safety and protection, we've destroyed your life. But, at least the bad guys didn't compromise you." ~The "Good" Guys
|
|
|
|
|
And did you check your privileges? (hehe) I mean for real, file ACLs and stuff.
|
|
|
|
|
I think it was introduced with Vista.
To make a long story short, try:
vssadmin.exe delete shadows /all
...and see if you regain any space.
And as others have written - try windirstat
|
|
|
|
|
Personally I show all files including the hidden and system files on every system I work on.
You could start at the root and work your way from there narrowing down the largest folders off of the root and keep working your way down untill you find the hog.
It is possible that it could be the (Hidden) System restore/ Volume shadow copy folder.
|
|
|
|
|
Try WinDirStat[^]
It's free, and it should tell you what is hogging your drive.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
|
|
As I noted in my message right above yours.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Oopsie!
|
|
|
|
|
It occurs to me that every algorithm is O(n) for some value n , which may be 2m , m! , m^2 , or pretty much anything else, so if I have an algorithm that is O(m!^z) , I can simply say that n = m!^z and voila! I have reduced my algorithm to O(n) .
Maybe this will bring Luc back in for a look.
|
|
|
|
|
As long as you're cheating like that, you can also add an arbitrary nesting of logarithms.
|
|
|
|
|
Nesting algorithms are for the birds.
|
|
|
|
|
|
I have the feeling that you are confusing simplifying a problem and solving it...
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Nah, not really, though I admit that I still don't truly understand Big-O notation.
What got me thinking about this today was the comment:
"If you have figured out the O(n) solution, try coding another solution using the divide and conquer approach, which is more subtle"
Now, I'm pretty sure that the first algorithm to come to mind (and the one I implemented) is not O(n) -- I think it's closer to O(n!) (edit: It isn't; it's O(n^2) ) -- so I wonder whether they actually know an O(n) algorithm or maybe they don't understand O(n) notation even as well as I.
From there, it was a simple matter to state that every algorithm is O(n) .
modified 2-Aug-15 14:31pm.
|
|
|
|
|
PIEBALDconsult wrote: From there, it was a simple matter to state that every algorithm is O(n) .
OK.
If you choose the "correct" criterion for measuring the complexity of your problem, then every problem is indeed O(n) . For example, in the Travelling Salesman Problem, if you choose "The number of possible paths" as your complexity criterion, then the problem may be seen as O(n) .
Most of us would choose "The number of stops on the route" to be a more useful complexity criterion, which makes the solution to the problem of much higher complexity.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
The maximum subarray thing? Obviously O(n) operations (with n being the size of the array), with Kadane's algorithm. Or O(n2) by just trying everything. O(n!) .. then you're doing something weird.
I don't know wtf they're talking about with their divide and conquer, it doesn't get any better than Kadane's.
|
|
|
|
|
harold aptroot wrote: The maximum subarray thing?
Yes, shhhh... I didn't want to make this a programming discussion.
Thanks for pointing me to Kadane's algorithm -- I didn't know about it and I see that it is indeed O(n) . My implementation is ummm... not.
But then, the OP was given a more complex problem to solve anyway.
So I didn't get to O(n) , but I got some good exercise in C and that's what I wanted.
And I implemented the "larger" problem of being able to tell you exactly which members of the array are involved in the greatest (and longest) subarray sum.
I don't think it's O(n^2) and I suppose I shouldn't have said O(n!) . I think it's more like O(1+2+...n) , but there's no name for that is there?
I'll continue to think about it and maybe there is an actual O(n) algorithm for this.
harold aptroot wrote: wtf they're talking about with their divide and conquer
I suspect that a shark has been jumped. The code complexity would far outweigh the problem complexity.
|
|
|
|
|
PIEBALDconsult wrote: I think it's more like O(1+2+...n) , but there's no name for that is there? You're absolutely right it would be that funny sum. But actually.. that would be O(n2)
Follows from the old "sum of 1 to n = n(n+1)/2" thing, and n(n+1)/2 is less than 2n2 for all n>0 so it's in O(n2)
edit: actually wait, I'm starting to doubt it would be that sum in the first place. No matter though, enumerating all the subarrays is going to be O(n2) anyway.
|
|
|
|
|
I can see that, thanks.
So the algorithm I implemented is O(n<sup>2</sup>) (at worst) and I added some improvement that should usually reduce the actual effort required.
|
|
|
|
|
harold aptroot wrote: I'm starting to doubt it would be that sum in the first place
Hope I didn't ruin your Sunday.
|
|
|
|
|
That's what she said.
|
|
|
|
|
I'm a C#/WPF guy, and every single one of my classes is coded as follows:
I use regions, and I have the following regions always in this order (assuming there's code there for it):
Constants
Event Declarations
Private Fields
Properties
Dependency Properties
Commands
CTOR
Public Methods
Method Overloads
Private Methods
Event Handlers
In each one of these sections, the items are always in alphabetical order. Why? because when you come in after me and open one of my classes, knowing I code this way, you'll always know where the piece you're looking for is.
I never put code in an event handler, except a call to a private method. Why? Assume you have a bunch of code in a ListBox SelectedItem event. Then you change ListBox to a ComboBox... now you have a bunch of code to do. For a button click.. you're almost certainly going to do multiple things, and all that code doesn't belong in MyButton_Click.
I always correct spelling errors. Why? because I'm not lazy and leaving it is just wrong.
I always use XAML comments. Why? So when you use my class you'll know what things do.
I always comment where appropriate, and I always keep comments current. Why? You already know why.
When a class is finished, I always remove and sort namespace usings. Why? Less code is better.
Now this is just me... I'm anal like this. What about you? I'm curious how other people code.
If it's not broken, fix it until it is
|
|
|
|
|
Yes.
Kevin Marois wrote: XAML comments
Kevin Marois wrote: Less code is better.
Sure, but that doesn't mean "fewer keystrokes" is better (some practitioners (even language designers) don't seem to understand that). A statement should be as informative to the reader as possible. You only write it once, but it's read many times, so don't be lazy up front.
modified 1-Aug-15 20:58pm.
|
|
|
|
|
I simply meant that I remove unused code. If a namespace is inserted, then not used, remove it.
Same with commented out code. If it's truly deprecated, the remove it.
If it's not broken, fix it until it is
|
|
|
|