К счастью, в данном случае налоговая проявила снисхождение и назначила штраф в минимально возможном объеме: 75% от суммы сделки. Единственный нюанс: в качестве продавцов выступали мама с дочерью (которая тоже владела частью жилплощади), так что штраф получили и та, и та. Итоговая сумма штрафа, соответственно, вышла в размере 150% от вырученных с продажи квартиры средств (то есть, 18 млн рублей).

Такая вот занимательная арифметика валютного регулирования: Маргарита с дочкой остались без квартиры и без денег – зато с долгом перед ФНС.

Тут или ФНС что-то напутало или журналюги. Скорее второе.
Если квартира стоила 12млн рублей, то сумма сделки у каждой из них меньше 12млн рублей, поэтому штраф в 9млн рублей должен был делиться на обоих.
Кроме того, фраза о том, что они «остались без квартиры» звучит несколько желтушно. Да, они остались без квартиры, но только потому, что они ее продали и получили за нее деньги. Этот чтож, теперь по каждой сделке купли-продажи писать что «продавец остался в результате без квартиры»?:)

Кто является валютным резидентом РФ (и, соответственно, вынужден соблюдать российское валютное законодательство)?

Многие путают понятия налогового и валютного резидента РФ. Перестать быть налоговым резидентом нетрудно – достаточно провести в России меньше 183 дней в течение календарного года. С валютным резидентством всё сложнее: валютными резидентами РФ считаются все счастливые обладатели российского гражданства или ВНЖ. Да, даже те, кто многие годы уже не живет в России!

Да не особо сложнее. Если живешь больше 183 дней вне россии, то несмотря на валютное резидентство — практически никаких требований нет, специальный режим действует. То есть никаких отчетов о счетах, о движении средств на них и так далее.
Есть определённые ограничений на сделки в россии и на сделки с резидентами РФ, но они как раз из-за того, что сделка идет в россии или с резидентом россии, а не потому что сам человек валютный резидент.

Также можно свободно перечислять валюту на свои зарубежные банковские счета с других собственных зарубежных и российских банковских счетов.

Не всегда!

Это уже геополитика, о ней лучше рассуждать сидя на терассе на даче июньским вечером с бокалом вина.
В свое время при распаде советского союза Россия точно так же начала трещать по швам, благо исторические предпосылки были, Сибирь и ДВ ближе к Китаю чем к Москве, а национальные республики сами себе на уме. И западный мир «спас» Россию от развала именно по такой же логике — лучше иметь дело с одним паханом с кнопкой, чем с десятком варлордов. По той же логике огромные запасы ЯО и иного вооружения с территории Украины передали РФ, во избежание. Украина тогда была намного более нестабильной чем РФ.
Теперь похоже планы поменялись, когда режим стал угрожать городу и миру без соблюдения правил приличия на фоне деградации систем управления. В приличном обществе не любят смутьянов, что напившись домогаются дам, машут ножами и угрожают пырнуть джентельменов, что за дам заступаются. И стали просчитывать, что может быть десятки варлордов это не так уж и плохо.

Да у РФ есть шансы превратиться в сырьевой придаток, но в средневековье она при всём желании не откатится.

