Все реально, о том и статья, но вопрос в мощности. Те то что можно извлеч из чего-то компактного, и близко не хватит чтобы телефон понял что его заряжают. Это как пытаться напиться вдыхая моросящий дождь, когда даже капель толком не чувствуешь... Те можно, но потребуется мнооого целофана чтобы все это собрать до существенных объемов. Или как сказано выше, надо подойти куда-то где сигнал очень сильный. П.С.: косо прочитал, и ответил в контексте зарядки телефона, но сути это не меняет.
Спасибо! Наконец-то до меня дошло, я думал что связь более линейная, в плане разницы в ускорении от истечения струи в контексте абсолютной(как я писал меня самого это смущало) скорости коробля. А если дело в практическом результате через массу, то тут все понятно, и вопросов нет. В практическом смысле я с этим даже в KSP сталкивался. Просто думал что есть что-то еще, в рамках реальной физики, как тот же эффект Оберта который до меня тоже тяжело доходил.
Хмм, с точки зрения скорости выхлопа как такового вы определенно правы. (именно что до релативистких скоростей как вы и сказали) Но по тому что я читал у меня создалось впечатление что есть какой-то подвох, как с эффектом Оберта. Который тоже не очевиден. Но мб. я спутал в скорость и ускорение. Это бы все объяснило. В любом случае спасибо, надо будет освежить в голове этот момент.
Не совсем так, насколько я понимаю, при приближении скорости перемещаемого объекта к скорости истечения реактивной струи(которая зависит от порождающей её реакции), эффективность двигателя падает вплоть до сравнимой с просто сбросом массы топлива... И насколько я читал, химические ракеты в этом плане достаточно ограничены, до скорости несколькоих км сек. (Не уверен подподает ли это под "запасом топлива и релятивистскими ограничениями", но это вполне реально ограничение для таких масштабов, и куда раньше чем приближение скорости света) А вот в у ионных и ядерных двигателей этот потолок гораздо выше.
Как человек знающий это больше из научпопа и не до конца понимающий, прошу если я не прав не молча минусить, а ткнуть в ошибку. Так как меня самого чуть смущает момент с относительностью скорости, до приближения к релятивистким.
Я я когда-то начал в виде веб-игрушки делать сетевой стек, с эзернетом и виртуальными свитчами и рабочими станциями. Но потом в какой-то момент обнаружил себя, работающим с TAP драйвером, чтобы связать игровую сеть с реальной. На этом моменте мне показалось что лучше заняться работой, но иногда возникает желание таки допилить с этим игру, но боюсь не так много народу оценит. А вот усилий много, и профиль не совсем мой рабочий чтобы они в портфолио окупились...
В медицине, увы, часто приходится лечить раньше чем готовы все необходимые анализы. Так что скорее всего это диагностика на предварительных данных, как и у врачей.
А еще серьёзные зловреды не делают ничего криминального когда обнаруживают виртуалку. И не я не за проверку на железе со сменой винта, так как в текущих реалиях и в материнке может потом нехорошие остаться...
С одной стороны это действительно трата ресурсов, но с другой, оно ведь реально может повлиять на ответ... Ну и имхо это не то же самое что всприятие как ..., а я бы скорее сравнил с синтаксисом SQL который где-то похож на анл., и имеет лишнии конструкции, тем не менее они необходимы. Проще говоря, я никогда не писал гуглу пожалуйста, но нейросетки учатся на натуральных данных, и вежливость в таком ключе уже часть запроса.
Alt+F(ile) работает наверное везде где это надо, в том числе и в Шторме. Не в защиту Шторма, но в совет, так как сам когда-то привык к так, и даже не знал что просто Alt не работает в нем...
Использует, но справедливости ради, хороший программный растиризатор тоже удивительно быстрым может быть. Тот же хром если отключить апаратку даже 3д не так уж медленно рисует... Те в плюсах и жсе сравнивать надо не их, а растеризатор в первую очередь.
Вообще может быть интересно рисовать на хосте, на который натравлять шейдер с инвертированной формулой. Те мы как бы будем своим рисованиям предоставлять x,y исходные...
А еще мне приходит в голову генерить это на шейдере, в том смысле что есть зависимость от сгенеренных, но в то же время сгенерив пару тысяч, мы можем шейдером каждым прогоном удваивать результат. А видеокарты щас быстрые. На самом деле это будет не полностью идентичный последовательной генерации результат, ибо погрешности попадения в пиксель будут, но близко думаю. Я проверил, если округлять границу пикселя, то все становится скучно, но если добавлять рандом после округления, то картинки визуально не отличимы от оригинала, не смотря на постоянное округление. (Тоже самое было бы с шейдером, но его я щас писать не готов)
Ну потому и сказал про WebWorker... Плюс даже на максимальной скорости полета там вроде не более 5ки картинок в секунду... Тут даже без многопоточности ресурсов достаточно.
Ну мой не то что бы оптимизированный вариант на JS при определенных значениях генерит вполне похожую картинку за 20к итераций что занимает 11мс, при том что для 60фпс надо уложится в 16... Это если по картике на кадр, а там куда реже генерация, так что если еще и в веб поркере делать...
Спорить не буду, но по мне так вообще не интересно, и +- вчера у меня на положительных что-то похожие было... А вот [-50,50,1000], 0.1, -10 выглядит куда интереснее. Но выставил +-2000, и scale от 0.1. Вообще если что на 24 строке исходника сами можете поправить лимиты, там без регистрации можно...
Увеличил лимит до 200, но имхо тогда уже менее удобно прицеливатся ползунками. Ну и на отрицательных не вижу особого смысла, так как там в основном повторение, а прицеливатся еще сложнее... Upd: сделал таки отрицательные, но имхо интересный результат с ними только на c...
Все реально, о том и статья, но вопрос в мощности. Те то что можно извлеч из чего-то компактного, и близко не хватит чтобы телефон понял что его заряжают.
Это как пытаться напиться вдыхая моросящий дождь, когда даже капель толком не чувствуешь... Те можно, но потребуется мнооого целофана чтобы все это собрать до существенных объемов. Или как сказано выше, надо подойти куда-то где сигнал очень сильный.
П.С.: косо прочитал, и ответил в контексте зарядки телефона, но сути это не меняет.
Интересное сочетание с отдельными бегающими частицами.
Спасибо! Наконец-то до меня дошло, я думал что связь более линейная, в плане разницы в ускорении от истечения струи в контексте абсолютной(как я писал меня самого это смущало) скорости коробля.
А если дело в практическом результате через массу, то тут все понятно, и вопросов нет.
В практическом смысле я с этим даже в KSP сталкивался. Просто думал что есть что-то еще, в рамках реальной физики, как тот же эффект Оберта который до меня тоже тяжело доходил.
Хмм, с точки зрения скорости выхлопа как такового вы определенно правы. (именно что до релативистких скоростей как вы и сказали)
Но по тому что я читал у меня создалось впечатление что есть какой-то подвох, как с эффектом Оберта. Который тоже не очевиден.
Но мб. я спутал в скорость и ускорение. Это бы все объяснило.
В любом случае спасибо, надо будет освежить в голове этот момент.
Не совсем так, насколько я понимаю, при приближении скорости перемещаемого объекта к скорости истечения реактивной струи(которая зависит от порождающей её реакции), эффективность двигателя падает вплоть до сравнимой с просто сбросом массы топлива...
И насколько я читал, химические ракеты в этом плане достаточно ограничены, до скорости несколькоих км сек. (Не уверен подподает ли это под "запасом топлива и релятивистскими ограничениями", но это вполне реально ограничение для таких масштабов, и куда раньше чем приближение скорости света)
А вот в у ионных и ядерных двигателей этот потолок гораздо выше.
Как человек знающий это больше из научпопа и не до конца понимающий, прошу если я не прав не молча минусить, а ткнуть в ошибку. Так как меня самого чуть смущает момент с относительностью скорости, до приближения к релятивистким.
Я я когда-то начал в виде веб-игрушки делать сетевой стек, с эзернетом и виртуальными свитчами и рабочими станциями.
Но потом в какой-то момент обнаружил себя, работающим с TAP драйвером, чтобы связать игровую сеть с реальной.
На этом моменте мне показалось что лучше заняться работой, но иногда возникает желание таки допилить с этим игру, но боюсь не так много народу оценит. А вот усилий много, и профиль не совсем мой рабочий чтобы они в портфолио окупились...
В медицине, увы, часто приходится лечить раньше чем готовы все необходимые анализы.
Так что скорее всего это диагностика на предварительных данных, как и у врачей.
А еще серьёзные зловреды не делают ничего криминального когда обнаруживают виртуалку.
И не я не за проверку на железе со сменой винта, так как в текущих реалиях и в материнке может потом нехорошие остаться...
С одной стороны это действительно трата ресурсов, но с другой, оно ведь реально может повлиять на ответ...
Ну и имхо это не то же самое что всприятие как ..., а я бы скорее сравнил с синтаксисом SQL который где-то похож на анл., и имеет лишнии конструкции, тем не менее они необходимы.
Проще говоря, я никогда не писал гуглу пожалуйста, но нейросетки учатся на натуральных данных, и вежливость в таком ключе уже часть запроса.
ICU есть под Linux. Я именно под ним первый раз и встретился с этой библиотекой. Раньше при попытке собрать что-то старое с ней часто были проблемы, во всяком случае у меня.
https://github.com/unicode-org/icu/releases/tag/release-75-1
В последнем
WebStorm 2024.1.5у меня работает как и прежде, правда я мигрировал, а не начисто ставил, так что может в настрйоках дело.Alt+F(ile)работает наверное везде где это надо, в том числе и в Шторме.Не в защиту Шторма, но в совет, так как сам когда-то привык к так, и даже не знал что просто
Altне работает в нем...Использует, но справедливости ради, хороший программный растиризатор тоже удивительно быстрым может быть.
Тот же хром если отключить апаратку даже 3д не так уж медленно рисует...
Те в плюсах и жсе сравнивать надо не их, а растеризатор в первую очередь.
Вообще может быть интересно рисовать на хосте, на который натравлять шейдер с инвертированной формулой. Те мы как бы будем своим рисованиям предоставлять x,y исходные...
А еще мне приходит в голову генерить это на шейдере, в том смысле что есть зависимость от сгенеренных, но в то же время сгенерив пару тысяч, мы можем шейдером каждым прогоном удваивать результат. А видеокарты щас быстрые.
На самом деле это будет не полностью идентичный последовательной генерации результат, ибо погрешности попадения в пиксель будут, но близко думаю.
Я проверил, если округлять границу пикселя, то все становится скучно, но если добавлять рандом после округления, то картинки визуально не отличимы от оригинала, не смотря на постоянное округление. (Тоже самое было бы с шейдером, но его я щас писать не готов)
Ну потому и сказал про WebWorker... Плюс даже на максимальной скорости полета там вроде не более 5ки картинок в секунду... Тут даже без многопоточности ресурсов достаточно.
Ну мой не то что бы оптимизированный вариант на JS при определенных значениях генерит вполне похожую картинку за 20к итераций что занимает 11мс, при том что для 60фпс надо уложится в 16... Это если по картике на кадр, а там куда реже генерация, так что если еще и в веб поркере делать...
У вас как и выше в треде x,y последовательно друг друга портят... Надо z=x;x=...,y=...(z);
Спорить не буду, но по мне так вообще не интересно, и +- вчера у меня на положительных что-то похожие было... А вот [-50,50,1000], 0.1, -10 выглядит куда интереснее. Но выставил +-2000, и scale от 0.1. Вообще если что на 24 строке исходника сами можете поправить лимиты, там без регистрации можно...
Увеличил лимит до 200, но имхо тогда уже менее удобно прицеливатся ползунками.
Ну и на отрицательных не вижу особого смысла, так как там в основном повторение, а прицеливатся еще сложнее...
Upd: сделал таки отрицательные, но имхо интересный результат с ними только на c...