Correct. The article got that part wrong. And it's an important one, I'd say: we never had to go and seize private property, since it was all public in the past.
In the past, all the electricity in Portugal was provided by a public company (EDP) that had a monopoly on all three aspects: production, transmission and distribution. Eventually, to foster not just renewable energy but mainly competition it was opened up in the following way: The transmission network (the high voltage high capacity lines) were to remain public property; these were taken from EDP and assigned to a new public company (REN) which was tasked with managing it. Even with REN being privatized, the transmission network is to remain public property and the Government will retain controlling rights in REN.
On the other hand, the production and distribution business was opened up to competition. But EDP was left with all the existing production and distribution assets, so it still is by far the largest player and has a "de facto" monopoly in distribution. As such, the distribution sector is still subject to Government regulation. Likewise, the Government still retains controlling rights in EDP.
All of these things have contributed to make it possible to put the incentives for renewable energy in place.
As many others, I don't find this tool very interesting. The writeback mechanism lacks any notion of write barriers or whatsoever and therefore the information on disk is very likely to become *extremely* corrupted in case of an unexpected system crash. Therefore, I find it unusable for any data I want to keep on disk.
For data I don't want to keep on disk.. we already have ramdisk and tmpfs.
1 This device will actively pre-load your entire disk into ram, a normal filesystem won't. 2 Event without sync(), a normal filesystem usually has limits on how many pending data it keeps, after which it'll start throtling the application's write requests. This device hasn't any. 3 Event without sync(), a normal filesystem retains some ordering when it writes data to the disk. Keeping that order requires more RAM to keep the pending data and a less efficient use of disk I/O. This device keeps no order.
Of course, the reason of (2) and (3) is that said normal filesystems try to minimize data loss and keep themselves consistent in case of an unexpected failure. With this device, an unexpected failure may very well yield a filesystem corrupted beyond any recovery.
ARIN and RIPE's current policy is to only give new blocks to those who demonstrate they need them. However, the policy does not include reverting old huge allocations such as those because they're only sparsely used.
Some address blocks were recovered in the past, but that was a more or less voluntary process. The remaining wasteful allocations are not easy to recover because, despite being sparsely used, recovery involves renumbering extensive networks and the owners are not going to give them up without a fight.
Essencially, it all leads to the same point: in the near future, having a globaly routable IPv4 address is going to become a more expensive privilege.
No, it's not all bad. GM3X is a sensible solution, with a different set of tradeoffs than FB-DIMM.
In both FB-DIMM and G3MX case you have the basic concept: Memory Controller --- buffer --- DRAM The difference is where the buffer is. On G3MX is't on the board and it can handle 1 or 2 DRAM modules. On FB-DIMM it's on the DIMM itself and can only handle one module but buffers can be daisy chained.
G3MX allows you the flexibility of having up to 2 modules per channel without an extra latency. With FB-DIMM, each modules in the channel worsens your average latency. The only way to add more modules without worsening latency is adding more channels. But each channel requires quite a bit of sillicon on the memory controllers, so it's not the best solution in the world.
OTOH, FB-DIMM allows up to 8 modules per channel. G3MX only allows two. The only way to get more modules with G3MX is adding more channels. Not only each channel costs a bit of sillicon as I mentioned earlier (I'm ignoring the fact that it actually costs you an entire CPU), it also costs quite a bit of board area too. DDRx channels require a lot more traces and board area than the FB-DIMM or HT links. We'll problably see some servers with the G3MX buffers and memory slots in daugher boards instead of mainboards, which will mititage the board area problem.
I don't think G3MX chips will have any kind of intelegence. They'll just be "dumb buffers", like FB-DIMM's AMBs or E8500's XMBs. All the intelegence will be back at the memory controller, in the CPU die as usual: which pages will be open, what should be prefetched, etc.
Intel, IBM et all have been using similar memory extenders on server chipsets for quite some time. For example, check the XMBs on Intel's E8500 chipset.
The reason why Intel has moved from such memory extenders and pushing FB-DIMM is simple though: there won't be a 4th DIMM on G3MX. DDR3 isn't likely to support more than 2 registered DIMMS per channel, 4 rank each.
Not the same kind of money sink. Due to a naive choice of partners and deals (mainly the CPU and GPU), Microsoft was unable to drive Xbox's manufacturing costs down the same way the competition was. Thus, it was impossible to Microsoft to ever compete in price with PS2 and not take a significant loss in each Xbox sold.
Despite it's other issues, XBox360 does not suffer of this issue. A few months ago, MS was already selling each Xbox360 for a small profit. It will take them years to recover the initial investment, which are being agravated by these warranty issues, but there's a good chance that, in a foreseeable future, Xbox360 will turn a net profit for MS.
Because DVB/HDTV channels carry MPEG-2 encoded video and sound, while DVI/HDMI carry raw video. There are two problem's with using DVB/HDTV as general interface between A/V devices. First, you need to reencode non-MPEG-2 sources into MPEG-2, which requires a lot of computing power and incurrs in some quality loss. Second, you're limited by HDTV quality and you still need a better interface to handle your BluRay/HD-DVD player.
Sorry, you're the proof we need the lame names (Ki, Mi, etc).:) Transfer rates are usually described using the "base 10" prefixes. For example, if you consider 1GB of DDR2 with a 6.4GB/s transfer rate, it means you 2^30 bytes of RAM with a 6.4 * 10^9 byte/second transfer rate.
The problem with using k, M , G, etc for 2^10, 2^20, 2^30, etc is that there has never been a consistent usage even in the computer industry. RAM/ROM sizes have traditionally used the prefixes in the "binary" sense. The 3.5" floppy also used the binary prefix and Microsoft adopted it for MS-DOS. Thus, using the prefix in the "binary" sense was made quite popular.
But many other uses in the computer industry have traditionally kept the "decimal/SI" sense. Magnetic storage size has usually been refered this way since the time of magnetic tapes. As I said before, transfer rates also have traditionally been expressed in the "decimal/SI" sense.
I agree that it is most usefull to use prefixes based on powers of 2, but we do need the lame names to clearly state that we're using the prefixes in the "binary" sense.
Users are still running the 32 bit version of Internet Explorer for flash support. They just don't know about it.:) Like Linux, Windows for x86-64 supports mixing 32 and 64 bit applications in the same system. Some independent software vendors feel that there is little point in porting (some of) their applications to 64 bit and thus will take their time in porting them. Among them, Adobe has no roadmap to release 64 bit Flashplayer or Reader for either Windows or Linux.
What the other poster was refering to is a phenomenon called "loudness wars". Most music labels and/or artists are keen to compress the dynamic range of the music as much as they can. This is done with a device (or piece of software nowadays) called a "compressor": it's essencially a sort of variable gain amplifier that amplifies the music in the quieter parts and Technically, the goal is to make the average sound level as closer to the maximum sound level as possible.
Experience wise, this makes the music sound "louder" when played at a given volume setting on your amplifier. Thus, it tends to stand out agains less "compressed" music. It's also "more listenable" in some environments, such as the car or the street.
With the improvements in technology, albums have been released with the average level just 10dB below the maximum. All of this while CDs allow for a dynamic range of 96dB!!!!
However, when you listen to a lot of music this quickly becomes unpleasent and tiresome. Actually, highly compressed music is not very inviting to crank your amp to the max and ignore the complaints of the neighbours. Less compressed stuff is so much better.
And what has vynil to do with this? Paraphrasing one sound engineer, "vynil's best feature is that it can't be played in a car". The music industry has always made a practice of mastering the same album in different ways for differnt medium, for multiple reasons, since the time of vynil, cassetes and 8-track.
Nowadays, most albums on CD have a lousy dynamic range due to excessive compression, while vynil, SACD or DVD-A editions are blessed with a better mastering.
This is why you have a bunch of people swearing that vynil sounds better and a bunch of people swearing that nothing can sound much better than a CD.
If I understand you correctly, you're proposing to hide the disk driver behind your "LVM" driver. This is a problem because/dev/hda provides a number of ATA/ATAPI specific system calls. The same is true for devices representing SATA, SCSI or whatever drives. This means your "LVM" needs to know about those system calls.
And the Linux kernel may have a problem with the entire ideia of "hiding" drivers: how can your "LVM" reference the ATA driver while the remaing kernel thinks/dev/hda means your "LVM" driver?
Another aproach would be adding snapshotting capabilities to your disk driver.
Then again, you're making all this mess just to hide stuff from users.:)
Depends. A transactional engine provides four features (as you likely know): Atomicity, Consistency, Isolation, Durability Some are fairly easy to work arround in MyISAM, some I have no idea how. Consistency is "easy", just make sure your application doesn't put inconsistent data in the database. Atomicity is doable. In MyISAM, single row updates are atomic. You need to design your database in a way that any multi-row updates are marked valid by a single row update. The database design will be more complex and might hurt performance a lot. Durability might be doable too, by combining the former technique with a liberal use of FLUSH TABLES but should be murder on performance. Isolation.. I have no bloody idea on how to simulate.
Doing that is awfully slow for a database that is bigger than tiny. To get decent performance you need some sort of indexing, which is what I think the other poster was refering to.
MySQL has a fulltext index feature (only for MyISAM tables currently) that does just that. Most other RDBMS also have similar. Firebird still hasn't any, thus applications need to build and keep their own indexes, which is often slower and requires more storage space than the RDBMs integrated fulltext search indexes.
Then again, both USA and UK rank way worse on privacy matters that the rest of western europe.. And I think there's a fundamental problem with USA and UK's system has something to do with it. Here's a bit of reasoning. But of course, take all this with a large grain of salt.
Most people want accountability. Not surveillance, just accountability. When something bad happens, people want a paper trail that can be followed back to the responsibles. They want answers to simple questions like "Who owned the car that ran over my child?" As far as I can see it, the american system does allow people to legally live without leaving no a very limited paper trail. But there are two problems: First, because of the need of accountability, living without a paper trail is living on the edge of society: don't drive a car, don't own a car, don't own a house, etc. Most people don't live like that and thus they leave a hell of a paper trail, which can always be abused by a future government that doesn't respect your privacy. Second, the american system is too vulnerable to both innocent errors and abuse, breaking the principle of accountability. And the ugly corollary of this: in order to try and get that some of accountability back, the system resorts to datamining. Too much information going back and forward too many entities, public and private, with too litte regulation.
On continental western europe, citizens are indeed forced to leave a clear and undeniable paper trail for many actions. But that clear paper trail is also protected by privacy laws that regulate how and which parts of that information is managed, even between parts of the Government. Even if in an hypothetical future a government with no respect for privacy comes to power and chooses to revert all those privacy laws, most western europeans are no worse than most americans: in practice, in both sides of the Atlantic, normal people leave a large paper trail to be abused by such government.
With 6to4, 32 bits of your IPv6 address are the same as your IPv4 address. So, no -- you don't get a static IPv6 address if you gave dynamic IPv4 address with 6to4. You need a traditional tunnel for that.
It's not on any RFC. That was the point of the other post: although the protocol itself hasn't changed, TCP has been improved over the years by improving the algorithms used.
PowerPC 970, also know as G5, was indeed an adaptation of the POWER4 microarchitecture. However G3 has nothing to do with any POWERx microarchitecture and G4 wasn't even a IBM chip, it was a Motorola one.
A part tolerance is usually a result, not a result's error. You made some calculations, problably arrived at an upper tolerance value like 0.0134AAA±0.00000BB, decided the result was good up to 0.0134 and thus specified it as 0.0134. Similar for lower tolerance. I'd have done the same thing.
I had 30 hypothetical values of Xi±0.01, added them all together and arrived at a result of RRRRRRR.RR±0.5477225575... Since Xi were specified to the second decimal place, I decided there isn't any significance of R beyond the second decimal place, so I wrote it as RRRRRRR.RR±0.55. Even RRRRRRR.R±0.6 migh be aceptable.
That rule of thumb is a pernicous source of error if you are doing repetitive calculations. Why add more error to your results if you don't have to?
Now try doing a 30 step calculation, rounding off after each step. Try it with and without rounding.
Yes, I know the the significant digits rule are a source of problem since they don't always ask for enough digits. But violating them is sure way for ugly results.
Let's say, that Y = X1 + X2 +... + X30, with Xi±0.10.
Even without any rounding in the calculation, the result will have an error of ±0.5477225575...
But I'd represent that number as RRRR.RR±0.55, it's pointless to have any more.
I don't remember how to calculate the rounding errors and I'm not going to look it up now but with enough guard digits, the round error won't show up in that representation. Which is my point all along: there is such thing as enough guard digits.
You haven't seen the demand because, as this thread illustrates, few understand the problems they get into with low precision.
That's a fallacy: you're stating that we don't know we're talking about because we have a diferent opinion.
Cray, NEC and IBM's customers don't understand the issue either because neither of their latest custom CPUs support such thing (even though Cray did support so in the distant past).
Nor HP and CERN's group who wrote a high performance vector library for IPF with 0.502 ulp acuracy in most or all functions, but ignored 80 bit floats.
Performance is for gamers where wrong answers don't matter. For numerical analysts, getting the correct answer is far, far more important than getting a quick wrong answer.
That's complete bullshit.
Maybe you should try to tell that to my friend who spent the entire chrismas vacation squeezing out every last minute of CPU time he was granted on a cluster.
More often than not, a good enough answer in reasonable time is better than a acurate answer in a unreasonable time. That's why you see people a never ending increase in the complexity and acuracy of simulations. It's not that people didn't want them before, they just couldn't aford them.
It doesn't require 80 bit floating point on architectures that don't have it. It requires that the greatest precision supported by the architecture must be supported.
My bad then, I can live with this. We already have so in C/C++, except in Windows.
The round off error doesn't matter if the error introduced by round off is smaller than the error in the value.
The rule of thumb I learned is that intermediate results should have one more digit than the significant digits. Your fellow engineer violated that rule, hence the catastrophic results.
If I have two measurements, X and Y with an error of 0.1 and I calculate X+Y, it doesn't really matter that I use a representation with an error of 0.01 or 0.0001.
Yes, the result of X+Y will differ but in both cases the true value will be somewhere in (X+Y)±0.2.
The net result is that I haven't seen much demand for >64 bit floats, even though in Linux C's long double does translate to 80 bit on x86 and IPF.
Even supercomuters made with custom made CPUs (which often require code to be tweaked anyway) have ignored >64 bit floats for over a decade now.
As for SSE being targeted at games, the design of x87 has never been much liked because it's complex to deal with, both for the hardware implementations and for the software that uses it, mainly due to the stack based aproach.
It's being overall disfavoured by SSE2 which provides a more common flat register file.
Both Linux and Windows x86-64 bit ABI rely on SSE2 for 32 and 64 bit floats.
Microsoft's documentation even says that, for 64 bit applications, x87/MMX register file isn't saved across context switches, although the observed behaviour is that it does indeed save the register file.
It's very likely that in the near future x87 performance will become a second class issue for x86 designers. Actually, Pentium 4 already did so, since it didn't implement FXCH as a "free" instruction.
It's your language but due to all of the above I think requiring 80 bit floats places an uneeded burden on non-x86/IPF implementations and on it's future.
While x86's x87 unit supports 80 bit floats, the use of x87 is depreceated in favor of the more sane SSE2 wich does not support 80 bit floats.
And no, x86 isn't mainstream enough. There's a world of RISC embedded CPUs out there that do not support 80 bit format.
Your example of the engineer rounding off results to two decimal places is a good example of how round off can adversely afect results but one must remember that roundoff is not necessarly the limiting factor in the error of your results. With 64 bit floats, the most common source of error I see people stumbling into is not the rounding imposed by the floating point format but either measurment error or aproximation error. The measurment error comes from the fact that usually either the input will be taken from the real world or the output will be compared to the real world or both. And measuring the real world involves an error, which will then propagate throughout the calculus. The aproximation error comes from the fact that often our calculations involve expressions that can't be analytically resolved or are too expensive and have to be replaced by aproximations, which have some error. This is not to say that more precision isn't ocasionally usefull. Obviously, someone also thought so when x87 was created. Some Cray supercomputers had 96 bit floats too. But mostly, it hasn't seem much demand. Even most supercomputers with custom CPUs have only 64 bit floating point.
It's also possible that if demand for a floating point format with higher precision comes, it will be a 128 bit format, not the actual 80 bit one.
Slashdot Mirror
^^
Correct. The article got that part wrong. And it's an important one, I'd say: we never had to go and seize private property, since it was all public in the past.
In the past, all the electricity in Portugal was provided by a public company (EDP) that had a monopoly on all three aspects: production, transmission and distribution.
Eventually, to foster not just renewable energy but mainly competition it was opened up in the following way:
The transmission network (the high voltage high capacity lines) were to remain public property; these were taken from EDP and assigned to a new public company (REN) which was tasked with managing it.
Even with REN being privatized, the transmission network is to remain public property and the Government will retain controlling rights in REN.
On the other hand, the production and distribution business was opened up to competition.
But EDP was left with all the existing production and distribution assets, so it still is by far the largest player and has a "de facto" monopoly in distribution. As such, the distribution sector is still subject to Government regulation. Likewise, the Government still retains controlling rights in EDP.
All of these things have contributed to make it possible to put the incentives for renewable energy in place.
I agree.
As many others, I don't find this tool very interesting.
The writeback mechanism lacks any notion of write barriers or whatsoever and therefore the information on disk is very likely to become *extremely* corrupted in case of an unexpected system crash.
Therefore, I find it unusable for any data I want to keep on disk.
For data I don't want to keep on disk.. we already have ramdisk and tmpfs.
1 This device will actively pre-load your entire disk into ram, a normal filesystem won't.
2 Event without sync(), a normal filesystem usually has limits on how many pending data it keeps, after which it'll start throtling the application's write requests. This device hasn't any.
3 Event without sync(), a normal filesystem retains some ordering when it writes data to the disk. Keeping that order requires more RAM to keep the pending data and a less efficient use of disk I/O. This device keeps no order.
Of course, the reason of (2) and (3) is that said normal filesystems try to minimize data loss and keep themselves consistent in case of an unexpected failure.
With this device, an unexpected failure may very well yield a filesystem corrupted beyond any recovery.
Under Linux, it's possible to use it as ramdisk but you need to start your system without 3D acceleration I think.
ARIN and RIPE's current policy is to only give new blocks to those who demonstrate they need them.
However, the policy does not include reverting old huge allocations such as those because they're only sparsely used.
Some address blocks were recovered in the past, but that was a more or less voluntary process.
The remaining wasteful allocations are not easy to recover because, despite being sparsely used, recovery involves renumbering extensive networks and the owners are not going to give them up without a fight.
Essencially, it all leads to the same point: in the near future, having a globaly routable IPv4 address is going to become a more expensive privilege.
No, it's not all bad. GM3X is a sensible solution, with a different set of tradeoffs than FB-DIMM.
In both FB-DIMM and G3MX case you have the basic concept: Memory Controller --- buffer --- DRAM
The difference is where the buffer is. On G3MX is't on the board and it can handle 1 or 2 DRAM modules. On FB-DIMM it's on the DIMM itself and can only handle one module but buffers can be daisy chained.
G3MX allows you the flexibility of having up to 2 modules per channel without an extra latency.
With FB-DIMM, each modules in the channel worsens your average latency. The only way to add more modules without worsening latency is adding more channels. But each channel requires quite a bit of sillicon on the memory controllers, so it's not the best solution in the world.
OTOH, FB-DIMM allows up to 8 modules per channel. G3MX only allows two.
The only way to get more modules with G3MX is adding more channels. Not only each channel costs a bit of sillicon as I mentioned earlier (I'm ignoring the fact that it actually costs you an entire CPU), it also costs quite a bit of board area too.
DDRx channels require a lot more traces and board area than the FB-DIMM or HT links. We'll problably see some servers with the G3MX buffers and memory slots in daugher boards instead of mainboards, which will mititage the board area problem.
I don't think G3MX chips will have any kind of intelegence. They'll just be "dumb buffers", like FB-DIMM's AMBs or E8500's XMBs.
All the intelegence will be back at the memory controller, in the CPU die as usual: which pages will be open, what should be prefetched, etc.
Intel, IBM et all have been using similar memory extenders on server chipsets for quite some time.
For example, check the XMBs on Intel's E8500 chipset.
The reason why Intel has moved from such memory extenders and pushing FB-DIMM is simple though: there won't be a 4th DIMM on G3MX. DDR3 isn't likely to support more than 2 registered DIMMS per channel, 4 rank each.
Not the same kind of money sink.
Due to a naive choice of partners and deals (mainly the CPU and GPU), Microsoft was unable to drive Xbox's manufacturing costs down the same way the competition was. Thus, it was impossible to Microsoft to ever compete in price with PS2 and not take a significant loss in each Xbox sold.
Despite it's other issues, XBox360 does not suffer of this issue. A few months ago, MS was already selling each Xbox360 for a small profit.
It will take them years to recover the initial investment, which are being agravated by these warranty issues, but there's a good chance that, in a foreseeable future, Xbox360 will turn a net profit for MS.
Because DVB/HDTV channels carry MPEG-2 encoded video and sound, while DVI/HDMI carry raw video.
There are two problem's with using DVB/HDTV as general interface between A/V devices.
First, you need to reencode non-MPEG-2 sources into MPEG-2, which requires a lot of computing power and incurrs in some quality loss.
Second, you're limited by HDTV quality and you still need a better interface to handle your BluRay/HD-DVD player.
Sorry, you're the proof we need the lame names (Ki, Mi, etc). :)
Transfer rates are usually described using the "base 10" prefixes. For example, if you consider 1GB of DDR2 with a 6.4GB/s transfer rate, it means you 2^30 bytes of RAM with a 6.4 * 10^9 byte/second transfer rate.
The problem with using k, M , G, etc for 2^10, 2^20, 2^30, etc is that there has never been a consistent usage even in the computer industry.
RAM/ROM sizes have traditionally used the prefixes in the "binary" sense. The 3.5" floppy also used the binary prefix and Microsoft adopted it for MS-DOS. Thus, using the prefix in the "binary" sense was made quite popular.
But many other uses in the computer industry have traditionally kept the "decimal/SI" sense.
Magnetic storage size has usually been refered this way since the time of magnetic tapes.
As I said before, transfer rates also have traditionally been expressed in the "decimal/SI" sense.
I agree that it is most usefull to use prefixes based on powers of 2, but we do need the lame names to clearly state that we're using the prefixes in the "binary" sense.
Users are still running the 32 bit version of Internet Explorer for flash support. They just don't know about it. :)
Like Linux, Windows for x86-64 supports mixing 32 and 64 bit applications in the same system.
Some independent software vendors feel that there is little point in porting (some of) their applications to 64 bit and thus will take their time in porting them.
Among them, Adobe has no roadmap to release 64 bit Flashplayer or Reader for either Windows or Linux.
What the other poster was refering to is a phenomenon called "loudness wars".
Most music labels and/or artists are keen to compress the dynamic range of the music as much as they can.
This is done with a device (or piece of software nowadays) called a "compressor": it's essencially a sort of variable gain amplifier that amplifies the music in the quieter parts and
Technically, the goal is to make the average sound level as closer to the maximum sound level as possible.
Experience wise, this makes the music sound "louder" when played at a given volume setting on your amplifier.
Thus, it tends to stand out agains less "compressed" music. It's also "more listenable" in some environments, such as the car or the street.
With the improvements in technology, albums have been released with the average level just 10dB below the maximum.
All of this while CDs allow for a dynamic range of 96dB!!!!
However, when you listen to a lot of music this quickly becomes unpleasent and tiresome. Actually, highly compressed music is not very inviting to crank your amp to the max and ignore the complaints of the neighbours. Less compressed stuff is so much better.
And what has vynil to do with this?
Paraphrasing one sound engineer, "vynil's best feature is that it can't be played in a car".
The music industry has always made a practice of mastering the same album in different ways for differnt medium, for multiple reasons, since the time of vynil, cassetes and 8-track.
Nowadays, most albums on CD have a lousy dynamic range due to excessive compression, while vynil, SACD or DVD-A editions are blessed with a better mastering.
This is why you have a bunch of people swearing that vynil sounds better and a bunch of people swearing that nothing can sound much better than a CD.
If I understand you correctly, you're proposing to hide the disk driver behind your "LVM" driver. /dev/hda provides a number of ATA/ATAPI specific system calls. The same is true for devices representing SATA, SCSI or whatever drives. This means your "LVM" needs to know about those system calls.
/dev/hda means your "LVM" driver?
:)
This is a problem because
And the Linux kernel may have a problem with the entire ideia of "hiding" drivers: how can your "LVM" reference the ATA driver while the remaing kernel thinks
Another aproach would be adding snapshotting capabilities to your disk driver.
Then again, you're making all this mess just to hide stuff from users.
Depends. A transactional engine provides four features (as you likely know): Atomicity, Consistency, Isolation, Durability
Some are fairly easy to work arround in MyISAM, some I have no idea how.
Consistency is "easy", just make sure your application doesn't put inconsistent data in the database.
Atomicity is doable. In MyISAM, single row updates are atomic. You need to design your database in a way that any multi-row updates are marked valid by a single row update. The database design will be more complex and might hurt performance a lot.
Durability might be doable too, by combining the former technique with a liberal use of FLUSH TABLES but should be murder on performance.
Isolation.. I have no bloody idea on how to simulate.
Doing that is awfully slow for a database that is bigger than tiny. To get decent performance you need some sort of indexing, which is what I think the other poster was refering to.
MySQL has a fulltext index feature (only for MyISAM tables currently) that does just that. Most other RDBMS also have similar.
Firebird still hasn't any, thus applications need to build and keep their own indexes, which is often slower and requires more storage space than the RDBMs integrated fulltext search indexes.
Then again, both USA and UK rank way worse on privacy matters that the rest of western europe..
And I think there's a fundamental problem with USA and UK's system has something to do with it.
Here's a bit of reasoning. But of course, take all this with a large grain of salt.
Most people want accountability. Not surveillance, just accountability.
When something bad happens, people want a paper trail that can be followed back to the responsibles. They want answers to simple questions like "Who owned the car that ran over my child?"
As far as I can see it, the american system does allow people to legally live without leaving no a very limited paper trail.
But there are two problems:
First, because of the need of accountability, living without a paper trail is living on the edge of society: don't drive a car, don't own a car, don't own a house, etc. Most people don't live like that and thus they leave a hell of a paper trail, which can always be abused by a future government that doesn't respect your privacy.
Second, the american system is too vulnerable to both innocent errors and abuse, breaking the principle of accountability.
And the ugly corollary of this: in order to try and get that some of accountability back, the system resorts to datamining. Too much information going back and forward too many entities, public and private, with too litte regulation.
On continental western europe, citizens are indeed forced to leave a clear and undeniable paper trail for many actions. But that clear paper trail is also protected by privacy laws that regulate how and which parts of that information is managed, even between parts of the Government.
Even if in an hypothetical future a government with no respect for privacy comes to power and chooses to revert all those privacy laws, most western europeans are no worse than most americans: in practice, in both sides of the Atlantic, normal people leave a large paper trail to be abused by such government.
With 6to4, 32 bits of your IPv6 address are the same as your IPv4 address.
So, no -- you don't get a static IPv6 address if you gave dynamic IPv4 address with 6to4.
You need a traditional tunnel for that.
Right click on a MP3 file
Select "Properties"
Select "Open With" tab
Select your application of choice
It's not on any RFC.
That was the point of the other post: although the protocol itself hasn't changed, TCP has been improved over the years by improving the algorithms used.
Of the top 5, only entry number 4 (ASC Purple) is based on POWER5.
PowerPC 970, also know as G5, was indeed an adaptation of the POWER4 microarchitecture.
However G3 has nothing to do with any POWERx microarchitecture and G4 wasn't even a IBM chip, it was a Motorola one.
It's not the same thing.
A part tolerance is usually a result, not a result's error.
You made some calculations, problably arrived at an upper tolerance value like 0.0134AAA±0.00000BB, decided the result was good up to 0.0134 and thus specified it as 0.0134. Similar for lower tolerance.
I'd have done the same thing.
I had 30 hypothetical values of Xi±0.01, added them all together and arrived at a result of RRRRRRR.RR±0.5477225575...
Since Xi were specified to the second decimal place, I decided there isn't any significance of R beyond the second decimal place, so I wrote it as RRRRRRR.RR±0.55. Even RRRRRRR.R±0.6 migh be aceptable.
Yes, I know the the significant digits rule are a source of problem since they don't always ask for enough digits. But violating them is sure way for ugly results.
Let's say, that Y = X1 + X2 +
Even without any rounding in the calculation, the result will have an error of ±0.5477225575...
But I'd represent that number as RRRR.RR±0.55, it's pointless to have any more.
I don't remember how to calculate the rounding errors and I'm not going to look it up now but with enough guard digits, the round error won't show up in that representation. Which is my point all along: there is such thing as enough guard digits.
That's a fallacy: you're stating that we don't know we're talking about because we have a diferent opinion.
Cray, NEC and IBM's customers don't understand the issue either because neither of their latest custom CPUs support such thing (even though Cray did support so in the distant past).
Nor HP and CERN's group who wrote a high performance vector library for IPF with 0.502 ulp acuracy in most or all functions, but ignored 80 bit floats.
That's complete bullshit.
Maybe you should try to tell that to my friend who spent the entire chrismas vacation squeezing out every last minute of CPU time he was granted on a cluster.
More often than not, a good enough answer in reasonable time is better than a acurate answer in a unreasonable time. That's why you see people a never ending increase in the complexity and acuracy of simulations. It's not that people didn't want them before, they just couldn't aford them.
My bad then, I can live with this. We already have so in C/C++, except in Windows.
I'm going to start in the end.
The round off error doesn't matter if the error introduced by round off is smaller than the error in the value.
The rule of thumb I learned is that intermediate results should have one more digit than the significant digits. Your fellow engineer violated that rule, hence the catastrophic results.
If I have two measurements, X and Y with an error of 0.1 and I calculate X+Y, it doesn't really matter that I use a representation with an error of 0.01 or 0.0001.
Yes, the result of X+Y will differ but in both cases the true value will be somewhere in (X+Y)±0.2.
The net result is that I haven't seen much demand for >64 bit floats, even though in Linux C's long double does translate to 80 bit on x86 and IPF.
Even supercomuters made with custom made CPUs (which often require code to be tweaked anyway) have ignored >64 bit floats for over a decade now.
As for SSE being targeted at games, the design of x87 has never been much liked because it's complex to deal with, both for the hardware implementations and for the software that uses it, mainly due to the stack based aproach.
It's being overall disfavoured by SSE2 which provides a more common flat register file. Both Linux and Windows x86-64 bit ABI rely on SSE2 for 32 and 64 bit floats.
Microsoft's documentation even says that, for 64 bit applications, x87/MMX register file isn't saved across context switches, although the observed behaviour is that it does indeed save the register file.
It's very likely that in the near future x87 performance will become a second class issue for x86 designers. Actually, Pentium 4 already did so, since it didn't implement FXCH as a "free" instruction.
It's your language but due to all of the above I think requiring 80 bit floats places an uneeded burden on non-x86/IPF implementations and on it's future.
While x86's x87 unit supports 80 bit floats, the use of x87 is depreceated in favor of the more sane SSE2 wich does not support 80 bit floats.
And no, x86 isn't mainstream enough. There's a world of RISC embedded CPUs out there that do not support 80 bit format.
Your example of the engineer rounding off results to two decimal places is a good example of how round off can adversely afect results but one must remember that roundoff is not necessarly the limiting factor in the error of your results.
With 64 bit floats, the most common source of error I see people stumbling into is not the rounding imposed by the floating point format but either measurment error or aproximation error.
The measurment error comes from the fact that usually either the input will be taken from the real world or the output will be compared to the real world or both. And measuring the real world involves an error, which will then propagate throughout the calculus.
The aproximation error comes from the fact that often our calculations involve expressions that can't be analytically resolved or are too expensive and have to be replaced by aproximations, which have some error.
This is not to say that more precision isn't ocasionally usefull. Obviously, someone also thought so when x87 was created. Some Cray supercomputers had 96 bit floats too.
But mostly, it hasn't seem much demand. Even most supercomputers with custom CPUs have only 64 bit floating point.
It's also possible that if demand for a floating point format with higher precision comes, it will be a 128 bit format, not the actual 80 bit one.