Let's see... Hydroelectric power floods huge areas of land and also creates mercury pollution (don't remember by which bio-chemical process)
Wind power is limited (You can't generate power for a whole country) and cause pollution by noise.
Solar power, although it looks "clean" also creates a lot of pollution because the solar cells are made of toxic chemicals.
Geothermal, like wind power is limited in power.
So far, there's no magical energy source. It would be nice to have a clean mass-to-energy converter (E=mc^2), but right now, there are lots of technical problems (like finding a source of anti-matter!) so it's not going to happen in a near future.
...I totally for this idea. You would need to use a different key then then one used for DVD's, but nothing prevents you from changing you $HOME/.csskey...
There are laws that say that switching the price tags on merchandise to get a lower price is theft
The equivalent of wwitching the price tags would be cracking *their* server to change the price database. This is like shopping for a $1000 item and, when at the cash saying: "That was $500, right?". It the dealer accepts, you have bargained, not stolen.
OK, I'm not talking about "standard" code with no library calls. If you get different results for a float calculation on two different platforms, it's most likely because:
- You've got an uninitialized variable that "happened" to have a value of 0 with some compiler/platform
- A comparison between two floats (a == b), which you should never do.
- An array bounds error, which can sometimes (if you're lucky) not overwrite any useful data (but does with another compiler/platform)
- Your trying to use things (int)10*.7 in some computation...
I think you did not understand anything at all from my several posts! THIS IS NOT A BUG, it's a feature! You cannot make the assumption that such float calculation will be exact to the last digit, period. If you round to the nearest integer, you'll get the right result, all the time. But when you make such stupid assumptions, you're just asking for trouble.
If you want to convince me that's a bug, go look up in the C language definition and find the place where they guaranty you that these kinds of calculations has to give what you're expecting. There's simply no guaranty of that, that's all. AFAIK, the only float calculations that are required to be exact (IEEE spec or something like that) are those that involve integer numbers, like 2.0 + 3.0 = 5.0... and certainly not.6*10 = 6.
OK, let's go... (with my previous 3 *.333333 example)
We'll work in decimal, so transpose this to binary for a real CPU. Let's say your "float" (as stored in memory) has 4 digits and your float registers can hold 6 digits (a double is 64 bits, a register is 80 bits).
If you load.333333 (6 digits in the register) in register and multiply by the 3 that's in memory. The result is.999999. When you store that in memory, it is rounded to 4 digits, giving 1.000, which when converted to int, gives 1.
Now, if you have 3 in the register and multiply by.3333 (4 digits in memory), you get.999900 in the register. When you store that in memory, you get.9999, which once conterted to int gives you 0.
The only thing that changed is what goes to register and what goes to memory. I'm not saying this is exactly what happens in your example, but it's probably something similar.
BTW, if you look at the gcc man page, there's an option called -ffloat-store which deals with registers that are larger than the memory representation of the float number.
There's nothing strange in your example. It looks strange because in the decimal system,.7 is easy to represent. What if I asked you to compute (3 *.3333333333), you'd say.9999999999 and if I asked you (int)(.9999999999), the answer would be 0. However, when I said.3333333333, I meant 1/3, but there's no way you could have known. In (binary) float representation,.7 is a periodic number, just like 1/3 in the decimal representation. That's why you need to expect wierd (random) outputs when you compute stupid things like (int)(10 *.7).
However, consider explaining that 10 equals 9 for small values of 10 only on Linux distros out of dozens of other platforms to someone that was being tortured while doing a C assignment.
In case you didn't read my other comment, this have nothing to do with Linux, since I could reproduce the same thing on Solaris x86 and I'm pretty sure I'd also get that with gcc/Win32. The way your code is, luck is the most important factor is determining whether it'll work or not! Regardless of the platform (I bet you could find another similar example that would produce 10=10 on your linux setup and 10=9 on other setups).
...and BTW, I tried on solarix x86 with gcc 2.95.2 and also got 10 = 9, so this is not even an OS issue. It's all about a bad programming practice that produces bad results with a certain compiler/CPU combination (using the same gcc version on solaris/SPARC gives 10=10). That's all there is to it.
If a certain program doesn't produce the same result with different compilers/platforms, the most like cause is not a bug in the compiler, but an undefined behaviour caused by a badly written program.
The value of: (int) (((60/6)*0.3) + (10*0.7)) can be either 9 or 10, depending on when the float values are moved in/out the floating point registers (which are 80 bits instead of 64 bits for a double). Your compiler cannot guaranty the result and you should no assume that the result is 10, unless you round to the nearest integer (instead of casting to an int, which is equivalent to a floor).
Therefor, it's not the compilers fault it this problem happens, it's your fault if you make those kind of assumptions (It's the same reason why you should almost never use == when comparing 2 floating point numbers).
...no offense, but that's why I don't want to work in the US, although I could easily have a x2 on my net salary. I think my values are sufficently different from there to significantly decrease my quality of life) and that's the main reason I choose to stay in Canada.
One thing you need to add: Things like Ozone and nitrogen oxydes aren't created by the fuel itself, but by the heat involved in the combustion. It's likely that a Hydrogen engine will still produce this kind of pollution.
Piper looks to be pretty heavy duty. How about something simple that is good for day-to-day use?
Try Overflow (http://freespeech.sourceforge.net/overflow.html), it's the standalone (non-distributed) processing layer in Piper. It's simpler, and it has its own GUI.
2.95.2 is an *official* gcc release, which is also OK for a kernel. It's been the compiler for mandrake 7.0 to 7.2 (don't know about other distros). The 2.96 kernel shipped with RH 7 is not official at all. There has never been a gcc 2.96 release.
At least, they could have chosen something that's binary compatible (I'm thinking C++ ABI) with 2.95.2.
The ABI issue is not as much of a deal as some people would want you to believe
Well, it means that since I develop my (C++) software with Mandrake 7.2 (gcc 2.95.2), and I *need* to make shared libraries (plugins), RH 7 people cannot use the binaries I build. That's the deal.
I though they would have had enough complaints to switch back to 2.95.2, but no... Anyone knows whether that a least the same 2.96 (compatible C++ ABI) as the one shipped with 7.0?
I can't wait for gcc 3.0 to be released and the C++ ABI to be frozen for a while.
We need unions. That is why its the united states of america.
I'm sorry, but I have to comment on that piece of patriotism... it's just that there are also unions outside of the united states. And AFAIK, US didn't invent it (UK, I think), nor is it the country with the most unions.
You need... a new distro. Of course, it's always possible to do the upgrade, but there's going to be way too much stuff that will need to be installed. It's much simpler to re-install a new distro than to look for all the compatibility/utilities problems... I suggest you wait for your favorite distro to ship with a 2.4.x kernel and install it.
I'm guessing this will be the next step, the only totally sure way of preventing copying is to ban all read-write drives. Soon, you're going to buy a read-only HD with windows pre-installed and that's going to be it.
Of course, you'll also need copy-protected RAM and registers, and...
What the f... let's get back to our good ol' typewriter/wax cylinder...
Slashdot Mirror
Hydroelectric, wind, solar, geothermal
Let's see... Hydroelectric power floods huge areas of land and also creates mercury pollution (don't remember by which bio-chemical process)
Wind power is limited (You can't generate power for a whole country) and cause pollution by noise.
Solar power, although it looks "clean" also creates a lot of pollution because the solar cells are made of toxic chemicals.
Geothermal, like wind power is limited in power.
So far, there's no magical energy source. It would be nice to have a clean mass-to-energy converter (E=mc^2), but right now, there are lots of technical problems (like finding a source of anti-matter!) so it's not going to happen in a near future.
...I totally for this idea. You would need to use a different key then then one used for DVD's, but nothing prevents you from changing you $HOME/.csskey ...
I'd worry about a smart thief who decides to jam a person's cell-phone just prior to mugging them.
:-)
Sure, no thief would use a jammer if jammers are illegal... You could be fined for using a jammer while committing a crime
There are laws that say that switching the price tags on merchandise to get a lower price is theft
The equivalent of wwitching the price tags would be cracking *their* server to change the price database. This is like shopping for a $1000 item and, when at the cash saying: "That was $500, right?". It the dealer accepts, you have bargained, not stolen.
I know all that... I said that to simplify things I was going to work in decimal, although (duh!) de CPU works in binary.
OK, I'm not talking about "standard" code with no library calls. If you get different results for a float calculation on two different platforms, it's most likely because:
- You've got an uninitialized variable that "happened" to have a value of 0 with some compiler/platform
- A comparison between two floats (a == b), which you should never do.
- An array bounds error, which can sometimes (if you're lucky) not overwrite any useful data (but does with another compiler/platform)
- Your trying to use things (int)10*.7 in some computation...
...you get the point.
I think you did not understand anything at all from my several posts! THIS IS NOT A BUG, it's a feature! You cannot make the assumption that such float calculation will be exact to the last digit, period. If you round to the nearest integer, you'll get the right result, all the time. But when you make such stupid assumptions, you're just asking for trouble.
.6*10 = 6.
If you want to convince me that's a bug, go look up in the C language definition and find the place where they guaranty you that these kinds of calculations has to give what you're expecting. There's simply no guaranty of that, that's all. AFAIK, the only float calculations that are required to be exact (IEEE spec or something like that) are those that involve integer numbers, like 2.0 + 3.0 = 5.0... and certainly not
I hope you get it now.
OK, let's go... (with my previous 3 * .333333 example)
.333333 (6 digits in the register) in register and multiply by the 3 that's in memory. The result is .999999. When you store that in memory, it is rounded to 4 digits, giving 1.000, which when converted to int, gives 1.
.3333 (4 digits in memory), you get .999900 in the register. When you store that in memory, you get .9999, which once conterted to int gives you 0.
We'll work in decimal, so transpose this to binary for a real CPU. Let's say your "float" (as stored in memory) has 4 digits and your float registers can hold 6 digits (a double is 64 bits, a register is 80 bits).
If you load
Now, if you have 3 in the register and multiply by
The only thing that changed is what goes to register and what goes to memory. I'm not saying this is exactly what happens in your example, but it's probably something similar.
BTW, if you look at the gcc man page, there's an option called -ffloat-store which deals with registers that are larger than the memory representation of the float number.
There's nothing strange in your example. It looks strange because in the decimal system, .7 is easy to represent. What if I asked you to compute (3 * .3333333333), you'd say .9999999999 and if I asked you (int)(.9999999999), the answer would be 0. However, when I said .3333333333, I meant 1/3, but there's no way you could have known. In (binary) float representation, .7 is a periodic number, just like 1/3 in the decimal representation. That's why you need to expect wierd (random) outputs when you compute stupid things like (int)(10 * .7).
However, consider explaining that 10 equals 9 for small values of 10 only on Linux distros out of dozens of other platforms to someone that was being tortured while doing a C assignment.
In case you didn't read my other comment, this have nothing to do with Linux, since I could reproduce the same thing on Solaris x86 and I'm pretty sure I'd also get that with gcc/Win32. The way your code is, luck is the most important factor is determining whether it'll work or not! Regardless of the platform (I bet you could find another similar example that would produce 10=10 on your linux setup and 10=9 on other setups).
...and BTW, I tried on solarix x86 with gcc 2.95.2 and also got 10 = 9, so this is not even an OS issue. It's all about a bad programming practice that produces bad results with a certain compiler/CPU combination (using the same gcc version on solaris/SPARC gives 10=10). That's all there is to it.
If a certain program doesn't produce the same result with different compilers/platforms, the most like cause is not a bug in the compiler, but an undefined behaviour caused by a badly written program.
The value of: (int) (((60/6)*0.3) + (10*0.7)) can be either 9 or 10, depending on when the float values are moved in/out the floating point registers (which are 80 bits instead of 64 bits for a double). Your compiler cannot guaranty the result and you should no assume that the result is 10, unless you round to the nearest integer (instead of casting to an int, which is equivalent to a floor).
Therefor, it's not the compilers fault it this problem happens, it's your fault if you make those kind of assumptions (It's the same reason why you should almost never use == when comparing 2 floating point numbers).
...no offense, but that's why I don't want to work in the US, although I could easily have a x2 on my net salary. I think my values are sufficently different from there to significantly decrease my quality of life) and that's the main reason I choose to stay in Canada.
One thing you need to add: Things like Ozone and nitrogen oxydes aren't created by the fuel itself, but by the heat involved in the combustion. It's likely that a Hydrogen engine will still produce this kind of pollution.
What they don't tell....
is that they've gotten 8:1 compression on *unicode* english ASCII text.
Piper looks to be pretty heavy duty. How about something simple that is good for day-to-day use?
, it's the standalone (non-distributed) processing layer in Piper. It's simpler, and it has its own GUI.
Try Overflow (http://freespeech.sourceforge.net/overflow.html)
2.95.2 is an *official* gcc release, which is also OK for a kernel. It's been the compiler for mandrake 7.0 to 7.2 (don't know about other distros). The 2.96 kernel shipped with RH 7 is not official at all. There has never been a gcc 2.96 release.
At least, they could have chosen something that's binary compatible (I'm thinking C++ ABI) with 2.95.2.
The ABI issue is not as much of a deal as some people would want you to believe
Well, it means that since I develop my (C++) software with Mandrake 7.2 (gcc 2.95.2), and I *need* to make shared libraries (plugins), RH 7 people cannot use the binaries I build. That's the deal.
GCC 2.96-RH
I though they would have had enough complaints to switch back to 2.95.2, but no... Anyone knows whether that a least the same 2.96 (compatible C++ ABI) as the one shipped with 7.0?
I can't wait for gcc 3.0 to be released and the C++ ABI to be frozen for a while.
...then MS Office for .NET sounds a lot like Corel Office for Java, which was a total disaster... Wil history repeat itself?
We need unions. That is why its the united states of america.
I'm sorry, but I have to comment on that piece of patriotism... it's just that there are also unions outside of the united states. And AFAIK, US didn't invent it (UK, I think), nor is it the country with the most unions.
I looked at what the guys think the algorithm is... and if they're right, it's one of the stupidest algorithm I've ever seen.
Out of the two best programmers that I know personally, one has a doctrait, the other dropped out of a fine institution.
;-)
...and out of the two best programmers that I know, one is my brother, therefore, 50% of the programmers are my brother
Sorry, but with a sample that large (2), don't try to draw conclusions...
You need... a new distro. Of course, it's always possible to do the upgrade, but there's going to be way too much stuff that will need to be installed. It's much simpler to re-install a new distro than to look for all the compatibility/utilities problems... I suggest you wait for your favorite distro to ship with a 2.4.x kernel and install it.
I'm guessing this will be the next step, the only totally sure way of preventing copying is to ban all read-write drives. Soon, you're going to buy a read-only HD with windows pre-installed and that's going to be it.
...
Of course, you'll also need copy-protected RAM and registers, and
What the f... let's get back to our good ol' typewriter/wax cylinder...