You know, if you asked me which bits of my code where the hardest to write, and likely to contain bugs, I can tell you. In fact, I usually comment on code reviews in this way to help direct a reviewer to the bits I think need attention. Being self-critical is a very useful skill, accepting your limitations, asking others to help.
I had a Fujitsu Eagle from the 80s which used multiple heads per side. The drive was used on a PDP-11, was 19 inch rack mount, and had a perspex cover, so you could watch the heads seeking when the drive was in use.
Actually, i'd suggest you find the market with the largest amount of liquidity, rather than worrying about where it comes from. NYSE, NASDAQ, LSE, OMX, there's plenty to choose from with sensible pricing, small spreads etc. Avoid countries with odd rules about stock ownership.
I think you've got the gist of my suggestions, and the implications.
As for community meetings, yes, i've attended a fair few. As for people being idiots, I think you'll find it's a bit more complex than that. The majority of people aren't used to speaking in public, many are uneducated, and a number will have very weird ideas. Collectively though, there will be a consensus which is likely to be conservative, and distrustful of change, and from experience will at the same time be sensible and pragmatic. You have to discard the outliers and seek the consensus which can be difficult, but you'll find it rather rewarding if you try.
There are heaps of scenarios which would lead to a different conclusion if, for example, the company was dishonest. Apparently, companies sometimes don't tell the truth. It would be quite possible for the company to not have built what it applied for, or for some important facts about the plan to have been omitted, or intentionally mis-represented.
Another possibility is that the planners are corrupt, or simply incompetent and the application should have been rejected.
As has been suggested, it's possible that the residents messed up, but i've a feeling this is unlikely.
I imagine an appeal will get to the bottom of this, and some sort of compromise would be the most likely outcome.
Well, when targeting a machine with large numbers of cores, memory and power, sure - it's a better tradeoff to avoid too much optimisation, and go for maintainability over raw performance. I know that, I do this all the time. As for writing assembler, my assembler days are long gone. The last I did was a bit of 56k maybe 10 years ago for an audio pipeline. The closest I get these days is looking at the output of the compiler;-)
However, when the user base is continuously worried about battery drain, how do you design a sensible tradeoff between memory use vs CPU time (storing vs re-calculating a given value), or knowing how to arrange data in cache lines to pull data efficiently through the memory bus to reduce runtime (and hence prolong battery life).
These devices are power constrained, and will be no matter what anyone says. Knowing the architecture, and the future direction of the architecture would allow devs to produce solutions that will scale, and be power efficient. Maybe you'll only get 10% power saving, but for a device which is being heavily used, this could translate into an hour or two of extra use which is going to be a big selling point for expensive handheld devices.
I'm struggling to understand how apple get away with not announcing any info about the codes, the cache size, memory bandwidth etc. Surely on a mobile device with limited power, optimisation of applications is a priority. How do people manage this without any idea of the physical architecture of the machine they are developing for?
Maybe i'm just old school, but knowing what hardware you are targeting is almost the first bit of info which informs an efficient use of the resources available.
I'm not sure where you heard this, or which market you think this works in, but that sounds dubious at the very least. The realisation that a trade isn't for a good price in an order driven market isn't obvious until further trading moves the price away from touch against the position you have just taken. You can't place one order off touch, the market doesn't work like that.
If, say, this happened on a major market (say NASDAQ) there would be a serious number of broken trade messages, or alternatively, some mechanism to re-instate an order which has been executed at the right place in the book (and there isn't). I can tell you there aren't a serious number of broken trade messages.
float->int conversion used to be expensive on x86 processors due to default rounding modes from C, and lack of suitable built in rounding functions. Looking back, my code contained this handy function. Ugly hack or elegant performance improvement? I'd suggest that the difference comes down to comments, unit tests, and whether people die if it's got bugs;-)
#ifdef WIN32
#ifdef ASSUME_ROUNDING// This method relies on knowing the rounding mode of the float processor//// It relies on it being set to round to nearest and offsets the value to// calculate a truncation
inline int convert(float f)
{
int i;
static const float half = 0.5f;
_asm
{
fld f// f = f
fsub half// f = f - 0.5
fistp i// i = round(f)
}
return i;
}
#else// Shift the bits in the double around so that the bits can be read directly as an int
inline int convert(double d)
{
const double D2I = 1.5*(double)(126)*(double)(126);
double temp = d - 0.499999999 + D2I;
return *((int*) (&temp));
}
#endif #else// On Mac we just use the standard C conversion since it doesn't suffer the performance hit// as on PC
#define convert(x) int(x) #endif
Indeed, sounds like a very one sided description of what went wrong. On the one hand, they say they are experts in doing something that other people couldn't, but then say it's apple's fault that their technology didn't work. Hmm, something wrong with this explanation.
Haha. That's why there is Objective C++, and C is commonly shoved through a C++ compiler. It's amazing how similar distinctly different languages can be;-) For distinctly different, I was thinking Prolog and Perl, or F# and bash. Anyhow, enough chat, code to write...
My understanding is that there is no room for decode artifacts in this - you either do it right, or it's not a proper decoder. This is a proper decoder, so will produce identical output to the google standard one. I believe there are test streams with md5s for the test frames, and this decoder passes the tests.
So, it's free, and it's correct, and it's fast. I think you have pre-conceived prejudices which are in this case wrong;-)
From my perspective, faster is good for low power devices, so if this helps spread decent video codecs to more devices, that's a win.
Maybe he doesn't like concurrent code because he's been bitten by nasty bugs enough times to shy away from it. Maybe he doesn't like your source control system as he has lost heaps of work in the past trusting it to a dodgy system. Maybe he has found code reviews a waste of time, or had bad experiences with pitched battles in a meeting room. Why don't you try asking him rather than speculating? 'Hey bob, it looks to me like you aren't keen on code reviews - why is that?' would be a good start.
Alternatively, he's a bit of a jerk, or bad at his job, and i'll leave that to you to figure out for yourself.
Actually I am a parent, and my son hasn't had a McDonald's, or a Pizza Hut, or a KFC. How come? A combination of luck (he prefers japanese) and the fact that I haven't eaten at these places either. I did go in a McDonald's once though.
Thanks for taking the time to try and spread some info about what has happened. It's amazing how unreasonable posters are being about this - you've already said the system failed, you have corrected the mistake and are trying to stop it happening again. Obviously people here have never produced software or a process with an error in it right ?;-)
Not my experience. I'm continually impressed with how fast java and C# are, and how well systems written in these languages perform in realtime apps. Sure, you get outliers, but then you get outliers from the OS, core swaps, networking stacks, etc etc, it's just one more area you have to watch and carefully consider, that's all. I'm not suggesting that code which hasn't been thought about performs well in this environment, but that it's possible to produce perfectly functional realtime systems with these languages.
The clever but somewhat unorthodox hacker employed by the Iranians pulls out his Apple Laptop and types furiously at a constant rate into a window with unrelated scrolling green text. A modal dialog box appears with a progress bar slowly ramping up to 100% and the text 'Sending virus to enemy drone'. He sits back looking smug with his hands behind his head. Once 100% is achieved, he again types furiously whilst explaining to the general standing behind him that he is going to send a surprise to the american scum operators. The drone sends out some sort of pulse of energy back up the channels being used to control it, and the equipment the american scum operators are using explodes in a shower of sparks and electrical discharges, frying the operators. The hacker than pushes a single button and the drone lands on a convenient long empty road. Everyone cheers. The hacker gets the girl.
I seem to remember Primo Levi wrote on this subject - not sure which of his books i've read, but something about a paint factory process springs to mind. Companies do loose information - it's entropy at work. It costs to keep information intact, and unfortunately there is much information and little indication of what may be important in the future.
Because CMOS sensors can't reset quickly. Why do you think any DSLR has a shutter? If they could do without they would have removed them. Although the name suggests the technology is digital, in actual fact digital sensors use good old analog techniques to capture charge based on light falling on the sensor. This is the bit which can't be reset (drained away) quickly enough when light is still falling on the sensor. The shutter really gives a black time when you can dump charge and reset things before allowing light to build up further charge.
I believe CCD sensors can be more quickly flushed of charge, but it's still not quick enough to do without a shutter. The benefits to a DSLR of not having a shutter would be to be able to sync flash at any shutter speed. This is one area where leaf shutters are good compared to focal plane shutters (as appear on DSLRs). Hasselblad made leaf and focal plane shutter cameras, and the abilty to use the leaf lenses on the focal plane shutter cameras to give more flexibilty on flash sync.
Lenses which cover 8*8 are basically large format lenses which include leaf shutters. Leaf shutters have a couple of problems - limited size, and a limited upper speed. Typically 1/500th is the fastest a leaf shutter will operate, and the limited diameter means you typically are down to f5.6 or f8 as a maximum aperture.
The maximum aperture will limit the speed advantage against a 35mm DSLR or medium format where f/2 and faster is common (f/1 can be achived at standard lengths if you compromise on image quality, say a noctilux). f/1 vs f/5.6 is 5 stops, or 32 times the amount of light. So an f/1 lens vs an f/5.6 will accept 32 times as much light to start with
The usual complaint about fast lenses is the limited depth of field. However, large format at f/5.6 will also suffer this problem as the larger image format will also offer a limited DOF, but in addition, a slow lens. I guess the answer will be to run the sensor at a higher ISO equivalent, make it more sensitive, and hence allow a smaller aperture to be used, but the tradeoff isn't obvious from the specifications
My guess is that this is a technology demonstrator, and will not be available to average punters on real cameras. Saying that an old large format camera with a 8*8 back would be very cool
I use a canon DSLRs, and 1/8000th is the limit. In strong light it can be a limit with a fast prime (a 1.2 or 1.4 prime for example). The best solution is to then use an ND filter.
If you want faster than that, you are best off using artificial light. Flash will stop just about any action, and it is easy enough to setup triggers for the flash to capture events from motion, sound, or electronically delayed triggering from an event. Of course the joy of digital with shots like this is the ability to quickly tell whether you have got or missed the shot, and due to the random nature of say, a drop of water hitting a bowl of water, you can repeat until you are happy with the result.
Slashdot Mirror
You know, if you asked me which bits of my code where the hardest to write, and likely to contain bugs, I can tell you. In fact, I usually comment on code reviews in this way to help direct a reviewer to the bits I think need attention. Being self-critical is a very useful skill, accepting your limitations, asking others to help.
1/4 inch is as sturdy as hell, but 3.5mm isn't bad.
I had a Fujitsu Eagle from the 80s which used multiple heads per side. The drive was used on a PDP-11, was 19 inch rack mount, and had a perspex cover, so you could watch the heads seeking when the drive was in use.
Actually, i'd suggest you find the market with the largest amount of liquidity, rather than worrying about where it comes from. NYSE, NASDAQ, LSE, OMX, there's plenty to choose from with sensible pricing, small spreads etc. Avoid countries with odd rules about stock ownership.
I think you've got the gist of my suggestions, and the implications.
As for community meetings, yes, i've attended a fair few. As for people being idiots, I think you'll find it's a bit more complex than that. The majority of people aren't used to speaking in public, many are uneducated, and a number will have very weird ideas. Collectively though, there will be a consensus which is likely to be conservative, and distrustful of change, and from experience will at the same time be sensible and pragmatic. You have to discard the outliers and seek the consensus which can be difficult, but you'll find it rather rewarding if you try.
There are heaps of scenarios which would lead to a different conclusion if, for example, the company was dishonest. Apparently, companies sometimes don't tell the truth. It would be quite possible for the company to not have built what it applied for, or for some important facts about the plan to have been omitted, or intentionally mis-represented.
Another possibility is that the planners are corrupt, or simply incompetent and the application should have been rejected.
As has been suggested, it's possible that the residents messed up, but i've a feeling this is unlikely.
I imagine an appeal will get to the bottom of this, and some sort of compromise would be the most likely outcome.
Well, when targeting a machine with large numbers of cores, memory and power, sure - it's a better tradeoff to avoid too much optimisation, and go for maintainability over raw performance. I know that, I do this all the time. As for writing assembler, my assembler days are long gone. The last I did was a bit of 56k maybe 10 years ago for an audio pipeline. The closest I get these days is looking at the output of the compiler ;-)
However, when the user base is continuously worried about battery drain, how do you design a sensible tradeoff between memory use vs CPU time (storing vs re-calculating a given value), or knowing how to arrange data in cache lines to pull data efficiently through the memory bus to reduce runtime (and hence prolong battery life).
These devices are power constrained, and will be no matter what anyone says. Knowing the architecture, and the future direction of the architecture would allow devs to produce solutions that will scale, and be power efficient. Maybe you'll only get 10% power saving, but for a device which is being heavily used, this could translate into an hour or two of extra use which is going to be a big selling point for expensive handheld devices.
I'm struggling to understand how apple get away with not announcing any info about the codes, the cache size, memory bandwidth etc. Surely on a mobile device with limited power, optimisation of applications is a priority. How do people manage this without any idea of the physical architecture of the machine they are developing for?
Maybe i'm just old school, but knowing what hardware you are targeting is almost the first bit of info which informs an efficient use of the resources available.
I'm not sure where you heard this, or which market you think this works in, but that sounds dubious at the very least. The realisation that a trade isn't for a good price in an order driven market isn't obvious until further trading moves the price away from touch against the position you have just taken. You can't place one order off touch, the market doesn't work like that.
If, say, this happened on a major market (say NASDAQ) there would be a serious number of broken trade messages, or alternatively, some mechanism to re-instate an order which has been executed at the right place in the book (and there isn't). I can tell you there aren't a serious number of broken trade messages.
Have a look at the ITCH spec - http://www.nasdaqtrader.com/co...
You can probably download a historical day of NASDAQ data, their main store is restricted to data licencees.
float->int conversion used to be expensive on x86 processors due to default rounding modes from C, and lack of suitable built in rounding functions. Looking back, my code contained this handy function. Ugly hack or elegant performance improvement? I'd suggest that the difference comes down to comments, unit tests, and whether people die if it's got bugs ;-)
#ifdef WIN32 // This method relies on knowing the rounding mode of the float processor // // It relies on it being set to round to nearest and offsets the value to // calculate a truncation // f = f // f = f - 0.5 // i = round(f) // Shift the bits in the double around so that the bits can be read directly as an int
#ifdef ASSUME_ROUNDING
inline int convert(float f)
{
int i;
static const float half = 0.5f;
_asm
{
fld f
fsub half
fistp i
}
return i;
}
#else
inline int convert(double d)
{
const double D2I = 1.5*(double)(126)*(double)(126);
double temp = d - 0.499999999 + D2I;
return *((int*) (&temp)); // On Mac we just use the standard C conversion since it doesn't suffer the performance hit // as on PC
}
#endif
#else
#define convert(x) int(x)
#endif
Well, everyone who's ever called gethostbyname() has an overflow bug in their code, so my guess is he doesn't know what he's talking about.
Indeed, sounds like a very one sided description of what went wrong. On the one hand, they say they are experts in doing something that other people couldn't, but then say it's apple's fault that their technology didn't work. Hmm, something wrong with this explanation.
Haha. That's why there is Objective C++, and C is commonly shoved through a C++ compiler. It's amazing how similar distinctly different languages can be ;-) For distinctly different, I was thinking Prolog and Perl, or F# and bash. Anyhow, enough chat, code to write...
I always like the way that C, C++ and objective C are split out to give the others a chance.
My understanding is that there is no room for decode artifacts in this - you either do it right, or it's not a proper decoder. This is a proper decoder, so will produce identical output to the google standard one. I believe there are test streams with md5s for the test frames, and this decoder passes the tests.
So, it's free, and it's correct, and it's fast. I think you have pre-conceived prejudices which are in this case wrong ;-)
From my perspective, faster is good for low power devices, so if this helps spread decent video codecs to more devices, that's a win.
Alternatively, he's a bit of a jerk, or bad at his job, and i'll leave that to you to figure out for yourself.
Actually I am a parent, and my son hasn't had a McDonald's, or a Pizza Hut, or a KFC. How come? A combination of luck (he prefers japanese) and the fact that I haven't eaten at these places either. I did go in a McDonald's once though.
Isn't that the wrong way around? Aren't you supposed to not eat in McDs because you have kids, like not smoking because you have kids?
Thanks for taking the time to try and spread some info about what has happened. It's amazing how unreasonable posters are being about this - you've already said the system failed, you have corrected the mistake and are trying to stop it happening again. Obviously people here have never produced software or a process with an error in it right ? ;-)
Not my experience. I'm continually impressed with how fast java and C# are, and how well systems written in these languages perform in realtime apps. Sure, you get outliers, but then you get outliers from the OS, core swaps, networking stacks, etc etc, it's just one more area you have to watch and carefully consider, that's all. I'm not suggesting that code which hasn't been thought about performs well in this environment, but that it's possible to produce perfectly functional realtime systems with these languages.
The clever but somewhat unorthodox hacker employed by the Iranians pulls out his Apple Laptop and types furiously at a constant rate into a window with unrelated scrolling green text. A modal dialog box appears with a progress bar slowly ramping up to 100% and the text 'Sending virus to enemy drone'. He sits back looking smug with his hands behind his head. Once 100% is achieved, he again types furiously whilst explaining to the general standing behind him that he is going to send a surprise to the american scum operators. The drone sends out some sort of pulse of energy back up the channels being used to control it, and the equipment the american scum operators are using explodes in a shower of sparks and electrical discharges, frying the operators. The hacker than pushes a single button and the drone lands on a convenient long empty road. Everyone cheers. The hacker gets the girl.
I seem to remember Primo Levi wrote on this subject - not sure which of his books i've read, but something about a paint factory process springs to mind. Companies do loose information - it's entropy at work. It costs to keep information intact, and unfortunately there is much information and little indication of what may be important in the future.
Because CMOS sensors can't reset quickly. Why do you think any DSLR has a shutter? If they could do without they would have removed them. Although the name suggests the technology is digital, in actual fact digital sensors use good old analog techniques to capture charge based on light falling on the sensor. This is the bit which can't be reset (drained away) quickly enough when light is still falling on the sensor. The shutter really gives a black time when you can dump charge and reset things before allowing light to build up further charge.
I believe CCD sensors can be more quickly flushed of charge, but it's still not quick enough to do without a shutter. The benefits to a DSLR of not having a shutter would be to be able to sync flash at any shutter speed. This is one area where leaf shutters are good compared to focal plane shutters (as appear on DSLRs). Hasselblad made leaf and focal plane shutter cameras, and the abilty to use the leaf lenses on the focal plane shutter cameras to give more flexibilty on flash sync.
Lenses which cover 8*8 are basically large format lenses which include leaf shutters. Leaf shutters have a couple of problems - limited size, and a limited upper speed. Typically 1/500th is the fastest a leaf shutter will operate, and the limited diameter means you typically are down to f5.6 or f8 as a maximum aperture.
The maximum aperture will limit the speed advantage against a 35mm DSLR or medium format where f/2 and faster is common (f/1 can be achived at standard lengths if you compromise on image quality, say a noctilux). f/1 vs f/5.6 is 5 stops, or 32 times the amount of light. So an f/1 lens vs an f/5.6 will accept 32 times as much light to start with
The usual complaint about fast lenses is the limited depth of field. However, large format at f/5.6 will also suffer this problem as the larger image format will also offer a limited DOF, but in addition, a slow lens. I guess the answer will be to run the sensor at a higher ISO equivalent, make it more sensitive, and hence allow a smaller aperture to be used, but the tradeoff isn't obvious from the specifications
My guess is that this is a technology demonstrator, and will not be available to average punters on real cameras. Saying that an old large format camera with a 8*8 back would be very cool
I use a canon DSLRs, and 1/8000th is the limit. In strong light it can be a limit with a fast prime (a 1.2 or 1.4 prime for example). The best solution is to then use an ND filter.
If you want faster than that, you are best off using artificial light. Flash will stop just about any action, and it is easy enough to setup triggers for the flash to capture events from motion, sound, or electronically delayed triggering from an event. Of course the joy of digital with shots like this is the ability to quickly tell whether you have got or missed the shot, and due to the random nature of say, a drop of water hitting a bowl of water, you can repeat until you are happy with the result.