Только список а не массив, ок?

а я массив сказал?

а. да. список, конечно же

четырьмя ))) хвостовая/не хвостовая, добавлять элементы в начало в конец

Давай дурные способы не будем рассматривать?

тогда первый. вариант из моих.

А вот и нет. Оба способа - хвостовой с реверсом и обычный работают сравнимое время. И в зависимости от размера списка тот или иной может быть быстрее. А памяти обычный требует меньше.

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

Прикол в том что стек и куча это одно пространство и растут они навстречу друг другу.

обычный, который со стеком? памяти меньше требует?

ну я не уверен. смотря как считать. вообще за все время. или в какой-то определенный момент

Реверсированный список и исходный. GC не сразу исходный съест.

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

Те пиково память больше.

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

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

Он стал меньше, но память-то не освободилась.

там память освобождается по стадиям каким-то. устаревания. забыл как называются

каких итогов добились то?

какие выводы сделали?

я бы в любом случае не поставил на стек

вся ерланг документация учит тому, чтобы писать так, чтоб стек не рос

Так я говорю, что стек, что куча - берут из одного объёма.

ну. я бы так не упрощал. там система мемори аллокаторов целая. не простая далеко

За что купил за то продаю.

вот я бы рекомендовал к прочтению

https://groups.google.com/forum/#!topic/erlang-russian/HxvQq7gaoOI

там хотя бы немножко открывается завеса над тем, как происходит выделение и освобождение памяти

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

лушей практикой является хвостовая.

по памяти статейка есть

О! Сергей, давай ка!

https://www.erlang-solutions.com/blog/erlang-19-0-garbage-collector.html

О! Алексей)

в закладочки пошло )

у нас еще для теплых длинных зимних вечеров припасена тема не последовательного извлечения сообщений из почтового ящика процесса )))))

Реверсированный список и исходный. GC не сразу исходный съест.

то, что VM не отдаст сразу в ОС зааллокейченый кусок памяти - не означает, что она не может этот кусок памяти использовать далее для своих нужд.

лушей практикой является хвостовая.

Потому что так написано в книжке? https://pragtob.wordpress.com/2016/06/16/tail-call-optimization-in-elixir-erlang-not-as-efficient-and-important-as-you-probably-think/

да. потому, что так я прочитал в книжке. но при этом, я и не утверждаю, что я господь бог ерланга )

к сожалению, не владею свободно английским. если не сложно, в общих чертах о чем там?

то, что VM не отдаст сразу в ОС зааллокейченый кусок памяти - не означает, что она не может этот кусок памяти использовать далее для своих нужд.

При чем тут VM? Он не пометится как свободный пока GC не пройдется.

как определяли задержку и факт того, что он не свободный?

Ну вернее так - GC не сразу будет помечать как свободные освободившееся пространство. И размер стека ограничен только оперативой. Советую почитать статью.

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

хочется сложность создавать там, где ее нет? у вас там действительно список в 16 гб?

мне кажется, что это все вырожденные случаи. так же, как, например, утверждать, что коробка автомат по льду скользит и не едет вообще.

Ну фишка в том, что обычный map быстрее хвосторекурсивного на маленьких и средних списках. И медленнее на больших (10 миллионов элементов). При этом требует меньше памяти и проще в понимании.

“Myth: Tail-Recursive Functions are Much Faster Than Recursive Functions”!

Идея в том что не всегда хвостовая рекурсия лучше, если мы строим большие структуры данных.

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

мне кажется, что это все вырожденные случаи. так же, как, например, утверждать, что коробка автомат по льду скользит и не едет вообще.

Мне кажется что утверждать что хвостовая рекурсия лучше все равно что говорить что задний привод всегда лучше.

не всегда он лучше. задачи разные есть

Старые привычки они не всегда полезны.

если есть желание засадить машину, то это можно и на полном приводе 6х6 сделать

не всегда он лучше. задачи разные есть

Ну и я про то.

просто статья воспринимается, как "ура, мы разрушили миф".

ну. допустим, да. был миф. разрушили. от этого жить легче стало, что-то поменялось?

завтра ты сам же поднастроишь параметры GC и библиотечная map опять порвет body на этом вырожденном примере

люди могут вон через ++ сложить массивы и от этой разницы в 10% следа не останется

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

во! прям один в один "In other cases my way of choosing is the one which gives me the most intelligible code. And that varies depending on what the function is supposed to do and how I choose to do it."

с добрым утром )

Ага, скоро узнаю, доброе или нет )

давай, рассказывай, какой на вкус австралийский кофе

о! ведь скоро узнаем, что там выгорело с проектом!

давай, рассказывай, какой на вкус австралийский кофе

Без шуток - лучший

пишут, что особо вроде не экспортируют. а было бы интересно попробовать.

пишут, что особо вроде не экспортируют. а было бы интересно попробовать.

Это очень странно

ERROR: S client not available

я совсем недавно упарываюсь по кофе. молю, варю сам. не скажу, что я вот прям на вкус и цвет одно от другого отличу. но вот даже по пенке - они и то отличаются.

пока из того, что есть в нашем, кхм, городке. больше всех понравился Гватемальский почему-то. а широты у вас подходящие, потому и спросил )

Вот таких дырок с кофе - сотни

Все варят отменный кофе и сразу зернами барыжат

У каждой - своя смесь

Я вот в этой беру. Очень мягкий кофе с каким то сотонинским количество кофеина

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

надо будет в нашей лавке спросить. вдруг есть )

Могу прислать пакет кофе вот из этой кофейни

сейчас вот варим эфиопскую арабику. у нее почему-то пенка белая. никогда такого не замечал ранее

Могу прислать пакет кофе вот из этой кофейни

вообще не представляю, сколько это будет стоить

12 баксов(aud) за 250г кажется

Пересылка баксов 15-20 думаю

ну. цены норм. мы вернемся к этому разговору ))) потому что ну очень интригующе

настоящий кофей, да еще напрямую из австралии. шикардос

а женщины на фото - это так выглядит местное население?

в Сиднее азиатов наверное 60%

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

типа

:)

стартап выгорел. я бохат )

т.е. вы остаетесь разработчиками, и старые ваши задачи в этой компании, уже не ваши?

типа будете заниматься своим сервисом, или как?

все так же, просто мы сервис развиваем в свободное время, получаю еще штук 10 за это.

мы же все на визах, да и развивать интеграции изнутри - проще

расходы на поддержку вашего сервиса кто оплачивать будет?

все так же, просто мы сервис развиваем в свободное время, получаю еще штук 10 за это.

А вас сколько в команде стартапа вообще

я про это