It has also gotten way too bloated. I just checked the installation on the computer I am currently using and it has over 60,000 (yes 60,000) files. Compare that with Mathematica's 1,200 and Maple's 400. For christ sake, Matlab has over 1,100 DIRECTORIES.
I found that I didn't need to use the package at all.
Of course you don't need to use it but it sure saves a hell of a lot of time and effort. I have better things to do than take up multiple pages of paper taking the derivative of some complicated function (and probably switching a sign somewhere...).
The difference in speed between Matlab and C/C++ is roughly the difference between Java and C/C++. Unless you use a few certain functions, Matlab compiles your code into Bytecode-like instructions called M-code, which is then interpreted like in Java's VM. It also has a built in converter to change M-code into C++ code that can be compiled by an external C++ compiler.
...the kind of people that send their hard drives to them are the kind that are DESPERATE to recover their data for whatever reason...
Oh come on. People who have data that is so important that they are "DESPERATE" to recover it should have backed up that data, and the fact that they didn't makes them idiots.
I agree, but my point (now) is that the ground Intel and AMD have gained (and may gain in the future) is not in spite of IBM/Sun/HP, but because of them.
You would be right if not for Newton adding "...by doing so bring the sacred prophesies into discredit...." That statement shows that Newton actually believed this shit. Just goes to show that even the smartest people can believe the stupidest things.
Cringely doesn't make much sense. His arguments imply that IBM and HP will be going out of business too. He seems to think the future server market will be dominated by Intel and AMD running Linux, which seems a little silly to me.
The article is very misleading. Rivest has a paper on his website on a couple micro-payment schemes (I assume one of these is the basis for Peppercoin) that clears up the confusion.
Here are two schemes in the paper:
Scheme 1
The Customer buys something from the Merchant.
The Merchant is issued a P-Coin which is payable with probablity S (if payable, the coin is worth 1/S cents).
If the coin is payable, when the Merchant redeams it his account is credited with 1/S Cents and the Customer is charged 1/S cents (over time the customer's payments and purchases balance).
Scheme 2
The Customer buys something from the Merchant.
The Merchant is issued a P-Coin which is payable with probablity S (if payable, the coin is worth 1/S cents).
If the coin is payable, when the Merchant redeams it his account is credited with 1/S Cents and the Customer is charged an amount equal to he amount he has spent since the last transaction that was processed (so over time payments and purchases balance).
The problem with Scheme 1 is the possibility of a customer overpaying. Scheme 2 solves this by shifting the risk (not really a risk, it all balances out over many transactions) of overpayment to the bank (in this case Peppercoin Co.). You are assured that you will never be charged more than you spend.
The key point is that only a small number of transactions are processed (from both the merchant's and customer's point of view) thus cutting costs.
Why the need for randomness? If Peppercoin just kept track of every transaction and paid the merchant in aggregate, it would still need to do a bunch of small transactions to charge the individual credit cards.
Why not just do the credit card transactions in aggregate (at the end of each month, say)? I'm not sure about this one. Maybe because the math is too uncomplicated if you do it that way.
Slashdot Mirror
It has also gotten way too bloated. I just checked the installation on the computer I am currently using and it has over 60,000 (yes 60,000) files. Compare that with Mathematica's 1,200 and Maple's 400. For christ sake, Matlab has over 1,100 DIRECTORIES.
Of course you don't need to use it but it sure saves a hell of a lot of time and effort. I have better things to do than take up multiple pages of paper taking the derivative of some complicated function (and probably switching a sign somewhere...).
True, and I would never use Matlab to do symbolic math, but I was just answering your question.
The difference in speed between Matlab and C/C++ is roughly the difference between Java and C/C++. Unless you use a few certain functions, Matlab compiles your code into Bytecode-like instructions called M-code, which is then interpreted like in Java's VM. It also has a built in converter to change M-code into C++ code that can be compiled by an external C++ compiler.
You would install this and us "diff" and "int", among others.
Yeah, and I suppose "Econonomics" should be refered to as "Econs", right? Quit whinging, you daft wanker. Cheers.
Oh come on. People who have data that is so important that they are "DESPERATE" to recover it should have backed up that data, and the fact that they didn't makes them idiots.
She's what I would call unattractive.
Maybe people who get suicidal over losing a few mp3s or pictures shouldn't be coaxed away from the ledge. In fact, maybe they should be pushed off.
Well, to be fair, that's almost word for word what I did say. It's just not quite what I meant. I hate it when that happens.
I agree, but my point (now) is that the ground Intel and AMD have gained (and may gain in the future) is not in spite of IBM/Sun/HP, but because of them.
You would be right if not for Newton adding "...by doing so bring the sacred prophesies into discredit...." That statement shows that Newton actually believed this shit. Just goes to show that even the smartest people can believe the stupidest things.
Cringely doesn't make much sense. His arguments imply that IBM and HP will be going out of business too. He seems to think the future server market will be dominated by Intel and AMD running Linux, which seems a little silly to me.
You mean this Linux?
Yeah, we've been warned for about 20 years now. And they've already solved the problem.
The article is very misleading. Rivest has a paper on his website on a couple micro-payment schemes (I assume one of these is the basis for Peppercoin) that clears up the confusion.
Here are two schemes in the paper:
Scheme 1
- The Customer buys something from the Merchant.
- The Merchant is issued a P-Coin which is payable with probablity S (if payable, the coin is worth 1/S cents).
- If the coin is payable, when the Merchant redeams it his account is credited with 1/S Cents and the Customer is charged 1/S cents (over time the customer's payments and purchases balance).
Scheme 2The problem with Scheme 1 is the possibility of a customer overpaying. Scheme 2 solves this by shifting the risk (not really a risk, it all balances out over many transactions) of overpayment to the bank (in this case Peppercoin Co.). You are assured that you will never be charged more than you spend.
The key point is that only a small number of transactions are processed (from both the merchant's and customer's point of view) thus cutting costs.
Why the need for randomness? If Peppercoin just kept track of every transaction and paid the merchant in aggregate, it would still need to do a bunch of small transactions to charge the individual credit cards.
Why not just do the credit card transactions in aggregate (at the end of each month, say)? I'm not sure about this one. Maybe because the math is too uncomplicated if you do it that way.