We have undefined because it means that our assumptions (in the expression leading up to it), were FALSE under the axioms of our proof system. (Either your assumptions were wrong or you forgot a few special cases of (f(x)!=0) somewhere). Calling it nullity and plowing ahead would completely invalidate anything you were trying to prove in the first place. Often times in mathematics you assume the converse is true and find a contradiction to show the original statement must be true, good luck with that after nullity. Mathematically useless.
You're exactly right. When you've got the limit sign, and a directionality of approach and everything, it's all good, you get a quantity. The value of the limit is wrapped up in the expression that approaches it (this is where the "constant" came from). But you can't evaluate the expression AT ZERO, that's ludicrous. The function is continouous with a hole, and that's just the way it is.
Read his papers... or attempt to. He thinks that by adding nullity he is 1) keeping the reals a commutative ring while 2) turning multiplication over reals into a group. Of course, nullity is not in the group. This just moves the goalposts. In fact, I still don't think multiplication over reals (using the definition of but excluding nullity) is a group anyway (haven't look hard for a contradiction, there's gotta be an easy one), so what's the point?
He introduced a multiplicative inverse for the additive identity (0), and added it to the real number field. Unfortunately, he just complicates things, because he doesn't define how the + and * operators map up with it (nullity + a = ?)... if he doesn't then he breaks assoc/commu/trans properties (no longer a field then). And of course that number we need additive/mult inverses which may require nullity-prime, and so on, and he's just going in circles.
The limit of c/x as x->0 (from a complex direction) yields a directional infinity. They look like the form (a+bi)*inf, where (a+bi) is on the complex unit circle.
If you don't specify a direction, then the limit does not exist.
The function c/x doesn't have that smooth neighborhood property at x=0, but it's differentiable, or something like that. (Help me out, math majors, I didn't take complex analysis)
You really don't understand crypto, do you. You can't "crack" PGP anymore than you can "crack" DHM key exchange, or "crack" finding a trivial solution for factoring large composite numbers, or find a weakness in SHA-1. If any of those things were possible, not only would PGP be broken, BUT SO WOULD SSL.
Face it. DRM that isn't assisted by resin-blobbed cryptohardware is intractable, especially when using irresponsbile, single-symmetric key encoding schemes. Bittorrent and DRM are NOT a good mix, which is my initial point.
And THAT'S where you strike. The only catch is that not only do you have a free-and-clear copy, but so does anybody else (the key is easier to distribute than the now-un-DRM movie itself). In a non P2P model, the content provider can limit the spread of a key that breaks an official file by using seperate per-file encrpytion keys for each registered user.
No amount of mucking about with SSL or PKI will fix that problem.
It would be trivial for a DVD-Jon-type to create a piece of softwarwe that can capture the symmetric key that is returned through the web transaction and break that file... permanently. For every potential user... And of course, the "thousands of keys" technique is still predicated on a single symmetric key protecting the file... that's the only one you care about breaking, where you focus your efforts is just different.
Bittorrent can't be used as a sustainable business model to profitably distribute DRM content. Those VCs are going find out they made a mistake sooner or later.
You are living my dream.
on
Fedora Linux
·
· Score: 1
I would love to have my servers boot off fixed media or CDROMs. Alas we do not have the time and things change to rapidly in short bursts for us to settle on such a solution. I can definitely see why a small and concise distribution would be right up your alley. It occurs to me that a more tractable solution might be to create images from a source box that has a full install; wherein you profile the software and make a tarball of all the files that are actually touched by a target configuration (something that can be done with instrumentation in LSM, created by lists of regexes). In such a setup the RPM command and the RPM databases would not be available since you don't actually use them in production. You'd patch the source box and re-derive your production images from it... I want to try that now... (evil grin)
I would argue that point since most packages where the options configured actually mattered for performance reasons tend to have workarounds. Take apache for instance. While the httpd package comes configured with mod_php and mod_perl, by commenting out those modules in the configuration file those interpreters aren't loaded and so apache takes up less memory. Or take Samba -- they have factored out a single large package (which is how it exists upstream) into half a dozen smaller packages divided up between management tools, clients, the server and documentation. It can cause an installation to be large (relative to say, DSL) to support a few key services, but is 1-2GB really that much space in an era of 160GB RAID-1 mirrored system disks? I try to spend time minimalizing the installation only to increase the speed of full system updates and backups, and not much else.
If you want to install linux on an embedded platform or reuse very old equipment; modern distros are probably no longer suited for this task.
Also, what is in the minimal install that shouldn't be there? Most of that stuff is to support the default configured kernel from userspace.
Pick a random, popular package.
on
Fedora Linux
·
· Score: 1
And open up the AUTHORS or CHANGES file. Grep for "@redhat.com".
Heat is random motion in a substance. Infrared radiation is something that a substance with a relatively high tempature emits to equalize it's temperature with the rest of the universe. Of course, they omit other frequencies of photons too. Things that absorb the infrared radiation... or light, or microwaves, get hot indirectly (i.e. your hand).
Targetting a specific frequency of blackbody radiation using a photovoltaic cell is a poor way to convert heat into energy. Most heat in our environment is conducted or convected away by air or other materials touching the hot thing. The remainder is a broad spectrum of radiation, of which a photovoltaic device can only hope to capture of fraction of the total radiated energy (due to small frequency window) and it even does that inefficiently.
Right now FFXII mob fight strategies for farming are sort of robbing my brain of awareness during the morning commute. Yesterday I found myself thinking about lane changes in terms of pathfinding. (eeesh)
Then again, it's a miracle I make it to work in one piece most days anyway, I'm still asleep walking through the door.
They're putting CUDA _in_ the CPU. It's a CPU, plus massively parallel stream processing. No PCI-e bus to traverse. Shared L3 cache. Scalable with however many cores that platform supports...
It may help you make cheap chips, but for performance, it sucks. You can't feed an instruction cache fast enough to justify RISC in high performance computing. The richer the instruction set, the more branch prediction, the more out of order and speculative your execution, the better.
The point is not to add a "video card" to the CPU. This Fusion would in no way prevent you from needing a graphics card. What it would do is add a general purpose DSP-style unit similar to a set of processing nodes in the new NVidia and ATI GPU implementations, capable of doing many graphics functions (vertex, pixel ops, etc.). You would still need to mate it to an output card which would have some of the less embarrasingly parallel operations of 3d graphics, framebuffers, 2D scaling acceleration, and output drivers.
In this fashion, using multi-socket boards you could scale your effective 3D processing power with additional or more dense chips that can be balanced between 3D, physics simulation, and other workloads.
This would be changing the way we do graphics and game design for enthusiasts, professionals, and home users alike.
I agree that it helps for stories to have an identifiable main character. However, there are many popular games where you do _NOT_ identify with the main character -- you become someone you are not and live through the avatar.
Prince of Persia, Perfect Dark, MDK, Final Fantasy VI, God of War... just a few examples of engaging games that have heavy story elements where you take control of powerful/specialized characters and experience the game through their eyes.
There are certain situations where a game becomes detached, impersonal, or confusing without an end-user sympathetic individual. This character can 'grow' with the game to adjust to increasing difficulty, and external characters can explain the goings on to this person as they are the "rookie", such that they are told everything they need to know about backstory or game mechanics in a natural way.
My point is that FFXII is not one of those games that needs this kind of avatar. A narrator gives you backstory. Optional CGs establish character relationships. And they could have expanded the role of the introductory sequence in which you take the role of a soldier during the "treaty signing" at the beginning of the game to learn additional game mechanics. Plus, all your characters are flexible (and largely undifferentiable) in growth, the total number of players just gives you extra life expetancy during boss fights.
From what I understand they wanted to introduce two stronger characters, hardened theif or ex-soldier resistance individuals to round out the cast to 6 (this allowed for 3 to play, and then 3 to swap in during boss fights). But the current Vaan and Penelo are entirely the product of marketing... I would have been happy if they dropped them and just let you have 4 active party members.
Slashdot Mirror
We have undefined because it means that our assumptions (in the expression leading up to it), were FALSE under the axioms of our proof system. (Either your assumptions were wrong or you forgot a few special cases of (f(x)!=0) somewhere). Calling it nullity and plowing ahead would completely invalidate anything you were trying to prove in the first place. Often times in mathematics you assume the converse is true and find a contradiction to show the original statement must be true, good luck with that after nullity. Mathematically useless.
You're exactly right. When you've got the limit sign, and a directionality of approach and everything, it's all good, you get a quantity. The value of the limit is wrapped up in the expression that approaches it (this is where the "constant" came from).
But you can't evaluate the expression AT ZERO, that's ludicrous. The function is continouous with a hole, and that's just the way it is.
Read his papers... or attempt to.
He thinks that by adding nullity he is 1) keeping the reals a commutative ring while 2) turning multiplication over reals into a group.
Of course, nullity is not in the group. This just moves the goalposts. In fact, I still don't think multiplication over reals (using the definition of but excluding nullity) is a group anyway (haven't look hard for a contradiction, there's gotta be an easy one), so what's the point?
He introduced a multiplicative inverse for the additive identity (0), and added it to the real number field.
Unfortunately, he just complicates things, because he doesn't define how the + and * operators map up with it (nullity + a = ?)... if he doesn't then he breaks assoc/commu/trans properties (no longer a field then). And of course that number we need additive/mult inverses which may require nullity-prime, and so on, and he's just going in circles.
The limit of c/x as x->0 (from a complex direction) yields a directional infinity.
They look like the form (a+bi)*inf, where (a+bi) is on the complex unit circle.
If you don't specify a direction, then the limit does not exist.
The function c/x doesn't have that smooth neighborhood property at x=0, but it's differentiable, or something like that. (Help me out, math majors, I didn't take complex analysis)
You really don't understand crypto, do you.
You can't "crack" PGP anymore than you can "crack" DHM key exchange, or "crack" finding a trivial solution for factoring large composite numbers, or find a weakness in SHA-1.
If any of those things were possible, not only would PGP be broken, BUT SO WOULD SSL.
Face it. DRM that isn't assisted by resin-blobbed cryptohardware is intractable, especially when using irresponsbile, single-symmetric key encoding schemes. Bittorrent and DRM are NOT a good mix, which is my initial point.
The client app decrypts the file...
And THAT'S where you strike. The only catch is that not only do you have a free-and-clear copy, but so does anybody else (the key is easier to distribute than the now-un-DRM movie itself). In a non P2P model, the content provider can limit the spread of a key that breaks an official file by using seperate per-file encrpytion keys for each registered user.
No amount of mucking about with SSL or PKI will fix that problem.
Just saying.
It would be trivial for a DVD-Jon-type to create a piece of softwarwe that can capture the symmetric key that is returned through the web transaction and break that file ... permanently. For every potential user...
And of course, the "thousands of keys" technique is still predicated on a single symmetric key protecting the file... that's the only one you care about breaking, where you focus your efforts is just different.
Bittorrent can't be used as a sustainable business model to profitably distribute DRM content. Those VCs are going find out they made a mistake sooner or later.
I would love to have my servers boot off fixed media or CDROMs. Alas we do not have the time and things change to rapidly in short bursts for us to settle on such a solution. I can definitely see why a small and concise distribution would be right up your alley.
It occurs to me that a more tractable solution might be to create images from a source box that has a full install; wherein you profile the software and make a tarball of all the files that are actually touched by a target configuration (something that can be done with instrumentation in LSM, created by lists of regexes). In such a setup the RPM command and the RPM databases would not be available since you don't actually use them in production. You'd patch the source box and re-derive your production images from it...
I want to try that now... (evil grin)
I would argue that point since most packages where the options configured actually mattered for performance reasons tend to have workarounds. Take apache for instance. While the httpd package comes configured with mod_php and mod_perl, by commenting out those modules in the configuration file those interpreters aren't loaded and so apache takes up less memory. Or take Samba -- they have factored out a single large package (which is how it exists upstream) into half a dozen smaller packages divided up between management tools, clients, the server and documentation.
It can cause an installation to be large (relative to say, DSL) to support a few key services, but is 1-2GB really that much space in an era of 160GB RAID-1 mirrored system disks? I try to spend time minimalizing the installation only to increase the speed of full system updates and backups, and not much else.
If you want to install linux on an embedded platform or reuse very old equipment; modern distros are probably no longer suited for this task.
Also, what is in the minimal install that shouldn't be there? Most of that stuff is to support the default configured kernel from userspace.
And open up the AUTHORS or CHANGES file. Grep for "@redhat.com".
I think they still care.
Heat is random motion in a substance.
Infrared radiation is something that a substance with a relatively high tempature emits to equalize it's temperature with the rest of the universe. Of course, they omit other frequencies of photons too. Things that absorb the infrared radiation... or light, or microwaves, get hot indirectly (i.e. your hand).
Targetting a specific frequency of blackbody radiation using a photovoltaic cell is a poor way to convert heat into energy. Most heat in our environment is conducted or convected away by air or other materials touching the hot thing. The remainder is a broad spectrum of radiation, of which a photovoltaic device can only hope to capture of fraction of the total radiated energy (due to small frequency window) and it even does that inefficiently.
Right now FFXII mob fight strategies for farming are sort of robbing my brain of awareness during the morning commute. Yesterday I found myself thinking about lane changes in terms of pathfinding. (eeesh)
Then again, it's a miracle I make it to work in one piece most days anyway, I'm still asleep walking through the door.
BTW, does anyone know why it's so hot in here?
I'm not wasting time with that shit.
They're putting CUDA _in_ the CPU. It's a CPU, plus massively parallel stream processing. No PCI-e bus to traverse. Shared L3 cache. Scalable with however many cores that platform supports...
It may help you make cheap chips, but for performance, it sucks.
You can't feed an instruction cache fast enough to justify RISC in high performance computing. The richer the instruction set, the more branch prediction, the more out of order and speculative your execution, the better.
The point is not to add a "video card" to the CPU. This Fusion would in no way prevent you from needing a graphics card. What it would do is add a general purpose DSP-style unit similar to a set of processing nodes in the new NVidia and ATI GPU implementations, capable of doing many graphics functions (vertex, pixel ops, etc.). You would still need to mate it to an output card which would have some of the less embarrasingly parallel operations of 3d graphics, framebuffers, 2D scaling acceleration, and output drivers.
In this fashion, using multi-socket boards you could scale your effective 3D processing power with additional or more dense chips that can be balanced between 3D, physics simulation, and other workloads.
This would be changing the way we do graphics and game design for enthusiasts, professionals, and home users alike.
I had an intervention for my brother.
I agree that it helps for stories to have an identifiable main character. However, there are many popular games where you do _NOT_ identify with the main character -- you become someone you are not and live through the avatar.
Prince of Persia, Perfect Dark, MDK, Final Fantasy VI, God of War... just a few examples of engaging games that have heavy story elements where you take control of powerful/specialized characters and experience the game through their eyes.
There are certain situations where a game becomes detached, impersonal, or confusing without an end-user sympathetic individual. This character can 'grow' with the game to adjust to increasing difficulty, and external characters can explain the goings on to this person as they are the "rookie", such that they are told everything they need to know about backstory or game mechanics in a natural way.
My point is that FFXII is not one of those games that needs this kind of avatar. A narrator gives you backstory. Optional CGs establish character relationships. And they could have expanded the role of the introductory sequence in which you take the role of a soldier during the "treaty signing" at the beginning of the game to learn additional game mechanics. Plus, all your characters are flexible (and largely undifferentiable) in growth, the total number of players just gives you extra life expetancy during boss fights.
From what I understand they wanted to introduce two stronger characters, hardened theif or ex-soldier resistance individuals to round out the cast to 6 (this allowed for 3 to play, and then 3 to swap in during boss fights). But the current Vaan and Penelo are entirely the product of marketing... I would have been happy if they dropped them and just let you have 4 active party members.
Just wow.
It really is. Which is why I won't associate with anyone who has an account... at the very least it shows a lack of fiscal responsibility.
If the characters leave the party, you have to play as Vaan. They could have dropped that requirement, and ... Vaan.