Well yeah, it is the job of an optimizing compiler to produce the most efficient code for a particular architecture. Of course, the compiler can only do that if the language supports a particular type of data. If the language doesn't support a particular datatype, then you can't do anything at all with that type of data. Which is why the gmplib has all the important stuff written in assembler (not C) - because C does not support decimal operations.
The question is not whether or not you can do a certain operation in a given language. You can do damn near anything in any language. The question is can you do it efficiently. The 'C' implementation is probably the least inefficient, but it is still worse than native support. The Java and Python implementations are ridiculous wasters of cycles.
Huh? You can do binary integer and floating point arithmetic in any of those languages without any libraries, classes, or modules. You can only do decimal operations in those languages by either converting the decimal numbers to binary, operating on them, and converting back or by calling something written in a different language. Hiding those things elsewhere does not magically mean that the language supports decimal.
If Java, Python, and C support decimal operations, then why are a class, a module, or a library required? COBOL, on the other hand, directly supports decimal numbers. Two fixed point numbers can be read in, then operated on directly, then written out with no conversions. And the operations (add, subtract, multiply, divide, format, etc) are done with a single machine instruction (on a mainframe).
For someone who says others are unable to follow a conversation, you certainly show yourself to be unable to do so.
You are talking about stability during a discharge cycle. Of course that is important, and nobody is saying anything that even remotely contradicts that. This is the 'stable voltage range' he is refering to.
But he was aked about the FAILURE mode of the batteries. And in answer to that he said there is a narrow WINDOW which will produce that stable voltage range. The WINDOW is refering to the CHARGE voltages that are required in order for the battery to produce that stable range on discharge. There is only a narrow window of charge voltages which will produce the desired output.
By reading ALL of his answers, you can see that the problem is that, on every cycle, more of a film builds up on the anode. This film interferes with the charging process (ie. less voltage is reaching the electrolyte). As long as the voltage is still in that window, stable output results. After a certain number of cycles there is enough film that the voltage reaching the electrolyte is OUTSIDE that window, and now the battery can no longer produce that stable voltage. The cell has FAILED.
And the solution he provides to the problem is to prevent the build-up of film by plating the anode, which can't be done with the liquid electrolytes. He is in no way saying the problem is the stable voltage range, he is saying that in order to keep the DESIRABLE stable voltage range, you must stay in the window by preventing the film on the anode.
Telsa's pre-sales run to about 400K cars. 17.55 million new cars were sold in the US in 2016. So, if all of those pre-sales turn into actual sales, that is about 2% of car sales. Once. Is there any indication that they would sell ANOTHER 400K cars the next year, or will everyone who wants one already have one? That remains to be seen.
You have provided zero evidence that 'manufacturers are adopting EVs at a much faster pace...'. Have they announced the conversion of factories to EVs away from ICEs? Have they announced new factories that are capable of building more than 2% of their cars by 2020 (only THREE years away)?
He did not say anything about a stable output voltage. He said the electrolytes have a small window for a stable voltage range. The most likely means that if you charge the electrolyte to (for instance) 3.4 volts it will be stable, but you can't charge it to more than 3.5 volts or less than 3.3 volts. That is a small stable voltage range REGARDLESS of how well it holds that charge or delivers that voltage on discharge. And that is important, because as the internal resistance increases (due to anode decay), the voltage reaching the electrolyte decreases. Once the voltage reaching the electrolyte falls below 3.3 volts the battery does not store it. Which is exactly what we see with lithium batteries.
What he is doing is cherry-picking. Yes, there have been cases where 'experts' drastically underestimated the impact something would have. However, there are just as many cases where they over-estimated the impact something would have. SSTs were going to drastically change air travel, except they didn't. Segways were going to change urban transport forever, except they didn't. The difference between over- and under-estimation is that the things that were under-estimated are around to remind us of the error, while the things that were over-estimated aren't.
Cars were immediately seen as better than horses by most people. They pretty much sold themselves. Manufacturers didn't have to convince people to buy A car, they had the convince people to buy THEIR car. Same with cell phones.
Does the average driver immediately see EVs as superior to ICE? About the only reason they would is price of fuel. Environmental concerns are important, but almost always take a back seat to economics at the individual level.
Yes, auto-makers may be projecting 1~2% sales by 2020, but the vast majority of them are rushing to bring EV's to market in the next few years. Their actions speak louder than their words.
This statement really doesn't make sense. 2020 IS 'the next few years'. Having 1-2% of your cars be EVs is better than having 0% of your cars be EVs and losing those customers to a competitor which is what will happen if they don't rush to bring out EVs. Their actions are in no way 'speaking louder than their words'.
In your effort to appear superior to the guy who invented that battery, you managed to prove his point. The reason that batteries have the characteristic you pointed out is BECAUSE lithium has a narrow stable VOLTAGE range. They are either at that narrow range, or they are dead. Once the anode deteriorates sufficiently (due to the lack of plating), the resistance increases until the lithium no longer reaches that voltage during a charge, and the battery is dead. If lithium had a wide range (as you stated), then it could charge to 3V, or 2V, or 1V. It would no longer be working one day and dead the next, it would gradually put out less and less voltage.
You are talking about completely different disciplines. Someone who is an expert in the chemistry of a battery may not know anything about the issues involved in actually manufacturing said battery. Someone who is an expert at manufacturing may not know anything about the chemistry involved.
Your 'kick the can' scenario doesn't have anything to do with the above. That happens because it is enormously expensive, in both time and money, to get a design change into hardware. The farther you move down that chain, the quicker and less expensive it becomes. Somewhere in that chain is the 'sweet spot' for any given problem. Some problems are best fixed in hardware, some are best fixed in documentation, and most are best fixed somewhere in between. There is no one-size-fits-all always right answer.
He mentioned the anode in several of the answers. He said the solution to the anode problem is using the electrolyte to plate the anode with lithium. He said that the organic, flammable, liquid electrolytes can't be used to plate the anode because dendrites form, leading to shorts and fires. About the only thing he did not specifically state was that as the anode deteriorates the voltage goes down until it is out of the electrolytes stable range, and then the battery is dead.
So, yes, the organic flammable liquid electrolyte is precisely why the batteries suddenly go dead.
Of course you can't make guarantees, but what you CAN do is quantify both the COSTS and the BENEFITS of doing something. Something with a low cost/benefit ratio is probably worth doing. Something with a high ratio is not. In your motorcycle example, we can look at history to make a determination: protected riders fare far better than unprotected riders, so the benefit is great. The cost is not absurd, so wearing protection makes sense.
So we can also apply this analysis to this problem. One the one hand, we have the current systems. What is their track record of dealing with change?
Went from running on 24, to 31, to 64 bit addressing hardware Went from data stored on punch cards and tapes to online DASD Went from standalone systems, to networked with SNA, to networked with TCP/IP Went from green-screen UI only available to bank employees to mobile apps available to all customers Went from all batch-processing to mostly on-line Went from account information only being available via a mailed monthly statement to being available 24 hours a day, updated in real-time Etc, etc
Now, what is the supposed 'risk' with these systems? The pure FUD that 'there may be a change they won't be able to deal with'. Such as what, exactly?
On the other hand, we have the 'new and improved' systems. Exactly what is THEIR track record? Exactly WHAT change are the existing systems going to be unable to cope with, but the new systems will be able to cope with? Any examples at all?
It seems that the 'benefits' portion of the equation is sadly lacking (except for the FUD factor, of course)
Then there is the COST portion of the equation. The track record here is not good. There have been many public and spectacular failures doing what you suggest, all at enormous cost.
So what we see is a gigantic cost, and a benefit of 'maybe this' and 'maybe that'. When your cost portion is that large, your benefit portion better be larger, as in as close to a guarantee as you can get. You have not provided anything even close to that.
It depends on why you didn't show up. Most common reason would be a missed connection. In that case, they get you to your destination so there is no reason to refund anything.
If you arrive at the airport late most airlines will get you on a later flight.
If you have a refundable ticket and let the airline know you want a refund (before the flight), you get a refund.
If you have a non-refundable ticket and let the airline know you don't want it, they will let you exchange it for another flight (for a fee)
In no case is there even the slightest hint of fraud. If every case the airline fully intended to get you to your destination, and in every case except the one where you just didn't bother showing up, they will get you to your destination. And that last case is 100% on you.
I never said anything remotely similar to there will be no new requirements. I was merely pointing out that there have been MANY changes already, and the stuff is still working. You, on the other hand want to spread the FUD that 'there may be changes that the COBOL may not respond well to'. Well, can you guarantee that whatever rewrite you do WILL respond well to these as-yet unknown changes? No, you can not. Therefore, what you are suggesting is that organizations spend tons of money and time, and incur enormous risk, to wind up with a system that will not necessarily be any better than what is already there,
I have no idea why you are babbling about SCADA systems and Oracle systems in an article about large financial institutions and COBOL, which are almost exclusively the realm of mainframes and CICS.
Of course the mainframe systems have to trust the data that is fed to them. Do you have some magical new system/language where that is no longer the case? If not, how is rewriting the COBOL code going to actually improve the situation?
There were no divisions 'spun off' to China. There were divisions SOLD to China, but they are not branded IBM, and they have no connection to IBM. I have no idea why they would say 'IBM PC Division' would be a part of Lenovo, because when it became part of Lenovo it was no longer the IBM PC Division.
'Eventually COBOL will need to interface with new code...' Eventually? Do you suppose these programs had support for EFT, ATMs, bank-by-phone, online banking, mobile apps, etc when they were written 50+ years ago? You're not going to scare them with 'Oooh - there could be a new requirement!'
When you say rewriting is a good strategy, do you have ANY idea what that entails? You are not just talking about a few COBOL modules here and there. You are talking about potentially changing the ENTIRE system. Your COBOL program is probably running under CICS. The hardware CICS and your program have been running on have been optimized for your workload. Your data is probably stored on ECKD DASDs. Your data is probably stored in packed decimal format, so it can be operated on with a single, optimized, machine instruction.
Now, you want to 'rewrite' it. OK, where do you start? If you just replace your one COBOL module with some other language, does your 'new' language natively support the data you are operating on? Does it support the types of datasets you are using? Does it do those things with the same performance characteristics as COBOL? Does it properly and efficiently interface with CICS?
Your last paragraph is laughable. These 'old' systems are 'chewing-gum-and-tinfoil' unreliable systems? Oh yeah? When have you heard of one of these systems failing? When have you heard of security breeches involving these systems? And before you incorrectly say 'airlines', I will point out that NONE of the recent airline outages involved the mainframe portion of the operation. It was the 'new, better' stuff that falied in every case.
Haha! IBM is making a 'killing supporting old systems'? IBM comes out with NEW mainframes about every two years. The current system (z13) is from all the way back in 2015. And you won't find 'better hardware' anywhere. Cheaper? Certainly. Better? No.
You do realize that many of those 'restrictions' are in there precisely BECAUSE of laws, don't you? Things like 'you must detect modifications to emissions systems' and 'you must detect modifications to safety systems'. And if you think those types of laws are going away, especially with things like self-driving cars, you're nuts.
The law does not say you can't replace a wheel without TPMS. It says you can't disable a safety system. In the case of TPMS, the 'safety' aspect is in the form of a warning to the driver that there is a problem - either tire pressure is low or there is a malfunction in the system. You can replace a wheel without TPMS, but you can not disable the malfunction indication because it is, in fact, malfunctioning.
Those printers were engineered and manufactured in NY. Todays zSeries (mainframe) servers are engineered in NY, Texas, and Germany, and are manufactured in NY and Singapore. The chips for them are manufactured in NY and Vermont. Not China. Not India.
Well, they certainly do still make (and market!) zSeries machines, but the laptops running OS/2 were replaced by laptops running Linux in 2005. In recent generations it is now 1U servers running Linux.
Nothing to do with adding more hardware. It is QC checks on the batteries themselves (Durability test, Visual Inspection, X-ray test, disassembling test, delta OCT test, charge/discharge test, TVOC test, accelerated usage test).
Blockchain is not bitcoin or other cryptocurrency. There is no 'proof of work'. These things are called permissioned blockchains, who gets to see and update what is controlled by cryptography.
If you are actually interested in those questions, look up open ledger and hyperledger. There is loads of information and places where you can see how it works and try it for yourself.
Slashdot Mirror
Well yeah, it is the job of an optimizing compiler to produce the most efficient code for a particular architecture. Of course, the compiler can only do that if the language supports a particular type of data. If the language doesn't support a particular datatype, then you can't do anything at all with that type of data. Which is why the gmplib has all the important stuff written in assembler (not C) - because C does not support decimal operations.
The question is not whether or not you can do a certain operation in a given language. You can do damn near anything in any language. The question is can you do it efficiently. The 'C' implementation is probably the least inefficient, but it is still worse than native support. The Java and Python implementations are ridiculous wasters of cycles.
Also 'INTELS' decimal128???? Seriously?
Huh? You can do binary integer and floating point arithmetic in any of those languages without any libraries, classes, or modules. You can only do decimal operations in those languages by either converting the decimal numbers to binary, operating on them, and converting back or by calling something written in a different language. Hiding those things elsewhere does not magically mean that the language supports decimal.
If Java, Python, and C support decimal operations, then why are a class, a module, or a library required? COBOL, on the other hand, directly supports decimal numbers. Two fixed point numbers can be read in, then operated on directly, then written out with no conversions. And the operations (add, subtract, multiply, divide, format, etc) are done with a single machine instruction (on a mainframe).
For someone who says others are unable to follow a conversation, you certainly show yourself to be unable to do so.
You are talking about stability during a discharge cycle. Of course that is important, and nobody is saying anything that even remotely contradicts that. This is the 'stable voltage range' he is refering to.
But he was aked about the FAILURE mode of the batteries. And in answer to that he said there is a narrow WINDOW which will produce that stable voltage range. The WINDOW is refering to the CHARGE voltages that are required in order for the battery to produce that stable range on discharge. There is only a narrow window of charge voltages which will produce the desired output.
By reading ALL of his answers, you can see that the problem is that, on every cycle, more of a film builds up on the anode. This film interferes with the charging process (ie. less voltage is reaching the electrolyte). As long as the voltage is still in that window, stable output results. After a certain number of cycles there is enough film that the voltage reaching the electrolyte is OUTSIDE that window, and now the battery can no longer produce that stable voltage. The cell has FAILED.
And the solution he provides to the problem is to prevent the build-up of film by plating the anode, which can't be done with the liquid electrolytes. He is in no way saying the problem is the stable voltage range, he is saying that in order to keep the DESIRABLE stable voltage range, you must stay in the window by preventing the film on the anode.
Telsa's pre-sales run to about 400K cars. 17.55 million new cars were sold in the US in 2016. So, if all of those pre-sales turn into actual sales, that is about 2% of car sales. Once. Is there any indication that they would sell ANOTHER 400K cars the next year, or will everyone who wants one already have one? That remains to be seen.
You have provided zero evidence that 'manufacturers are adopting EVs at a much faster pace...'. Have they announced the conversion of factories to EVs away from ICEs? Have they announced new factories that are capable of building more than 2% of their cars by 2020 (only THREE years away)?
He did not say anything about a stable output voltage. He said the electrolytes have a small window for a stable voltage range. The most likely means that if you charge the electrolyte to (for instance) 3.4 volts it will be stable, but you can't charge it to more than 3.5 volts or less than 3.3 volts. That is a small stable voltage range REGARDLESS of how well it holds that charge or delivers that voltage on discharge. And that is important, because as the internal resistance increases (due to anode decay), the voltage reaching the electrolyte decreases. Once the voltage reaching the electrolyte falls below 3.3 volts the battery does not store it. Which is exactly what we see with lithium batteries.
What he is doing is cherry-picking. Yes, there have been cases where 'experts' drastically underestimated the impact something would have. However, there are just as many cases where they over-estimated the impact something would have. SSTs were going to drastically change air travel, except they didn't. Segways were going to change urban transport forever, except they didn't. The difference between over- and under-estimation is that the things that were under-estimated are around to remind us of the error, while the things that were over-estimated aren't.
Cars were immediately seen as better than horses by most people. They pretty much sold themselves. Manufacturers didn't have to convince people to buy A car, they had the convince people to buy THEIR car. Same with cell phones.
Does the average driver immediately see EVs as superior to ICE? About the only reason they would is price of fuel. Environmental concerns are important, but almost always take a back seat to economics at the individual level.
Yes, auto-makers may be projecting 1~2% sales by 2020, but the vast majority of them are rushing to bring EV's to market in the next few years. Their actions speak louder than their words.
This statement really doesn't make sense. 2020 IS 'the next few years'. Having 1-2% of your cars be EVs is better than having 0% of your cars be EVs and losing those customers to a competitor which is what will happen if they don't rush to bring out EVs. Their actions are in no way 'speaking louder than their words'.
In your effort to appear superior to the guy who invented that battery, you managed to prove his point. The reason that batteries have the characteristic you pointed out is BECAUSE lithium has a narrow stable VOLTAGE range. They are either at that narrow range, or they are dead. Once the anode deteriorates sufficiently (due to the lack of plating), the resistance increases until the lithium no longer reaches that voltage during a charge, and the battery is dead. If lithium had a wide range (as you stated), then it could charge to 3V, or 2V, or 1V. It would no longer be working one day and dead the next, it would gradually put out less and less voltage.
You are talking about completely different disciplines. Someone who is an expert in the chemistry of a battery may not know anything about the issues involved in actually manufacturing said battery. Someone who is an expert at manufacturing may not know anything about the chemistry involved.
Your 'kick the can' scenario doesn't have anything to do with the above. That happens because it is enormously expensive, in both time and money, to get a design change into hardware. The farther you move down that chain, the quicker and less expensive it becomes. Somewhere in that chain is the 'sweet spot' for any given problem. Some problems are best fixed in hardware, some are best fixed in documentation, and most are best fixed somewhere in between. There is no one-size-fits-all always right answer.
He mentioned the anode in several of the answers. He said the solution to the anode problem is using the electrolyte to plate the anode with lithium. He said that the organic, flammable, liquid electrolytes can't be used to plate the anode because dendrites form, leading to shorts and fires. About the only thing he did not specifically state was that as the anode deteriorates the voltage goes down until it is out of the electrolytes stable range, and then the battery is dead.
So, yes, the organic flammable liquid electrolyte is precisely why the batteries suddenly go dead.
It was not 'an IP lawsuit', it was a suit about overpayments.
Wow, talk about missing the point.
Of course you can't make guarantees, but what you CAN do is quantify both the COSTS and the BENEFITS of doing something. Something with a low cost/benefit ratio is probably worth doing. Something with a high ratio is not. In your motorcycle example, we can look at history to make a determination: protected riders fare far better than unprotected riders, so the benefit is great. The cost is not absurd, so wearing protection makes sense.
So we can also apply this analysis to this problem. One the one hand, we have the current systems. What is their track record of dealing with change?
Went from running on 24, to 31, to 64 bit addressing hardware
Went from data stored on punch cards and tapes to online DASD
Went from standalone systems, to networked with SNA, to networked with TCP/IP
Went from green-screen UI only available to bank employees to mobile apps available to all customers
Went from all batch-processing to mostly on-line
Went from account information only being available via a mailed monthly statement to being available 24 hours a day, updated in real-time
Etc, etc
Now, what is the supposed 'risk' with these systems? The pure FUD that 'there may be a change they won't be able to deal with'. Such as what, exactly?
On the other hand, we have the 'new and improved' systems. Exactly what is THEIR track record? Exactly WHAT change are the existing systems going to be unable to cope with, but the new systems will be able to cope with? Any examples at all?
It seems that the 'benefits' portion of the equation is sadly lacking (except for the FUD factor, of course)
Then there is the COST portion of the equation. The track record here is not good. There have been many public and spectacular failures doing what you suggest, all at enormous cost.
So what we see is a gigantic cost, and a benefit of 'maybe this' and 'maybe that'. When your cost portion is that large, your benefit portion better be larger, as in as close to a guarantee as you can get. You have not provided anything even close to that.
It depends on why you didn't show up. Most common reason would be a missed connection. In that case, they get you to your destination so there is no reason to refund anything.
If you arrive at the airport late most airlines will get you on a later flight.
If you have a refundable ticket and let the airline know you want a refund (before the flight), you get a refund.
If you have a non-refundable ticket and let the airline know you don't want it, they will let you exchange it for another flight (for a fee)
In no case is there even the slightest hint of fraud. If every case the airline fully intended to get you to your destination, and in every case except the one where you just didn't bother showing up, they will get you to your destination. And that last case is 100% on you.
I never said anything remotely similar to there will be no new requirements. I was merely pointing out that there have been MANY changes already, and the stuff is still working. You, on the other hand want to spread the FUD that 'there may be changes that the COBOL may not respond well to'. Well, can you guarantee that whatever rewrite you do WILL respond well to these as-yet unknown changes? No, you can not. Therefore, what you are suggesting is that organizations spend tons of money and time, and incur enormous risk, to wind up with a system that will not necessarily be any better than what is already there,
I have no idea why you are babbling about SCADA systems and Oracle systems in an article about large financial institutions and COBOL, which are almost exclusively the realm of mainframes and CICS.
Of course the mainframe systems have to trust the data that is fed to them. Do you have some magical new system/language where that is no longer the case? If not, how is rewriting the COBOL code going to actually improve the situation?
There were no divisions 'spun off' to China. There were divisions SOLD to China, but they are not branded IBM, and they have no connection to IBM. I have no idea why they would say 'IBM PC Division' would be a part of Lenovo, because when it became part of Lenovo it was no longer the IBM PC Division.
'Eventually COBOL will need to interface with new code...' Eventually? Do you suppose these programs had support for EFT, ATMs, bank-by-phone, online banking, mobile apps, etc when they were written 50+ years ago? You're not going to scare them with 'Oooh - there could be a new requirement!'
When you say rewriting is a good strategy, do you have ANY idea what that entails? You are not just talking about a few COBOL modules here and there. You are talking about potentially changing the ENTIRE system. Your COBOL program is probably running under CICS. The hardware CICS and your program have been running on have been optimized for your workload. Your data is probably stored on ECKD DASDs. Your data is probably stored in packed decimal format, so it can be operated on with a single, optimized, machine instruction.
Now, you want to 'rewrite' it. OK, where do you start? If you just replace your one COBOL module with some other language, does your 'new' language natively support the data you are operating on? Does it support the types of datasets you are using? Does it do those things with the same performance characteristics as COBOL? Does it properly and efficiently interface with CICS?
Your last paragraph is laughable. These 'old' systems are 'chewing-gum-and-tinfoil' unreliable systems? Oh yeah? When have you heard of one of these systems failing? When have you heard of security breeches involving these systems? And before you incorrectly say 'airlines', I will point out that NONE of the recent airline outages involved the mainframe portion of the operation. It was the 'new, better' stuff that falied in every case.
Haha! IBM is making a 'killing supporting old systems'? IBM comes out with NEW mainframes about every two years. The current system (z13) is from all the way back in 2015. And you won't find 'better hardware' anywhere. Cheaper? Certainly. Better? No.
You do realize that many of those 'restrictions' are in there precisely BECAUSE of laws, don't you? Things like 'you must detect modifications to emissions systems' and 'you must detect modifications to safety systems'. And if you think those types of laws are going away, especially with things like self-driving cars, you're nuts.
The law does not say you can't replace a wheel without TPMS. It says you can't disable a safety system. In the case of TPMS, the 'safety' aspect is in the form of a warning to the driver that there is a problem - either tire pressure is low or there is a malfunction in the system. You can replace a wheel without TPMS, but you can not disable the malfunction indication because it is, in fact, malfunctioning.
Those printers were engineered and manufactured in NY. Todays zSeries (mainframe) servers are engineered in NY, Texas, and Germany, and are manufactured in NY and Singapore. The chips for them are manufactured in NY and Vermont. Not China. Not India.
Heh, you're right. In all the sniveling about patents I lost track of the facts. My apologies.
Eh, you have that backwards. Titleist is suing, Costco is being sued.
So AC had it right - the ones who can (Titleist) did, and the ones who can't (Costco) copied and are whining.
Well, they certainly do still make (and market!) zSeries machines, but the laptops running OS/2 were replaced by laptops running Linux in 2005. In recent generations it is now 1U servers running Linux.
Nothing to do with adding more hardware. It is QC checks on the batteries themselves (Durability test, Visual Inspection, X-ray test, disassembling test, delta OCT test, charge/discharge test, TVOC test, accelerated usage test).
Blockchain is not bitcoin or other cryptocurrency. There is no 'proof of work'. These things are called permissioned blockchains, who gets to see and update what is controlled by cryptography.
If you are actually interested in those questions, look up open ledger and hyperledger. There is loads of information and places where you can see how it works and try it for yourself.