Россия сейчас это уже сырьевой придаток, с ЯО. От второй экономической силы в мире до 3% мирового ВВП, преимущественно за счёт полезных ископаемых, это надо умудриться. Причем было 20 ​лет на исправление ошибок так нет, только хуже все сделали.
Что будет не скажет никто, но вариантом я вижу ползущую фрагментацию, которая станет очевидной и юридически закреплённой лишь к самому концу. Сильные мира сего будут гарантировать сохранность и утилизацию ЯО и других мощных видов вооружения, что ещё остались от СССР, например с востока до Урала включительно подключится наш безграничный друг, мы все его знаем и на него надеемся. Во всех остальных сферах новообразованным государственным единицам дадут полную свободу — как жить, чем бодяжить, куда идти воевать на соседей по несчастью ( но не сантиметром дальше), благо конвеционного оружия останется ещё куча. Таких крупных войн как сейчас уже не будет — людей не хватит, а вот по мелочи — пожалуйста, развлечение для всего остального мира в прайм тайм. Возможно в каких-нибудь будущих кусках распавшейся империи жизнь даже будет приличной и мирной, хотя и относительно бедной. Но это процесс не месяца-двух, а годов и даже десятков лет.
Что касается отъезда специалистов — когда распался советский союз то в западный мир хлынул поток учёных, инженеров и прочего образованного люда. Не все смогли устроиться на новом месте, но например американские математики стали массово выходит на пенсию, не выдерживая конкуренцию с приехавшими из СССР. Сейчас нет мощного потока, сейчас тоненькая струйка. Человеческий потенциал Россия и так иссяк, выжимать его бесполезно, там все иссохло как пустыня Негев к октябрю. Пока я работал год за границей я был единственным постдоком из России, и не потому что русские брезгуют. А просто уже некому ехать.
И развитые страны совсем не против приглашать людей из России и делать их своими, особенно когда эмоции улягутся и наступит новое равновесие. Было бы кого приглашать.

Теоретически (в том смысле, в котором может метеорит в голову прилететь, когда за хлебом идешь) — вполне возможно. Не исключено.

И как только Фейсбук начнет шантажировать российских пользователей — эта сугубо теоретическая угроза — станет реальной. И тогда доверие к фейсбуку упадет. Но пока что, люди почему-то считают, что ВК и мейлру для них опаснее, чем фейсбук.

Вообще, в принципе, я с вами согласен. Вот только это не проблема пользователей. Это проблема руководства страны, роскомнадзора, спецслужб. Они заинтересованы, чтобы вся наша переписка была у нас. Поэтому коли они хотят этого добиться, они должны изо всех сил стараться, чтобы людям нравилось общаться в ВК и пользоваться почтой mail.ru, и регать домены в зоне .ru и хоститься в России.

Сделал сервер в России — будь уверен, его не изымут. Написал сообщение или пост в ВК — будь уверен, никаких судебных дел против тебя не будет. Вот когда государство добьется такой уверенности — тогда оно получит результат, который вы желаете. Люди сами будут говорить — что-то этот Цукерберг какой-то мутный, го общаться в ВК, безопаснее будет. И претензий к Цукербергу и американской слежке во всем мире — очень много. Россия вполне имеет шансы стать страной информационной свободы и безопасности. Да только эти идеи, которые вы защищаете — никому во власти на самом деле не нужны. Они «продают» эту идею с экранов, но самим им она не важна совершенно.

Сделаю выжимку из парочки курсов, что проходил:
1) Deep Learning от Ынга
Я бы сказал, имеет краткую выжимку(с большего) ML от него же в первых 2 из 5 частей, к тому же рассчитана больше на технически подкованных ребят. (Там нет «можете не знать, что такое производная, и так поймёте»), 3 часть — всякие фичи-советы от Ынга насчёт обучения, 4 и 5 — некоторые попсовые технологии вплоть до 2016 года.

2) Machine Learning от Ынга (Hardcore edition)
На сайте engineering everywhere stanford есть курс по МЛу от Ынга в Стэнфорде. Со всеми их заданиями, тензорными вычислениями и всем-всем-всем. По сложности и полноте не сопоставимо.

3) Convex optimization от Stephan Boyd
На том же engineering everywhere, есть книга. Один из лучших курсов по оптимизации, который рекомендуют просто все, кому не лень, даже жуткие любители исконно русской литературы в математике.

Game theory, mining massive datasets — определённо стоит того, первое ближе к reinforcement learning, второе — к анализу данных непосредственно.

Наверное, закончу небольшой подборкой наиболее годных книг, а то выйдет целый пост, а не комментарий:

