Насчёт карточек, а точнее SRS, я не соглашусь:
SRS это методика, который позволяет не забыть. Она ни в коем случае не отменяет контекста.
Но карточки надо создавать самому, только тогда будет наибольшая эффективность.
Узнал слово — сделай карточку с определением, карточку с изображением/ситуацией, сделай карточки со словосочетаниями/фразами с опущенным словом (clozes).
И всё. Теперь уже никогда не забудешь, об этом позаботится SRS.
И естественно, эта методика дополняет изучение языка, с ней просто легче, так как изучение слов не является блокировкой процесса.
Любопытный подход, единственное, что непонятно, почему у нас он не был никак отражён. Ведь это очень старая технология, должна была быть известна советским специалистам.
С чего бы это? Эсперанто в этом отношении ничем таким от натлангов не отличается, те же проблемы с переводом, неоднозначностью смыслов и прочим. Его единственное достоинство — регулярная грамматика — при текущем уровне NLP, не играет большой роли.
Есть статья от Эрика Липперта, в которой он делится опытом создания такой структуры и причинами, по которым они в последующих проектах от них отказались.
А я, наверное, не устану рекомендовать классическую книгу, посвящённую в том числе и планированию размещения кода по заголовочным, исходным файлам и модулям: John S. Lakos — Large-Scale C++ Software Design.
Она, конечно, скучная и уже старая, но общие идеи не устарели до сих пор.
Это только если IP статический.
А так у Tor Hidden Services есть следующие преимущества над VPN:
1. Бесплатный постоянный onion-адрес в условиях динамического IP/NAT.
2. Тонкий контроль над доступом к вынесенным во внешнюю сеть ресурсом: наружу попадают только те сервисы, которые указаны в настройках.
Потому что это пустой спор, в нём не нужны аргументы.
По мне, в IDE есть редактор текста и он проигрывает как редактор и VIM и Emacs.
Для себя я решил всё проще: я работаю в IDE, но когда надо что-то отредактировать, я нажимаю горячую клавишу и оказываюсь в VIM, выполняю то, что хотел, и снова оказываюсь в своей IDE.
Для меня это оказалось гораздо комфортней, чем отсутствие средств IDE в редакторе, или отсутствие нормального редактора в IDE.
Коллеги! Я, наверное, повторюсь, но смотрите:
Мир IT ещё молод, но уже есть отдельные примеры сложной «археологии кода» — когда вроде бы прошло немного времени, но технологии настолько изменились, что ни извлечь данные, ни запустить программы уже не получается.
Под Windows было написано множество программ, исходные коды которых недоступны или уже утеряны, через 20–30 лет единственный способ получить доступ к их данным или поведению будет только запуск в эмуляторах. Поэтому наличие Open Source NT это хороший задел на будущее, который поможет нам сохранить для истории множество, я не побоюсь этого слова, произведений искусства и других воплощённых в ПО человеческих знаний.
Если ограничиваться только текущим моментом, то да, они делают что-то сомнительное, если же попытаться представить дальнее будущее, то их работа обретает глубокий смысл.
Ещё есть вариант преобразования с помощью CPS: вот обсуждение на StackOverflow.
Вкратце, идея в том, чтобы действия, которые надо выполнить с полученным результатом, передать в первый рекурсивный вызов. Тут тоже никаких преимуществ перед обычной рекурсией, разве что память, которая потребляется, обычно меняется со стека на кучу.
Про машины с числами в обратном коде я знаю только про UNIVAC, но стандарт явно отказывается от указания способа представления числа со знаком, так что гарантировать их работу нельзя.
При заданных начальных условиях xn = (3n+1+5n+1)/(3n+5n)
Очевидно, что предел равен 5, при вычислениях в рациональных числах для исходной рекуррентной формулы мы также получаем последовательные приближения к 5.
Т. е. ожидаемый и правильный ответ должен быть равен 5.
Другое дело, что действительно, точка 5 неустойчива и при вычислениях с привнесённой ошибкой мы сразу от неё уйдём.
Так в этом и есть смысл статьи: вычисления с плавающей точкой сложны и могут приводить к неожиданным результатам, даже когда числа не являются малыми/большими, надо внимательно за ними следить.
Те статьи, на которые автор сослался как раз за авторством Уильяма Кэхэна. Он занимается проблемами вычислений с плавающей точкой больше 30 лет и не видит универсального способа, только понимание, только тесты.
Можно ещё наверное посоветовать его довольно известную статью Mathematics Written in Sand (pdf).
Насколько я понял из первого слинкованного документа: xn = (3n+1+5n+1)/(3n+5n) без ошибок округления.
При их наличии xn ≈ (3n+1+5n+1+γn*100n+1)/(3n+5n+γn*100n) где n = 3,4,5,… а γn — малое число представляющее собой ошибку округления.
Далее получается xn ≈ 100 — (95+97*(3/5)n)/(20n*γn + 1 + (3/5)n)
Т. е. само наличие малой ошибки (как бы мала она не была) смещает предел с 5 к 100.
Тут лучше сами документы почитать, так как там есть ещё более дикие примеры типа гладкой функции G(x).
Насчёт карточек, а точнее SRS, я не соглашусь:
SRS это методика, который позволяет не забыть. Она ни в коем случае не отменяет контекста.
Но карточки надо создавать самому, только тогда будет наибольшая эффективность.
Узнал слово — сделай карточку с определением, карточку с изображением/ситуацией, сделай карточки со словосочетаниями/фразами с опущенным словом (clozes).
И всё. Теперь уже никогда не забудешь, об этом позаботится SRS.
И естественно, эта методика дополняет изучение языка, с ней просто легче, так как изучение слов не является блокировкой процесса.
Она, конечно, скучная и уже старая, но общие идеи не устарели до сих пор.
А так у Tor Hidden Services есть следующие преимущества над VPN:
1. Бесплатный постоянный onion-адрес в условиях динамического IP/NAT.
2. Тонкий контроль над доступом к вынесенным во внешнюю сеть ресурсом: наружу попадают только те сервисы, которые указаны в настройках.
По мне, в IDE есть редактор текста и он проигрывает как редактор и VIM и Emacs.
Для себя я решил всё проще: я работаю в IDE, но когда надо что-то отредактировать, я нажимаю горячую клавишу и оказываюсь в VIM, выполняю то, что хотел, и снова оказываюсь в своей IDE.
Для меня это оказалось гораздо комфортней, чем отсутствие средств IDE в редакторе, или отсутствие нормального редактора в IDE.
Мир IT ещё молод, но уже есть отдельные примеры сложной «археологии кода» — когда вроде бы прошло немного времени, но технологии настолько изменились, что ни извлечь данные, ни запустить программы уже не получается.
Под Windows было написано множество программ, исходные коды которых недоступны или уже утеряны, через 20–30 лет единственный способ получить доступ к их данным или поведению будет только запуск в эмуляторах. Поэтому наличие Open Source NT это хороший задел на будущее, который поможет нам сохранить для истории множество, я не побоюсь этого слова, произведений искусства и других воплощённых в ПО человеческих знаний.
Если ограничиваться только текущим моментом, то да, они делают что-то сомнительное, если же попытаться представить дальнее будущее, то их работа обретает глубокий смысл.
вот обсуждение на StackOverflow.
Вкратце, идея в том, чтобы действия, которые надо выполнить с полученным результатом, передать в первый рекурсивный вызов. Тут тоже никаких преимуществ перед обычной рекурсией, разве что память, которая потребляется, обычно меняется со стека на кучу.
Очевидно, что предел равен 5, при вычислениях в рациональных числах для исходной рекуррентной формулы мы также получаем последовательные приближения к 5.
Т. е. ожидаемый и правильный ответ должен быть равен 5.
Другое дело, что действительно, точка 5 неустойчива и при вычислениях с привнесённой ошибкой мы сразу от неё уйдём.
Так в этом и есть смысл статьи: вычисления с плавающей точкой сложны и могут приводить к неожиданным результатам, даже когда числа не являются малыми/большими, надо внимательно за ними следить.
Можно ещё наверное посоветовать его довольно известную статью Mathematics Written in Sand (pdf).
xn = (3n+1+5n+1)/(3n+5n) без ошибок округления.
При их наличии
xn ≈ (3n+1+5n+1+γn*100n+1)/(3n+5n+γn*100n) где n = 3,4,5,… а γn — малое число представляющее собой ошибку округления.
Далее получается xn ≈ 100 — (95+97*(3/5)n)/(20n*γn + 1 + (3/5)n)
Т. е. само наличие малой ошибки (как бы мала она не была) смещает предел с 5 к 100.
Тут лучше сами документы почитать, так как там есть ещё более дикие примеры типа гладкой функции G(x).