I write some of Apple’s FFTs and other signal-processing code, and I happen to have been pondering this question lately. My software will be in a billion computers in the next few years, and there will be sextillions of executions of instructions I have written. However, somebody out there will have more...
As others have noted, spreading a virus and teaching others to spread a virus is dangerous, even if the virus is "benign." If the virus spreads to the system of any person who did not consent, you have committed an unethical and possibly unlawful act.
That said, it is necessary to learn and to teach. If you have responsible students who have agreed to take proper precautions, it may be permissible to perform certain exercises with viruses. However, while you can get ideas from Slashdot, you should not accept advice. You should verify the ideas independently with professionals in computer security.
I am not one, but one idea is to take some ideas from the methods used to prevent biological organisms from spreading while experimenting on those. For example, design the virus to spread only to systems that contain a special marker, such as a file in a known location that contains the text "This system is part of the equipment for course 123 in the Fall 2012 semester." This would prevent the virus from spreading to other systems even if a network connection were made or somebody moved a disk from your isolated systems to a networked system. It would not, of course, stop one of your students from disabling that part of the virus and making themselves a fun "toy" to play with, which is why you need to ensure your students are trustworthy.
"Hell, what if they said 'If you keep taking that pill, you will die in 10 years, otherwise you will die in 15'? Well, right now some might actually say 'I'll keep taking it', speaking for that person in 9 3/4 years who may answer VERY differently-- again a human inability to logically analyze the situation and come to an honest conclusion."
That example does not demonstrate any inability to analyze the situation. A person might value their quality of life with the pill more than 50% more than their quality of life without the pill, in which case 10 years with the pill is worth more than 15 years without the pill.
Then, in 9 3/4 years, their choice is 1/4 year with the pill versus 5 1/4 year without the pill, in which case it makes sense to discontinue the pill, unless their quality of life is much, much greater with the pill.
Because your bank or broker gives you statements that you must keep for tax or evidentiary purposes, and you think you can read them, but they break sometime in the future when your bank or broker "upgrades" their system.
Because you keep important information in Google Documents or some other quasi-online service, and you lose access to them in the future when the service is discontinued. Or when the free service is changed to a paid service.
Because the software is important to your business, and you need to ensure you will be able to continue to run it.
Because you want to keep a copy of the agreement offered when you opened an account.
Because you want to study the encryption and other security features used to protect your information or to allow qualified professionals to study the security features so they can advise the public about them. (E.g., you would like skilled and informed university professors to analyze the security features so they can warn you when certain software is not up to snuff, so that extra care can be taken.)
If you just use your web "browser" to browse or play games, you might not care about the software running in it. But if you use it for things you rely on, for safety or security or important information or record-keeping or making money, then you care about the software running on it, and you want some assurance and control over it.
"What I mean, is that to pay with credit cards, from what I know, you only need the data that is written right on the card."
No, there are other safeguards. For one thing, you need to know some address information associated with the card, such as house number and postal code. If the product is not being shipped to an address the credit card issuer knows is associated with the card, then there may be additional checks. There is a three-digit verification code that the purchaser may be asked to supply. This code is not printed in raised lettering, so it is not recorded on old-style physical imprints of the card, and merchants are not supposed to keep a record of it once the transaction has been approved. (They have the credit card number and an approval number unique to the transaction.)
As another respondent mentions, the credit card holder is responsible for reviewing their statements and notifying the credit card issuer of fraudulent transactions. Then the issuer can withhold the money from the merchant or otherwise get it back.
In Germany, you can send money to people by writing some information about your account and about the payee and their account on a bank form and depositing it into a box at your bank. What prevents that from being used fraudulently? I wondered about that when I lived there. I suppose the fact that the money goes to account provides some safety, as the destination back should have some knowledge of their customer.
"Why in the world do modern e-mail clients still allow reply all to hundreds of recipients without an additional safety question."
Because the client has no information about the number of recipients. It only knows the number of addresses the message is addressed to. A "reply all" on the lists I participate in commonly generates a message with two destination addresses, the individual sender and the list. The client does not know how many people are on the list or even that it is a list.
Certainly a client ought to ask for confirmation when there are more than a few addresses (subject to a customizable threshold so users who regularly send messages to many people can do so easily). However, you also need list servers to guard against email storms. Perhaps servers should request confirmation when there are symptoms of inadvertent, indiscriminate, or ignorant reply-all messages, such as trivial new text in a message with much quoted text, requests to unsubscribe, a reply from a new first-time sender on the list, etc.
Ideally, one should have a formal education before writing software professionally--there is a lot of theory that has been figured out that is useful to know in practice. However, given that that is not going to happen, then my advice is to avoid reinventing the wheel, or, worse, inventing a bumpy thing that the car rides on but is slow and inefficient and uncomfortable and breaks from time to time. Collect references where you can look up algorithms and theory--apply what other people have done instead of writing new algorithms. Most programmers' jobs are tailoring known algorithms to current situations, not writing new algorithms.
"People are willing to pay $0.10 to send a text message. What it COSTS to provide the message is irrelevant."
The cost is not irrelevant. If consumers are willing to buy for $.1 and the providers are willing to sell for $.01, economics says the price should be between $.01 and $.1. But why should it be $.1 and not $.01? Why is it clamped at what the consumers are willing to pay and not what the providers are willing to sell for?
It is because the providers set the stage. They have control of the market. They operate together, not necessarily directly through collusion, but possibly indirectly through using the same marketing research companies, industry organizations, et cetera.
In a healthy market, the price floats somewhere between the minimum price the providers are willing to sell for and the maximum price the sellers are willing to buy for. There is a give-and-take. Prices may hit one end of the clamp or another from time to time due to natural fluctuations, but when it is grossly disproportionate to actual costs, then there is something wrong. The market is unhealthy and is being unfairly manipulated.
"And information in digital form is inherently binary, both when stored, and when manipulated."
While common methods of storing information may be inherently binary, the amount of information is not. However, since memory also has to be addressed, and the addresses are also in binary form, that leads to the amount of memory being a power of two, or small multiples of a power of two. E.g., it is easier to design a system into which you can plug some number of one-mebibyte memory chips because then 20 bits can select the byte within each chip and additional bits can select which chip. If the chips were one-megabyte, it would be harder to design electronics that could select the chip given an address in a continuous address space.
However, that reasoning does not apply when there is a single device involved. If you had only one memory chip, it would not make much difference whether it were one-mebibyte, one-megabyte, or some other number--all the address bits involved would select a byte within the chip, and the operating system would simply never use an address larger than those in the chip. The same applies to disk drivesyou do not need to fit together the bytes or blocks of multiple disks into a seamless sequential number scheme, so there is no particular reason for the sizes to fall into any particular pattern.
"... kB, mB and gB. The idea being that the lower case prefix would prevent confusion with SI prefixs.
I have never seen any such convention. In fact, the SI abbreviation for kilo is k, in lowercase, unlike M for mega and G for giga.
Electronics has a long history of correct use of SI units for quantities of information, including device sizes and communication speeds. The use of binary units is newer, and the old and correct uses should not be required to change to the new uses that violate the formal, specific, and long-standing SI definitions.
I work at Apple, and I entered a bug report. I suspect the problem is merely a display error in World Clock, but, since it is affecting many people, I asked my manager to ensure the right people are notified quickly.
The problem does not seem to affect date displays outside of World Clock. For example, if you go into General settings, then Date & Time, turn off "Set Automatically," set the date to January 1, 2008, and then look at some recent calls in the phone, you will see they have correct dates. At least for me. If somebody observes otherwise, please let me know, and I will add it to the bug report.
"Maybe we should do away with insurance (averaging) altogether..."
Insurance is not for averaging events with different probabilities. Insurance is for reducing standard deviation, which is done by averaging samples of about the same probability.
If the average chance I will suffer $100,000 damages (such as needing surgery) is 1/1,000, why would I sign up for insurance with somebody whose average chance of suffering $100,000 damages is 1/100? We would have to pay $550 each, which is way more than my $100 average loss.
On the other hand, I want to do something about this risk; many people cannot withstand a $100,000 event. If 100 people with the same risk get together and agree to share expenses, their risk changes from 1/1,000 of $100,000 to about 4.5% of $1,000 (chance and per-person cost of exactly one person getting sick) plus about.0045% chance of $2,000 (chance and cost of two people getting sick) plus the costs of three, four, or more people getting sick. On average, each person in the group pays $100 (plus business costs), but the probability they would have to pay a great deal of money decreases tremendously. (The probability they have to pay a little money goes up.)
With insurance, the average stays the same (except for business costs) but the standard deviation decreases. Insurance works that way. If you try to use it to change a person's average cost, it will not work, because the people who have low averages will not do business with you.
I am one of the few programmers who still work in assembly language. I work in
a specialized group at Apple that produces numerical libraries. One is the
standard math library that provides functions like sin and log. Others are
high-performance libraries for signal and image processing.
The high-performance numerical work requires more than just assembly
programming. You also need some mathematics, understanding of processor
internals and system architecture, and how to use assembly programming to get
high performance. Getting the most out of a modern processor can be quite
complicated. Although compilers get better, processors get more complicated,
and there are gaps. Sometimes these gaps are large, so good assembly
programmers can get huge performance gains over compilers. And that makes it
worth paying them.
A modern processor does not just execute one instruction after another. It may
start a floating-point multiplication in one of its execution units and an
integer add in another. In the next processor cycle, the add may be done, but the
multiplication has two more cycles to go. Meanwhile, the processor is fetching
data for a load that was requested five cycles ago. It is not in cache, so you
have to wait longer for it. There is a store waiting to execute, but it cannot
start because it needs the multiply to finish. Dozens of instructions are in
various stages of execution at one time.
Good compilers "know" some of this, and they can do some instruction scheduling
to reduce some of the wait times. But they are not great, and programmers can
do a lot more. They can rearrange data structures or patterns of use so that
data is in cache when it is needed. They can overlap different parts of their
code so that while that store is waiting for that multiply, a different
multiply for another set of data can execute. Some compilers might spot a few
of those opportunities, but a programmer can rearrange code in ways a compiler
is not allowed to. A programmer might know that a load is reading from a
different address than a store is writing to, so it is okay to move the load
instruction ahead of the store instruction. A compiler is not allowed to make
that assumption.
Compilers are also not good at using Single Instruction Multiple Data (SIMD)
instructions (as in AltiVec or SSE). SIMD exists because the control logic of
a processor is very complicated -- a lot of logic is needed to keep track of
which instructions have started executing, what data they need, what other
instructions depend on their outputs, and so on. Some processors have
speculative branching; they "guess" which way a conditional branch will go and
start work early on instructions along that branch. If the guess turns out to
be wrong, they have to throw away the speculative work and restore to an
earlier state -- processor contents, flags, everything has to appear as if the
branch had never been taken. That takes a lot of silicon. So one way to get
more work done without creating more instructions to be kept track of is SIMD
instructions -- one instruction does the same operation on multiple pieces of
data. Processors with SIMD instructions have registers that may be 128 bits
wide, enough to hold four single-precision floating-point values or eight
16-bit integers, or other combinations. Executing one SIMD instruction may
multiply each of the four numbers in one register by each of the four numbers
in another register.
That is great, you can get a lot of work done, but how much of your code is
written to multiply four numbers by four other numbers? Most programmers just
think about one set of data at a time, and that is what they write, so that is
what the compiler sees. When you compile regular code, you get regular
instructions, not SIMD instructions. Wouldn't you rather your code go four
times as fast? If you have a nice clean loop that processes all the contents of
several arrays, some compilers, called vectorizing compilers, can generate SIMD
instructions for your loop. If you really want to take advantage
"As they've been releasing 10.5 beta updates to developers, they've been simultaneously releasing even newer builds for internal use only. Why do that unless you have some UI changes you're trying to keep a secret?"
Apple releases plenty of internal builds because there is a lot of work going on, and doing builds daily is a way of keeping on top of the latest work by various engineers. The compiler people make a change that the kernel people wanted, the kernel people add a new feature for the file system to use, the file system people use that to enable something that's been under development, then an application that wanted the feature changes, et cetera. Another reason for frequent builds is to get new code distributed to many people so that it is exercised and problems are discovered as quickly as possible. Apple releases only a few external builds because, I presume, they are much more work to manage, and they are generally better builds with more coordinated features and fewer problems. This is simply normal software development practice for complicated projects, so I am not saying anything particular about Apple.
I expect there are some features held back from the external releases to developers, and a UI change could be part of that, especially if it mostly cosmetic and does not affect programming interfaces, but largely those releases are simply done on occasion, and Apple tries to select a reasonably good build to release. (Some of the internal releases are quite, um, challenging to use.) One purpose for distributing releases to external developers is so they can work with API changes in time to prepare their software. Occasional releases are fine for that.
Note that I cannot fully say from actual knowledge how the external releases are constructed. Apple is very secretive and does have various projects that are undisclosed externally and internally, but I do not think external build releases being rarer than internal releases is a sign of this.
I will add "me too" on the Ameritrade issue. My unique Ameritrade address was leaked before 2005-10-31, and a different unique Ameritrade address was leaked between 2005-11-24 and 2006-8-11. They did not respond to the first letter I sent about it, but now they have acknowledged the problem. At this point, they have to know when it happens, people will know.
"In floating-point arithmetic, the algorithm was proved in 1966..."
"Proof" is nice, but my comments are based on actual measurement. I have code that performs single- and double-precision FFTs on eight million numbers randomly selected from a uniform distribution over [0, 1). (The test program uses simple radix-2 code just for study, not anything you'd use in high performance.)
In a typical run, I observe an average error of 2^-12.5 (using double as a reference for error in single). In three runs, I observe a maximum error of 2^-2.28, 2^-2.90, and 2^-2.74. Compare that to, say, 1024 elements, where I observed an average of 2^-19.5 and maximums around 2^-15.5. If the maximum error were proportional to log N and the 1024-element case were representative, we'd extrapolate around 23/10*2^-15.5 for the eight-million-element case, which is 2^-14.3.
If you cite an easily accessible paper, I'll take a look at it.
"(See this page for more info.)"
That page uses an L[2] norm to determine one error for the entire vector, and it is a relative error. I discussed absolute errors in individual elements (real and imaginary separately). It also indicates the bounds on growth apply to the L[2] norm. I do not see a comment on growth with the L[1] or L[infinity] norms, which would correspond to the average error in the elements and the maximum error in the elements.
Note also that their error is a relative error. They take the norm of the error vector and divide it by the norm of the correct vector. The norm of the correct vector is proportional to N. If the relative error is proportional to log(N) and you multiply it by N, you get log(N)*N, just what I stated for the absolute errors.
That page also used a distribution over [-.5,.5). I changed my code to use that and saw a change in absolute scale of the error but not the order of growth.
"If you are taking data off of some kind of sensor, there are damned few sensors with 24 good bits of data out of the noise floor. Radars work just fine with 16-bit A/D converters."
Take a look at their benchmarks. The chart goes up to eight million elements. The accumulated rounding error in FFT outputs may be around n * log2(n) ULP, where n is the number of elements, and ULP (units in last place) is relative to the largest input element. (Caveats: That is the maximum; the distribution of the logs of the errors resembles a normal distribution. Input was numbers selected from a uniform distribution over [0, 1). The error varies slightly depending on whether you have fused multiply-add and other factors.)
So with eight million elements, the error may be 184 million ULP, or over 27 bits. With only 24 bits in your floating-point format, that is a problem. Whether you had 24-bit or 1-bit data to start with, it is essentially gone in some output elements. Most errors are less than the maximum, but it seems there is a lot of noise and not so much signal.
It may be that the most interesting output elements are the ones with the highest magnitude. (The FFT is used to find the dominant frequencies in a signal.) If so, those output elements may be large relative to the error, so there could be useful results. However, anybody using such a large FFT with single-precision floating-point should analyze the error in their application.
This isn't a bug in the arithmetic; it is an artifact of the design. The calculator is almost certainly using the hardware's double-precision floating-point numbers for calculation. The implementation obeys the IEEE 754 standard for floating-point arithmetic. It represents a number with a sign, 11 bits for an exponent of two, and 53 bits for the significand (the "fraction part" in some sense and including an implicit one bit).
The mathematical number 9533.24 cannot be represented exactly as a double-precision number, because 9533.24 expressed in binary has a repeating string that goes on forever. It is 10010100111101.00111101011100001010001111010111000 01010001111...
When you round it after 53 bits, you have 10010100111101.00111101011100001010001111010111000 0101, or 81889908046875/8589934592 or about 9533.2399999999997817.
Similarly, 215.10 is 11010111.00011001100110011001100110011001100110011 00110011001...
Rounded to 53 digits, that is 11010111.00011001100110011001100110011001100110011 0011 or 7568158436307763/35184372088832 or about 215.09999999999999432.
The difference is exactly 327852904935829005/35184372088832 or 10010001100110.00100011110101110000101000111101011 1000001101 or about 9318.1399999999997874.
However, you cannot represent the difference in double-precision, because it requires too many bits.
The result of a subtraction instruction is rounded, and you get 640337704952791/68719476736 or 10010001100110.00100011110101110000101000111101011 1 or about 9318.1399999999994179.
(Caveat: I produced the above numbers with some quick Maple commands. They could be off a bit, but the concepts are correct.)
It might be nice if calculators intended for the general public used decimal arithmetic internally. (But it still would not be able to exactly calculate 1/3 * 3. There will always be limits to mathematical correctness.) But that is an issue of application design; it has nothing to do with correct floating-point results, as mentioned in the post you responded to. The floating-point arithmetic here is correct.
"Do I get these with a generic compile of an XCode project (curious)?"
Yes, in things like memcpy, you will get AltiVec instructions with just default switches. You could single-step through memcpy (actually a subroutine named __bigcopy) in the debugger and see the instructions.
The compiler isn't going to automatically recognize you're doing an FFT routine and call an optimized routine instead of using your code. So, to use the optimized signal processing routines, you would add a reference to the Accelerate framework to your project and call the routines explicitly. There is work on having the compiler recognize more and more situations where it can use AltiVec code or prepared routines.
"No, at this point too much needs hand tuning for everything to fully utilize the potential of Altivec. Most serious DSP-class apps spend the effort to do this in critical code, but..."
Of course it is rarely true that AltiVec instructions are used to their "full potential" in the sense you can usually find another CPU cycle to eliminate, but neither is it necessary to use hand tuning to get big boosts from AltiVec. We do the hand tuning for you (in C with AltiVec extensions or in assembly language) and provide optimized libraries, such as BLAS, vDSP, vImage, and others bundled into the Accelerate framework. (As another participant notes, some library interfaces and functions are not original to Apple, but Apple provides optimization.) The libraries are used in a variety of places throughout Apple's software, even inside the kernel, and are available to external developers.
It does take a certain class of algorithms to get a lot of use from the libraries, but some of the routines are of general benefit. You would expect image processing, music encoding and decoding, and mathematical algorithms to run faster with AltiVec, but even simple things like copying memory are significantly faster when done with AltiVec instructions.
"Basically, what the crowd here seems to want is that:"
That is utter rubbish. It is ad hominem and is not consistent with comments I have generally observed in Slashdot.
"Spammers should be summarily shot."
Redress should be quick and effective, like the ability of recipients of unlawful telephone calls to sue in small claims court.
"To accomplish that, Internet anonymity should be eliminated for spammers, while not affecting the rest of us."
Anonymity should be preserved in web browsing, participating in discussion fora where the owners desire that, sending email where the recipients desires to allow sender anonymity, and in other communications where all parties consent to such arrangements. Anonymity should not be allowed in sending email if the recipient does not desire that.
"Oh, and if anyone can think of a way by which a single spam might slip through, a proposal is obviously worthless and the person who proposed it is a techno-illiterate simpleton."
The flaws of the CAN-SPAM act are many orders of magnitude greater than letting a single spam slip through. The CAN-SPAM legitimized spam that was illegal before, by overriding state laws. It provided no effective redress. It did not outlaw much, perhaps most, of the spam that people do not want, even within US jurisdiction.
"Paypal has the right to determine with whom they do business."
I do not understand the thinking behind statements like this. What is your point? There is no dispute that a right exists. However, that has nothing to do with whether it is behavior we wish to encourage or discourage or whether the behavior is good or bad for us.
If a company makes a policy we think is harmful to interests we want to promote, why shouldn't we criticize it, even boycott it? The fact that the company has a right to do what it does is not a reason for us to remain silent and do nothing.
If Jane opens a new restaurant and serves only foods loaded with things that are bad for you (and loaded in gross disproportion to any benefit, such as good taste), she has a right to do that, and I have a right, and it is a good idea, for me to avoid that restaurant. It is also a good idea for me to advise my friends to avoid the restaurant.
The fact that somebody has a right to do something means we should not use force to stop them. It does not mean we should not use other means to discourage them.
"It implies that MS would be getting taxed on things they buy, not taxing the end user..."
The article said no such thing. It just said a "90 percent tax rate" for 90 percent market share. It did not say tax on sales of things sold, tax on sales of things bought, tax on income, tax on real estate, tax on income, or anything else specific. This idea could be implemented in ways such that marginal profit per increase in market share approaches a positive value (impairing but not preventing unending growth), zero (limiting growth asymptotically), or a negative value (stopping growth before reaching market saturation).
"So what's the incentive to grow bigger?"
As I said originally, the goal is to reduce the incentive to grow bigger. You haven't addressed the fundamental assumption of this suggestion -- that bigger is not always better. You've complained because the suggestion impedes growth, but you haven't given any reason to believe that isn't a good thing.
"That, of course, leads to questions like, 'Who will decide what the best market share is?'"
So? A suggestion is bad because it leads to questions? All of life leads to questions. You might as well argue against taxes altogether becuase it leads to questions like, "Who will decide what the best tax rate is?" Or argue against laws altogether because it leads to questions like, "Who decides what should be illegal?" Yes, there are questions. We'll work on them.
Economists can estimate how much harm monopolistic or dominant practices cause and recommend tax amounts, which will then be negotiated in the political process like everything else. Yes, they will only be estimates, but so is everything complicated.
"When it started, Apple had about 99% market share."
They didn't have 99% of music sales. And new markets can be exempt for a few years.
"By your model..."
It is not my model. I didn't suggest it. As I said, I wasn't supporting it, just explaining it. I'm not sure I would support it if it came up for vote. I'm encouraging discussion and thought.
"... fully thought through."
Opposing an idea because it is not fully thought through is doing the same thing you were complaining about -- preventing Apple from starting a new market. It's a novel idea; let it grow for a bit before you tax it out of existence.
Slashdot Mirror
I write some of Apple’s FFTs and other signal-processing code, and I happen to have been pondering this question lately. My software will be in a billion computers in the next few years, and there will be sextillions of executions of instructions I have written. However, somebody out there will have more...
As others have noted, spreading a virus and teaching others to spread a virus is dangerous, even if the virus is "benign." If the virus spreads to the system of any person who did not consent, you have committed an unethical and possibly unlawful act.
That said, it is necessary to learn and to teach. If you have responsible students who have agreed to take proper precautions, it may be permissible to perform certain exercises with viruses. However, while you can get ideas from Slashdot, you should not accept advice. You should verify the ideas independently with professionals in computer security.
I am not one, but one idea is to take some ideas from the methods used to prevent biological organisms from spreading while experimenting on those. For example, design the virus to spread only to systems that contain a special marker, such as a file in a known location that contains the text "This system is part of the equipment for course 123 in the Fall 2012 semester." This would prevent the virus from spreading to other systems even if a network connection were made or somebody moved a disk from your isolated systems to a networked system. It would not, of course, stop one of your students from disabling that part of the virus and making themselves a fun "toy" to play with, which is why you need to ensure your students are trustworthy.
"Hell, what if they said 'If you keep taking that pill, you will die in 10 years, otherwise you will die in 15'? Well, right now some might actually say 'I'll keep taking it', speaking for that person in 9 3/4 years who may answer VERY differently-- again a human inability to logically analyze the situation and come to an honest conclusion."
That example does not demonstrate any inability to analyze the situation. A person might value their quality of life with the pill more than 50% more than their quality of life without the pill, in which case 10 years with the pill is worth more than 15 years without the pill.
Then, in 9 3/4 years, their choice is 1/4 year with the pill versus 5 1/4 year without the pill, in which case it makes sense to discontinue the pill, unless their quality of life is much, much greater with the pill.
Because your bank or broker gives you statements that you must keep for tax or evidentiary purposes, and you think you can read them, but they break sometime in the future when your bank or broker "upgrades" their system.
Because you keep important information in Google Documents or some other quasi-online service, and you lose access to them in the future when the service is discontinued. Or when the free service is changed to a paid service.
Because the software is important to your business, and you need to ensure you will be able to continue to run it.
Because you want to keep a copy of the agreement offered when you opened an account.
Because you want to study the encryption and other security features used to protect your information or to allow qualified professionals to study the security features so they can advise the public about them. (E.g., you would like skilled and informed university professors to analyze the security features so they can warn you when certain software is not up to snuff, so that extra care can be taken.)
If you just use your web "browser" to browse or play games, you might not care about the software running in it. But if you use it for things you rely on, for safety or security or important information or record-keeping or making money, then you care about the software running on it, and you want some assurance and control over it.
"What I mean, is that to pay with credit cards, from what I know, you only need the data that is written right on the card."
No, there are other safeguards. For one thing, you need to know some address information associated with the card, such as house number and postal code. If the product is not being shipped to an address the credit card issuer knows is associated with the card, then there may be additional checks. There is a three-digit verification code that the purchaser may be asked to supply. This code is not printed in raised lettering, so it is not recorded on old-style physical imprints of the card, and merchants are not supposed to keep a record of it once the transaction has been approved. (They have the credit card number and an approval number unique to the transaction.)
As another respondent mentions, the credit card holder is responsible for reviewing their statements and notifying the credit card issuer of fraudulent transactions. Then the issuer can withhold the money from the merchant or otherwise get it back.
In Germany, you can send money to people by writing some information about your account and about the payee and their account on a bank form and depositing it into a box at your bank. What prevents that from being used fraudulently? I wondered about that when I lived there. I suppose the fact that the money goes to account provides some safety, as the destination back should have some knowledge of their customer.
"Why in the world do modern e-mail clients still allow reply all to hundreds of recipients without an additional safety question."
Because the client has no information about the number of recipients. It only knows the number of addresses the message is addressed to. A "reply all" on the lists I participate in commonly generates a message with two destination addresses, the individual sender and the list. The client does not know how many people are on the list or even that it is a list.
Certainly a client ought to ask for confirmation when there are more than a few addresses (subject to a customizable threshold so users who regularly send messages to many people can do so easily). However, you also need list servers to guard against email storms. Perhaps servers should request confirmation when there are symptoms of inadvertent, indiscriminate, or ignorant reply-all messages, such as trivial new text in a message with much quoted text, requests to unsubscribe, a reply from a new first-time sender on the list, etc.
Ideally, one should have a formal education before writing software professionally--there is a lot of theory that has been figured out that is useful to know in practice. However, given that that is not going to happen, then my advice is to avoid reinventing the wheel, or, worse, inventing a bumpy thing that the car rides on but is slow and inefficient and uncomfortable and breaks from time to time. Collect references where you can look up algorithms and theory--apply what other people have done instead of writing new algorithms. Most programmers' jobs are tailoring known algorithms to current situations, not writing new algorithms.
"People are willing to pay $0.10 to send a text message. What it COSTS to provide the message is irrelevant."
The cost is not irrelevant. If consumers are willing to buy for $.1 and the providers are willing to sell for $.01, economics says the price should be between $.01 and $.1. But why should it be $.1 and not $.01? Why is it clamped at what the consumers are willing to pay and not what the providers are willing to sell for?
It is because the providers set the stage. They have control of the market. They operate together, not necessarily directly through collusion, but possibly indirectly through using the same marketing research companies, industry organizations, et cetera.
In a healthy market, the price floats somewhere between the minimum price the providers are willing to sell for and the maximum price the sellers are willing to buy for. There is a give-and-take. Prices may hit one end of the clamp or another from time to time due to natural fluctuations, but when it is grossly disproportionate to actual costs, then there is something wrong. The market is unhealthy and is being unfairly manipulated.
That is why cost is relevant.
"And information in digital form is inherently binary, both when stored, and when manipulated."
While common methods of storing information may be inherently binary, the amount of information is not. However, since memory also has to be addressed, and the addresses are also in binary form, that leads to the amount of memory being a power of two, or small multiples of a power of two. E.g., it is easier to design a system into which you can plug some number of one-mebibyte memory chips because then 20 bits can select the byte within each chip and additional bits can select which chip. If the chips were one-megabyte, it would be harder to design electronics that could select the chip given an address in a continuous address space.
However, that reasoning does not apply when there is a single device involved. If you had only one memory chip, it would not make much difference whether it were one-mebibyte, one-megabyte, or some other number--all the address bits involved would select a byte within the chip, and the operating system would simply never use an address larger than those in the chip. The same applies to disk drivesyou do not need to fit together the bytes or blocks of multiple disks into a seamless sequential number scheme, so there is no particular reason for the sizes to fall into any particular pattern.
"... kB, mB and gB. The idea being that the lower case prefix would prevent confusion with SI prefixs.
I have never seen any such convention. In fact, the SI abbreviation for kilo is k, in lowercase, unlike M for mega and G for giga.
Electronics has a long history of correct use of SI units for quantities of information, including device sizes and communication speeds. The use of binary units is newer, and the old and correct uses should not be required to change to the new uses that violate the formal, specific, and long-standing SI definitions.
I work at Apple, and I entered a bug report. I suspect the problem is merely a display error in World Clock, but, since it is affecting many people, I asked my manager to ensure the right people are notified quickly.
The problem does not seem to affect date displays outside of World Clock. For example, if you go into General settings, then Date & Time, turn off "Set Automatically," set the date to January 1, 2008, and then look at some recent calls in the phone, you will see they have correct dates. At least for me. If somebody observes otherwise, please let me know, and I will add it to the bug report.
"Maybe we should do away with insurance (averaging) altogether..."
Insurance is not for averaging events with different probabilities. Insurance is for reducing standard deviation, which is done by averaging samples of about the same probability.
If the average chance I will suffer $100,000 damages (such as needing surgery) is 1/1,000, why would I sign up for insurance with somebody whose average chance of suffering $100,000 damages is 1/100? We would have to pay $550 each, which is way more than my $100 average loss.
On the other hand, I want to do something about this risk; many people cannot withstand a $100,000 event. If 100 people with the same risk get together and agree to share expenses, their risk changes from 1/1,000 of $100,000 to about 4.5% of $1,000 (chance and per-person cost of exactly one person getting sick) plus about .0045% chance of $2,000 (chance and cost of two people getting sick) plus the costs of three, four, or more people getting sick. On average, each person in the group pays $100 (plus business costs), but the probability they would have to pay a great deal of money decreases tremendously. (The probability they have to pay a little money goes up.)
With insurance, the average stays the same (except for business costs) but the standard deviation decreases. Insurance works that way. If you try to use it to change a person's average cost, it will not work, because the people who have low averages will not do business with you.
I am one of the few programmers who still work in assembly language. I work in a specialized group at Apple that produces numerical libraries. One is the standard math library that provides functions like sin and log. Others are high-performance libraries for signal and image processing.
The high-performance numerical work requires more than just assembly programming. You also need some mathematics, understanding of processor internals and system architecture, and how to use assembly programming to get high performance. Getting the most out of a modern processor can be quite complicated. Although compilers get better, processors get more complicated, and there are gaps. Sometimes these gaps are large, so good assembly programmers can get huge performance gains over compilers. And that makes it worth paying them.
A modern processor does not just execute one instruction after another. It may start a floating-point multiplication in one of its execution units and an integer add in another. In the next processor cycle, the add may be done, but the multiplication has two more cycles to go. Meanwhile, the processor is fetching data for a load that was requested five cycles ago. It is not in cache, so you have to wait longer for it. There is a store waiting to execute, but it cannot start because it needs the multiply to finish. Dozens of instructions are in various stages of execution at one time.
Good compilers "know" some of this, and they can do some instruction scheduling to reduce some of the wait times. But they are not great, and programmers can do a lot more. They can rearrange data structures or patterns of use so that data is in cache when it is needed. They can overlap different parts of their code so that while that store is waiting for that multiply, a different multiply for another set of data can execute. Some compilers might spot a few of those opportunities, but a programmer can rearrange code in ways a compiler is not allowed to. A programmer might know that a load is reading from a different address than a store is writing to, so it is okay to move the load instruction ahead of the store instruction. A compiler is not allowed to make that assumption.
Compilers are also not good at using Single Instruction Multiple Data (SIMD) instructions (as in AltiVec or SSE). SIMD exists because the control logic of a processor is very complicated -- a lot of logic is needed to keep track of which instructions have started executing, what data they need, what other instructions depend on their outputs, and so on. Some processors have speculative branching; they "guess" which way a conditional branch will go and start work early on instructions along that branch. If the guess turns out to be wrong, they have to throw away the speculative work and restore to an earlier state -- processor contents, flags, everything has to appear as if the branch had never been taken. That takes a lot of silicon. So one way to get more work done without creating more instructions to be kept track of is SIMD instructions -- one instruction does the same operation on multiple pieces of data. Processors with SIMD instructions have registers that may be 128 bits wide, enough to hold four single-precision floating-point values or eight 16-bit integers, or other combinations. Executing one SIMD instruction may multiply each of the four numbers in one register by each of the four numbers in another register.
That is great, you can get a lot of work done, but how much of your code is written to multiply four numbers by four other numbers? Most programmers just think about one set of data at a time, and that is what they write, so that is what the compiler sees. When you compile regular code, you get regular instructions, not SIMD instructions. Wouldn't you rather your code go four times as fast? If you have a nice clean loop that processes all the contents of several arrays, some compilers, called vectorizing compilers, can generate SIMD instructions for your loop. If you really want to take advantage
"As they've been releasing 10.5 beta updates to developers, they've been simultaneously releasing even newer builds for internal use only. Why do that unless you have some UI changes you're trying to keep a secret?"
Apple releases plenty of internal builds because there is a lot of work going on, and doing builds daily is a way of keeping on top of the latest work by various engineers. The compiler people make a change that the kernel people wanted, the kernel people add a new feature for the file system to use, the file system people use that to enable something that's been under development, then an application that wanted the feature changes, et cetera. Another reason for frequent builds is to get new code distributed to many people so that it is exercised and problems are discovered as quickly as possible. Apple releases only a few external builds because, I presume, they are much more work to manage, and they are generally better builds with more coordinated features and fewer problems. This is simply normal software development practice for complicated projects, so I am not saying anything particular about Apple.
I expect there are some features held back from the external releases to developers, and a UI change could be part of that, especially if it mostly cosmetic and does not affect programming interfaces, but largely those releases are simply done on occasion, and Apple tries to select a reasonably good build to release. (Some of the internal releases are quite, um, challenging to use.) One purpose for distributing releases to external developers is so they can work with API changes in time to prepare their software. Occasional releases are fine for that.
Note that I cannot fully say from actual knowledge how the external releases are constructed. Apple is very secretive and does have various projects that are undisclosed externally and internally, but I do not think external build releases being rarer than internal releases is a sign of this.
His scents sense makes cents.
I will add "me too" on the Ameritrade issue. My unique Ameritrade address was leaked before 2005-10-31, and a different unique Ameritrade address was leaked between 2005-11-24 and 2006-8-11. They did not respond to the first letter I sent about it, but now they have acknowledged the problem. At this point, they have to know when it happens, people will know.
"Proof" is nice, but my comments are based on actual measurement. I have code that performs single- and double-precision FFTs on eight million numbers randomly selected from a uniform distribution over [0, 1). (The test program uses simple radix-2 code just for study, not anything you'd use in high performance.)
In a typical run, I observe an average error of 2^-12.5 (using double as a reference for error in single). In three runs, I observe a maximum error of 2^-2.28, 2^-2.90, and 2^-2.74. Compare that to, say, 1024 elements, where I observed an average of 2^-19.5 and maximums around 2^-15.5. If the maximum error were proportional to log N and the 1024-element case were representative, we'd extrapolate around 23/10*2^-15.5 for the eight-million-element case, which is 2^-14.3.
If you cite an easily accessible paper, I'll take a look at it.
"(See this page for more info.)"
That page uses an L[2] norm to determine one error for the entire vector, and it is a relative error. I discussed absolute errors in individual elements (real and imaginary separately). It also indicates the bounds on growth apply to the L[2] norm. I do not see a comment on growth with the L[1] or L[infinity] norms, which would correspond to the average error in the elements and the maximum error in the elements.
Note also that their error is a relative error. They take the norm of the error vector and divide it by the norm of the correct vector. The norm of the correct vector is proportional to N. If the relative error is proportional to log(N) and you multiply it by N, you get log(N)*N, just what I stated for the absolute errors.
That page also used a distribution over [-.5, .5). I changed my code to use that and saw a change in absolute scale of the error but not the order of growth.
Take a look at their benchmarks. The chart goes up to eight million elements. The accumulated rounding error in FFT outputs may be around n * log2(n) ULP, where n is the number of elements, and ULP (units in last place) is relative to the largest input element. (Caveats: That is the maximum; the distribution of the logs of the errors resembles a normal distribution. Input was numbers selected from a uniform distribution over [0, 1). The error varies slightly depending on whether you have fused multiply-add and other factors.)
So with eight million elements, the error may be 184 million ULP, or over 27 bits. With only 24 bits in your floating-point format, that is a problem. Whether you had 24-bit or 1-bit data to start with, it is essentially gone in some output elements. Most errors are less than the maximum, but it seems there is a lot of noise and not so much signal.
It may be that the most interesting output elements are the ones with the highest magnitude. (The FFT is used to find the dominant frequencies in a signal.) If so, those output elements may be large relative to the error, so there could be useful results. However, anybody using such a large FFT with single-precision floating-point should analyze the error in their application.
The mathematical number 9533.24 cannot be represented exactly as a double-precision number, because 9533.24 expressed in binary has a repeating string that goes on forever. It is 10010100111101.00111101011100001010001111010111000 01010001111...
When you round it after 53 bits, you have 10010100111101.00111101011100001010001111010111000 0101, or 81889908046875/8589934592 or about 9533.2399999999997817.
Similarly, 215.10 is 11010111.00011001100110011001100110011001100110011 00110011001...
Rounded to 53 digits, that is 11010111.00011001100110011001100110011001100110011 0011 or 7568158436307763/35184372088832 or about 215.09999999999999432.
The difference is exactly 327852904935829005/35184372088832 or 10010001100110.00100011110101110000101000111101011 1000001101 or about 9318.1399999999997874.
However, you cannot represent the difference in double-precision, because it requires too many bits.
The result of a subtraction instruction is rounded, and you get 640337704952791/68719476736 or 10010001100110.00100011110101110000101000111101011 1 or about 9318.1399999999994179.
(Caveat: I produced the above numbers with some quick Maple commands. They could be off a bit, but the concepts are correct.)
It might be nice if calculators intended for the general public used decimal arithmetic internally. (But it still would not be able to exactly calculate 1/3 * 3. There will always be limits to mathematical correctness.) But that is an issue of application design; it has nothing to do with correct floating-point results, as mentioned in the post you responded to. The floating-point arithmetic here is correct.
Yes, in things like memcpy, you will get AltiVec instructions with just default switches. You could single-step through memcpy (actually a subroutine named __bigcopy) in the debugger and see the instructions.
The compiler isn't going to automatically recognize you're doing an FFT routine and call an optimized routine instead of using your code. So, to use the optimized signal processing routines, you would add a reference to the Accelerate framework to your project and call the routines explicitly. There is work on having the compiler recognize more and more situations where it can use AltiVec code or prepared routines.
Of course it is rarely true that AltiVec instructions are used to their "full potential" in the sense you can usually find another CPU cycle to eliminate, but neither is it necessary to use hand tuning to get big boosts from AltiVec. We do the hand tuning for you (in C with AltiVec extensions or in assembly language) and provide optimized libraries, such as BLAS, vDSP, vImage, and others bundled into the Accelerate framework. (As another participant notes, some library interfaces and functions are not original to Apple, but Apple provides optimization.) The libraries are used in a variety of places throughout Apple's software, even inside the kernel, and are available to external developers.
It does take a certain class of algorithms to get a lot of use from the libraries, but some of the routines are of general benefit. You would expect image processing, music encoding and decoding, and mathematical algorithms to run faster with AltiVec, but even simple things like copying memory are significantly faster when done with AltiVec instructions.
That is not a bug but an accurate model of reality. When you strand 32,768 passengers, they will turn negative.
That is utter rubbish. It is ad hominem and is not consistent with comments I have generally observed in Slashdot.
"Spammers should be summarily shot."
Redress should be quick and effective, like the ability of recipients of unlawful telephone calls to sue in small claims court.
"To accomplish that, Internet anonymity should be eliminated for spammers, while not affecting the rest of us."
Anonymity should be preserved in web browsing, participating in discussion fora where the owners desire that, sending email where the recipients desires to allow sender anonymity, and in other communications where all parties consent to such arrangements. Anonymity should not be allowed in sending email if the recipient does not desire that.
"Oh, and if anyone can think of a way by which a single spam might slip through, a proposal is obviously worthless and the person who proposed it is a techno-illiterate simpleton."
The flaws of the CAN-SPAM act are many orders of magnitude greater than letting a single spam slip through. The CAN-SPAM legitimized spam that was illegal before, by overriding state laws. It provided no effective redress. It did not outlaw much, perhaps most, of the spam that people do not want, even within US jurisdiction.
I do not understand the thinking behind statements like this. What is your point? There is no dispute that a right exists. However, that has nothing to do with whether it is behavior we wish to encourage or discourage or whether the behavior is good or bad for us.
If a company makes a policy we think is harmful to interests we want to promote, why shouldn't we criticize it, even boycott it? The fact that the company has a right to do what it does is not a reason for us to remain silent and do nothing.
If Jane opens a new restaurant and serves only foods loaded with things that are bad for you (and loaded in gross disproportion to any benefit, such as good taste), she has a right to do that, and I have a right, and it is a good idea, for me to avoid that restaurant. It is also a good idea for me to advise my friends to avoid the restaurant.
The fact that somebody has a right to do something means we should not use force to stop them. It does not mean we should not use other means to discourage them.
This survey didn't prove people treat passwords as unimportant. It proved chocolate is more important than passwords! Get your priorities straight.
The article said no such thing. It just said a "90 percent tax rate" for 90 percent market share. It did not say tax on sales of things sold, tax on sales of things bought, tax on income, tax on real estate, tax on income, or anything else specific. This idea could be implemented in ways such that marginal profit per increase in market share approaches a positive value (impairing but not preventing unending growth), zero (limiting growth asymptotically), or a negative value (stopping growth before reaching market saturation).
"So what's the incentive to grow bigger?"
As I said originally, the goal is to reduce the incentive to grow bigger. You haven't addressed the fundamental assumption of this suggestion -- that bigger is not always better. You've complained because the suggestion impedes growth, but you haven't given any reason to believe that isn't a good thing.
"That, of course, leads to questions like, 'Who will decide what the best market share is?'"
So? A suggestion is bad because it leads to questions? All of life leads to questions. You might as well argue against taxes altogether becuase it leads to questions like, "Who will decide what the best tax rate is?" Or argue against laws altogether because it leads to questions like, "Who decides what should be illegal?" Yes, there are questions. We'll work on them.
Economists can estimate how much harm monopolistic or dominant practices cause and recommend tax amounts, which will then be negotiated in the political process like everything else. Yes, they will only be estimates, but so is everything complicated.
"When it started, Apple had about 99% market share."
They didn't have 99% of music sales. And new markets can be exempt for a few years.
"By your model..."
It is not my model. I didn't suggest it. As I said, I wasn't supporting it, just explaining it. I'm not sure I would support it if it came up for vote. I'm encouraging discussion and thought.
"... fully thought through."
Opposing an idea because it is not fully thought through is doing the same thing you were complaining about -- preventing Apple from starting a new market. It's a novel idea; let it grow for a bit before you tax it out of existence.