Computer Vision — Adrian Rosebrock (Хочет кто запиратить все 3 бандла — обращайтесь)

General — Yan Goodfellow (Классика, но она больше для тех, кто уже в теме и в математике хорош, не для новичков), как и Kevin Murphy (более подробно, всё ещё довольно хардкорно)
Существует книга на русском, я удивлён: «Погружение в мир нейронных сетей», 2018 год.

Reinforcement Learning — Richard Sutton, абсолютно всеми рекомендуется.

Да, тоже хотел написать пост, но всё ленился. Наверное даже напишу ещё, так как у вас нет ничего про применимость и использование.
Про DIGITS. Он очень неплох, но нельзя очень много вещей настраивать, а хотелось бы. По сути говоришь «распознай», он берёт какой-нить VGG16 и распознаёт. Но тюнинговать и настраивать не умеет. Тем не менее, мне кажеться что нужный и послезный инструмент.

По поводу простоты установки сразу скажу, что это немного не так:) Просто должен ставиться под 14 убунту, если у вас свежая система и не последняя видюха. В остальных ситуациях стоит приготовиться к сборке DIGITS+CAFFE. Это на пол дня.

Ваш комментарий звучит более оскорбительно, чем я отзывался об индусах.
Про женщин ничего оскорбительного не говорил. Про индийский код, я думаю, всем здесь известно, даже наверное им самим.

Я согласен, что в любой компании есть выше перечисленные проблемы, но моя мысль была в том, что их нужно решать, а не смириться и жить с ними, они же не хотят что-то менять, может потому что для них это норма.

Проблема мастер класса в том что, толку от того, что мы рассказывали нет. Вы думаете они научились пользоваться констреинтами? — Нет, они до сих пор не могут их правильно выставить, хотя эта тема обсуждалась не один раз. Когда человек спрашивает, то нам не составляет труда помочь, но когда это делается чисто для галочки, то это другая история.

Самые большие расходы это жилье, как я писал оно зависит от ваших требований от 500$ за пол комнаты до 2000$ за квартиру средних размеров (но верхней цене предела нет). Коммуналка зависит от квартиры, но все, включая интернет, вам обойдется до 300$ для маленькой квартиры. В случае если вы снимаете комнату, то коммуналка обычно включена.
Питание вам обойдется примерно 500$ в мес на двоих.
Проезд: здесь дешевле иметь машину, чем пользоваться городским транспортом, на который у вас уйдет от 50$ до 150$ в месяц на одного (в зависимости откуда и куда ездить, если очень большие расстояния, то даже больше). Бак бензина обходится в 30$, которого в среднем хватит на неделю. Но есть платные дороги, которые лучше объезжать.
Развлечения: тут предела нет, опять же зависит от ваших требований. В кино можно сходить и за 10$, и за 50$.

Всё остальное — это искажения термина и лишь ещё один интерфейс для Thread Pool.

Наверху же была ссылка на Youtube с CppCon 2015. Гор Нишанов рассказывает об истории корутин. Похоже это то, что он читал на С++ Russia 2016.
Вкратце:
есть реализация за счет подмена стека( Boost.Coroutines/Fibers/goroutine);
есть реализация за счет встраивания state machine в функцию. Для этой реализации предлагается поддержка её компилятором.
В приведенном вами примере используется таймер, а не поток.

В июле 2015 на C++ User Group Meeting был доклад Александра Фокина из Яндекс на тему текущего состояния "Resumable функции в C++".
Там он сообщает, что "честной" реализации coroutines в Visual Studio 2015 RC нет, а сделано на fibers.

С 14-й минуты видео со слов "Теперь плохие новости...".

К 2017 году MS может и запилят "честную" реализацию без Thread Pool и fibers. Хотя для реализации в GCC и Clang потребуется еще время и испытания могут вылететь из графика C++17.

Но нам же насрать на решение Ленинского районного суда г. Грозного, правда? Все же понимают, что подобные решения принимают откровенные идиоты, и спокойно получат доступ по мере необходимости.

