Re:Issues with the euro in day-to-day life
on
The Euro
·
· Score: 1
The 1-2.5-5 system (as we have in The Netherlands) is mathematically just as efficient: just multiply everything by 2 and you get 2-5-10, which fits exactly in the 1-2-5-10-20-50 system.
The most efficient system (in terms of number of coins need for an arbitrary transaction) would of course be 1-3-9-27-81-... but since we have 10 fingers that would also be a little awkward.
Re:Good question. Simple answer.
on
The Euro
·
· Score: 1
The currencies have been locked since January 1, 1999. So for the last three years, these 12 currencies have been 12 different representations of the same thing.
Re:Picture of bills with US bill
on
The Euro
·
· Score: 1
It was the last 'new' note, issued in 1997. We could have done without it, but they probably decided it was worth the trouble for the remaining 4-5 years.
Btw, if you think the Euro notes are colorful, you've never seen the more recent Dutch notes. I think the Dutch designer was also in the race for the design of the Euro notes, but unfortunately that task went to some Swiss guy.
Re:Its recession if they don't join
on
The Euro
·
· Score: 1
Uh... you're both saying the same thing.
The pound is valued too high wrt other currencies, therefore British exports are not competitive, making the UK a net importer.
They should be hammered if they effectively override the quality settings made by the user in the q3a settings menu. And that's what ATI's drivers did...
It's just plain cheating. If the user is willing to sacrifice image quality for better performance he can easily change those settings himself. There is absolutely no reason why the driver should do that for him (except to get better results in benchmarks).
Sorry, I should have read the article you responded to. It seems that _that_ guy was confused by the two types of write caching (calling the kernel write caching dangerous, which it is not... while the disk write caching can in fact defeat the purpose of a JFS).
There are two kinds of write caching: within the kernel, and within the drive. Only the latter needs to be disabled to ensure proper functioning of a JFS.
In your example, the kernel will let you believe it wrote the 500mb to the single drive, without actually sending this data to the drive. That is ok. Now when you type 'sync' it will really write the 500mb out and then the kernel will think the 500mb is physically on the magnetic platter. But that is *wrong* when write caching is enabled within the disk!
Of course a disk will usually not have much more than a meg or so of cache.
Well, there are sound APIs, and MS has DirectPlay which helps with network code and apparently offers voice over IP. And of course there's Direct3D as alternative to OpenGL.
This was certainly true for old versions of gcc/g++ (in the 2.7.2 days), but one of the goals of gcc-3.0 will be to support 100% of the C++ standard. Current versions (2.95) are already quite close to it, possibly closer than most commercially available compilers.
Sure P4 optimization isn't perfect yet. Try to find a compiler with perfect P4 optimization in the shop.
If mangling of files would get around CPRM, then a simple change to the filesystem would disable CPRM. On the linux-kernel mailing list I read that this would not be possible.
Therefore, it looks like _anything_ you write to disk will need to be signed before the controller accepts it, so effectively you won't be able to store data you generate yourself.
Ok so that's madness... but is there any other explanation?
According to the article, the P4 (chipset) bug does apply here. If I read it right, the problem occurs when using a PCI videocard. Hemos' comment does not seem to be correct.
On the current P4 chipset you can't use a PCI videocard without major slowdowns and image corruption. So effectively you are stuck to a single AGP card. That's what the article says.
During the days that we were blown away with being able to record TV shows, the _three_ systems (VHS, Betamax and Philips' Video 2000) basically did equally well (umm Video 2000 at least in Europe, don't know about the US). But as soon as people started to rent videos they found they needed a VHS because most movies came out for VHS only. Especially so for porn. And yes, everything had to be verified before it could be put out on Betamax.
The increased record times probably didn't matter too much... Video 2000 from the start (or at least soon after it had come out) supported 4 hour videotapes that could be used on both sides (for a total of 8 hours).
The interesting thing about this calculation is that it did *not* give all the digits up to the quadrillionth digit. The algorithm used really computes only the Nth binary digit. The algorithm is based on a formula for Pi that was found using one of the "10 algorithms of the 20th century". This algorithm (sorry I can't think of the exact name at the moment) is used to find relations between real numbers. They used it to find a relation between Pi and certain fast-to-compute numbers.
The 2GB limit is due to limits of the linux VFS (virtual file system) layer. These limits are gone in 2.4 kernels. I doubt that even the recent 2.2 kernels have the capability to go over 2GB, but RH 7.0 might prove me wrong.
Slashdot Mirror
The 1-2.5-5 system (as we have in The Netherlands) is mathematically just as efficient: just multiply everything by 2 and you get 2-5-10, which fits exactly in the 1-2-5-10-20-50 system.
The most efficient system (in terms of number of coins need for an arbitrary transaction) would of course be 1-3-9-27-81-... but since we have 10 fingers that would also be a little awkward.
The currencies have been locked since January 1, 1999. So for the last three years, these 12 currencies have been 12 different representations of the same thing.
It was the last 'new' note, issued in 1997. We could have done without it, but they probably decided it was worth the trouble for the remaining 4-5 years.
Btw, if you think the Euro notes are colorful, you've never seen the more recent Dutch notes. I think the Dutch designer was also in the race for the design of the Euro notes, but unfortunately that task went to some Swiss guy.
Uh... you're both saying the same thing.
The pound is valued too high wrt other currencies, therefore British exports are not competitive, making the UK a net importer.
The optimizations impact image quality.
Set quake3 to low quality in the in-game menu and you get similar performance as with ATI's hack. And equally degraded image quality.
They should be hammered if they effectively override the quality settings made by the user in the q3a settings menu. And that's what ATI's drivers did...
It's just plain cheating. If the user is willing to sacrifice image quality for better performance he can easily change those settings himself. There is absolutely no reason why the driver should do that for him (except to get better results in benchmarks).
It's sufficient to set all games to 'low-quality' since that's basically what the ATI drivers are doing.
It's windows media video. On linux, play it with mplayer.
Sorry, I should have read the article you responded to. It seems that _that_ guy was confused by the two types of write caching (calling the kernel write caching dangerous, which it is not... while the disk write caching can in fact defeat the purpose of a JFS).
There are two kinds of write caching: within the kernel, and within the drive. Only the latter needs to be disabled to ensure proper functioning of a JFS.
In your example, the kernel will let you believe it wrote the 500mb to the single drive, without actually sending this data to the drive. That is ok. Now when you type 'sync' it will really write the 500mb out and then the kernel will think the 500mb is physically on the magnetic platter. But that is *wrong* when write caching is enabled within the disk!
Of course a disk will usually not have much more than a meg or so of cache.
Maybe UT2 will be better, but graphically UT certainly doesn't match q3a. Plus I can't strafe jump in UT :).
Well, there are sound APIs, and MS has DirectPlay which helps with network code and apparently offers voice over IP. And of course there's Direct3D as alternative to OpenGL.
The UT guy's name is Tim Sweeney, if I spell that right ;)
I'm not exactly sure if he did the initial port to linux.
The number of CDs would not increase at all... the q3a binary itself is only about a meg in size, the rest is platform independent data.
Having to support official ports is where the real problem lies...
Fortunately we can still play it on linux with the q3a-1.27g-beta patch. (Actually, both the demo and the full windows version run fine under wine.)
If they could just put both the windows and linux binary on the same CD (or is that DVD for D3)...
Note that these were likely the words of a Belgian AC that submitted the story...
This was certainly true for old versions of gcc/g++ (in the 2.7.2 days), but one of the goals of gcc-3.0 will be to support 100% of the C++ standard. Current versions (2.95) are already quite close to it, possibly closer than most commercially available compilers.
Sure P4 optimization isn't perfect yet. Try to find a compiler with perfect P4 optimization in the shop.
It does *not*.
A long time ago it did, but those days have past.
If mangling of files would get around CPRM, then a simple change to the filesystem would disable CPRM. On the linux-kernel mailing list I read that this would not be possible.
Therefore, it looks like _anything_ you write to disk will need to be signed before the controller accepts it, so effectively you won't be able to store data you generate yourself.
Ok so that's madness... but is there any other explanation?
According to the article, the P4 (chipset) bug does apply here. If I read it right, the problem occurs when using a PCI videocard. Hemos' comment does not seem to be correct.
On the current P4 chipset you can't use a PCI videocard without major slowdowns and image corruption. So effectively you are stuck to a single AGP card. That's what the article says.
Judging from the amount of dupe postings, most posters don't read slashdot, let alone the articles.
During the days that we were blown away with being able to record TV shows, the _three_ systems (VHS, Betamax and Philips' Video 2000) basically did equally well (umm Video 2000 at least in Europe, don't know about the US). But as soon as people started to rent videos they found they needed a VHS because most movies came out for VHS only. Especially so for porn. And yes, everything had to be verified before it could be put out on Betamax.
The increased record times probably didn't matter too much... Video 2000 from the start (or at least soon after it had come out) supported 4 hour videotapes that could be used on both sides (for a total of 8 hours).
The interesting thing about this calculation is that it did *not* give all the digits up to the quadrillionth digit. The algorithm used really computes only the Nth binary digit. The algorithm is based on a formula for Pi that was found using one of the "10 algorithms of the 20th century". This algorithm (sorry I can't think of the exact name at the moment) is used to find relations between real numbers. They used it to find a relation between Pi and certain fast-to-compute numbers.
The 2GB limit is due to limits of the linux VFS (virtual file system) layer. These limits are gone in 2.4 kernels. I doubt that even the recent 2.2 kernels have the capability to go over 2GB, but RH 7.0 might prove me wrong.