I think you're reading the "SAMPLE LEGAL APPRAISAL" which is an appraisal for a different item. I think it's just to give you an idea of the form of appraisal they'd provide for insurance purposes.
Impressive paint & decal restoration. I've spent a little time trying to restore some of these finished before and given up. This gives me hope. Maybe I'll try again.
Not as of 2 months ago. It took days of crashing or hanging programs to get the photos off my wife's iPhone. I tried everything mentioned including Image Capture on a new MacBook, and the problems were at least as bad for me. I had to change the sleep settings on every device involved to multiple hours because a 30 minute hang was on the good side. In the end, what ended up working best was a full backup of the phone to a PC with iTunes, and extracting the photos out of the backup with iMazing.
For perspective.. I remember downloading and installing Linux off floppies. That sucked too, especially with bad disks or download errors, but it was less frustrating than this.
It seems like they don't improve it because iCloud seems like it works smoothly, and they get an on-going profit stream out of it. The process was so brutal I almost broke down and paid for a ton of iCloud storage.. but didn't because getting lots of photos out of iCloud is also painful.
Were you not about to use the import function in Mac OS Photos app? If you connect a phone via cable, it should present a list of photos and let you import them to the Photos local library.
- 50mb is >> total cache on most systems you'll use.
- This is far from the only function you need to optimize.
--> The best performing algorithm in a micro-benchmark can be sub-optimal in real use.
- You've got a fixed-for-the-day list of <10k <9 letter unique upper-case strings
- The bulk of them you'll process are <= 4 letters (CMCSA/CMCSK be damned).
- The median is 3 and the mean is <3.6.
- The symbols aren't anywhere close to uniformly active
--> Benchmark with a typical data stream, not a uniformly distributed one.
- You're likely not even considering trading most of them.
- How much better is your algorithm than the obvious binary-search?
- Or worse -- plain'ol front-to-back linear search?
- Are you sure you understand 100% of how the computer works?
--> Yes? Mail a check to Goldman and find a better line of work.
--> No? Test it with a quick benchmark.
- Is binary search cache friendly?
- Why not? Plot out the memory accesses if need be.
- What's wrong with taking a linear-interpolated guess?
- Is that cache friendly? .. or could it be?
- When your guess misses, what's that cost?
- Can you think of a cheap modification to lower that cost?
- Is the distribution really linear?
- What's wrong with a "perfect hash function"?
- Does it need to be perfect?
Incidentally, hardware wins at this function. You can just generate logic to do all the if symbol == "XYZ": return 3's in parallel.
Unfortunately it's not that simple anymore. You actually have to do most of the order-book-building legwork to figure out if the quote is relevant: every order modification message, such as canceling an order or execution, omits the ticker. Makes sense: after all, the add-quote actually tells you the ticker, so there's no need to repeat that info.
This is where it gets tricky. FPGA based systems don't really give an edge here, and tilera-based solutions are still nascent
This craziness is what happens when you try to implement a specialized algorithm on a general-purpose state-machine. What stupid thing is a "cache" anyway, but an optimization because we are not using real computers but hugely complex state-machines called CPUs. FPGAs are as close as a real computer as we can have today.
The parallels to high end network security are again interesting here; for instance, on the more interesting network processors, memory accesses were asynchronous, and instead of a "cache" you had a manually addressed "scratch" memory with latency comparable to registers.
... because "general purpose cache" wasn't helpful, but "exploitable locality" definitely was.
That's pretty close to how the first NVIDIA GPGPU (G80) worked. There was no cache, but only different kinds of memory, of which one was as fast as registers. Optimal access to RAM memory was possible with a limited set of access patterns, so "caching" had to be managed carefully manually.
In later GPUs they (mainly due to programmer laziness :-) ) switched to a more GPU-like automatically managed general purpose cache. The problem was that in most cases, being able to quickly write code that is reasonably fast was more important to developers than being able to squish out every cycle (though I believe it's still possible to disable the cache and manage it manually...)
The problem with automatic cache is the same as all "intelligent" CPU features, the CPU tries to predict what the program is doing, the programmer has to predict what the CPU will predict to optimize for that CPU. In the next generation of the CPU, the CPU vendor will try to optimize again for programs currently around. In the end, optimizing becomes much more complex.
There's certainly an advantage to keeping the logic "dumb" and simply having the software manage everything.
- The bulk of them you'll process are <= 4 letters (CMCSA/CMCSK be damned).
With 5 bits per letter, this means the bulk of stock tickers could be stored in 20 bits, so the data structure could just be one big 128 MB array, if the size of the structure was rounded up from 109 to 128 bytes.
I'm not sure that's a given ..., I've known quite a few people who didn't like their gigs and would 'work from home' a lot ... they eventually got canned for poor performance
You could skip all the CSS transformation stuff and just serve the browser the images in the orientation you want them. In this projection and buildings-of-cubes, there's only 2 perspectives for a wall and 1 for ground/roofs.
Panning would work fine since the objects in this projection don't change anything but position with panning. Spinning would only work in 90 degree increments, but that's fine for many, maybe most cases you'd be doing this. Most isometric-ish projection systems I recall seeing don't spin / change perspective. I'd imagine that's because it's disturbing to look at since things don't get smaller as they get farther away. For whatever reason the static version doesn't induce the same reaction.
Smartphones are replacing standalone cameras, but the analysis in the article is busted. Popular camera models are constantly being replaced with newer shinier models, so of course every model trends down a little while after release. It'd probably be a lot more enlightening to do the analysis grouping usage by family (e.g. Canon G11, G10, G9, etc) once and then doing an age analysis for each family.
Agreed. Although it would be significant to note that, under that rationale, the iPhones would be grouped together again, and would likely be top dogs.
He just taught me that I'm supposed to uses two spaces after a period when doing most of my writing.. in programs.. which are still usually viewed with fixed width fonts.
