My question is what is the approximate size (diameter) of this black-hole and what is its density. I assume its not particuarly dense just particuarly big.
Huh? It's a singularity, of course. You know, point-mass and all that, so it's very dense and very small.
But maybe you mean how far out is the event horizon? You can exactly calculate it from the mass of the black hole using R = 2 * G * M / c^2 where G is the gravitational constant, 6.67e-11, and c is the speed of light, 3e8. Since the Sun's mass is 1.989e30 kg, you can find this black holes mass by multiplying by 2.6e6. When I work out the radius of the event horizon, I get 7.7 million kilometers. From that you can calculate the "density" if you are still interested.
I bet you could have found all this out with this here Internet thing. After all, that's what it's here for.
.GIF uses LZW compression and.PNG uses the deflate algorithm.
First some background for people who don't know much about compression. LZ77 and LZ78 are algorithms published by the same researchers in 1977 and 1978 which exploit repeated patterns in your data to efficiently compress information. Huffman encoding is a different technique for compression which will make the common symbols in your data take up less space.
LZW is a variant of LZ78 compression. It is modified for speed of compression. (Note: compression, not decompression). LZW is what Unisys has a patent on.
Deflate is the algorithm used by gzip and is also used by PKZip. It combines LZ77 with Huffman encoding. It nearly always compresses better than LZW because besides exploiting patterns it will also make the most frequent symbols represented by a small number of bits.
Because LZW is the thing which is patented, and Deflate doesn't use LZW,.PNGs don't have patent issues like gifs, and because Huffman encoding is used they also compress better. So, technically, they are the obvious choice. The only issue is browser compatibility.
It's very good to see curved surface representations making it in to the gaming industry. It looks like Quake 3 will be leading the pack with its support for Bezier patches.
I'm a huge fan of subdivision surface representations. In my mind, they're much nicer than tensor product surfaces because they are topologically unconstrained and can have natural constraints on for sharpened edges in your geometry.
Do you see subdivision surfaces making it in to the gaming industry soon? It seems like it would be a big win for character animation at least. Would a major game need to use subdivision surfaces before we start to see direct hardware support for them? What do you think the future is for curved surfaces in games?
BeOS makes it easy to write a multithreaded app, and the OS services it provides are multithreaded, but if you port a single threaded app, it's still a single threaded app. Sure, the OS calls you are making might be serviced by threads running on another processor, but all your ported code is just running in one thread.
That said, Be's OpenGL might allow, say, transformations to be done on a different processor than the game logic is running on. It depends on how it was written.
This is exactly my problem. X11 doesn't have anything to do with sound. I think it should. My thinking goes like this: X11 gives me nearly what I need to do all my I/O remotely, except it doesn't do anything about sound. If I remotely run an application which uses sound, all the sound will playback on the machine where the app is running, but the display will be on my X terminal. This is weird, and not what I wanted.
1. No alpha channel support. 2. No subpixel precision for drawing primitives. 3. No network-transparent support for sound. 4. No support for hardward accelerated 3D. (Well, there is GLX, but that isn't X). 5. No integration with support for printing. 6. The single-threaded implementation of most conventional X servers leads to unresponsiveness. 7. No support for switching display depth on-the-fly. 8. The X11 protocol is not easily extensible.
I tried VB once, setting aside my prejudices about it being inspired by BASIC and only for Windows, and produced by Microsoft. The GUI form builder was sort of neat, but I had been spoiled by the 'pack' style tools of AWT, Tk and GTK+, so I was a bit dissapointed when there was no obvious or easy way to reflow the controls when the window size changes.
I could like with this, I thought. The real problem was that I couldn't find a damn BNF of the language to save my life. The on-line docs didn't help at all, and when I went to my local book superstore, all I could find were books that either like "how to learn programming with VB" or "here is a bunch of man pages on the standard libraries". To this day, I'm still not sure how the syntax of VB really works.
Nevertheless, it *is* nice to drag 'n drop GUI components on a form, and then edit properties of the components with immediate visual feedback. So there's something. But I couldn't figure out how to do any useful computations behind the UI code.
I say give me Tcl or Python or Perl or Lisp as a RAD language anytime over VB. I think it's ironic that I had an easier time learning each of those languages that I had with my attempt at learning VB. Hell, I even think it was easier for me to learn C, C++ and various assembly languages that it was for me to learn VB. They actually had decent documentation.
Slashdot Mirror
Huh? It's a singularity, of course. You know, point-mass and all that, so it's very dense and very small.
But maybe you mean how far out is the event horizon? You can exactly calculate it from the mass of the black hole using R = 2 * G * M / c^2 where G is the gravitational constant, 6.67e-11, and c is the speed of light, 3e8. Since the Sun's mass is 1.989e30 kg, you can find this black holes mass by multiplying by 2.6e6. When I work out the radius of the event horizon, I get 7.7 million kilometers. From that you can calculate the "density" if you are still interested.
I bet you could have found all this out with this here Internet thing. After all, that's what it's here for.
First some background for people who don't know much about compression. LZ77 and LZ78 are algorithms published by the same researchers in 1977 and 1978 which exploit repeated patterns in your data to efficiently compress information. Huffman encoding is a different technique for compression which will make the common symbols in your data take up less space.
LZW is a variant of LZ78 compression. It is modified for speed of compression. (Note: compression, not decompression). LZW is what Unisys has a patent on.
Deflate is the algorithm used by gzip and is also used by PKZip. It combines LZ77 with Huffman encoding. It nearly always compresses better than LZW because besides exploiting patterns it will also make the most frequent symbols represented by a small number of bits.
Because LZW is the thing which is patented, and Deflate doesn't use LZW, .PNGs don't have patent issues like gifs, and because Huffman encoding is used they also compress better. So, technically, they are the obvious choice. The only issue is browser compatibility.
--
I'm a huge fan of subdivision surface representations. In my mind, they're much nicer than tensor product surfaces because they are topologically unconstrained and can have natural constraints on for sharpened edges in your geometry.
Do you see subdivision surfaces making it in to the gaming industry soon? It seems like it would be a big win for character animation at least. Would a major game need to use subdivision surfaces before we start to see direct hardware support for them? What do you think the future is for curved surfaces in games?
That said, Be's OpenGL might allow, say, transformations to be done on a different processor than the game logic is running on. It depends on how it was written.
This is exactly my problem. X11 doesn't have anything to do with sound. I think it should. My thinking goes like this: X11 gives me nearly what I need to do all my I/O remotely, except it doesn't do anything about sound. If I remotely run an application which uses sound, all the sound will playback on the machine where the app is running, but the display will be on my X terminal. This is weird, and not what I wanted.
Heh, I've got some too:
1. No alpha channel support.
2. No subpixel precision for drawing primitives.
3. No network-transparent support for sound.
4. No support for hardward accelerated 3D. (Well, there is GLX, but that isn't X).
5. No integration with support for printing.
6. The single-threaded implementation of most conventional X servers leads to unresponsiveness.
7. No support for switching display depth on-the-fly.
8. The X11 protocol is not easily extensible.
I could like with this, I thought. The real problem was that I couldn't find a damn BNF of the language to save my life. The on-line docs didn't help at all, and when I went to my local book superstore, all I could find were books that either like "how to learn programming with VB" or "here is a bunch of man pages on the standard libraries". To this day, I'm still not sure how the syntax of VB really works.
Nevertheless, it *is* nice to drag 'n drop GUI components on a form, and then edit properties of the components with immediate visual feedback. So there's something. But I couldn't figure out how to do any useful computations behind the UI code.
I say give me Tcl or Python or Perl or Lisp as a RAD language anytime over VB. I think it's ironic that I had an easier time learning each of those languages that I had with my attempt at learning VB. Hell, I even think it was easier for me to learn C, C++ and various assembly languages that it was for me to learn VB. They actually had decent documentation.