> > While Microsoft was battling with Vista that is a dog slow and resource-hungry Apple it would seem was focusing on speed, performance and elegance.
> Since when have Microsoft OSs not been slow and resource-hungry? And when did Apple ever not prioritize elegance and performance?
It is absolutely and utterly moot that these things have been true for a while, if the positions of the involved companies positions one better to leverage this difference and positions the other to be more succeptible to this perception. THAT is the point.
> > The upcoming "Leopard" OS is expected to be even slicker and faster than its predecessor OS X.
> Careful - your fanboyism's showing.
You're right. Any reasonable person would expect the next OS X release to have features toned-down and removed and arbitrary wait-loops thrown in just to keep people guessing. Good thing you called him on that.
> > And with Macs running on Intel hardware, how long will it be before Mac OS "Leopard" or its successor spreads out into the PC realm?
> Erm, a long time. Apple needs to differentiate itself from Microsoft to retain its market share. Moving to an Intel architecture was a risky step, > as it deprived them of one of their major differentiating factors, PPC architecture.
I know everyone in our art department at work is thinking: "Let's keep buying Mac's. I love that they use that fabulous PPC architecture." The percentage of people that know or care about the underlying architecture of the hardward is barely measurable.
> The minute Apple runs on commodity PC hardware no-one has any reason to buy expensive Mac hardware, so they won't.
Few problems here. First, some people buy Mac hardware explicitly because it is more expensive and in their minds is of a higher quality. Second, you are assuming that there will be no "value-add" to running on Apple's hardware. Third, you are assuming that Mac hardware is and will continue to be "over priced" relative to some absurd benchmark such as the cheapest Dell machine you can rangle up.
> This takes Apple out of the hardware game, and makes them entirely reliant on software and iPods.
Yeah, that IS the question. Is it worth the risk for Apple to move to a more software-focused portfolio. I, myself, am unsure.
> Mac OS/X will then compete directly with Windows, and though it's faster, more stable and more secure, Windows has that whole 90%+ market > share thing going for it. Apple would be squished in short order.
That would be true of anyone who wished to compete with Microsoft. Is your point that this is impossible and no one should ever try?
And you are under the impression that that is what ID is?
Here's how this sounds to me:
OP: ID as commonly discussed and presented at trial is not science and shouldn't be taught in schools. You: But if you make ID mean this entirely different thing, then you are wrong. Me: And your point is?
Your left and right eyes can't always see the same set of objects.
If you use occluders and occluder volumes, then you run the risk of missing objects that were occluded from the view-point of the primary eye, but are not from the view-point of the secondary eye. So, you have to perform occlusion tests per eye or not use occluders at all.
You also run the obvious problem of objects "popping" in from the sides of your vision. There will be a moment when an object approaches from the side, into your peripheral vision, that the object is only visible from one eye. If this is your secondary eye, then I guess you'll miss it. When it is finally visible from your primary eye, it will suddenly "pop" into view. This problem can be fixed by performing your visibility tests from neither eye, but from an in-between eye with the view frustum scaled up to encompass both eye's frustums.
I just wanted to point out that this wasn't as easy as your made it sound. You can't just draw the primary eye, remember what objects you drew, and then draw them again from the secondary eye. Atleast, you can't do that if you want accurate results.
Okay, implementation-dependent things happen, so you might find yourself tied to Steel Bench for some reason... but if you can also target OpenMCL you'll find it has a kick-ass compiler as well as a fully preemptive thread scheduling model. ("[as of 0.14], lisp threads are native threads and all scheduling decisions involving them are made by the OS kernel. (Those decisions might involve scheduling multiple lisp threads simultaneously on multiple processors on SMP systems.)"
I am pretty familiar with OpenMCL. It is my primary Lisp environment. It just hit 1.0 too! However, I've never been able to get the speed of OpenMCL-compiled code to compare the SBCL-compiled code. Every now and then I find myself switching back to SBCL for that reason, as I do some hacking in my free-time that is numerically intensive.
As I understand it, SBCL's PPC implementation's blocking issue on native threading is a combination of the heap model, the existing stop-and-copy garbage collector, and fundamental differences in the dynamic linking of Mach-O and ELF (and COFF and a.out) binary formats. In particular, the x86 format and FFI and the ISA's small supply of registers to allow for register-to-register tagging and detagging, have driven a conservative collector.
Yeah, the GC port is the main hurdle. A second is that the current threading implementation relies on futexes, which are a Linux 2.6.x specific thing. So right now threads only work on Linux 2.6 on x86. It's easy enough to use pthreads rather than futexes, but unfortunately pthreads aren't relocatable in memory and futexes are, so you'd need to allocate your pthreads in non-gc'ed memory. So, now you need finalizers to clean them up. It just gets a little messy.
However, since we're talking about programming Lisp rather than implementing it, surely the important thing to do is to start writing maximally-portable Common Lisp, get everything to work, and then optimize sections for various implementations and platforms?
Naturally. Aside from a few unfortunately unportable things like Threads and Sockets all my Lisp is quite portable.
Speaking of portability... everyone should play with Fetter (formerly Verrazano) and CFFI. A few lines of code later and you've got all kinds of C or C++ libraries accessible from Lisp. I'm doing some hacking on some code using OpenGL, OpenAL and GLUT from OpenMCL right now. Fun fun!
They will almost invariable switch to the new Intel-based macs. I would say that most of them don't even know or care what chipset they are running on.
2. New OS X users.
These are people who will now be enticed to switch, because of the Intel move, that otherwise wouldn't have been. Perhaps they were waiting for the extra performance that Apple can offer in a laptop now that they have Intel processors. Perhaps they like that they can recompile their x86 specific programs on Macs now. (Yay! SBCL w/ Threading on OS X!? Dare I dream!?!?)
3. New Mac Hardware users (but not OS X)
This is the group you seem to be in. You want the Mac hardware, but don't care for the OS. I can't say I agree with you, but that's beside the point.
So, Apple will have all the people they have now (group 1), some new folks (group 2) and some additional hardware sales to people who are going to install Linux or Windows or BSD or something on the box (group 3).
Do you seiously believe that group 3 is big enough compared to the combined sizes of groups 1 and 2 that it will do anything other than add more to Apple's bottom-line? You aren't going to affect Apple's image unless group 3 is BIG or astonishingly well publisized.
Besides, even if group 3 were very large, we are talking about people who are buying the Hardware for the Hardware's sake. Because it's high-quality, attractive hardware. This could NEVER put them into direct competition with Dell. Dell is all about volumes. High volumes at low prices. Apple is EXACTLY the opposite. If Apple were buying the cheapest parts at the highest volumes to crank out machines as quickly and cheaply as possible, then group 3 wouldn't exist.
Well, those are my thoughts. You know the drill. Grain of sand and what-not.
I would say that your statement is as much a mischaracterization as any other I've heard.
IBM did not design the product. Lenovo did not design the product. They are companies. People designed the product. Those people were IBM employees while the product was being designed and those same people are Lenovo employees now that it's being shipped and supported.
It's basically this sentence that seems like non-sense to me: "Lenovo was simply in charge when it made it to market."
What does that mean to you? "In charge"? It's the same people. 1800 employees in RTP, NC that used to be IBM employees and are now Lenovo employees. Same deal with their other offices around the world including China and Japan.
I finally got around to finish the article. I loved number 8.
Goal:
"We wish to rotate an image, shrink it 50%, attach it to an e-mail and send it to a deaf musician."
Proposed solution:
"Say Tip a quarter to the right, crop by half and e-mail to Stevie Wonder."
Great. Except that cropping means cutting off the sides of an image, not scaling it. So, now you just sent the middle of an image to Stevie Wonder rather than the image at half-size.
Not only are screen corners the easiest to get to, they are the easiest to get to accidentally. I hit the screen corners all the time on the way to other things. So, they shouldn't do anything real invasive or complicated. Luckily, two of the four corners dont' do anything unless I click in them.
On a mac:
top-left: Apple menu. Yes, pixel (0, 0). Try it. top-right: Spotlight. Yes, pixel (w, 0). Try it.
On my mac, easily configuration through System Preferences.
bottom-left: Dashboard. weather, dictionary, phone book, man pages,.... bottom-right: Expose. All windws tiled on the screen.
These last two don't require a click, just the mouse hitting that corner. I trigger Dahsboard by mistake on a semi-regular basis. Kinda annoying. I never seem to hit the bottom-right accidentally though.
Either way, this seems to contradict the article, as top-left (Apple menu) includes system prefs, top-right is Spotlight which is definitly document relaed. bottom-left (Dashboard) is information related. bottom-right (Expose) is definitly document related.
Justin Dubs
Re:Boiling Point, Stupid!
on
How Ice Melts
·
· Score: 1
Thanks for the inforrmation/corrections. I'm more of a cook than a scientist at this point, it seems.:-)
Justin Dubs
Re:Boiling Point, Stupid!
on
How Ice Melts
·
· Score: 2, Informative
The key is that water has a high specific energy, so it can absorb a lot of energy without actually increasing in temperature. The other types of molecules in your gravy solution can happily be heated to over 212 degrees without boiling; only the water boils. As more and more water cooks out of the gravy, there becomes less water to absorb the energy through evaporation so the energy begins heating the remaining non-water liquid to a higher temperature than water's boiing point.
This is the entire methodology of fudge making. Create a sugar-water solution. Apply heat. It gets to 212 slowly. Water begins to evaporate. Sugar continues to heat, driving the temperature of the solution above 212 degrees. The less water there is the less resistance there is to moving above 212. At the appropriate temperature (235 degrees; soft ball stage) you remove the solution from the heat and let it cool. You now have fudge. Ideally you would also add corn syrup, chocolate, cream instead of water, butter and vanilla extract (at the end) to improve the flavor. And hopefully you would stir vigorously once it drops below 150 or so so that the sugar crystals that are created are as small as possible and your fudge has a smooth texture.:-)
Caramel is made in the same way. Heat the sugar-water solution to just before the burning point for sugar (around 350), add cream, boil for 3 minutes then cool. Youv'e got caramel!
This may be a theoritical truth (not that I'm conceding that), but it is certainly not a practical truth.
Example:
The number of possibly game states in the Go is over 10^150. Many orders of mangnitude higher than the number of atoms in the universe. The best Go playing computer is ranked around 5k or so, which would make it a relatively strong amateur.
Question:
Can you name something that you believe can not be explained mathematically? Do you have evidence for this? If not, then your first sentance could be accurately paraphrased as "Personally, I believe that computers, at this point, can beat mankind in anything."
Perhaps your bid gets spread out with a portion being divided proportionally over the critical bugs based on their severity and the rest being applied to the bug of your choice.
This would keep the severe problems at a higher dollar value than all but the most popular of feature requests...
Either make it 4 * pi * r^2 or make the answer 1/3 * pi * r^3...
Justin Dubs
That's not what car and cdr are for...
on
Practical Common Lisp
·
· Score: 4, Informative
That's probably not the right way to think about it. A cons cell is a data structure that holds a pair of items. The first is the car; the second is the cdr. The accessors for those parts of a cons cell also have the names car and cdr.
Linked lists are just one data structure that you can implement with cons cells. You can also implement a stack, queue, binary-tree, association-list, etc...
If your are using "cons cells" in your program, use car and cdr. If you are using lists that are implemented via cons cells use first and rest. If you are using a stack use push and pop. And so on...
Buy one of the ones with the "p" at the end of the model. The "p" means "performance." Either a T-series or an R-series will do. The R-series will give you more for less, but in a slightly bigger package. I use an R50p at work here (IBM in RTP). It's got a ATI FireGL 2 Mobility w/ 128MB of Video RAM.
I just finished playing Half-Life 2 on it, and I'm still playing Counter-Strike: Source. It works wonderfully. So, unless you can reconcile "very old" and "very sucky" with "just played Half-Life 2 at a good frame rate" I'm going to have to call shenanigans.
Sorry dude, but 1024 bits is 256 hex digits. Each hex digit represents one nibble, or one half-byte which is 4-bits. And, 1024 >> 2 is clearly 256.
Now, I notice you are listing them in groups of 4, which makes 64 groups of four. But, those groups aren't hexadecimal characters, they are hexadecimal words of 2-bytes in length.
10 here. i wrote a computer program to draw a sexy 3d version of it and let me move pieces by tapping the 1, 2 and 3 keys. after solving 4 or 5 discs a few times my fingers would get into this wierd zone where they'd just fly over those three keys without any conscious thought. very cool.
It is annoying that Gimp doesn't do CMYK, but why can't you manipulate all your images in Gimp as RGB, then use ImageMagick to convert to CMYK? Admittedly it's more of a hassle, but it's not the end of the world. It's worked for me.
LOL. Try reading some color theory. RGB and CMYK are different subsets of the full color spectrum. CMYK is almost a subset of RGB, but not quite. Each can display colors the other can not, with RGB having far more such colors than CMYK.
Nearly every print medium is printed using CMYK. Nearly every display medium uses RGB. Display mediums and print mediums have entirely different representational abilities. If you tone a picture well on a display, it won't come out quite right on print. If it's toned well on paper, it won't look quite right on the display.
The conversion from RGB to CMYK is lossy. The conversion from CMYK to RGB is also lossy. Both result in reduced image quality. And both would require retoning.
So, I'm afraid saying "convert to CMYK when you're done" just doesn't work out that well in practice. No newspaper will use a photo editing tool that doesn't support CMYK.
If by that you mean that it runs on hardware, then yes. It is dependent on you having a computer. It supports Windows on any supported platform. AMD or Intel. It supports any Mac capable of running OS X. Meaning, G3, G4 or G5.
If you mean iPod dependent then you are full of crap. Perhaps you haven't actually tried it?
> 2. Until recently it was Mac OS dependent too.
This is my favorite complaint. "They did it wrong cause it USED TO have a problem." Jesus, son.
> 3. Terms of licensing are high with the music > labels...recent articles suggest iMusic is a > loss-run enterprise intended to drive iPod sales > (see #1).
And your final complaint is based on an unfounded rumor...
Then put a separate copy of the original firmware into read-only memory at manufacturing time and provide a physical button that writes the known good firmware over the current firmware...
Shrink all visible applications to tiles on the desktop, allow the user to choose one, and then expand the applications back to their original sizes with the user chosen one on top?
Also, Expose doesn't resize windows, it scales them. In other words, the windows don't receive resize events because the aren't being resized. Instead, their presentation is being scaled by the vector graphics system in Quartz Extreme.
Have you ever actually used Tile Windows Horizontally? If so, have you ever actually seen or used Expose?
A "big" gun probably means it is of a large caliber in terms of the rounds that it fires and has nothing to do with physical size.
A "big" server has impressive hardware and again has nothing to do with size.
"Big" breasts are actually just more physically large.
However, even with the third meaning of physical size, it's degree will vary depending on whether it is applied to a star or a spoon. The difference between a big star and a regular star is much greater than that between a big spoon and a regular spoon. Unless it's one gigantic spoon. But, then it's gigantic and not big... or something.:-)
Slashdot Mirror
> > While Microsoft was battling with Vista that is a dog slow and resource-hungry Apple it would seem was focusing on speed, performance and elegance.
> Since when have Microsoft OSs not been slow and resource-hungry? And when did Apple ever not prioritize elegance and performance?
It is absolutely and utterly moot that these things have been true for a while, if the positions of the involved companies positions one better to leverage this difference and positions the other to be more succeptible to this perception. THAT is the point.
> > The upcoming "Leopard" OS is expected to be even slicker and faster than its predecessor OS X.
> Careful - your fanboyism's showing.
You're right. Any reasonable person would expect the next OS X release to have features toned-down and removed and arbitrary wait-loops thrown in just to keep people guessing. Good thing you called him on that.
> > And with Macs running on Intel hardware, how long will it be before Mac OS "Leopard" or its successor spreads out into the PC realm?
> Erm, a long time. Apple needs to differentiate itself from Microsoft to retain its market share. Moving to an Intel architecture was a risky step,
> as it deprived them of one of their major differentiating factors, PPC architecture.
I know everyone in our art department at work is thinking: "Let's keep buying Mac's. I love that they use that fabulous PPC architecture." The percentage of people that know or care about the underlying architecture of the hardward is barely measurable.
> The minute Apple runs on commodity PC hardware no-one has any reason to buy expensive Mac hardware, so they won't.
Few problems here. First, some people buy Mac hardware explicitly because it is more expensive and in their minds is of a higher quality. Second, you are assuming that there will be no "value-add" to running on Apple's hardware. Third, you are assuming that Mac hardware is and will continue to be "over priced" relative to some absurd benchmark such as the cheapest Dell machine you can rangle up.
> This takes Apple out of the hardware game, and makes them entirely reliant on software and iPods.
Yeah, that IS the question. Is it worth the risk for Apple to move to a more software-focused portfolio. I, myself, am unsure.
> Mac OS/X will then compete directly with Windows, and though it's faster, more stable and more secure, Windows has that whole 90%+ market
> share thing going for it. Apple would be squished in short order.
That would be true of anyone who wished to compete with Microsoft. Is your point that this is impossible and no one should ever try?
I don't have time to respond to the rest of this.
Justin Dubs
And you are under the impression that that is what ID is?
Here's how this sounds to me:
OP: ID as commonly discussed and presented at trial is not science and shouldn't be taught in schools.
You: But if you make ID mean this entirely different thing, then you are wrong.
Me: And your point is?
Your left and right eyes can't always see the same set of objects.
If you use occluders and occluder volumes, then you run the risk of missing objects that were occluded from the view-point of the primary eye, but are not from the view-point of the secondary eye. So, you have to perform occlusion tests per eye or not use occluders at all.
You also run the obvious problem of objects "popping" in from the sides of your vision. There will be a moment when an object approaches from the side, into your peripheral vision, that the object is only visible from one eye. If this is your secondary eye, then I guess you'll miss it. When it is finally visible from your primary eye, it will suddenly "pop" into view. This problem can be fixed by performing your visibility tests from neither eye, but from an in-between eye with the view frustum scaled up to encompass both eye's frustums.
I just wanted to point out that this wasn't as easy as your made it sound. You can't just draw the primary eye, remember what objects you drew, and then draw them again from the secondary eye. Atleast, you can't do that if you want accurate results.
Justin Dubs
Okay, implementation-dependent things happen, so you might find yourself tied to Steel Bench for some reason... but if you can also target OpenMCL you'll find it has a kick-ass compiler as well as a fully preemptive thread scheduling model. ("[as of 0.14], lisp threads are native threads and all scheduling decisions involving them are made by the OS kernel. (Those decisions might involve scheduling multiple lisp threads simultaneously on multiple processors on SMP systems.)"
I am pretty familiar with OpenMCL. It is my primary Lisp environment. It just hit 1.0 too! However, I've never been able to get the speed of OpenMCL-compiled code to compare the SBCL-compiled code. Every now and then I find myself switching back to SBCL for that reason, as I do some hacking in my free-time that is numerically intensive.
As I understand it, SBCL's PPC implementation's blocking issue on native threading is a combination of the heap model, the existing stop-and-copy garbage collector, and fundamental differences in the dynamic linking of Mach-O and ELF (and COFF and a.out) binary formats. In particular, the x86 format and FFI and the ISA's small supply of registers to allow for register-to-register tagging and detagging, have driven a conservative collector.
Yeah, the GC port is the main hurdle. A second is that the current threading implementation relies on futexes, which are a Linux 2.6.x specific thing. So right now threads only work on Linux 2.6 on x86. It's easy enough to use pthreads rather than futexes, but unfortunately pthreads aren't relocatable in memory and futexes are, so you'd need to allocate your pthreads in non-gc'ed memory. So, now you need finalizers to clean them up. It just gets a little messy.
However, since we're talking about programming Lisp rather than implementing it, surely the important thing to do is to start writing maximally-portable Common Lisp, get everything to work, and then optimize sections for various implementations and platforms?
Naturally. Aside from a few unfortunately unportable things like Threads and Sockets all my Lisp is quite portable.
Speaking of portability... everyone should play with Fetter (formerly Verrazano) and CFFI. A few lines of code later and you've got all kinds of C or C++ libraries accessible from Lisp. I'm doing some hacking on some code using OpenGL, OpenAL and GLUT from OpenMCL right now. Fun fun!
Happy hacking.
Justin Dubs
So, we have a few groups of people here:
1. Current OS X users.
They will almost invariable switch to the new Intel-based macs. I would say that most of them don't even know or care what chipset they are running on.
2. New OS X users.
These are people who will now be enticed to switch, because of the Intel move, that otherwise wouldn't have been. Perhaps they were waiting for the extra performance that Apple can offer in a laptop now that they have Intel processors. Perhaps they like that they can recompile their x86 specific programs on Macs now. (Yay! SBCL w/ Threading on OS X!? Dare I dream!?!?)
3. New Mac Hardware users (but not OS X)
This is the group you seem to be in. You want the Mac hardware, but don't care for the OS. I can't say I agree with you, but that's beside the point.
So, Apple will have all the people they have now (group 1), some new folks (group 2) and some additional hardware sales to people who are going to install Linux or Windows or BSD or something on the box (group 3).
Do you seiously believe that group 3 is big enough compared to the combined sizes of groups 1 and 2 that it will do anything other than add more to Apple's bottom-line? You aren't going to affect Apple's image unless group 3 is BIG or astonishingly well publisized.
Besides, even if group 3 were very large, we are talking about people who are buying the Hardware for the Hardware's sake. Because it's high-quality, attractive hardware. This could NEVER put them into direct competition with Dell. Dell is all about volumes. High volumes at low prices. Apple is EXACTLY the opposite. If Apple were buying the cheapest parts at the highest volumes to crank out machines as quickly and cheaply as possible, then group 3 wouldn't exist.
Well, those are my thoughts. You know the drill. Grain of sand and what-not.
Justin Dubs
I would say that your statement is as much a mischaracterization as any other I've heard.
IBM did not design the product. Lenovo did not design the product. They are companies. People designed the product. Those people were IBM employees while the product was being designed and those same people are Lenovo employees now that it's being shipped and supported.
It's basically this sentence that seems like non-sense to me: "Lenovo was simply in charge when it made it to market."
What does that mean to you? "In charge"? It's the same people. 1800 employees in RTP, NC that used to be IBM employees and are now Lenovo employees. Same deal with their other offices around the world including China and Japan.
Justin Dubs
I finally got around to finish the article. I loved number 8.
Goal:
"We wish to rotate an image, shrink it 50%, attach it to an e-mail and send it to a deaf musician."
Proposed solution:
"Say Tip a quarter to the right, crop by half and e-mail to Stevie Wonder."
Great. Except that cropping means cutting off the sides of an image, not scaling it. So, now you just sent the middle of an image to Stevie Wonder rather than the image at half-size.
Justin Dubs
Not only are screen corners the easiest to get to, they are the easiest to get to accidentally. I hit the screen corners all the time on the way to other things. So, they shouldn't do anything real invasive or complicated. Luckily, two of the four corners dont' do anything unless I click in them.
....
On a mac:
top-left: Apple menu. Yes, pixel (0, 0). Try it.
top-right: Spotlight. Yes, pixel (w, 0). Try it.
On my mac, easily configuration through System Preferences.
bottom-left: Dashboard. weather, dictionary, phone book, man pages,
bottom-right: Expose. All windws tiled on the screen.
These last two don't require a click, just the mouse hitting that corner. I trigger Dahsboard by mistake on a semi-regular basis. Kinda annoying. I never seem to hit the bottom-right accidentally though.
Either way, this seems to contradict the article, as top-left (Apple menu) includes system prefs, top-right is Spotlight which is definitly document relaed. bottom-left (Dashboard) is information related. bottom-right (Expose) is definitly document related.
Justin Dubs
Thanks for the inforrmation/corrections. I'm more of a cook than a scientist at this point, it seems. :-)
Justin Dubs
The key is that water has a high specific energy, so it can absorb a lot of energy without actually increasing in temperature. The other types of molecules in your gravy solution can happily be heated to over 212 degrees without boiling; only the water boils. As more and more water cooks out of the gravy, there becomes less water to absorb the energy through evaporation so the energy begins heating the remaining non-water liquid to a higher temperature than water's boiing point.
:-)
This is the entire methodology of fudge making. Create a sugar-water solution. Apply heat. It gets to 212 slowly. Water begins to evaporate. Sugar continues to heat, driving the temperature of the solution above 212 degrees. The less water there is the less resistance there is to moving above 212. At the appropriate temperature (235 degrees; soft ball stage) you remove the solution from the heat and let it cool. You now have fudge. Ideally you would also add corn syrup, chocolate, cream instead of water, butter and vanilla extract (at the end) to improve the flavor. And hopefully you would stir vigorously once it drops below 150 or so so that the sugar crystals that are created are as small as possible and your fudge has a smooth texture.
Caramel is made in the same way. Heat the sugar-water solution to just before the burning point for sugar (around 350), add cream, boil for 3 minutes then cool. Youv'e got caramel!
Mmmmm.... food....
Justin Dubs
This may be a theoritical truth (not that I'm conceding that), but it is certainly not a practical truth.
Example:
The number of possibly game states in the Go is over 10^150. Many orders of mangnitude higher than the number of atoms in the universe. The best Go playing computer is ranked around 5k or so, which would make it a relatively strong amateur.
Question:
Can you name something that you believe can not be explained mathematically? Do you have evidence for this? If not, then your first sentance could be accurately paraphrased as "Personally, I believe that computers, at this point, can beat mankind in anything."
Justin Dubs
Perhaps your bid gets spread out with a portion being divided proportionally over the critical bugs based on their severity and the rest being applied to the bug of your choice.
This would keep the severe problems at a higher dollar value than all but the most popular of feature requests...
Justin Dubs
Either make it 4 * pi * r^2 or make the answer 1/3 * pi * r^3...
Justin Dubs
That's probably not the right way to think about it. A cons cell is a data structure that holds a pair of items. The first is the car; the second is the cdr. The accessors for those parts of a cons cell also have the names car and cdr.
Linked lists are just one data structure that you can implement with cons cells. You can also implement a stack, queue, binary-tree, association-list, etc...
If your are using "cons cells" in your program, use car and cdr.
If you are using lists that are implemented via cons cells use first and rest.
If you are using a stack use push and pop.
And so on...
In other words:
CL-USER> (car (cons 1 2))
1
CL-USER> (cdr (cons 1 2))
2
CL-USER> (first (list 1 2 3))
1
CL-USER> (rest (list 1 2 3))
(2 3)
Justin Dubs
Buy one of the ones with the "p" at the end of the model. The "p" means "performance." Either a T-series or an R-series will do. The R-series will give you more for less, but in a slightly bigger package. I use an R50p at work here (IBM in RTP). It's got a ATI FireGL 2 Mobility w/ 128MB of Video RAM.
I just finished playing Half-Life 2 on it, and I'm still playing Counter-Strike: Source. It works wonderfully. So, unless you can reconcile "very old" and "very sucky" with "just played Half-Life 2 at a good frame rate" I'm going to have to call shenanigans.
Justin Dubs
Sorry dude, but 1024 bits is 256 hex digits. Each hex digit represents one nibble, or one half-byte which is 4-bits. And, 1024 >> 2 is clearly 256.
Now, I notice you are listing them in groups of 4, which makes 64 groups of four. But, those groups aren't hexadecimal characters, they are hexadecimal words of 2-bytes in length.
Justin Dubs
If you have BSD's date instead of GNU's then try:
$ date -u -r $((1 30))
Sat Jan 10 13:37:04 GMT 2004
10 here. i wrote a computer program to draw a sexy 3d version of it and let me move pieces by tapping the 1, 2 and 3 keys. after solving 4 or 5 discs a few times my fingers would get into this wierd zone where they'd just fly over those three keys without any conscious thought. very cool.
justin
"That business wouldn't be where it is today if they didn't do stuff to stay in business."
Duh. What, do you think every other company exists in a little bubble where they survive soley on the work of internal employees?
Justin Dubs
It is annoying that Gimp doesn't do CMYK, but why can't you manipulate all your images in Gimp as RGB, then use ImageMagick to convert to CMYK? Admittedly it's more of a hassle, but it's not the end of the world. It's worked for me.
LOL. Try reading some color theory. RGB and CMYK are different subsets of the full color spectrum. CMYK is almost a subset of RGB, but not quite. Each can display colors the other can not, with RGB having far more such colors than CMYK.
Nearly every print medium is printed using CMYK. Nearly every display medium uses RGB. Display mediums and print mediums have entirely different representational abilities. If you tone a picture well on a display, it won't come out quite right on print. If it's toned well on paper, it won't look quite right on the display.
The conversion from RGB to CMYK is lossy. The conversion from CMYK to RGB is also lossy. Both result in reduced image quality. And both would require retoning.
So, I'm afraid saying "convert to CMYK when you're done" just doesn't work out that well in practice. No newspaper will use a photo editing tool that doesn't support CMYK.
Justin DubsSo...
> 1. It's hardware dependant.
If by that you mean that it runs on hardware, then yes. It is dependent on you having a computer. It supports Windows on any supported platform. AMD or Intel. It supports any Mac capable of running OS X. Meaning, G3, G4 or G5.
If you mean iPod dependent then you are full of crap. Perhaps you haven't actually tried it?
> 2. Until recently it was Mac OS dependent too.
This is my favorite complaint. "They did it wrong cause it USED TO have a problem." Jesus, son.
> 3. Terms of licensing are high with the music
> labels...recent articles suggest iMusic is a
> loss-run enterprise intended to drive iPod sales
> (see #1).
And your final complaint is based on an unfounded rumor...
Congratulations! You win!
Justin Dubs
It's all fine and good that you think Macs are unconfigurable and "lacking reasonable options", but some examples would be appreciated...
Justin Dubs
Then put a separate copy of the original firmware into read-only memory at manufacturing time and provide a physical button that writes the known good firmware over the current firmware...
So, "Tile Windows Horizontally" is the same as:
Shrink all visible applications to tiles on the desktop, allow the user to choose one, and then expand the applications back to their original sizes with the user chosen one on top?
Also, Expose doesn't resize windows, it scales them. In other words, the windows don't receive resize events because the aren't being resized. Instead, their presentation is being scaled by the vector graphics system in Quartz Extreme.
Have you ever actually used Tile Windows Horizontally? If so, have you ever actually seen or used Expose?
Justin Dubs
They mean entirely different things.
:-)
A "big" gun probably means it is of a large caliber in terms of the rounds that it fires and has nothing to do with physical size.
A "big" server has impressive hardware and again has nothing to do with size.
"Big" breasts are actually just more physically large.
However, even with the third meaning of physical size, it's degree will vary depending on whether it is applied to a star or a spoon. The difference between a big star and a regular star is much greater than that between a big spoon and a regular spoon. Unless it's one gigantic spoon. But, then it's gigantic and not big... or something.
Justin Dubs