Из этого происходит очень печальный вывод: авторитет судебной власти в РФ никакой. И с каждым идиотским решением становится всё меньше. Страна, в которой решения суда не вызывают уважения, является страной с нелегитимной судебной системой, то есть страной без суда. Именно уважение к решениям суда, а не наличие судебных приставов определяет границу между судом и произволом чиновника.

Впрочем… Кого это волнует? Давайте лучше устроим митинг протеста против действий Турции. Или напомним ЮАР про годы апартеида. В мире много нерешённых проблем, мы должны на них сконцентрироваться и не отвлекаться на будничную рутину вокруг.

А я думаю вот что.
Мне не нравятся исключения в существующем виде тем, что кроме вызова функции необходимо еще городить try-catch, причем если возвращаемое значение доступно из прототипа функции, то какие там функция выбросит исключения — тайна, для раскрытия которой нужно или читать документацию (если она есть и актуальна) или изучать код функции и всех функций, которые она вызывает. То есть — неявность.
С другой стороны, бесконечные if-else тоже не лучший вариант.
Откуда вывод — необходимо придумать что-то еще, совмещающее достоинства обоих методов и лишенное недостатков.

И вот какие мысли. Основной недостаток исключений — неявность. Поэтому сделаем их явными. Для начала, использование/неиспользование исключений в данном конкретном месте — это дело программиста. То есть если программист заключает функцию в try-catch с обработкой конкретного типа исключений — то этот тип исключений может генерироваться в данном коде. Иначе — не может, и должен генерироваться код возврата.
Хорошо бы в заголовке каждой функции обязать прописывать исключения, которые она в принципе может генерировать.
Принцип «ошибка это значение» тоже сохраняется. Для этого должен быть оператор, аналогичный return, но умеющий вместо возврата кода ошибки выбрасывать исключение, при его разрешенности в данном контексте вызова.
И наконец, переход от распространения исключения к возврату ошибки (хотя это самое сомнительное, но ладно — напишу): для этого, при отсутствии явных блоков try-catch, каждая функция является неявным блоком try-catch, превращающим любое исключение внутри себя в возврат кода ошибки по умолчанию для данной функции. Со всеми фичами исключений вроде раскрутки стека.

Выглядеть это должно так.
1. по умолчанию программист вызывает любую функцию, будучи уверенным, что она не выбросит исключений, а всегда вернет код возврата.
2. если программист хочет чтобы функция выбросила исключение и он готов его обработать, он просто разрешает раскрутку этого исключения для каждой функции, входящей в цепочку вызовов, до того места где исключение ловится; и второе — перед вызовом функции используется специальное ключевое слово (то же try), говорящее что мы готовы принять и исключение в том числе. Это наглядно, никаких неожиданностей — написано int x = try foo() значит мы не просто вызываем функцию, а «пытаемся вызвать, понимая что может и не получится». Городить catch при этом не нужно: если функция foo() вывалится с исключением, а у нас нет на нее catch — сработает catch по умолчанию, который конвертирует это в код возврата ошибки для данной функции. Исключение может распространяться дальше только в случае если мы разрешили это, указав в заголовке нашей функции что она может генерировать исключение такого типа.

Пока еще не во всем уверен до конца, но как-то так…

Так это же невероятно круто для меня, нище*ба!

Меня связка pip+virtualenv+wheel устраивает и работает довольно стабильно. Я один раз компилирую пакеты в wheel, а wheel остаются закешироваными в. Поэтому сосздание нового venvа с нуля занимает пару минут:

$ mkvirtualenv x
$ pip install wheel
$ pip install -r requirements.txt

В .bash_profile у меня что-то такое:

PIP_REQUIRE_VIRTUALENV=true
PIP_CACHE_DIR=/Users/x/.pip/cache
PIP_WHEEL_DIR=/Users/x/.pip/wheel
PIP_FIND_LINKS=/Users/x/.pip/wheel /Users/x/.pip/cache
PIP_USE_WHEEL=YES

