И остались довольны результатом. Теперь хотят отправить ее на орбиту Земли.
Сегодня мы попробуем разобраться в физике пятого состояния материи и выясним, зачем ее сбрасывать с башни.Читать полностью »
Рубрика «ленивые вычисления»
Самую холодную капельку во Вселенной уронили с высокой колокольни
2021-10-20 в 9:00, admin, рубрики: Julia, ruvds_статьи, Блог компании RUVDS.com, гравитация, квантовые технологии, конденсат Бозе-Эйнштейна, ленивые вычисления, Научно-популярное, солитоны, спасибо scihub, уравнение Шрёдингера, физикаИ остались довольны результатом. Теперь хотят отправить ее на орбиту Земли.
Перемещение — прошлый век! Альтернативы std::move в «C++ будущего»
2020-01-17 в 13:41, admin, рубрики: autoclosure, c++, closure, lambda, lazy, move semantics, proposal, relocation, замыкание, ленивые вычисления, лямбда, перемещение, ПрограммированиеКаждый раз, когда мы пишем класс, управляющий ресурсами, мы задумываемся о том, что, скорее всего, для него придётся писать move-конструктор и move-присваивание. Ведь иначе объекты такого типа становятся неуклюжими, как std::mutex, ими тяжело пользоваться на практике: ни вернуть из функции, ни передать в функцию по значению, ни положить в вектор — а если положить его в другой класс как один из членов, то тот класс также «заболевает».
Положим, мы преодолели свою лень (хотя в Rust таких проблем нет!) и садимся писать move-операции для нашего класса. Проблема в том, что move-семантика в C++ имеет фундаментальное ограничение: каждый владеющий ресурсами тип с move-операциями должен иметь пустое состояние, то есть состояние с украденными ресурсами. Его нужно описывать в документации и предоставлять ему поддержку, то есть тратить время и силы на то, что нам не нужно.
Для абстрактных типов данных пустое состояние обычно бессмысленно — если у объекта украли его ресурсы, то он не сможет выполнять свои обычные функции. Но мы вынуждены это делать, чтобы реализовать move-семантику. Для некоторых типов пустое состояние недопустимо: open_file (в противовес теоретическому file), not_null_unique_ptr<T> (в противовес unique_ptr<T>).
Говоря словами Arthur O'Dwyer, мы заказывали телепорт, а нам дали «вас клонируют и убивают первоначальную копию». Чтобы вернуть себе телепорт, проходите под кат!
PostgreSQL Antipatterns: вредные JOIN и OR
2019-12-10 в 9:00, admin, рубрики: dba, explain, explain.tensor.ru, lazy sql, postgresql, sql, sql antipatterns, Администрирование баз данных, базы данных, визуализация данных, ленивые вычисленияБойтесь операций, buffers приносящих…
На примере небольшого запроса рассмотрим некоторые универсальные подходы к оптимизации запросов на PostgreSQL. Пользоваться ими или нет — выбирать вам, но знать о них стоит.
Читать полностью »
Пишем Java Stream API на коленке за пару минут
2017-03-17 в 13:12, admin, рубрики: filter, java, map, spliterator, stream api, генераторы, ленивые вычисления, ПрограммированиеStream API — замечательная вещь быстро завоевавшая популярность у джава программистов. Лаконичные однострочники обрабатывающие коллекции данных посредством цепочек простых операций map, filter, forEach, collect оказались очень удобны. Операции над парами ключ-значение, конечно, тоже не помешали бы, но увы.
В целом примерно понятно как это всё устроено, но все же зачастую ответ на вопрос «А как бы это написал я?» здорово помогает понять внутренние механизмы той или иной технологии. Так получилось, что внезапно для себя я ответил на этот вопрос применительно к Stream API, историей изобретения этого велосипеда и спешу с вами поделиться.
Читать полностью »
Ленивый список в C++
2016-02-22 в 18:13, admin, рубрики: c++, ленивые вычисления, ненормальное программирование 
В Scala есть интересная коллекция — Stream. Контейнер, который представляет собой список, элементы которого вычисляются (и сохраняются после этого) при первом обращении:
The class Stream implements lazy lists where elements are only evaluated when they are needed.
Мне захотелось реализовать нечто подобное на C++.
Читать полностью »
Как работают ленивые вычисления
2015-01-05 в 12:08, admin, рубрики: haskell, lazy evaluation, ленивые вычисления, ПрограммированиеМаленькая Лямбда решила, что уборку в комнате можно отложить и на потом.
Ленивые вычисления — часто используемая методика при исполнении компьютером программ на Haskell. Они делают наш код проще и модульнее, но могут вызвать и замешательство, особенно когда речь заходит об использовании памяти, становясь для новичков распространённой ловушкой. Например, безобидно выглядящее выражение
foldl (+) 0 [1..10^8]потребует для своего вычисления гигабайты памяти.
В этом руководстве я хочу объяснить, как работают ленивые вычисления и что они означают для времени выполнения и объёма памяти, затрачиваемыми программами на Haskell. Я начну рассказ с основ редукции графов, а после перейду к обсуждению строгой левой свёртки — простейшего примера для понимания и ликвидации утечек памяти.
Тема ленивых вычислений рассматривалась во многих учебниках (например, в книге Саймона Томпсона «Haskell — The Craft of Functional Programming»), но информацию о них, кажется, всё ещё проблематично найти в сети. Надеюсь, моё руководство посодействует решению этой проблемы.
Ленивые вычисления — это компромисс. С одной стороны, они помогают нам сделать код более модульным. С другой стороны, бывает невозможно до конца разобраться, как происходит вычисление в конкретной программе — всегда существуют небольшие отличия между реальностью и тем, что вы о ней думаете. В конце статьи я дам рекомендации, как поступать в ситуациях такого рода. Итак, приступим!
Принципы быстрого Хаскеля под GHC
2013-03-05 в 8:21, admin, рубрики: ghc, haskell, LLVM, yarr, абстрактное синтаксическое дерево, высокая производительность, каррирование, Компиляторы, ленивые вычисления, метки: ghc, LLVM, yarr, абстрактное синтаксическое дерево, каррирование, ленивые вычисленияGHC (Glasgow Haskell Compiler) — стандартный компилятор Хаскеля. GHC — один из самых крутых компиляторов в мире, но к сожалению без дополнительных телодвижений скомпилированные им программы по скорости больше напоминают интерпретируемые, т. е. работают очень медленно. Однако если раскрыть весь потенциал компилятора, Хаскель приближается по производительности к аналогичному коду на C.
В этой статье я обобщаю опыт выжимания максимума из GHC при создании dataflow-фреймворка Yarr.
Читать полностью »
Ленивый hGetContents. Баг или фича? (Haskell)
2012-10-04 в 21:17, admin, рубрики: haskell, ленивые вычисления, метки: ленивые вычисленияМеня давно беспокоит одна тема. Вот решил высказаться и услышать, что думают люди по этому поводу. Речь пойдет о функции hGetContents. Если вы когда-нибудь работали с файлами, то вы знаете, что эта функция возвращает содержимое файла (потока). Вот типичный пример использования этой функции.
import System.IO
main = do
file <- openFile "1.txt" ReadMode
content <- hGetContents file
print content
hClose file
-- результат: выводит содержимое файла на экран