1,894 karma · joined March 8, 2010
There’s a (very) short story about a device exactly like this: https://www.nature.com/articles/436150a
However, it's hard to separate image patterns from camera structure insofar as linear projection is a result of camera structure.
http://www.increpare.com/2009/11/platonic-archetypes-of-dice...
http://journal.neilgaiman.com/2009/05/entitlement-issues.htm...
Of course, encryption per se is overkill for that. Something like ROT13 would do the trick.
:w !sudo tee %In the present era, the act of typing is separate from the act of typesetting. The comment I'm typing now may be typeset in Arial in Chrome, typeset in Ubuntu Mono in Emacs, or read aloud by a software program to a blind person. No prescribed number of space characters is going to be appropriate for all cases.
The reading software, not I, should be responsible for locating my sentence breaks and setting appropriate spacing there. Perhaps in the future we'll assist the software by marking up sentence breaks using a special character sequence. Ironically, a double-space would serve that function pretty well.
We found that the Purchasability Type for one or more of your In-App Purchase products was inappropriately set, which is not in compliance with the App Store Review Guidelines.
Your In-App Purchase is currently an Auto-Renewable Subscription. However, it would be more appropriate to use the Non-Renewing Subscription In-App Purchase type. Auto-Renewable Subscriptions are intended for periodical apps, such as magazines and newspapers. Non-Renewing Subscriptions should be used for products that are not appropriate for Auto-Renewable Subscriptions.
Nothing in Apple's documentation hints that Auto-Renewable Subscriptions are more appropriate for one class of app than for another, so I was hoping that my reviewer was acting on some subjective, high-level guideline that I could argue on. However, it's beginning to look as if there is a specific, unwritten policy against non-periodical apps.
add 2 0.390000 0.000000 0.390000 ( 0.390529)
+= 2 0.540000 0.000000 0.540000 ( 0.537450)
add 3 0.530000 0.000000 0.530000 ( 0.534131)
+= 3 0.760000 0.000000 0.760000 ( 0.752280)
add 4 0.660000 0.000000 0.660000 ( 0.668154)
+= 4 0.960000 0.000000 0.960000 ( 0.954727)
Code: https://gist.github.com/1562994I haven't used Erlang, so the two patterns seem roughly equivalent. I've even heard exception handling referred to as "happy path programming" by way of contrast to return value handling.
That actually sounds like a very uncommon case. Even fully client-side software has variable costs in the form of support costs.
Support costs aren't relevant to your parent's example, but they do imply another misalignment of incentives. If a salesperson's commission is based on revenue alone, she'll just as soon sell to a costly, high-maintenance customer as to a profitable, low-maintenance one.
$ ruby -v
ruby 1.8.7 (2010-01-10 patchlevel 249) [universal-darwin11.0]
$ ruby benchmark.rb
user system total real
add 2 0.390000 0.000000 0.390000 ( 0.385910)
join 2 0.300000 0.000000 0.300000 ( 0.305812)
add 3 0.530000 0.000000 0.530000 ( 0.527388)
join 3 0.320000 0.010000 0.330000 ( 0.329390)
add 4 0.720000 0.000000 0.720000 ( 0.720500)
join 4 0.350000 0.000000 0.350000 ( 0.353237)
Code: https://gist.github.com/1562617 """