И да, стоит у меня еще pipvirtualenvwrapper для удобства.

Раз в какое-то время запускаю в бэкграунде pip wheel -r requirements.txt && pip install -U -r requirements.txt и получаю новые версии пакетов.

Про «принято в руби мире» давайте не будем, вы были в каком-то плохом его варианте ;) Давайте по теме.

Возможно ли, что virtualenv в принципе странная вещь? Что это такое — это такая папка, куда питон пакеты по старинке валят всё что им угодно. Как-то откатывать версии пакетов или гарантировано удалить из этой среды какой-то пакет невозможно. Гарантировать что эта папка не сломается просто в один прекрасные день — тоже.

У меня бывали ситуации, неоднократно, когда virtualenv приходилось сносить и ставить всё заново. Это боль, это долго и неприятно.

pip+virtualenv никак мне не трекают что за версии пакетов они там наставили — pip freeze выдает какую-то фигню. Каждый пакет прописывать руками в requirements.txt с ``==`` мне лично странно.

В общем тут с моей точки зрения просто — припомните на самом ли деле всё так у вас безоблачно с virtualenv? Действительно pip дотягивает до bundler? Максимум до gem. И так ли уж ужасен был опыт с bundler?

Откуда вы взяли это определение?

Из двух классических книг: «Типы в языках программирования» и «Design and concepts in programming languages» и из работы «Semantic Domains» Дана Скотта. Собственно, в Wikipedia написано то же самое: evaluation of mathematical functions… Каков математический смысл этого процесса оценки? Как раз цепочка beta-редукций выражения до его нормальной формы. При этом, чтобы получать нормальную форму, необходимо придерживаться определённого порядка вычислений. Если применять их произвольно и «параллельно», то в общем случае можно никогда не получить эту самую нормальную форму, то есть результат вычисления.

При этом, изменение состояний и изменяемые данные запросто можно описать кучей функциональных конструкций и вполне программировать с их применением не выходя за рамки парадигмы.

Ну. Собственно, прядок вычисления и определяется ассоциативностью.

Конечно задавая зависимости мы в какой-то мере задаем порядок вычисления. Но не полностью (например, теоретически можно вычислить при foldl f z [f1,f2] мы можем вычислить z, f1 и f2 в любом порядке и частично вычислить f по мере готовности аргументов).

Это не соответствует действительности, к сожалению. Мы могли бы так поступать, если бы имело дело именно с функциями. Но как ни крути, даже в функциональных языках, мы имеем дело с вычислениями, которые задаются порядком beta-редукций. И чтобы получать результат нам необходимо фиксировать порядок beta-редукций. Мы не можем использовать вообще произвольный, иначе, можно никогда не добраться до нормальной формы выражений, даже в простейших рекурсивных формулах.

Порядок надо фиксировать. И, поэтому, никакой параллельности именно из lambda-выражений выжать не получается. Нужны дополнительные внешние абстракции… Ну, типа параллелящего компилятора.

НужныйМнеЧайник = ПоставленныйНаПлиту(СНалитойВодой(ПустойЧайник)) мы задаем порядок в котором мы наливаем чайник и ставим на огонь, но можем это и не делать, если нам это не важно.И поддействия внутри каждого из этих действий могут выполняться независимо друг от друга.

Да. Но функциональное программирование так не работает. То, что Вы описали, называется (традиционно, хотя оно и вышло уже за эти свои рамки) логическое программирование. Например, есть интересный проект Oz, в котором именно так всё и происходит. Но там совсем другая модель вычислений, основанная на унификации термов.

Как вы, наверное, знаете, обычные функции в Haskell — это аналог функций в математике. Они зависят исключительно от своих аргументов, и сколько бы раз вы их ни вызывали с одними и теми же результатами, столько же раз вы будете получать один и тот же результат. Это позволяет нам получать распараллеливание вычислений «из коробки», так как нам неважно, в каком порядке будут выполняться вычисления.

