Wow, I'm not sure if you did it intentially, but you linked to the C++ FQA, *not* the C++ FAQ. I'll assume from context that's what you meant, and just labeled it wrong.
Do you mean Fritos??? (Seriously, what do you mean?)
Re:I've been using vi for so long...
on
The Birth of vi
·
· Score: 1
Perhaps, but my point was back then I didn't know enough to do that. I had been taught the minimal 'vi' basics, which was generally "use:wq to write and quit." I never even thought about:w!q versus:wq!, as I always did that in two steps.
Believe me I'm a wiz at Emacs, and I always thought 'vi' came up well short, but I'm REALLY enjoying learning vim. To me, it is that big an improvement over vi (and possibly over emacs, once I master it)...
Re:I've been using vi for so long...
on
The Birth of vi
·
· Score: 1
I've used Emacs for 20 years, and only ever learned enough vi to barely get by (a few simple editing commands and:wq). Now I'm in the process of switching completely to VIM. I really like it, as it has many of the great things I loved about Emacs (split windows with multiple buffers, command and file completion, unlimited undo, etc.).
However, I had to remap some keys to make it less painful. Specifically, I swapped the TAB and ESC keys when in insert mode, and swapped the CTRL and CAPSLOCK keys on my keyboard mapping. Now I have CTRL in the proper place (left of 'A'), the ESC key is just above it when I need it most (to enter command mode).
The CTRL/CAPSLOCK swap is done in various ways on different OS's (Mac has it as a preferences toggle), and my ~/.vimrc has these two lines to swap TAB/ESC only when in insert mode:
I've heard of those techniques, and they can actually be quite secure I believe (assuming the shared secret is sufficiently unguessable). Keep in mind the reason it is so effective, is because nothing is broadcast.
Hmmm, so you are suggesting a rather novel form of cryptography, in which the secret (ie. the key) is broadcast in the clear. Interesting... But totally insecure, and thus probably not worth the effort that long distance radio broadcasting requires.
Since the starting value is passed as an argument, and is a float (not a union), you would have to do a little extra work to define the passed in argument as part of a union (semantically). In the end, it is probably not worth it.
If you knew your compiler could pass values by register (rather than on the stack), it might conceivably save a copy or two by avoiding use of the address-of operator. At that point, though, you would probably just write the function in assembly language.
Think of the magic value as actually two magic values stuck together. One part chosen to fix up the exponent part of the float, and one part to help fix up the mantissa part of the float.
The right shift reduces the mantissa by two (effectively an approximate square root of the value). The magic value is chosen so that the exponent is always made negative. Thus, the shift performs a sort-of square root, and the subtraction performs a sort-of inversion of the square root.
If a '1' bit is shifted into the mantissa, that effectively increases the value of the mantissa by 1/2. That can be compensated for, somewhat, by choosing a magic number that sometimes forces a borrow from the exponent bit during the subtraction, thus reducing the exponent bits by one, and reducing the resulting float value by half. But sometimes the mantissa part is not increased by half (ie. a zero bit is shifted in from the exponent bits). Basically, you need to do an optimization in order to find what value for the mantissa bits is best (ie. gives the best approximation over all possible cases). The analysis is a bit hairy (and discussed in the pdf linked to by others), but doable.
In the end, you convert back to a float, which is a pretty good starting point (the main effect being the exponent value of the input argument has been halved and negated), and use that for one iteration of Newton-Raphson square root approximation. Newton-Raphson is highly sensitive to the starting point (ie. it works much better and faster with a good first guess), which makes the integer shift-and-subtract step so valuable.
Here is a discussion of a related method that is used for (non inverted) square roots:
Well the "new" data that made the Thiokol engineers (not NASA engineers, BTW) say it was unsafe to fly was the weather report which said Florida was going to have freezing temperatures over the night. It was the fact that NASA wanted to launch on a day that was FAR colder than any previous shuttle launches, that made those engineers have their "eleventh hour" call to not launch.
Unfortunately, their reasons were mainly intuitive ones (as opposed to hard data saying the O-Rings had been tested at those cold temperatures, and they were likely to fail), and the hasty presentation by the engineers, to both Thiokol and NASA management, was uncompelling. In fact, famously, it was NASA management that convinced the Thiokol management to ignore their own engineers intuition, based on a perceived lack of evidence.
He said "digital", not "binary". Digital implies digits, or numbers, however they are encoded. Much like ASCII is a mapping of 7-bit numbers to a set of symbols, each unique set of dots, dashes, and pauses represent a unique codeword mapped to a symbol.
That said, I think calling Morse code "digital" is a bit of a stretch; you could maybe also say it is a pulse-width-modulated analog signal that is temporally encoded, or some such thing. If it was truly digital, you could do checksums on it (directly); anyway, it may be open for debate, although I'd be happy to be convinced by someone.
Not sure I see how the Hillary quote (to tax well-off people, not "average" people), supports the "Democrats are faux-compassionate" assertion, but whatever. Both parties are fucking us.
Democrats will raise taxes, borrow money, and spend it all. Republicans have cut taxes, continue to borrow shitloads of money, and spend it all. Either way, neither party has the guts to truly spend less and deal with the political consequences that will bring. Meanwhile, we better hope our credit holds...
Linus (famously) released his code under GPL v2 only, with no implicit option to relicense to later versions. Other individual contributors may have chosen (or choose) to release for later licenses, but in general, licensing the whole thing under a later version would be a pain, or impossible. Only a fool (like, perhaps, Jeff Merkey) would even attempt it...
But the marginal benefit to go from 4GB to 60GB is very small
No way. Uh uh. There is a HUGE benefit going from 4Gb to 60GB, for a lot of people. I can fit all my music (barely) on a 60GB, which means when I travel I just pop my iPod into my backpack. I needn't worry about what subset of music I'm bringing. And, since I am never sure what music mood I'll be in, it does matter. (Why do I feel like Banky, from Chasing Amy?)
I just got a T-Mobile Motorola V360 and mine does NOT sync with my Mac using iSync. There are some hacks to get it mostly working (Basically is just involves copying the specs of a similar phone, putting the right model number in, and adding it to a file that contains all the iSync specs), and I'm hoping OS X 10.4.4 will make it work. But, at least for me, it didn't iSync right out of the box (as of 10.4.3). Otherwise a pretty good phone (and much more comfortable than the RAZR, IMO).
Either way we're not talking about Blu-Ray-RW yet, so how does capacity help?
If you mean to say that Blu-Ray doesn't yet record, then you are (apparently) wrong. The format supports write-once and rewritable use, and recorders will be available at the same time, or not long after players.
The flip side is that subscription cable channels like HBO, or subscription digital radio, are not driven by commercials, and so are arguably better geared towards giving you (the customer) what you would like to see. "Free" services, like broadcast TV or radio are geared towards giving their advertisers (their customers) what they want (your eyes and ears).
You ARE correct that the recurrant cost for "basic" CABLE which is mostly simulcast of broadcast TV, breaks that model a little. It would perhaps have been nice to only pay a one time installation fee to receive it (like with a Sirius or XM receiver), but that one time fee would most likely have been pretty hefty.
Forgive the reply to myself, but just to clarify: Yes, if you have 0.5 then you probably don't need to round it further. 0.5 is a convenience value to illustrate the concept of rounding. But what if, after some floating point operation, the "5" is just beyond the last digit of what can be stored in a floating point value? Now you DO have round it. After all operations are done, then you may round further, in order to display or store a number with less precision for convenience.
There ARE systems that can do math directly with rational numbers, with arbitrary precision, thus reducing the need for some of the per operation rounding (or at least further reducing the impact of that rounding), but that is not the kind of quick arithmetic that typical 32 or 64 bits-per-value CPUs provide. For speed, you accept the need to round, and try to understand the consequences to your application.
Ah, but what if you have 0.49999999999999999999999999999999999999999999999, or any other number that just can't fit exactly into an n-bit floating or fixed point system? At that point, you are forced to do some kind of rounding, giving you a small error, and those small errors accumulate as the number of arithmetic operations increase.
Yes, for certain types of numerical problems, there is a bounded precision, or set of values, for which you could create a specialized counting system (ie. many financial problems are more amenable to fixed point operations); for most everything else, there is floating point, hence non-exact numerical representations, hence rounding (at EACH operation!).
I wish I knew which commentary talked about it, but it was basically Al Jean (or someone) saying that they FINALLY switched over fully to "digital" production. I think it was somewhere on the fourth season DVDs. So while what you said apparently was true, I'm guessing as of around 2003 or so (my estimate for when the commentary was recorded), it may no longer be the case. Clearly my recollection is not definitive, but disregarding dates, I think the gist is accurate (that they recently, finally, went to fully digital production).
The Simpsons is now an all digital production, according to the DVD commentary. It may involve "hand drawing", but that either means hand drawing immediately scanned into a computer (for cleanup and coloring), or drawing on a tablet, etc. that goes directly into a computer. I don't know what software is used, but I haven't searched either.
Slashdot Mirror
"I personally call Steam a fare deal." Ha ha! That's an awesome unintentional mispelling....
Its factoring *composites* of 2 large primes that is hard! Fuck Bill Gates and that stupid quote of his, he's totally fubared public key discussions.
Wow, I'm not sure if you did it intentially, but you linked to the C++ FQA, *not* the C++ FAQ. I'll assume from context that's what you meant, and just labeled it wrong.
In any case, both are very useful reads:
http://codemines.blogspot.com/2007/10/no-updates-for-6-months-then-two-in-day.html
http://www.parashift.com/c++-faq-lite/
http://yosefk.com/c++fqa/index.html
A "googol" years... Not "Google" years.
Do you mean Fritos??? (Seriously, what do you mean?)
Perhaps, but my point was back then I didn't know enough to do that. I had been taught the minimal 'vi' basics, which was generally "use :wq to write and quit." I never even thought about :w!q versus :wq!, as I always did that in two steps.
Believe me I'm a wiz at Emacs, and I always thought 'vi' came up well short, but I'm REALLY enjoying learning vim. To me, it is that big an improvement over vi (and possibly over emacs, once I master it)...
However, I had to remap some keys to make it less painful. Specifically, I swapped the TAB and ESC keys when in insert mode, and swapped the CTRL and CAPSLOCK keys on my keyboard mapping. Now I have CTRL in the proper place (left of 'A'), the ESC key is just above it when I need it most (to enter command mode).
The CTRL/CAPSLOCK swap is done in various ways on different OS's (Mac has it as a preferences toggle), and my ~/.vimrc has these two lines to swap TAB/ESC only when in insert mode: For some more VIM tips on dealing with weird ESC placement, see here:
http://vim.sourceforge.net/tips/tip.php?tip_id=28
As a longtime Emacs user, I think VIM really is worth learning. It is useful to be proficient in both.
I've heard of those techniques, and they can actually be quite secure I believe (assuming the shared secret is sufficiently unguessable). Keep in mind the reason it is so effective, is because nothing is broadcast.
Hmmm, so you are suggesting a rather novel form of cryptography, in which the secret (ie. the key) is broadcast in the clear. Interesting... But totally insecure, and thus probably not worth the effort that long distance radio broadcasting requires.
Since the starting value is passed as an argument, and is a float (not a union), you would have to do a little extra work to define the passed in argument as part of a union (semantically). In the end, it is probably not worth it.
If you knew your compiler could pass values by register (rather than on the stack), it might conceivably save a copy or two by avoiding use of the address-of operator. At that point, though, you would probably just write the function in assembly language.
Think of the magic value as actually two magic values stuck together. One part chosen to fix up the exponent part of the float, and one part to help fix up the mantissa part of the float.
_ square_roots#Approximations_that_depend_on_IEEE_re presentation
The right shift reduces the mantissa by two (effectively an approximate square root of the value). The magic value is chosen so that the exponent is always made negative. Thus, the shift performs a sort-of square root, and the subtraction performs a sort-of inversion of the square root.
If a '1' bit is shifted into the mantissa, that effectively increases the value of the mantissa by 1/2. That can be compensated for, somewhat, by choosing a magic number that sometimes forces a borrow from the exponent bit during the subtraction, thus reducing the exponent bits by one, and reducing the resulting float value by half. But sometimes the mantissa part is not increased by half (ie. a zero bit is shifted in from the exponent bits). Basically, you need to do an optimization in order to find what value for the mantissa bits is best (ie. gives the best approximation over all possible cases). The analysis is a bit hairy (and discussed in the pdf linked to by others), but doable.
In the end, you convert back to a float, which is a pretty good starting point (the main effect being the exponent value of the input argument has been halved and negated), and use that for one iteration of Newton-Raphson square root approximation. Newton-Raphson is highly sensitive to the starting point (ie. it works much better and faster with a good first guess), which makes the integer shift-and-subtract step so valuable.
Here is a discussion of a related method that is used for (non inverted) square roots:
http://en.wikipedia.org/wiki/Methods_of_computing
Well the "new" data that made the Thiokol engineers (not NASA engineers, BTW) say it was unsafe to fly was the weather report which said Florida was going to have freezing temperatures over the night. It was the fact that NASA wanted to launch on a day that was FAR colder than any previous shuttle launches, that made those engineers have their "eleventh hour" call to not launch.
Unfortunately, their reasons were mainly intuitive ones (as opposed to hard data saying the O-Rings had been tested at those cold temperatures, and they were likely to fail), and the hasty presentation by the engineers, to both Thiokol and NASA management, was uncompelling. In fact, famously, it was NASA management that convinced the Thiokol management to ignore their own engineers intuition, based on a perceived lack of evidence.
Ah, you are correct, and I apologize.
He said "digital", not "binary". Digital implies digits, or numbers, however they are encoded. Much like ASCII is a mapping of 7-bit numbers to a set of symbols, each unique set of dots, dashes, and pauses represent a unique codeword mapped to a symbol.
That said, I think calling Morse code "digital" is a bit of a stretch; you could maybe also say it is a pulse-width-modulated analog signal that is temporally encoded, or some such thing. If it was truly digital, you could do checksums on it (directly); anyway, it may be open for debate, although I'd be happy to be convinced by someone.
Not sure I see how the Hillary quote (to tax well-off people, not "average" people), supports the "Democrats are faux-compassionate" assertion, but whatever. Both parties are fucking us.
Democrats will raise taxes, borrow money, and spend it all. Republicans have cut taxes, continue to borrow shitloads of money, and spend it all. Either way, neither party has the guts to truly spend less and deal with the political consequences that will bring. Meanwhile, we better hope our credit holds...
RTFA
Linus (famously) released his code under GPL v2 only, with no implicit option to relicense to later versions. Other individual contributors may have chosen (or choose) to release for later licenses, but in general, licensing the whole thing under a later version would be a pain, or impossible. Only a fool (like, perhaps, Jeff Merkey) would even attempt it...
No way. Uh uh. There is a HUGE benefit going from 4Gb to 60GB, for a lot of people. I can fit all my music (barely) on a 60GB, which means when I travel I just pop my iPod into my backpack. I needn't worry about what subset of music I'm bringing. And, since I am never sure what music mood I'll be in, it does matter. (Why do I feel like Banky, from Chasing Amy?)
I like to refer to him as "Gutter-Boll".
I just got a T-Mobile Motorola V360 and mine does NOT sync with my Mac using iSync. There are some hacks to get it mostly working (Basically is just involves copying the specs of a similar phone, putting the right model number in, and adding it to a file that contains all the iSync specs), and I'm hoping OS X 10.4.4 will make it work. But, at least for me, it didn't iSync right out of the box (as of 10.4.3). Otherwise a pretty good phone (and much more comfortable than the RAZR, IMO).
If you mean to say that Blu-Ray doesn't yet record, then you are (apparently) wrong. The format supports write-once and rewritable use, and recorders will be available at the same time, or not long after players.
http://www.blu-ray.com/faq/
The flip side is that subscription cable channels like HBO, or subscription digital radio, are not driven by commercials, and so are arguably better geared towards giving you (the customer) what you would like to see. "Free" services, like broadcast TV or radio are geared towards giving their advertisers (their customers) what they want (your eyes and ears).
You ARE correct that the recurrant cost for "basic" CABLE which is mostly simulcast of broadcast TV, breaks that model a little. It would perhaps have been nice to only pay a one time installation fee to receive it (like with a Sirius or XM receiver), but that one time fee would most likely have been pretty hefty.
Forgive the reply to myself, but just to clarify: Yes, if you have 0.5 then you probably don't need to round it further. 0.5 is a convenience value to illustrate the concept of rounding. But what if, after some floating point operation, the "5" is just beyond the last digit of what can be stored in a floating point value? Now you DO have round it. After all operations are done, then you may round further, in order to display or store a number with less precision for convenience.
There ARE systems that can do math directly with rational numbers, with arbitrary precision, thus reducing the need for some of the per operation rounding (or at least further reducing the impact of that rounding), but that is not the kind of quick arithmetic that typical 32 or 64 bits-per-value CPUs provide. For speed, you accept the need to round, and try to understand the consequences to your application.
Ah, but what if you have 0.49999999999999999999999999999999999999999999999, or any other number that just can't fit exactly into an n-bit floating or fixed point system? At that point, you are forced to do some kind of rounding, giving you a small error, and those small errors accumulate as the number of arithmetic operations increase.
Yes, for certain types of numerical problems, there is a bounded precision, or set of values, for which you could create a specialized counting system (ie. many financial problems are more amenable to fixed point operations); for most everything else, there is floating point, hence non-exact numerical representations, hence rounding (at EACH operation!).
I wish I knew which commentary talked about it, but it was basically Al Jean (or someone) saying that they FINALLY switched over fully to "digital" production. I think it was somewhere on the fourth season DVDs. So while what you said apparently was true, I'm guessing as of around 2003 or so (my estimate for when the commentary was recorded), it may no longer be the case. Clearly my recollection is not definitive, but disregarding dates, I think the gist is accurate (that they recently, finally, went to fully digital production).
The Simpsons is now an all digital production, according to the DVD commentary. It may involve "hand drawing", but that either means hand drawing immediately scanned into a computer (for cleanup and coloring), or drawing on a tablet, etc. that goes directly into a computer. I don't know what software is used, but I haven't searched either.