Thanks for pointing this out - I knew I should have been more clear. If I have an element, and I want to remove it from a vector, I have to write a bunch of code. I have to find it first, make sure I actually found an element, and THEN I can erase it. This means I either keep a local copy of the iterator, or I call the find_first algorithm twice.
It's kind of like the hoops you have to jump through to do a case-insensitive compare on strings.
I really don't like functors. If people aren't careful, they end up implementing the same functor in multiple locations. I think the method paradigm is much better, because they're tightly coupled with the class that they act on. Functors can live just about anywhere - and you can end up with duplicated effort (ie bugs), once a project gets large enough.
Also, I dislike the fact that some STL functions will return "npos" and some "::end()" to indicate "no results".
How the hell do people cope with Daylight Savings Time? How do you indicate whether 1:30 AM is the/FIRST/ 1:30 AM, or the/SECOND/ 1:30 AM, when Daylight Savings Time hits?
Before you listen to any of us, go out and buy "Effective STL" by Scott Meyers, and probably "The C++ Standard Template Library" by Nicolai M. Josuttis.
Now, I don't want to get off on a rant here, but in my personal opinion, the worst thing about STL is their string support. It's great, because it's standardized, but that's about the only thing going for it, from a programmer's perspective. (Yes, it's highly optimized, but the API isn't very rich. I like rich APIs!) In other words, build your own string class, and give it a Has-A relationship to the STL string.
Also, I hate that Containers change paradigms on you, some places you can use integer indecies, sometimes you have to use iterators - and in my opinion, the line isn't very clearly drawn.
Also, the methods are written along the lines of, "if it's not optimal, you have to write the code yourself." I'm sorry - that sucks. Sometimes I need to remove an element from a Vector. Maybe I should be using another Container. Or maybe the API should allow it, but make it clear in the documentation that it's not efficient. I vote for the latter.
Get used to having your objects copied. STL Containers work by copying your objects. It's a different way of thinking for a lot of people. It has rammifications that are kind of hard to grasp, at first, if you're not used to it.
Don't use Containers of AutoPtr's! It won't work right! (Read "Effective STL" for an explanation.)
In my opinion, everyone should wrap every third-party library they use with an API that they can live with. STL is no exception. You might even expose every single member function, but you have the freedom to expand your API if you want. If you can't afford a stack push, then you probably shouldn't be using STL in the first place.
If you end up really liking STL, take a look at Boost. Some parts of Boost are really cool and well written.
Really, I think the best advice I can give is this : get to really know an API before you start to use it. Because, if you try to just use the parts of an API that you know and like, you're going to make horrible mistakes. Invest the time to get to know the library well enough to use it the right way. STL is no exception.
Of course, that's just my opinion, I could be wrong.
The algorithm has nothing to do with the transmition medium.
If you want to make a One Time Pad that's long enough, you are free to disguise the length of a message by padding your text with 0s. This is essentially "wasting" your pad, but if you're really concerned about the length of your message being revealed, you are free to obscure it and make it seem artificially larger. (You can't make it artificially smaller, unless you somehow compress your message before you encrypt it.)
And you can hide the fact that a message has been sent by using any steganographic method you chose. Just as you can with any other encryption algorithm.
Don't confuse the algorithm with the transmition medium.
Re:oh really?
on
Worst Buy
·
· Score: 3, Insightful
When does this cross the line to bait-and-switch, which is illegal?
I think it's a pretty fine line, not a blatant misunderstanding on the part of the poster. Don't be so critical - there's a real issue at stake, here.
Or, to sum up Best Buy's mistake in Fortune Cookie wisdom:
Customers would soon be faced with the prospect of finding and
distinguishing among, for example, Corel WordPerfect for Compaq Windows, Corel
WordPerfect for Dell Windows and Corel WordPerfect for Gateway Windows (and for Sun
Windows and AOL Windows), each with varying capabilities reflecting the underlying
capabilities of the version of Windows to which they were written. Software innovation
would slow as ISVs devoted greater resources to (i) duplicating functionality that Windows
might otherwise provide and (ii) testing many variations of their products to reflect
variations in the underlying operating systems.
Kind of like they have to with different versions of Windows today, right?
Customers ARE faced with the prospect of finding and distinguishing among, for example, Windows 95, Windows 98 and Windows 2000 (and for Windows NT 3.51 and Windows 4.0 and Windows XP and Windows Me), each with varying capabilities reflecting the underlying
capabilities of the version of Windows to which they were written. Software innovation
HAS SLOWED as ISVs devote greater resources to (i) duplicating functionality that Windows might otherwise provide and (ii) testing many variations of their products to reflect
variations in the underlying operating systems.
What a jerk! He makes money off of doing what he says is bad for the industry! Doesn't anyone recognize this hypocrisy?
I agree with this assesment. I got a Masters in Computer Science from the University of Minnesota, and one of the courses I took was from the Psychology Department, named "The Psychology of Human / Computer Interactions," and the course was EXCELLENT. I don't know that they really offer much to students, after this course, but the one I had was great!
Check out Confluence, which is another cool project involving digital images and geographic locations. Their goal is to take a photo at every confluence point - an intersection of integer longitude and latitude points. Very fun, very cool.
This is a cool map, showing where they have photos, and is fully navigable.
Why must a framebuffer only contain "completed frames"?
The proposed OpenGL 2.0 specification supports more arbitrary blending modes under the title "Frame Buffer Operations". By their definition, the framebuffer does not only store "completed frames," so your definition of framerate is incorrect.
Why are the intricacies of the internal rendering procedure irrelevant? I thought that's what we were talking about. If you want to pretend that rendering is a black box, and then magically an image is painted on the screen, feel free - but don't pretend you understand "framerate."
Maybe you're correct - maybe I should use the term "render rate" to refer to partially-completed frames per second. But I can't understand why you'd even _hint_ that more "render rate" isn't better.
Motion blur is accomplished by rendering multiple frames, and then combining them. One method of anti-aliasing is to render multiple jittered frames, and then to combine them. Soft shadows can be done the same - multiple renderings with jittered light sources, and then combining them.
The rate of preparing frames and the rate of displaying frames are related, but saying that additional framerate beyond the refresh rate "makes ZERO difference" is incorrect.
Also, my latency point holds quite well. Framerate is the rate at which you may draw frames, wouldn't you agree? If you have an increased framerate, you may either draw more frames than you render (which is foolish, unless you combine them, somehow - as in motion blur, anti-aliasing, soft shadows), or you can simply delay drawing the frame until the last possible instant before you need it. Doing so will decrease the perceived latency, especially if you have a higher sampling rate for your input devices than your refresh rate on your display - which I believe is quite possible with USB mice, and I'm certain it's possible with firewire devices.
To borrow an analogy, framerate is the speed of your car. If you only intend on driving a certain overall speed (a given refresh rate), there are other ways you can use that extra speed. You can travel a greater overall distance (motion blur, multiple rendering passes, anti-aliasing, soft shadows), or you can simply leave later and still arrive on time (for decreased latency.)
By the way, I'd like to analyze your term, "power for more visual quality"; "Power" is the rate of doing work. Therefore it sounds to me like what you're describing is "framerate," the rate of doing the work of preparing images. My analysis is that you're saying that "higher framerate is better," which was my original point.
If you can render the entire image in the 1/700th of a second before the screen refresh, you can much more accurately track events than if it took you 1/60th of a second to render the image. USB mice allow a much higher sampling rate that you could take advantage of, for instance. When you incorporate things like motion-tracking polhemus devices, and a head-mounted display, things get really interesting.
It's not an either-or proposition. You go after both. People who facilitate breaking the law are also known as "accomplices".
If it is within your power to prevent someone from breaking the law, and it poses no risk to you to do so, I would say that you are ethically obligated to do so. IANAL, so I don't know if you're legally obligated to do so.
I stand disappointed. =( You've certainly used enough jargon to convince me that you're right - plus what you've said just makes sense.
My only real point was that from the standpoint of raw ingredients going in to a reaction, nothing that we know of is more powerful than anti-matter. If you have to pick one fuel to bring along with you on your spaceship - it's going to be anti-matter. (The other half of the reaction is just matter, and that's everywhere!)
Re:Accessibility: suddenly it's a priority...
on
GNOME 2.0 Beta
·
· Score: 3, Informative
There have been previous slashdot articles on unique keyboards. I might investigate a Twiddler from HandKey corporation if I were you (if you can use your fingers freely, but you can't flex at the wrist).
Also, there was a reference to a keyboard that was two pucks that each moved in one of eight direction (64-possibilities) that you could use without fingers! If you can't flex fingers or your wrists, this keyboard might work for you, as it works largely on shoulder and elbow movements.
I'm trying to figure out what having broken wrists would mean. Do you have full use of your fingers, but you can't flex at your wrists? Do you just get to type with a couple fingers? How are you typing?
Also (of course), you could investigate voice recognition systems. Dragon Naturally Speaking (I think that's what it's called) has an entry-level system for about $100.
If any of these sound interesting to you, and you want help digging up further information on them, feel free to ask me. Just tell me which ones to look into for you.
I believe a correct interpretation would be to say that in detonating an anti-matter explosion, it's theoretically possible to get out exactly twice as much as you put into it.
It's like by making one anti-particle, you've instantly turned it and one normal particle into an atomic bomb.
E = (m + anti-m) * c^2
That's part of the joy of anti-matter engines. They're maximally efficient in using their fuel. You only have to bring half of your fuel with you! You can scoop up free hydrogen as you go along.
That's just amazing! Let's test it. Here's an idea of a pretty good test :
I'll prepare 257 files containing random data, which are each 100 bytes in length. Then, they'll be able to compress each of those files into a corresponding lossless compressed file which is one byte long! (Remember, this is supposedly 100:1 lossless compression of random data.)
Oh, wait a sec... How can they possibly represent 257 different files, with only one byte each? That one byte can only represent 256 different possible values!
What about if the files that I asked them to compress were only 2 bytes in length, instead of 100 bytes in length? Still, 257 of them. Since they claim to be able to do 100:1 lossless compression of random data, they should be able to do 2:1 lossless compression of random data. I mean, that's 50 times less impressive! But, wait... They still have to express 257 different files with only 256 different possible values!
Huh... How many different files are 2-bytes long? I guess there's 65,536 of them. I only wanted them to compress 257 different files each into a byte. The task of compressing 65,536 different files into one byte is almost 256 times harder than what they already can't do!
This is starting to sound like a theorem, or something!
There was a HUGE difference between midnight and 4am, from my viewing location, west of Minneapolis. Almost no comparrison. I was with four other people who eventually fell asleep, and I woke them up at about 3:45, because the show was getting so good. No one fell asleep after that. It was amazing - the count was so much higher, and we saw several bolides - huge flashes, lingering tails probably 6 times in the 4:00 hour. I happened to miss the first bolide of the evening, I stood up, and looked down, just in time to miss it - but the ground was all lit up. It looked like someone had taken a picture - that's how bright it was. Nothing like that, previous to the 4:00 hour! In fact, we saw a bright one - right after dawn. Pretty amazing, when you can beat the light of the SUN. =)
I fear that one day, you may get the retribution you deserve for mocking the pain of others.
Have you never felt pain, such that you can now ignore the pain of others?
The buildings did move on impact
on
More WTC News
·
· Score: 2
A survivor from Tower 2 reported that on about the 40th floor, the building jumped about two feet, knocking many people out of their shoes, when the second plane struck.
Slashdot Mirror
Thanks for pointing this out - I knew I should have been more clear. If I have an element, and I want to remove it from a vector, I have to write a bunch of code. I have to find it first, make sure I actually found an element, and THEN I can erase it. This means I either keep a local copy of the iterator, or I call the find_first algorithm twice.
It's kind of like the hoops you have to jump through to do a case-insensitive compare on strings.
I really don't like functors. If people aren't careful, they end up implementing the same functor in multiple locations. I think the method paradigm is much better, because they're tightly coupled with the class that they act on. Functors can live just about anywhere - and you can end up with duplicated effort (ie bugs), once a project gets large enough.
Also, I dislike the fact that some STL functions will return "npos" and some "::end()" to indicate "no results".
Again, that's just my opinion - I could be wrong.
This brings up an interesting question for me.
/FIRST/ 1:30 AM, or the /SECOND/ 1:30 AM, when Daylight Savings Time hits?
How the hell do people cope with Daylight Savings Time? How do you indicate whether 1:30 AM is the
Before you listen to any of us, go out and buy "Effective STL" by Scott Meyers, and probably "The C++ Standard Template Library" by Nicolai M. Josuttis.
Now, I don't want to get off on a rant here, but in my personal opinion, the worst thing about STL is their string support. It's great, because it's standardized, but that's about the only thing going for it, from a programmer's perspective. (Yes, it's highly optimized, but the API isn't very rich. I like rich APIs!) In other words, build your own string class, and give it a Has-A relationship to the STL string.
Also, I hate that Containers change paradigms on you, some places you can use integer indecies, sometimes you have to use iterators - and in my opinion, the line isn't very clearly drawn.
Also, the methods are written along the lines of, "if it's not optimal, you have to write the code yourself." I'm sorry - that sucks. Sometimes I need to remove an element from a Vector. Maybe I should be using another Container. Or maybe the API should allow it, but make it clear in the documentation that it's not efficient. I vote for the latter.
Get used to having your objects copied. STL Containers work by copying your objects. It's a different way of thinking for a lot of people. It has rammifications that are kind of hard to grasp, at first, if you're not used to it.
Don't use Containers of AutoPtr's! It won't work right! (Read "Effective STL" for an explanation.)
In my opinion, everyone should wrap every third-party library they use with an API that they can live with. STL is no exception. You might even expose every single member function, but you have the freedom to expand your API if you want. If you can't afford a stack push, then you probably shouldn't be using STL in the first place.
If you end up really liking STL, take a look at Boost. Some parts of Boost are really cool and well written.
Really, I think the best advice I can give is this : get to really know an API before you start to use it. Because, if you try to just use the parts of an API that you know and like, you're going to make horrible mistakes. Invest the time to get to know the library well enough to use it the right way. STL is no exception.
Of course, that's just my opinion, I could be wrong.
The algorithm has nothing to do with the transmition medium.
If you want to make a One Time Pad that's long enough, you are free to disguise the length of a message by padding your text with 0s. This is essentially "wasting" your pad, but if you're really concerned about the length of your message being revealed, you are free to obscure it and make it seem artificially larger. (You can't make it artificially smaller, unless you somehow compress your message before you encrypt it.)
And you can hide the fact that a message has been sent by using any steganographic method you chose. Just as you can with any other encryption algorithm.
Don't confuse the algorithm with the transmition medium.
When does this cross the line to bait-and-switch, which is illegal?
:
I think it's a pretty fine line, not a blatant misunderstanding on the part of the poster. Don't be so critical - there's a real issue at stake, here.
Or, to sum up Best Buy's mistake in Fortune Cookie wisdom
Measure twice, cut once.
Kind of like they have to with different versions of Windows today, right?
Customers ARE faced with the prospect of finding and distinguishing among, for example, Windows 95, Windows 98 and Windows 2000 (and for Windows NT 3.51 and Windows 4.0 and Windows XP and Windows Me), each with varying capabilities reflecting the underlying capabilities of the version of Windows to which they were written. Software innovation HAS SLOWED as ISVs devote greater resources to (i) duplicating functionality that Windows might otherwise provide and (ii) testing many variations of their products to reflect variations in the underlying operating systems.
What a jerk! He makes money off of doing what he says is bad for the industry! Doesn't anyone recognize this hypocrisy?
What openMosix was openMosix the openMosix name openMosix of openMosix that openMosix project openMosix again?
I agree with this assesment. I got a Masters in Computer Science from the University of Minnesota, and one of the courses I took was from the Psychology Department, named "The Psychology of Human / Computer Interactions," and the course was EXCELLENT. I don't know that they really offer much to students, after this course, but the one I had was great!
Check out Confluence, which is another cool project involving digital images and geographic locations. Their goal is to take a photo at every confluence point - an intersection of integer longitude and latitude points. Very fun, very cool.
This is a cool map, showing where they have photos, and is fully navigable.
You should definately check out Confluence.org. Here's one of their great pictures : world map.
Why must a framebuffer only contain "completed frames"?
The proposed OpenGL 2.0 specification supports more arbitrary blending modes under the title "Frame Buffer Operations". By their definition, the framebuffer does not only store "completed frames," so your definition of framerate is incorrect.
Why are the intricacies of the internal rendering procedure irrelevant? I thought that's what we were talking about. If you want to pretend that rendering is a black box, and then magically an image is painted on the screen, feel free - but don't pretend you understand "framerate."
Maybe you're correct - maybe I should use the term "render rate" to refer to partially-completed frames per second. But I can't understand why you'd even _hint_ that more "render rate" isn't better.
Motion blur is accomplished by rendering multiple frames, and then combining them. One method of anti-aliasing is to render multiple jittered frames, and then to combine them. Soft shadows can be done the same - multiple renderings with jittered light sources, and then combining them.
The rate of preparing frames and the rate of displaying frames are related, but saying that additional framerate beyond the refresh rate "makes ZERO difference" is incorrect.
Also, my latency point holds quite well. Framerate is the rate at which you may draw frames, wouldn't you agree? If you have an increased framerate, you may either draw more frames than you render (which is foolish, unless you combine them, somehow - as in motion blur, anti-aliasing, soft shadows), or you can simply delay drawing the frame until the last possible instant before you need it. Doing so will decrease the perceived latency, especially if you have a higher sampling rate for your input devices than your refresh rate on your display - which I believe is quite possible with USB mice, and I'm certain it's possible with firewire devices.
To borrow an analogy, framerate is the speed of your car. If you only intend on driving a certain overall speed (a given refresh rate), there are other ways you can use that extra speed. You can travel a greater overall distance (motion blur, multiple rendering passes, anti-aliasing, soft shadows), or you can simply leave later and still arrive on time (for decreased latency.)
By the way, I'd like to analyze your term, "power for more visual quality"; "Power" is the rate of doing work. Therefore it sounds to me like what you're describing is "framerate," the rate of doing the work of preparing images. My analysis is that you're saying that "higher framerate is better," which was my original point.
If you can render the entire image in the 1/700th of a second before the screen refresh, you can much more accurately track events than if it took you 1/60th of a second to render the image. USB mice allow a much higher sampling rate that you could take advantage of, for instance. When you incorporate things like motion-tracking polhemus devices, and a head-mounted display, things get really interesting.
"Motion blur".
Or how about "rendering passes"?
Or how about "anti-aliasing"? (Kind of cheating on that one.)
Or how about "soft shadows"?
In short, more is better. If you give me higher framerate, I'll figure out what to do with those extra cycles.
Apparently Kevin "Mr. Subliminal" Nealon from Saturday Night Live was a consultant on the User Interface for Windows XP.
Either that or Windows XP has Tourette's Syndrome.
It's not an either-or proposition. You go after both. People who facilitate breaking the law are also known as "accomplices".
If it is within your power to prevent someone from breaking the law, and it poses no risk to you to do so, I would say that you are ethically obligated to do so. IANAL, so I don't know if you're legally obligated to do so.
I stand disappointed. =( You've certainly used enough jargon to convince me that you're right - plus what you've said just makes sense.
My only real point was that from the standpoint of raw ingredients going in to a reaction, nothing that we know of is more powerful than anti-matter. If you have to pick one fuel to bring along with you on your spaceship - it's going to be anti-matter. (The other half of the reaction is just matter, and that's everywhere!)
There have been previous slashdot articles on unique keyboards. I might investigate a Twiddler from HandKey corporation if I were you (if you can use your fingers freely, but you can't flex at the wrist).
Also, there was a reference to a keyboard that was two pucks that each moved in one of eight direction (64-possibilities) that you could use without fingers! If you can't flex fingers or your wrists, this keyboard might work for you, as it works largely on shoulder and elbow movements.
I'm trying to figure out what having broken wrists would mean. Do you have full use of your fingers, but you can't flex at your wrists? Do you just get to type with a couple fingers? How are you typing?
Also (of course), you could investigate voice recognition systems. Dragon Naturally Speaking (I think that's what it's called) has an entry-level system for about $100.
If any of these sound interesting to you, and you want help digging up further information on them, feel free to ask me. Just tell me which ones to look into for you.
This is somewhat of a mis-interpretation.
I believe a correct interpretation would be to say that in detonating an anti-matter explosion, it's theoretically possible to get out exactly twice as much as you put into it.
It's like by making one anti-particle, you've instantly turned it and one normal particle into an atomic bomb.
E = (m + anti-m) * c^2
That's part of the joy of anti-matter engines. They're maximally efficient in using their fuel. You only have to bring half of your fuel with you! You can scoop up free hydrogen as you go along.
That's just amazing! Let's test it. Here's an idea of a pretty good test :
I'll prepare 257 files containing random data, which are each 100 bytes in length. Then, they'll be able to compress each of those files into a corresponding lossless compressed file which is one byte long! (Remember, this is supposedly 100:1 lossless compression of random data.)
Oh, wait a sec... How can they possibly represent 257 different files, with only one byte each? That one byte can only represent 256 different possible values!
What about if the files that I asked them to compress were only 2 bytes in length, instead of 100 bytes in length? Still, 257 of them. Since they claim to be able to do 100:1 lossless compression of random data, they should be able to do 2:1 lossless compression of random data. I mean, that's 50 times less impressive! But, wait... They still have to express 257 different files with only 256 different possible values!
Huh... How many different files are 2-bytes long? I guess there's 65,536 of them. I only wanted them to compress 257 different files each into a byte. The task of compressing 65,536 different files into one byte is almost 256 times harder than what they already can't do!
This is starting to sound like a theorem, or something!
We've been looking for you for quite some time now, Mr. Baggins.
-Agent Elrond
NEWSFLASH :
Nerds like The Lord of the Rings movie.
There was a HUGE difference between midnight and 4am, from my viewing location, west of Minneapolis. Almost no comparrison. I was with four other people who eventually fell asleep, and I woke them up at about 3:45, because the show was getting so good. No one fell asleep after that. It was amazing - the count was so much higher, and we saw several bolides - huge flashes, lingering tails probably 6 times in the 4:00 hour. I happened to miss the first bolide of the evening, I stood up, and looked down, just in time to miss it - but the ground was all lit up. It looked like someone had taken a picture - that's how bright it was. Nothing like that, previous to the 4:00 hour! In fact, we saw a bright one - right after dawn. Pretty amazing, when you can beat the light of the SUN. =)
I fear that one day, you may get the retribution you deserve for mocking the pain of others.
Have you never felt pain, such that you can now ignore the pain of others?
A survivor from Tower 2 reported that on about the 40th floor, the building jumped about two feet, knocking many people out of their shoes, when the second plane struck.