IMHO, это некоторое заблуждение. Для классических математических отображений, действительно не важно, в каком порядке будут выполняться вычисления. Но lambda-выражения не задают классические математические отображения. Потому что множества таких отображений не могут быть решением уравнения (я об этом говорил раньше) T: T → T.

И для этих lambda-выражений, на самом деле, порядок вычисления (то есть, порядок beta-редукций) очень даже имеет значение. Порядок вычисления просто задаётся всегда явно, через структуру lambda-абстракций. Иначе, никакой бы разницы между foldr и foldl не было бы. Автоматического и бесплатного параллелизма тоже в функциональном программировании нет, ну, если не прибегать к старым, добрым низкоуровневым ухищрениям типа компиляции map в LLVM с последующей векторизацией. Сама же классическая структура вычисления map весьма далека от «параллельной».

Но что, если нам нужно выйти за пределы «чистых» функций? Например, нам нужен определенный порядок вычислений (то есть одна функция должна знать, вычислена ли другая функция или нет). Или мы взаимодействуем с внешним миром, и в качестве результата выполнения нашей функции мы можем получить не одно, а много разных значений (недетерминированные вычисления). Или нам нужно «тащить» за собой, помимо результата функции, некое состояние. Для всех этих случаев, когда у значения результата наших функций есть некий «контекст», как мы это называем, Haskell предлагает нам использовать определенный шаблон — монады. При помощи этого шаблона мы можем унифицированно работать со всеми случаями, когда у нас имеется значение плюс какой-то контекст (мы обычно называем это значением, «обернутым» в контекст).

Ну, то есть, проблема создана искусственно? Ведь, на самом деле, существуют и другие строгие высокоуровневые абстракции для алгоритмов. Допустим, есть та же CSP Чарльза Хоара, в которой вычисления — это процессы, что гораздо, гораздо, несравненно, несравненно ближе к происходящему при исполнении программ в компьютерах. Или есть, допустим, теория абстрактных машин состояний Гуревича, которая без всяческих проблем позволяет определять системы с вводом/выводом. Почему обязательно нужно так напирать именно на lambda-исчисление, как на некую uber-абстракцию, если для реального программирования требуется вводить дополнительные обёртки и прочее, прочее? Я просто до сих пор не вижу profit-а.

Повторюсь: вот пишу я текстовый редактор, где мне могут пригодиться классы объектов?

Я же не ставлю под сомнение полезность классов типов. Для меня эта польза очевидна. И я могу её интерпретировать не только в контексте классического ООП, но и, допустим, в рамках теории CSP или ASM. Да и вообще классы типов, или просто классы — это универсальная концепция. Это способ представления системы типов с определёнными формальными свойствами.

Так же я могу рассуждать о монадах: монады — это такой pattern, который позволяет легче описывать (исключительно за счёт синтаксического сахара, потому что описания тех же цепочек операций через >>= и return — ещё тот адский ад) вычисления, в которых необходим threading какого-нибудь состояния. Но даже для монад совершенно не ясно, какой profit можно получить от рассуждения о них в терминах теории категорий. Это всё вполне себе укладывается в теорию типов и в классы типов.

А вот уже о функторах как-то рассуждать не получается. Ну, то есть, вот абстрактно — это действительно так и есть, некая штука, которая позволяет отображать морфизмы из одной категории в другую… Но это чрезмерно абстрактное описание. Хочется конкретного примера с рассуждением в терминах функторов, отличных от fmap. Примеров мне не хватает для осознания. Как я уже говорил, я читал книгу Real World Haskell, и там что-то никаких рассуждений в терминах именно теории категорий нет. Разве только сказано, что термин «монада» взят из этой теории.

Надеюсь, стало понятнее ;)).

К сожалению, пока слишком абстрактно.