I thought the bay was created by the fault-lines. Tectonic plates moving and all that.
Populations and natural disasters go together. The same conditions that increase the risk of a natural disaster also make it attractive for people to live there.
After a recent hurricane knocked out power in my area, the people from the electric company said that underground power lines were about 4x the cost of overhead lines. I'm not sure how large a percentage of the power company's total costs that is. Is the public willing to pay the costs of burying the power lines?
Another issue is rural areas. Some of my relatives live on farms, and they have told me that they have to pay for the power company to string the electric wires from the county road to the buildings on the farm, and that it can be quite expensive, even for overhead lines.
The compare operation for a binary date sort key would be a bit faster than the same for an 8-character field. The problem is that, in the case of the binary date, you have to also consider the extra time spent converting between character and binary format during I/O.
What's there to parse if you use a fixed format like YYMMDD or YYYYMMDD?
If the only thing we did with dates was to use them in calculations, a binary format would optimal. For many programs, date processing is dominated by I/O and sorting. This is classic mainframe data processing. Someone types a date into a form, which is written to a file, processed, displayed and printed. Date calculations are usually limited to comparisons, is date1 (less than, equal to, greater than) date2. These can be easily done in BCD or character form, without converting the date to an integer.
The big win is when you do I/O. Conversion between BCD and ASCII/EBCDIC is fast and efficient. So is creating a formatted output record for a display or printer. Using a date as a sort key doesn't require that it be converted to integer form, it can be left in its native form.
All of this becomes plain if you are writing software for an older and slower computer. Say something with the number crunching ability of a Z-80 or an 8088, where multiply and divide are obvious performance killers.
Dates were usually stored as character strings or in BCD format on older systems. It was more efficient in CPU time than using integers. Many computers did not have hardware for doing multiplication and division. Even if they had the hardware, multiply and divide were usually much slower than the other ALU operations. It was easier and faster to use BCD or character strings.
Computer clocks can follow UTC very closely with the use of NTP (Network Time Protocol). The problem is that NTP fudges leap seconds. Every time there is a leap second, NTP must tweak the local clock to compensate for the discontinuity. This would not be necessary if NTP was based on TAI. With NTP, even the clocks in commodity PC hardware can be consistently within 20-30 ms of UTC. They could easily meet the same standard with TAI.
The question is, do we want a uniform and precise time scale, or a time scale that is kept in synchronization with the rotation of the Earth, at the expense of unpredictable discontinuities.
Integers are represented exactly in IEEE floating point as long as they do not exceed the size of the mantissa. Many systems do not provide 64-bit integers. The trick is to use the correct base unit. For time, I've often used elapsed microseconds since the epoch. For money, you can use cents or millicents, depending on how you want to round things.
My guess is that it is because an IEEE double can be used to store and manipulate large (53-bit) integers. I've done that on systems that didn't support anything larger than 32-bit integral types. It's more portable than assuming the existence of "long long" or some other 64-bit integral type.
Higher education in the United States is damned expensive. What about those of us without well-off parents who are willing to pay the bills? It is expensive enough to get a bachelors degree, let alone a masters or Ph.D. Some of us were too busy working a full-time job just to pay the rent, eat, and pay for the car. I've had to pay my own way since I was 17.
While it has some benefits, it's also another tool for control freaks, such as some parents and SOs, who go nuts if they don't know where you are 24 hours a day. It isn't voluntary if you are a minor or have a SO with severe mental problems concerning trust.
It can be very expensive and risky to replace the old systems. Many organizations just don't have the money to replace their older systems. You may not have all of the original/current source code. The written requirements, if any are still available, are hopelessly out-of-date and useless. As soon as a proposal for a replacement is floated, gnomes will come out of the woodwork with endless lists of new features and buzzwords that they want in the new system. The Microsoft zombies will insist that you only use Microsoft products, no matter how ill-suited they are for the application. The whole thing can rapidly turn into an expensive disaster that never works properly.
I wouldn't call it gouging. It's been the trend for many years in the electronics business. In the old days, technicians would troubleshoot the problem down to the component level and fix/replace the bad components. That took time, experienced technicians, lots of test equipment and a large parts inventory, all of which cost serious money. It became much cheaper to only troubleshoot down to the level of a field replaceable unit or module. Fewer parts needed to be stocked, less time was needed, experienced technicians could be replaced with trained monkeys, little or no test equipment was needed, and much less training was needed for the monkeys. The only problem is, as you discovered, that in some cases, it is cheaper to do things the old way. From the repair department's point of view, the "cheap" repair is not possible without them spending a lot of money on tools, parts, training and higher wages. The Mom and Pop shop may be able to do it in some cases because the repair is simple and their employees are overqualified for their jobs. They also don't have to deal with the standardized processes and procedures of a large corporation.
How about changing the law so lenders are required to verify the identity of the people they lend money to? If they don't, they would be prohibited from taking any legal action against the debtor, referring the debt to a collection agency, or putting a black mark on the debtor's credit record. The identity verification process would have to meet high standards, comparable to what the government requires before issuing sensitive licenses and identification documents. Maybe a current photograph, thumbprint, and signature, collected by someone like a notary public or other trusted person, and submitted directly to the creditor.
Sometimes you need to store personal information on your work computer. The company may require you to create and maintain electronic forms for employee master records, resumes, skills lists, security clearance applications, expense accounts, travel requests and other forms with sensitive information. Many companies and organizations now use MS Office and Outlook/Exchange to handle all of their paperwork. It costs money and time to shuffle physical pieces of paper. It's easier to tell the employee to use an electronic form and email it to the appropriate person/department. It also creates a whole new set of security issues that few managers are willing to address.
Wait until after it has made a successful landing and becomes operational. It can be difficult to compare budgets. Development costs can be cut if you are willing to do less testing and accept higher risks. Is the supporting infrastructure "free" or is it charged to the project? Are major components being scrounged from other projects or are they being designed and built from scratch? Who is paying for the data acquisition, archiving, reduction, distribution and analysis? How much of the work is being done by professional employees vs. grad students?
I've built SMP machines from Intel CPUs and motherboards with Intel chipsets without many problems. The trick is to get a motherboard from a company that knows how to design an SMP motherboard, or just buy a low-end SMP server.
Is there a Microsoft document that defines the boundaries between the operating system and user-installed applications? I haven't run into any problems with the Windows applications that I have written, but I haven't written any particularly large and complex programs for Windows. I've always assumed that files in the installation directory, and the directory itself, should be treated as read-only. Any new or modified files should be in the user's file space.
Slashdot Mirror
Populations and natural disasters go together. The same conditions that increase the risk of a natural disaster also make it attractive for people to live there.
Another issue is rural areas. Some of my relatives live on farms, and they have told me that they have to pay for the power company to string the electric wires from the county road to the buildings on the farm, and that it can be quite expensive, even for overhead lines.
At least some of them are there for the control, signaling and communication needs of the railroads.
Our customers got upset when we tried sending them their bills in binary.
The compare operation for a binary date sort key would be a bit faster than the same for an 8-character field. The problem is that, in the case of the binary date, you have to also consider the extra time spent converting between character and binary format during I/O.
If the only thing we did with dates was to use them in calculations, a binary format would optimal. For many programs, date processing is dominated by I/O and sorting. This is classic mainframe data processing. Someone types a date into a form, which is written to a file, processed, displayed and printed. Date calculations are usually limited to comparisons, is date1 (less than, equal to, greater than) date2. These can be easily done in BCD or character form, without converting the date to an integer. The big win is when you do I/O. Conversion between BCD and ASCII/EBCDIC is fast and efficient. So is creating a formatted output record for a display or printer. Using a date as a sort key doesn't require that it be converted to integer form, it can be left in its native form.
All of this becomes plain if you are writing software for an older and slower computer. Say something with the number crunching ability of a Z-80 or an 8088, where multiply and divide are obvious performance killers.
Dates were usually stored as character strings or in BCD format on older systems. It was more efficient in CPU time than using integers. Many computers did not have hardware for doing multiplication and division. Even if they had the hardware, multiply and divide were usually much slower than the other ALU operations. It was easier and faster to use BCD or character strings.
The question is, do we want a uniform and precise time scale, or a time scale that is kept in synchronization with the rotation of the Earth, at the expense of unpredictable discontinuities.
UTC is a mess. I'd rather see all computer clocks use TAI (International Atomic Time) internally.
Short version, it simplified leap-year calculations.
Integers are represented exactly in IEEE floating point as long as they do not exceed the size of the mantissa. Many systems do not provide 64-bit integers. The trick is to use the correct base unit. For time, I've often used elapsed microseconds since the epoch. For money, you can use cents or millicents, depending on how you want to round things.
Nothing too important, just things like weapons control software for warships :-).
There are computers that use 30-bit integers, such as some old Univac systems. Just because you've never seen one, doesn't mean that they don't exist.
My guess is that it is because an IEEE double can be used to store and manipulate large (53-bit) integers. I've done that on systems that didn't support anything larger than 32-bit integral types. It's more portable than assuming the existence of "long long" or some other 64-bit integral type.
Higher education in the United States is damned expensive. What about those of us without well-off parents who are willing to pay the bills? It is expensive enough to get a bachelors degree, let alone a masters or Ph.D. Some of us were too busy working a full-time job just to pay the rent, eat, and pay for the car. I've had to pay my own way since I was 17.
While it has some benefits, it's also another tool for control freaks, such as some parents and SOs, who go nuts if they don't know where you are 24 hours a day. It isn't voluntary if you are a minor or have a SO with severe mental problems concerning trust.
It can be very expensive and risky to replace the old systems. Many organizations just don't have the money to replace their older systems. You may not have all of the original/current source code. The written requirements, if any are still available, are hopelessly out-of-date and useless. As soon as a proposal for a replacement is floated, gnomes will come out of the woodwork with endless lists of new features and buzzwords that they want in the new system. The Microsoft zombies will insist that you only use Microsoft products, no matter how ill-suited they are for the application. The whole thing can rapidly turn into an expensive disaster that never works properly.
Lithium batteries have a higher energy density that NiCD or NiMH batteries. More power in less space/weight.
I wouldn't call it gouging. It's been the trend for many years in the electronics business. In the old days, technicians would troubleshoot the problem down to the component level and fix/replace the bad components. That took time, experienced technicians, lots of test equipment and a large parts inventory, all of which cost serious money. It became much cheaper to only troubleshoot down to the level of a field replaceable unit or module. Fewer parts needed to be stocked, less time was needed, experienced technicians could be replaced with trained monkeys, little or no test equipment was needed, and much less training was needed for the monkeys. The only problem is, as you discovered, that in some cases, it is cheaper to do things the old way. From the repair department's point of view, the "cheap" repair is not possible without them spending a lot of money on tools, parts, training and higher wages. The Mom and Pop shop may be able to do it in some cases because the repair is simple and their employees are overqualified for their jobs. They also don't have to deal with the standardized processes and procedures of a large corporation.
How about changing the law so lenders are required to verify the identity of the people they lend money to? If they don't, they would be prohibited from taking any legal action against the debtor, referring the debt to a collection agency, or putting a black mark on the debtor's credit record. The identity verification process would have to meet high standards, comparable to what the government requires before issuing sensitive licenses and identification documents. Maybe a current photograph, thumbprint, and signature, collected by someone like a notary public or other trusted person, and submitted directly to the creditor.
Sometimes you need to store personal information on your work computer. The company may require you to create and maintain electronic forms for employee master records, resumes, skills lists, security clearance applications, expense accounts, travel requests and other forms with sensitive information. Many companies and organizations now use MS Office and Outlook/Exchange to handle all of their paperwork. It costs money and time to shuffle physical pieces of paper. It's easier to tell the employee to use an electronic form and email it to the appropriate person/department. It also creates a whole new set of security issues that few managers are willing to address.
Wait until after it has made a successful landing and becomes operational. It can be difficult to compare budgets. Development costs can be cut if you are willing to do less testing and accept higher risks. Is the supporting infrastructure "free" or is it charged to the project? Are major components being scrounged from other projects or are they being designed and built from scratch? Who is paying for the data acquisition, archiving, reduction, distribution and analysis? How much of the work is being done by professional employees vs. grad students?
I've built SMP machines from Intel CPUs and motherboards with Intel chipsets without many problems. The trick is to get a motherboard from a company that knows how to design an SMP motherboard, or just buy a low-end SMP server.
Is there a Microsoft document that defines the boundaries between the operating system and user-installed applications? I haven't run into any problems with the Windows applications that I have written, but I haven't written any particularly large and complex programs for Windows. I've always assumed that files in the installation directory, and the directory itself, should be treated as read-only. Any new or modified files should be in the user's file space.
You would stand a good chance of being caught, and you do not want to be the "example" for some prosecutor at the Department of Justice.