Нам нужен способ передавать контекст в нашем приложении. Мы могли бы делать это вручную: let { span, newContext } = new Span("api-req", oldContext); И да, в официальном Go SDK действительно так и делают
кандидат философских наук, культурный тренд-аналитик и специалист по цифровой философии
Интересно, в курсе ли культурный тренд-аналитик что такое стохастический градиентный спуск? И чем он отличается от метода сопряженных градиентов? И почему в нейронных сетях первый используется, а второй нет? И какому из вполне известных механизмов функционирования головного мозга соответствует этот самый градиентный спуск? И соответствует ли?
Хотя как по мне если у кого возникла потребность умножать 1e170 на 1e170 - значит матмодель кривая. И понятно почему. Лично сталкивался с людьми которым уже некому было объяснить что такое "привести систему уравнений к безразмерному виду". А чо, будем заряд электрона в кулонах умножать на его массу в килограммах, а дальше пусть дура железная думает.
Зато, в отличии от "джуна", GPT не будет жаловаться на то, что из-за токсично-абьюзивных комментариев сеньора он выгорел и поэтому сегодня работать больше не может, а может пить тыквенный латте и смотреть нетфликс ))
Engee — мультиязычная среда с поддержкой Julia, Python, MATLAB, C/C++. Для хранения кода Engee существует специальный инструмент — Редактор скриптов. Скрипты имеют формат ngscript, однако вы можете работать и со всем известным форматом ipynb.
Как код на компилируемом языке запускается через "редактор скриптов"? Тот же C++, к примеру. Cling?
Речь тут, как мне кажется (или не кажется) не про эстетическую сторону (правила наименования, к примеру). А про то, что люди в принципе не понимают (или игнорируют) как те или иные решения влияют на потребление ресурсов (CPU, RAM), и в конечном счете на производительность.
Много раз обращал внимание, к примеру, на то, что авторы многочисленных поделий на numpy/scipy в принципе не отличают, когда их логика будет исполняться кодом "из под капота" (BLAS/LAPACK и т.д.), написанном на Fortran/C/C++, и соответствующим образом скомпилированном и собранном, и когда исполнение переедет на уровень собственно Python, с соответствующим падением производительности.
Года два или три назад попалась на глаза статья одного из "вычислительных физиков", в которой он делился с коллегами своими мыслями по поводу того, что у нас сейчас petascale (петабайты, петафлопсы), а на подходе exascale (экзабайты, экзафлопсы), и надо срочно придумать задачи, которые мы на exascale будем решать. То есть не сначала сформулировать задачу, а потом определить требуемые для ее решения ресурсы, а наоборот.
Глядя на уровень большинства поделий в этой области, не сомневаюсь, что они и exascale сумеют загрузить каким-нибудь линейным уравнением теплопроводности с однородными коэффициентами и стационарными источниками. Я в них верю.
Я некоторое время назад скачал и прочитал диссертацию Брайана Мея по астрофизике. Того самого гитариста из Queen. Он в свое время покинул аспирантуру ради карьеры профессионального музыканта, а году в 2007 таки дописал и защитил PhD. Там экспериментальная работа по изучению облаков пыли в солнечной системе, телескопы, интерферометры, вот это все. А в самом конце в приложении код на Fortran который данные обрабатывал. Он реально внушает, всем советую разыскать и глянуть ))
А по поводу "было ли раньше лучше" - такое как сейчас на БЭСМ-6 с оперативной памятью в 128 кбайт (если повезет) на ферритовых вентилях просто бы отсеялось само собой. Ограниченные ресурсы как-то сами располагали к написанию если не оптимизированного, то хотя бы чуть-чуть осмысленного кода.
Пример из JS (или TS), под ним ссылка на Go SDK
Автор, пиши еще
Чтобы что-то ненужное продать, сначала надо что-то ненужное купить (c)
Чтобы обнаружить и исправить галлюциногенный контент, его сначала надо сгенерировать
Все молодцы, все заняты делом, одни создают инструмент для генерации галлюциногенного контента, другие - инструменты для его обнаружения
Вариант отказаться от контента вообще не рассматривается.
Зачем? )) Почему просто не переписать запутанный C++ код на распутанный?
Интересно, в курсе ли культурный тренд-аналитик что такое стохастический градиентный спуск? И чем он отличается от метода сопряженных градиентов? И почему в нейронных сетях первый используется, а второй нет? И какому из вполне известных механизмов функционирования головного мозга соответствует этот самый градиентный спуск? И соответствует ли?
полностью согласен
я тоже ))
Я это просто к тому что если есть бетонная стена и голова, нет особого смысла изобретать метод пробивания бетона головой
Для решения систем уравнений с плохо обусловленными матрицами можно применить, например метод регуляризации
Умножать десять в степени афулиард на десять в степени минус афулиард чтобы получить в итоге единицу в любом случае бессмысленно, да и не нужно
На тему
можно также взглянуть вот на это
Хотя как по мне если у кого возникла потребность умножать
1e170на1e170- значит матмодель кривая. И понятно почему. Лично сталкивался с людьми которым уже некому было объяснить что такое "привести систему уравнений к безразмерному виду". А чо, будем заряд электрона в кулонах умножать на его массу в килограммах, а дальше пусть дура железная думает.Зато, в отличии от "джуна", GPT не будет жаловаться на то, что из-за токсично-абьюзивных комментариев сеньора он выгорел и поэтому сегодня работать больше не может, а может пить тыквенный латте и смотреть нетфликс ))
Годный промпт
Убежден, сейчас только 6.5 + 5.0 = 11.5 ярдов зелени добудут, и гидранты наконец будут повержены
))
Увидел заголовок и сразу подумал - найдется место для арены, или нет?
Нашлось ))
Ну и сразу вопрос - если в работе приложения такие затыки с памятью возникают, есть ли смысл дальше упираться в Go и его GC? Может все-таки C/C++? ))
Зачем в итоге понадобилось что-то "анализировать"? Оно работать перестало?
Как код на компилируемом языке запускается через "редактор скриптов"? Тот же C++, к примеру. Cling?
Речь тут, как мне кажется (или не кажется) не про эстетическую сторону (правила наименования, к примеру). А про то, что люди в принципе не понимают (или игнорируют) как те или иные решения влияют на потребление ресурсов (CPU, RAM), и в конечном счете на производительность.
Много раз обращал внимание, к примеру, на то, что авторы многочисленных поделий на numpy/scipy в принципе не отличают, когда их логика будет исполняться кодом "из под капота" (BLAS/LAPACK и т.д.), написанном на Fortran/C/C++, и соответствующим образом скомпилированном и собранном, и когда исполнение переедет на уровень собственно Python, с соответствующим падением производительности.
Года два или три назад попалась на глаза статья одного из "вычислительных физиков", в которой он делился с коллегами своими мыслями по поводу того, что у нас сейчас petascale (петабайты, петафлопсы), а на подходе exascale (экзабайты, экзафлопсы), и надо срочно придумать задачи, которые мы на exascale будем решать. То есть не сначала сформулировать задачу, а потом определить требуемые для ее решения ресурсы, а наоборот.
Глядя на уровень большинства поделий в этой области, не сомневаюсь, что они и exascale сумеют загрузить каким-нибудь линейным уравнением теплопроводности с однородными коэффициентами и стационарными источниками. Я в них верю.
"программу на фортране можно написать на любом языке" (c)
COMMON BLOCKS не хватает, с ними совсем было бы хорошо
Я некоторое время назад скачал и прочитал диссертацию Брайана Мея по астрофизике. Того самого гитариста из Queen. Он в свое время покинул аспирантуру ради карьеры профессионального музыканта, а году в 2007 таки дописал и защитил PhD. Там экспериментальная работа по изучению облаков пыли в солнечной системе, телескопы, интерферометры, вот это все. А в самом конце в приложении код на Fortran который данные обрабатывал. Он реально внушает, всем советую разыскать и глянуть ))
А по поводу "было ли раньше лучше" - такое как сейчас на БЭСМ-6 с оперативной памятью в 128 кбайт (если повезет) на ферритовых вентилях просто бы отсеялось само собой. Ограниченные ресурсы как-то сами располагали к написанию если не оптимизированного, то хотя бы чуть-чуть осмысленного кода.