Bloody hell yes it is! Ok, so maybe we've misunderstood each other. I'll state my stand again, lamely obvious:
By sqrt() I mean the root sign, the one that loks somewhat like \/"""
x^2 = 9 <==> x=sqrt(9) would be wrong, missing one solution
x^2 = 9 <==> x=± sqrt(9) would be correct
sqrt(9) = -3 would be wrong
sqrt(9) = 3 would be correct
sqrt(9) = ± 3 would be wrong
About your definition; that's not the 'square root'. It's a general case, and the sign convention should have been pointed out in that book (I don't have it). As this semi-decent page says, "If a is any nonnegative real number, then its square root is the nonnegative number whose square is a" and "Unlike square roots, the cube root of a number may be negative".
Now of course I didn't find some real good web references backing me up and explaining the thing once more, so we can see where we differ. Misunderstandings are easier to avoid using paper (refering to GIFs on a real page) than ASCII art. Anyway, here are a few:
"Positive numbers have always have two square roots, one positive and one negative. The radical sign, , always denotes the positive, or principle, square root. Zero only has one square root, 0 itself. Negative numbers do not have real number square roots.
5 is the square root of 25 because 5 5 = 25. 5 is the Principle Square Root because it is positive."http://epsb.edmonton.ab.ca/schools/crestwood/real_ numbers_1.3.html
Perhaps I should have said 'The radical sign' or something instead of sqrt()?
Actually, I'd kind of disagree. When you take the square root of something, it's "defined" to be the positive root of it. Thus, sqrt(4) = 2, not +-2. If you want to include the negative root, you'd write +- sqrt(4). For example, in physics you often see stuff like +(-) sqrt(x), with - within parentheses to include that the negative solution isn't valid. Besides, the statement
|x| = sqrt(x^2)
is true for all x! Obviously
|30| = sqrt(30^2)
|-30| = sqrt( (-30)^2)
This was the lame statement: |x| = sqrt(x^2) = (x^2)^0.5 = x^(2*0.5) = x^1 = x
Linux 3.0? doesn't matter. The kernel development ceased being interesting for approx 4 years ago. The interesting things now, when it comes to workstation use, is the development of X and toolskits such as gnome/kde, and, most importantly, APPLICATIONS. The kernel is already as good as it needs to be / is useful to be. Does anybody think workstations running linux 2.4 were more useful than the ones running linux 2.2? Or 2.2 instead of 2.0? NO! KDE2 instead of KDE1? YES! Same with Gnome!! XFree86 4.x instead of 3.x makes a huge difference - a new kernel almost just a cosmetic one. Biggest exception would be if the new kernel supports some hardware the old one didn't support - but then the interesting thing is the new driver - NOT the new kernel version.
I understand I speculated about things somewhat of the topic you gave answers to and I appologize if that didn't show through. The thing I wonder and that still do puzzle me is why so many companies doesn't filter of.vbs. They have happened before (ILuvU) and now it happened again...
And that suggestion I made, about having each *new* never-checked extension read by somebody - is it really so unimaginable? Once.ssf has been rejected once, it doesn't reach administration. Only 'new' extensions pass by. Until some moron figures that out and starts mailing attachments with new extensions, wouldn't it work? And the dont-let-anybody-see-the-ceo-mail problem could be handled by just showing the _extensions_ (not the mails - or filenames - or header, just the extension, as in 'JPG'). The admins could be trusted to do that - they have control over the network anyway, right?
Am I naive? Anyway, _at least_ filtering *.vbs seems almost obilgatory. Lots of gain at low cost.
at least that would give it a little, but still, more dignity. What we need now is a virus written in C64 basic-with-line-numbers. In five years, if the common Joe uses Gnome, expect bash viruses to become common. urgh!
yeah, as in 'clueless people running untrusted scripts without checking them'. I don't think that quallifies as a 'virus'. Rather 'Cluelessnessexploit', or CLNE
why not just filter all attachments that comes with a file named '*.vbs' (and what scripting suffixes there are in Windows world. Just check all suffixes that are registered in the registry to see what there is. Or even simpler, just allow known extensions to pass thru the company mail server, such as jpg zip png. When one fails, you could have it auto-mail some admin that checks what kind of file it is, and if the extension would be allowed to pass, adds it to the 'allowed extensions' list so future attachments pass thru. You could probably quite soon have covered all extensions, cutting the administrative overhead to practical nill, and no longer get these EXTREMELY beyond reason LAME 'viruses'.
yes, that was what I ment - a alternative renderer in the povray package that could use openGL to render a quick preview, so you could get a good idea of how the image was shaping up. Having this ability in the modeleller would of course be great, but I know of no such modeller.
Exactly - that's why you would use the povray renderer for the final step. Since it's slow, you'd rather have a lower quality but faster renderer while you work on the picture, so you can see how it's going to look before you do the final time consuming rendering.
The povray renderer is way too slow. How about adding support in povray for openGL? That would make it a lot more useful - just use the povray renderer for the final image.
not to mention even windows 3.1 had true type, which looked WAY better at low resolutions (that is, on the screen) than the fonts in X do today, unless you have a true type server...
Slashdot Mirror
By sqrt() I mean the root sign, the one that loks somewhat like \/"""
x^2 = 9 <==> x=sqrt(9) would be wrong, missing one solution
x^2 = 9 <==> x=± sqrt(9) would be correct
sqrt(9) = -3 would be wrong
sqrt(9) = 3 would be correct
sqrt(9) = ± 3 would be wrong
e w11.24.98.html
a ths03.htm
_ numbers_1.3.html
About your definition; that's not the 'square root'. It's a general case, and the sign convention should have been pointed out in that book (I don't have it). As this semi-decent page says, "If a is any nonnegative real number, then its square root is the nonnegative number whose square is a" and "Unlike square roots, the cube root of a number may be negative".
Now of course I didn't find some real good web references backing me up and explaining the thing once more, so we can see where we differ. Misunderstandings are easier to avoid using paper (refering to GIFs on a real page) than ASCII art. Anyway, here are a few:
"[...] when we take the square root of a value, we want the principle square root. For real numbers, that is the positive value. "
http://forum.swarthmore.edu/dr.math/problems/andr
"[...]the square root sign denotes the positive square root"
http://www.stockportmbc.gov.uk/curriculum/maths/m
"Positive numbers have always have two square roots, one positive and one negative. The radical sign, , always denotes the positive, or principle, square root. Zero only has one square root, 0 itself. Negative numbers do not have real number square roots.
5 is the square root of 25 because 5 5 = 25. 5 is the Principle Square Root because it is positive." http://epsb.edmonton.ab.ca/schools/crestwood/real
Perhaps I should have said 'The radical sign' or something instead of sqrt()?
Actually, I'd kind of disagree. When you take the square root of something, it's "defined" to be the positive root of it. Thus, sqrt(4) = 2, not +-2. If you want to include the negative root, you'd write +- sqrt(4). For example, in physics you often see stuff like +(-) sqrt(x), with - within parentheses to include that the negative solution isn't valid. Besides, the statement
|x| = sqrt(x^2)
is true for all x! Obviously
|30| = sqrt(30^2)
|-30| = sqrt( (-30)^2)
This was the lame statement: |x| = sqrt(x^2) = (x^2)^0.5 = x^(2*0.5) = x^1 = x
so how about this one:
|x| = sqrt(x^2) = (x^2)^0.5 = x^(2*0.5) = x^1 = x
From where comes the l4m3n355???
uhm.. did the soviets land on the moon? :)
Perhaps you could have written that it was a disgusting link? :(
well, the smart geeks would not speak 'British English'
yeah, the 'Very Smart Geeks' might even be able to spell to 'optimize'!!
The Coronado C++ tutorial. Taught me the first stuff. I remember it as being great!!!c pp/
http://swt-www.informatik.uni-hamburg.de/~strunk/
Linux 3.0? doesn't matter. The kernel development ceased being interesting for approx 4 years ago. The interesting things now, when it comes to workstation use, is the development of X and toolskits such as gnome/kde, and, most importantly, APPLICATIONS. The kernel is already as good as it needs to be / is useful to be.
Does anybody think workstations running linux 2.4 were more useful than the ones running linux 2.2? Or 2.2 instead of 2.0? NO! KDE2 instead of KDE1? YES! Same with Gnome!! XFree86 4.x instead of 3.x makes a huge difference - a new kernel almost just a cosmetic one. Biggest exception would be if the new kernel supports some hardware the old one didn't support - but then the interesting thing is the new driver - NOT the new kernel version.
I understand I speculated about things somewhat of the topic you gave answers to and I appologize if that didn't show through. The thing I wonder and that still do puzzle me is why so many companies doesn't filter of .vbs. They have happened before (ILuvU) and now it happened again...
.ssf has been rejected once, it doesn't reach administration. Only 'new' extensions pass by. Until some moron figures that out and starts mailing attachments with new extensions, wouldn't it work? And the dont-let-anybody-see-the-ceo-mail problem could be handled by just showing the _extensions_ (not the mails - or filenames - or header, just the extension, as in 'JPG'). The admins could be trusted to do that - they have control over the network anyway, right?
And that suggestion I made, about having each *new* never-checked extension read by somebody - is it really so unimaginable? Once
Am I naive? Anyway, _at least_ filtering *.vbs seems almost obilgatory. Lots of gain at low cost.
perheps it was a win for business, when you include the revenue from stockpiled cans'n'ammo?
ok, so for foreigncultural fools, just what is a 2x4??
hey... study that Troll's 'Read the rest of this comment...'-link. That was a close one!
and 'good luck, mr Gorsky!'
:)
'good luck, mr Clinton'
at least that would give it a little, but still, more dignity. What we need now is a virus written in C64 basic-with-line-numbers. In five years, if the common Joe uses Gnome, expect bash viruses to become common. urgh!
yeah, as in 'clueless people running untrusted scripts without checking them'. I don't think that quallifies as a 'virus'. Rather 'Cluelessnessexploit', or CLNE
why not just filter all attachments that comes with a file named '*.vbs' (and what scripting suffixes there are in Windows world. Just check all suffixes that are registered in the registry to see what there is. Or even simpler, just allow known extensions to pass thru the company mail server, such as jpg zip png. When one fails, you could have it auto-mail some admin that checks what kind of file it is, and if the extension would be allowed to pass, adds it to the 'allowed extensions' list so future attachments pass thru. You could probably quite soon have covered all extensions, cutting the administrative overhead to practical nill, and no longer get these EXTREMELY beyond reason LAME 'viruses'.
viruses in BASIC.. now, if somebody had told you that ten years ago, would you laughed? believed them?
approx how much cheaper would leo be than geo?
to get themself a nuclear-powered laser weapon system. Great idea!
why imperial units? Isn't that unusual for that kind of a project?
yes, that was what I ment - a alternative renderer in the povray package that could use openGL to render a quick preview, so you could get a good idea of how the image was shaping up. Having this ability in the modeleller would of course be great, but I know of no such modeller.
Exactly - that's why you would use the povray renderer for the final step. Since it's slow, you'd rather have a lower quality but faster renderer while you work on the picture, so you can see how it's going to look before you do the final time consuming rendering.
The povray renderer is way too slow. How about adding support in povray for openGL? That would make it a lot more useful - just use the povray renderer for the final image.
not to mention even windows 3.1 had true type, which looked WAY better at low resolutions (that is, on the screen) than the fonts in X do today, unless you have a true type server...