Вы всё-таки почитайте книжку самого Шноля. Тут вверху статьи на неё ссылка. Я только начал читать и из прочитанного понял, что эффекты совсем не тонкие. Просто ими всегда, начиная от Ньютона и Галилея, пренебрегают. В измерениях учитывается только матожидание и дисперсия. Всё. Тонкие детали функции распределения результатов измерений всегда опускаются. Шноль же обращает внимание именно на них. Насколько я знаю, он первый. До него это просто никому не было интересно. Кстати Шноль вполне серьёзный ученый. Вот гляньте новый (относительно конечно) ролик Хазина www.youtube.com/watch?v=9aUDN9Tu59s. Он там и Шноля мельком упоминает. Оказывается дядька в своё время едва не получил Нобелевку.
Кстати да. Вспоминаю, читал об этом в конце 90-х начале 2000-х. Думаю будь на дворе другая эпоха, не столь пошло завязанная на бизнес и выгоду, эти опыты продолжались бы и сейчас. Увы, люди сейчас бросают то что не сулит какого-то немедленного профита. Но заниматься тем не менее этим кто-то должен. Иначе встанем на четвереньки и обрастём шерстью.
Зачем ??? Меня интересует поймать во-первых эффект ближней зоны во-вторых суточную корреляцию, в третьих корреляцию на параллельных датчиках. Если я это увижу, можно будет думать о чём-то более серьёзном. А это увидеть можно и на достаточно простом оборудовании.
Абсолютно согласен. Поэтому самое безопасное это сидеть на попе ровно и рассуждать о том что аффтар идиот, дебил и вообще нехороший человек редиска. Тут уж точно и ошибок не наловишь и даже о схемах экспериментов думать не придется. А описанные эффекты никто никогда и не искал. От них просто теми или иными способами избавлялись, как от шумов. Очень рекомендую, скачайте книгу Шноля и почитайте. Я только начал и пишет он об этом вобщем-то с самого начала.
Уважаемый blue_limon, скажите, а Вы сами не пробовали ставить эксперименты и получать данные? Если будете возиться с химией, соседи подумают что варите наркоту. Если напишете объявление что мол куплю для экспериментов немного плутония, заинтересуются люди в черном. А вот такие вещи как Время ожидания разряда в RC генераторе на неоновой лампе
и Шумы в диодах Зенера и других полупроводниковых генераторах шума
выглядят вполне приемлемыми для домашней лаборатории. Особенно первое, поскольку там во-первых сигнал чисто временной (длительность импульсов генератора), во-вторых довольно высокая частота (сотни и тысячи герц), что позволяет рисовать гистограмму каждую секунду, а возможно даже чаще, в третьих в отличии от шумов в полупроводниках, довольно понятная (во всяком случае на пальцах) физика, в четвертых очень дешевые компоненты (неоновые лампы стоят в чипе и дипе от 7 до 40 рублей). В течении 50 лет измерять конечно довольно напряженно, да и в течении года пожалуй тоже. Но в течении недели, почему бы и нет? Суточный ритм оно покажет. К тому же как я понял, если сделать несколько датчиков, гистограммы каждого из них измеренные в одно и то же время должны быть похожи. Не хотите заняться этим? Я например хочу. Сейчас только текущие дела немного раскидаю и попытаюсь это сделать. Кстати может получиться шикарная публикация на хабре.
Тарелочки во-первых на куда меньшей высоте и дистанции, во-вторых летят очень предсказуемо. Тот же дрон, заставь его хоть немного случайно маневрировать, сбить будет совершенно нереально. Мне мужик рассказывал, который участвовал в грузинской войне 2008-го. У них над головами висел дрон. Стреляли в него из всего что только было. От автоматов до ПЗРК и пушек БМП. И нихрена не могли с ним поделать. Слава богу что грузины оказались настолько паршивыми вояками, что не сумели воспользоваться своим же дроном. Иначе кончилось бы это весьма печально. Так что дроны это очень серьёзно. Даже такие игрушечные. Кстати в этом видео не учитывается, что реальный дрон, даже не очень большой в ответ мог бы тоже стрелять. Интересно как тогда бы кампашка развлекалась?
Ну что сказать… С одной стороны «безумству храбрых», а потому респект и уважуха безоговорочно. С другой… С другой стороны ребят, признайтесь честно. Используется ли колибри сейчас хоть где нибудь на практике? Я вот что-то не слыхал, хотя проектом в своё время интересовался. Нет, я понимаю что лично Вы получили от проекта массу удовольствия и пользы. Но сделал ли он лучше окружающий мир? У самого было несколько идей подобного уровня. Но эти соображения меня и остановили. Да, реализовать бы мог. Причем на первом этапе вообще один. Только смысл…
Владимир, прошу прощения, о какой версии llvm тут идёт речь? Дело в том что серия статей начиналась в 2011-м году, а наверняка с тех пор много чего поменялось. Хотел немного в это поиграться, просто для общего развития. В результате сейчас не знаю, какую версию llvm качать.
Спасибо! Обязательно гляну подробнее, описание по крайней мере очень интригующее. Хотя вообще Haskell я выбрал скорее как учебный язык, предполагая в будущем ориентироваться на Scala. Уж больно Scala тетка мягкая да сердобольная. Позволяет всяким раздолбаям писать код, какой их левая пятка на правой ноге пожелает. В итоге ничему функциональному научить не может. А мистер Haskell Curry учитель строгий. С ним не забалуешь и не пораздолбайствуешь. Как язык для продакшена это делает Scala очень привлекательной, но для обучения функциональной парадигме на мой взгляд только Haskell и ничего кроме него.
Проблема с Any в том, что для использования какого-то конкретного метода все равно нужно приводить его к какому-то типу (простите, если я ошибаюсь, мне всегда казалось, что это так).
Всё верно. Однако чем это плохо? На том же питоне или джаваскрипте Вы тоже всегда проверяете, что за объект пришел. Только там Вам приходится деконструировать его по частям. Скажем смотрим, словарь это или массив, если словарь что у него на первом месте, что на втором и т.д. А Any Вы сразу можете проверить на множество заранее определённых типов и увидеть что же конкретно пришло. Если же пришло что-то неизвестное на момент написания кода, Вы и обработать это не сможете вне зависимости от языка. Единственно что Вы можете, это передать данные какому-то другому обработчику, который возможно знает что с ними делать, либо сообщить об ошибке.
Ну и динамическая типизация не является необходимой, она просто поощряет другой подход к разработке, что позволяет, например разрабатывать библиотеки более гибко и делать страшные вещи с программой, вплоть до полной замены одного класса в runtime другим. Мне кажется, в том же C++ такое вряд ли можно сделать.
Вот этот момент меня тоже всегда очень интересовал. На плюсах такое сделать разумеется не получится, но мне всегда было очень интересно ЗАЧЕМ. Всё равно меняете Вы что-то в классе с помощью какого-то написанного Вами же(или другим человеком) кода, в ответ на какие-то события или данные. Т.е. чуда не происходит, и за Вас компьютер думать не начинает. На плюсах вместо полной замены класса в рантайме я всегда могу понять, что такие-то и такие-то данные для моего класса не годятся и передать их куда-то ещё. В крайнем случае подгрузить плагин из динамической библиотеки. Зато если в своих исходниках я вижу такой-то и такой-то класс, я твёрдо знаю что делает он то-то и то-то, всегда и везде. Как число пи в математике. Как в исходниках на джаваскрипте понять, что в этом месте программы такой-то класс уже полностью или хотя бы наполовину изменен, мне например не очень ясно. А вообще не знаю, можете запинать меня ногами, покрыть вечным позором и ненормативной лексикой, но по моему глубокому убеждению, программы мы пишем в первую очередь для людей, а не для компьютеров. Такая вот современная латынь(в средние века язык врачей, юристов и ученых, где важна была точность). Поэтому стремиться надо даже не к элегантности и красоте. А к ПОНЯТНОСТИ.
Ну я чисто по практике сужу. Скажем в той же Idea. Пишем на javascript, пока пользуемся чистым языком, всё более не менее. Подключаем jquery, уже начинаются проблемы. Подключаем plumb.js и начинаем гнусно материться. Переходим на typescript или scala и радостно вздыхаем :)
С явой проблема всё-таки не так остра, она достаточно быстрая сама по себе. Кстати для неё биндинги я уже писал, играясь с андроидом. С ней мне другое не нравится. Уж больно жруча она до памяти. Сейчас с теми же продуктами от JetBrains почему-то стало приличнее, но года три назад это было НЕЧТО… Я с Pycharm на WingIde тогда ушел. Работать было просто невозможно.
Кстати давно меня интересует. Возможно текущий проект по работе напишу всё-таки на нём. Благо там лишь бы работало, а жестких требований по языку нет. Для обсуждаемой темы большой недостаток — это отсутствие ядра поддержки для jupyter. Я например сейчас вообще жизни себе не представляю без этого инструмента и не совсем понимаю как обходился без него раньше. Впрочем ядро конечно тоже можно написать, не бином Ньютона.
Стоит учесть, что большинство решений для data science написаны с сишными биндингами. Производительность языка тут не всегда играет роль.
Что тоже кстати как и всякая медалька, о двух сторонах. Пока Вы пользуетесь какой-то библиотекой и не выходите за её рамки, всё прекрасно. Та же numpy например. Но стоит Вам захотеть чего-то бОльшего, начнутся проблемы. Кстати сишные биндинги для питона мне пока писать не приходилось. Не думаю что это особо сложно, но хотелось бы в рамках одного проекта обходиться одним языком.
Возможно наилучшее решение тут опциональная статическая типизация. Тип Any в scala, dynamic в dart, * в ActionScript3 и т.п. Хочешь что-то такое совсем уж эдакое, явным образом отказывайся от статического типа и пиши на свой страх и риск. Впрочем это есть и на С. На чистом С даже, а не на плюсах. Передавай указатель на данные как *void, и делай с ними что хочешь. Однако из своего опыта программирования на С/C++ (как образец языка с опциональной статической типизацией), могу сказать, что необходимость в подобном возникает всё-таки достаточно редко. В 90% случаях заранее известно с какими данными будет работать код.
Смотря что Вы делаете. Если просто хотите посмотреть на данные и обучить простую сетку на tensorflow, то да, согласен. Но если Вы разрабатываете какой-то свой алгоритм, и решили (как это почему-то модно) сделать прототип на питоне, могут быть и неприятности. Начиная от того что сам по себе язык не быстрый (хотя и порядком шустрее R или матлаба), и заканчивая динамической типизацией. Сам я последнее время сильно полюбил Scala, хотя начал ей пользоваться исключительно в как обёрткой над джаваскриптом(проект scala.js, впрочем с 2015-го года уже официальная платформа для языка). Хотя сейчас намеренно её забросил и всерьёз занялся хаскелем. Просто потому что понял что функциональному стилю на скале не научишься, слишком уж многое она позволяет. А чтобы полноценно ей пользоваться нужно для начала изучить что-то гораздо более строгое.
Большое спасибо, пожалуй первый за долгую историю моих попыток завязать разговор на эту тему, толковый ответ (хотя Вам тут совершенно правильно заметили, что говорите Вы скорее не о статике вообще, а о системе типов конкретной явы). А то обычно рассказывают как удивительно гибок питон, а я не понимаю, что он может такого, чего я не сделаю хотя бы на том же С++ и даже на чистом С, причём гораздо более безопасно и контролируемо. Т.е. по-Вашему наверно получается что динамическая типизация переносит часть трудностей в будущее. Из времени обдумывания кода, на время его отладки. Любопытно! И кстати многое объясняет. Есть программисты по складу мышления стратеги, любящие обдумывать и планировать. А есть тактики, любящие конкретно заставить код работать. Наверно первым нравится статическая типизация, вторым динамическая. Впрочем не скрою, что мне как лентяю и раздолбаю, ещё очень нравится автокомплит, который по очевидным причинам нормально работает только со статическими языками. Для динамических языков у меня слишком плохая память :)
динамическую, динамическая при работе с данными скорее только плюс
Прошу прощения, но не могли бы Вы немного прояснить этот вопрос, желательно с примерами кода? Я не стёба ради, просто хочу разобраться в этом вопросе раз и навсегда. Сам я динамическую типизацию просто тихо ненавижу. И не понимаю как на подобном языке можно написать что-то превышающее тысячи строк. С другой стороны я вижу огромные, в десятки и сотни тысяч строк пакета на том же питоне и джаваскрипте. Т.е. люди с этим как-то справляются и это медицинский факт, с которым не поспоришь. С третьей стороны есть куча народа, утверждающего что динамическая типизация это очень круто и гораздо удобнее статической. С четвёртой — никто из них так и не смог мне толком объяснить в чём же тут крутость и удобство. Вот и прошу хоть кого нибудь, покажите пожалуйста убедительный пример, где динамическая типизация даёт очевидное преимущество перед статической. Очень хочется в этом разобраться хотя бы для общего развития.
а для студента конвейерные трюки (а также OoO, потом всякую работу кэшей, MESI итд) нужно на чем-нибудь изучить.
С одной стороны так, с другой даже не знаю… Всё это по-моему можно изучить уже потом. Гораздо важнее перестроить логику мышления, если до этого человек на чём-то программировал. Мне например сначала трудно пришлось. Тут думать приходится совершенно по-другому, параллельными категориями. По-моему важнее этому научить.
Время ожидания разряда в RC генераторе на неоновой лампе
и
Шумы в диодах Зенера и других полупроводниковых генераторах шума
выглядят вполне приемлемыми для домашней лаборатории. Особенно первое, поскольку там во-первых сигнал чисто временной (длительность импульсов генератора), во-вторых довольно высокая частота (сотни и тысячи герц), что позволяет рисовать гистограмму каждую секунду, а возможно даже чаще, в третьих в отличии от шумов в полупроводниках, довольно понятная (во всяком случае на пальцах) физика, в четвертых очень дешевые компоненты (неоновые лампы стоят в чипе и дипе от 7 до 40 рублей). В течении 50 лет измерять конечно довольно напряженно, да и в течении года пожалуй тоже. Но в течении недели, почему бы и нет? Суточный ритм оно покажет. К тому же как я понял, если сделать несколько датчиков, гистограммы каждого из них измеренные в одно и то же время должны быть похожи. Не хотите заняться этим? Я например хочу. Сейчас только текущие дела немного раскидаю и попытаюсь это сделать. Кстати может получиться шикарная публикация на хабре.
Всё верно. Однако чем это плохо? На том же питоне или джаваскрипте Вы тоже всегда проверяете, что за объект пришел. Только там Вам приходится деконструировать его по частям. Скажем смотрим, словарь это или массив, если словарь что у него на первом месте, что на втором и т.д. А Any Вы сразу можете проверить на множество заранее определённых типов и увидеть что же конкретно пришло. Если же пришло что-то неизвестное на момент написания кода, Вы и обработать это не сможете вне зависимости от языка. Единственно что Вы можете, это передать данные какому-то другому обработчику, который возможно знает что с ними делать, либо сообщить об ошибке.
Вот этот момент меня тоже всегда очень интересовал. На плюсах такое сделать разумеется не получится, но мне всегда было очень интересно ЗАЧЕМ. Всё равно меняете Вы что-то в классе с помощью какого-то написанного Вами же(или другим человеком) кода, в ответ на какие-то события или данные. Т.е. чуда не происходит, и за Вас компьютер думать не начинает. На плюсах вместо полной замены класса в рантайме я всегда могу понять, что такие-то и такие-то данные для моего класса не годятся и передать их куда-то ещё. В крайнем случае подгрузить плагин из динамической библиотеки. Зато если в своих исходниках я вижу такой-то и такой-то класс, я твёрдо знаю что делает он то-то и то-то, всегда и везде. Как число пи в математике. Как в исходниках на джаваскрипте понять, что в этом месте программы такой-то класс уже полностью или хотя бы наполовину изменен, мне например не очень ясно. А вообще не знаю, можете запинать меня ногами, покрыть вечным позором и ненормативной лексикой, но по моему глубокому убеждению, программы мы пишем в первую очередь для людей, а не для компьютеров. Такая вот современная латынь(в средние века язык врачей, юристов и ученых, где важна была точность). Поэтому стремиться надо даже не к элегантности и красоте. А к ПОНЯТНОСТИ.
Что тоже кстати как и всякая медалька, о двух сторонах. Пока Вы пользуетесь какой-то библиотекой и не выходите за её рамки, всё прекрасно. Та же numpy например. Но стоит Вам захотеть чего-то бОльшего, начнутся проблемы. Кстати сишные биндинги для питона мне пока писать не приходилось. Не думаю что это особо сложно, но хотелось бы в рамках одного проекта обходиться одним языком.
Прошу прощения, но не могли бы Вы немного прояснить этот вопрос, желательно с примерами кода? Я не стёба ради, просто хочу разобраться в этом вопросе раз и навсегда. Сам я динамическую типизацию просто тихо ненавижу. И не понимаю как на подобном языке можно написать что-то превышающее тысячи строк. С другой стороны я вижу огромные, в десятки и сотни тысяч строк пакета на том же питоне и джаваскрипте. Т.е. люди с этим как-то справляются и это медицинский факт, с которым не поспоришь. С третьей стороны есть куча народа, утверждающего что динамическая типизация это очень круто и гораздо удобнее статической. С четвёртой — никто из них так и не смог мне толком объяснить в чём же тут крутость и удобство. Вот и прошу хоть кого нибудь, покажите пожалуйста убедительный пример, где динамическая типизация даёт очевидное преимущество перед статической. Очень хочется в этом разобраться хотя бы для общего развития.
С одной стороны так, с другой даже не знаю… Всё это по-моему можно изучить уже потом. Гораздо важнее перестроить логику мышления, если до этого человек на чём-то программировал. Мне например сначала трудно пришлось. Тут думать приходится совершенно по-другому, параллельными категориями. По-моему важнее этому научить.