Хм, т.е. предполагается, что пользователь, условно, Adobe Premier или Apple Final Cut, не сможет убедить эти программы, с помощью отладчика и какой-то матери, что они редактируют оригинальные видео Leica или оргинальный репортаж ТАСС?
Сомнительно. Как я понял из их спецификации речь идёт только о гарантиях "авторства" конечного видео. А дальше уж, каждый сам недоверяет или доверяет корреспондентам CNN, ТАСС, и др., камерам Leica, Apple, Android или HarmonyOS.
К примеру, аналогичную систему Canon "взламывали" же, так что и Leica сомнительно, что справится. Возможно, у Apple больше шансов защитить доступ к ключам, но...
Можно, наверное, пытаться депонировать всю цепочку промежуточных видеоматериалов, но есть сомнения в правовой и технической возможности этого.
Немного запутанная статья, но, обычно, идея в стимуляции того фитопланктона, который усваиваетс образованием карбоната кальция (, мел). Главное, что б этот фитопланктон не сожрал кто-нибудь, кому этот кальций нужен, и кто сумеет его переварить.
Самая древняя из ныне известных звёзд – красный гигант SPLUS J210428.01−004934.2, расположенный примерно в 16 тысячах световых лет от Земли.
Хм, неаккуратная формулировка, однако. К примеру, один из самых холодных белых карликов LSPM J0207+3331 (0,69 M⊙) только на стадии белого карлика находится 3 млрд. лет, а собственно как звезда класса K образовался в числе самых первых звёзд.
Не понятно, картинка с уже предложенным Вами градиентом? Похоже, что нет. Попробуйте построить четыре тестовые картинки: 100 пикселов сверху, слева, справа и снизу.
Броюсь что проблема не в том, где лучше делать линейный градиент, в пространстве RGB, или в пространстве HSV, а в самой формулировке идеи дополнения.
... падающее под него вещество успело как-то нагреться и передать энергию в стороны (как мне кажется)
Для ПЧД на верхней границе , если оценить долю захватываемой массы превращаемой в гамма излучение ≈30%, то для Луны по диаметру получим 5 килотонн в тротиловом эквиваленте. Полтора грамма "взрывчатки" на метр пути, наверное, есть шанс заметить.
Впрочем, ПЧД на нижней границе , проскочит совершенно незамеченной, что твоё нейтрино.
Да, уж, ПЧД на верхней границе масс, рассматриваемой в статье, - , образует канал радиуса ≈150 нм (1500 Å), общий объём которого, даже если взять диаметр Земли, всего ≈1 мл. Забавно. 😉
И, да, потери на энергию разорванных химических связей (200.. 500 кДж/моль) по сравнению с общей кинетической энергией - будут тоже микроскопическими.
Однако, чувствительный элемент сейсмометра, а тем более гравиметра, возможно, сможет заметить гравитационное воздействие, как бы, 0,0014 массы Луны это немало.
Честно говоря, помнится, по гравитационным возмущениям комет и прочего, была такая гипотетическая планета Тюхе, массой в полтора Юпитера на расстоянии 30000 а.е. (0,5 св.г) в облаке Оорта (или даже целый коричневый карлик Немезида, но немного дальше). Однако, по архивам WISE, это дело не подтвердилось и до сих пор находится на уровне сомнительных домыслов.
Но, заметим, прямо так существенных бед от них не ожидалось, ну по расчётам.
Ну, да, если к нам прилетит шальная звезда, то тоже будет "капут".
Единственное отличие шальной ЧД от шальной звезды, это время обнаружения того факта, что "капут".
Однако, тёмной материи несильно больше, чем барионной материи (звёзд). Наша Галактика - очень большая, а наша Солнечная система (вплоть до облака Оорта) - очень маленькая, так что вероятность на нашей стороне.
Для шальных звёзд мы её можем даже посчитать - 0 целых, шиш десятых на один оборот вокруг центра Галактики (230 млн лет). И для шальных ЧД - примерно тоже самое.
У ЛИГО частотный диапазон ограничен. Сливающиеся ЧД массой от пары сотен масс Солнца и выше слишком быстро его проскочат, поэтому они практически не могут быть обнаружены ЛИГО.
Да, у нас есть пара примеров: 1I/Оумуамуа (скорость на момент ухода вдаль: 26,33 км/с, 5,55 а. е./год), 2I/Борисова (скорость на момент ухода вдаль: 30,7 км/с, 6,47 а. е./год).
Насчёт быстро, это ж от перигелия зависит, у 1I/Оумуамуа перигелий 0,26 а.е. (пересечение с эклиптикой, одно внутри орбиты Мергурия, второе внутри орбиты Марса), поэтому скорость в перигелии немаленькая - 87,71 км/с
А у 2I/Борисова перигелий 2 а.е. (пересечение эклиптики внутри орбиты Юпитера), соответственно и скорость у неё в перигелии по-меньше, примерно 50 км/с.
Обе скорости более менее соответствуют движению Солнца по отношению к ближайшим звездам со скоростью 20 км/с (к ближайшим, которые, из нашего курятника).
Простой метод возведения в степень возведением в квадрат выполняет , операций (если вероятность ненулевого бита ), но если разделить степень на группы бит, можно получить .
Кстати, если степень имеет особый вид, к примеру, как у Вас, , то можно попробовать получить для этих степеней цепочки сложения короче, чем , но это будет непросто (не факт, что окупится).
*(n^2048)*(n^1024)*(n^512)*(n^256)*(n^64) плюс ещё 5 умножений на известные числа
Не очень понял, Вы имеете ввиду составить таблицу небольших степеней, скажем, до 4096, и сэкономить на умножениях, а ля оконный метод ?
А так то, и сам bc, и код выше, используют простое возведение в квадрат val *= val и умножение res *= val для ненулевых бит степени, только у bc проблема в том, что эти операции выполняются с неограниченной(абсолютной) точностью, а округление до абсолютной ошибки происходит только в конце, что вызывает заметный расход памяти и тормоза.
А по хорошему надо выполнять вычисления с ограниченной точностью, исходя из
На самом деле, эта оценка, в общем случае, ИМХО, не даст существенного выигрыша, кроме как случая, когда близко к 1. 😉
P.S.
Пожалуй, я поторопился со словами "в общем случае не даст", для и она позволит гораздо быстрее получить 0. 😉
bc 6.5.0 (Gavin D. Howard and contributors), входит в состав macOS Sonoma
GNU bc 1.07.1 из MacPorts
BSD bc 6.5.0 хранит 9 цифр в 32 бит целом и умножает методом Карацубы, в отличие от GNU bc, который хранит одну цифру в char и умножает в столбик, при n=10^5, работает шустрее примерно в 700 раз.
В вашем примере дойти можно, где-то, до n=10^7
Почти во всех программах похоже, что используется внутреннее экспоненциальное представление, и это хорошо. Однако с уверенностью этого нельзя сказать о троице старейших программ: bc, dc и calc.
Хм, в документации на bc и dc (man bc) указано, что они используют представление с фиксированной точкой.
Но выяснилось, что возведение в степень сделано в bc довольно плохо. При увеличении n время вычисления увеличивается экспоненциально, а должно быть не хуже линейного.
Для фиксированной точки, всё не так просто, поскольку число значащих цифр может расти.
Конкретно в bc и dc, с необходимой точностью промежуточных вычислений при возведении в степень разбираться не стали, промежуточные вычисления выполняются точно, дробная часть растёт, округляют только результат.
Но, ясное дело, что рекомендованный в документации способ возведения в вещественную степень: scale=30000; n=10^(scale-10); e(l(1 + 1/n)*n), вполне себе работает.
Впрочем, и в целую степень можно самостоятельно возвести итеративно:
define pown(x, n, iscale) {
auto escale, res, val, n2
if(n < 0) {
print "pown(): FAIL: n < 0 - unimplemented\n"
return(0/0)
}
escale = scale
res = 1
val = x
while(n > 0) {
scale = 0
n = divmod(n, 2, n2[])
scale = iscale
if(n2[0]) {
res *= val
}
val *= val
}
scale = escale
return(res/1)
}
define void testpown() {
auto escale, i, j, x, n, s
escale = scale
scale = 10
for(i = 0; i <= 8; i += 1) {
x[i] = (i-4)*0.5;
n[i] = 3^i
s[i] = n[i]
}
for(i = 0; i <= 8; i += 1) {
for(j = 0; j <= 8; j += 1) {
if(pown(x[i], n[j], s[j]) != x[i]^n[j]) {
print "testpown(): FAIL pown(", x[i], ", ", n[j], ")\n";
print pown(x[i], n[j], s[j]), "\n";
print x[i]^n[j], "\n";
}
}
}
scale = escale
}
testpown()
При самостоятельном итеративном возведении можно дойти примерно до: scale=8000; n=10^(scale-10); pown(1 + 1/n, n, scale), и немного далее.
Хм, т.е. предполагается, что пользователь, условно, Adobe Premier или Apple Final Cut, не сможет убедить эти программы, с помощью отладчика и какой-то матери, что они редактируют оригинальные видео Leica или оргинальный репортаж ТАСС?
Сомнительно. Как я понял из их спецификации речь идёт только о гарантиях "авторства" конечного видео. А дальше уж, каждый сам недоверяет или доверяет корреспондентам CNN, ТАСС, и др., камерам Leica, Apple, Android или HarmonyOS.
К примеру, аналогичную систему Canon "взламывали" же, так что и Leica сомнительно, что справится. Возможно, у Apple больше шансов защитить доступ к ключам, но...
Можно, наверное, пытаться депонировать всю цепочку промежуточных видеоматериалов, но есть сомнения в правовой и технической возможности этого.
Немного запутанная статья, но, обычно, идея в стимуляции того фитопланктона, который усваивает
с образованием карбоната кальция (
, мел). Главное, что б этот фитопланктон не сожрал кто-нибудь, кому этот кальций нужен, и кто сумеет его переварить.
Со Старлинк - можно, но с Цяньфань (если/когда её развернут) - вряд ли, как и с каким-нибудь Бюро-1440.
Хм, неаккуратная формулировка, однако. К примеру, один из самых холодных белых карликов LSPM J0207+3331 (0,69 M⊙) только на стадии белого карлика находится 3 млрд. лет, а собственно как звезда класса K образовался в числе самых первых звёзд.
Не понятно, картинка с уже предложенным Вами градиентом? Похоже, что нет. Попробуйте построить четыре тестовые картинки: 100 пикселов сверху, слева, справа и снизу.
Броюсь что проблема не в том, где лучше делать линейный градиент, в пространстве RGB, или в пространстве HSV, а в самой формулировке идеи дополнения.
P.S.
Прошу прощения.
Для ПЧД на верхней границе
, если оценить долю захватываемой массы превращаемой в гамма излучение ≈30%, то для Луны по диаметру получим 5 килотонн в тротиловом эквиваленте. Полтора грамма "взрывчатки" на метр пути, наверное, есть шанс заметить.
Впрочем, ПЧД на нижней границе
, проскочит совершенно незамеченной, что твоё нейтрино.
Да, уж, ПЧД на верхней границе масс, рассматриваемой в статье, -
, образует канал радиуса ≈150 нм (1500 Å), общий объём которого, даже если взять диаметр Земли, всего ≈1 мл. Забавно. 😉
И, да, потери на энергию разорванных химических связей (200.. 500 кДж/моль) по сравнению с общей кинетической энергией - будут тоже микроскопическими.
Однако, чувствительный элемент сейсмометра, а тем более гравиметра, возможно, сможет заметить гравитационное воздействие, как бы, 0,0014 массы Луны это немало.
Честно говоря, помнится, по гравитационным возмущениям комет и прочего, была такая гипотетическая планета Тюхе, массой в полтора Юпитера на расстоянии 30000 а.е. (0,5 св.г) в облаке Оорта (или даже целый коричневый карлик Немезида, но немного дальше). Однако, по архивам WISE, это дело не подтвердилось и до сих пор находится на уровне сомнительных домыслов.
Но, заметим, прямо так существенных бед от них не ожидалось, ну по расчётам.
Ну, да, если к нам прилетит шальная звезда, то тоже будет "капут".
Единственное отличие шальной ЧД от шальной звезды, это время обнаружения того факта, что "капут".
Однако, тёмной материи несильно больше, чем барионной материи (звёзд). Наша Галактика - очень большая, а наша Солнечная система (вплоть до облака Оорта) - очень маленькая, так что вероятность на нашей стороне.
Для шальных звёзд мы её можем даже посчитать - 0 целых, шиш десятых на один оборот вокруг центра Галактики (230 млн лет). И для шальных ЧД - примерно тоже самое.
У ЛИГО частотный диапазон ограничен. Сливающиеся ЧД массой от пары сотен масс Солнца и выше слишком быстро его проскочат, поэтому они практически не могут быть обнаружены ЛИГО.
Аккреционный диск "размером с один атом", или немного больше, в принципе не может выдать много света.
Да, температурка для ЧД массы астероида порядка
, но ввиду микроскопического радиуса, их всё равно обнаружить будет невозможно.
Однако, по-моему, все ПЧД массой существенно меньше Луны (т.е. с температурой существенно больше 2,7 К) должны уже были напрочь испарится.
Не очень понятно в каких оценочных моделях такие ПЧД могут существовать в значимых количествах.
Ну, как? Вот звезды Барнарда или Глизе 445 из древней сферической составляющей нашей Галактики, типа, нас "догоняют" - 110 км/с.
А двигались бы "навстречу" могло бы быть и 500 км/с, скажем, звезда Каптейна, которая движется "поперёк" имеет относительную скорость - 250 км/с.
Да, у нас есть пара примеров: 1I/Оумуамуа (скорость на момент ухода вдаль: 26,33 км/с, 5,55 а. е./год), 2I/Борисова (скорость на момент ухода вдаль: 30,7 км/с, 6,47 а. е./год).
Насчёт быстро, это ж от перигелия зависит, у 1I/Оумуамуа перигелий 0,26 а.е. (пересечение с эклиптикой, одно внутри орбиты Мергурия, второе внутри орбиты Марса), поэтому скорость в перигелии немаленькая - 87,71 км/с
А у 2I/Борисова перигелий 2 а.е. (пересечение эклиптики внутри орбиты Юпитера), соответственно и скорость у неё в перигелии по-меньше, примерно 50 км/с.
Обе скорости более менее соответствуют движению Солнца по отношению к ближайшим звездам со скоростью 20 км/с (к ближайшим, которые, из нашего курятника).
Простой метод возведения в степень возведением в квадрат выполняет
, операций (если вероятность ненулевого бита 
), но если разделить степень на группы бит, можно получить 
.
Кстати, если степень имеет особый вид, к примеру, как у Вас,
, то можно попробовать получить для этих степеней цепочки сложения короче, чем 
, но это будет непросто (не факт, что окупится).
Не очень понял, Вы имеете ввиду составить таблицу небольших степеней, скажем, до 4096, и сэкономить на умножениях, а ля оконный метод ?
А так то, и сам
происходит только в конце, что вызывает заметный расход памяти и тормоза.
bc, и код выше, используют простое возведение в квадратval *= valи умножениеres *= valдля ненулевых бит степени, только уbcпроблема в том, что эти операции выполняются с неограниченной(абсолютной) точностью, а округление до абсолютной ошибкиА по хорошему надо выполнять вычисления с ограниченной точностью, исходя из
На самом деле, эта оценка, в общем случае, ИМХО, не даст существенного выигрыша, кроме как случая, когда
близко к 1. 😉
P.S.
Пожалуй, я поторопился со словами "в общем случае не даст", для
и 
она позволит гораздо быстрее получить 0. 😉
У самоката (СИМ) есть номер, зачем курьеру id? Если агрегатор фиксирует использование СИМ конкретным сотрудником?
Но требование о знаниий ПДД в рамках необходимых для управления СИМ выглядит более менее разумным, хотя, причём здесь "корпорация"?
С уверенностью, порождённой чтением документации, а так же испытаниям, за
bcиdcможно сказать - числа с фиксированной точкой.Это Вы пока не исправили, а зря, ИМХО, это существенный момент.
Сравнение на MacBook Pro 2021 года:
bc 6.5.0 (Gavin D. Howard and contributors), входит в состав macOS Sonoma
GNU bc 1.07.1 из MacPorts
BSD bc 6.5.0 хранит 9 цифр в 32 бит целом и умножает методом Карацубы, в отличие от GNU bc, который хранит одну цифру в char и умножает в столбик, при
n=10^5, работает шустрее примерно в 700 раз.В вашем примере дойти можно, где-то, до
n=10^7Хм, в документации на
bcиdc(man bc) указано, что они используют представление с фиксированной точкой.Для фиксированной точки, всё не так просто, поскольку число значащих цифр может расти.
Конкретно в
bcиdc, с необходимой точностью промежуточных вычислений при возведении в степень разбираться не стали, промежуточные вычисления выполняются точно, дробная часть растёт, округляют только результат.Но, ясное дело, что рекомендованный в документации способ возведения в вещественную степень:
scale=30000; n=10^(scale-10); e(l(1 + 1/n)*n), вполне себе работает.Впрочем, и в целую степень можно самостоятельно возвести итеративно:
При самостоятельном итеративном возведении можно дойти примерно до:
scale=8000; n=10^(scale-10); pown(1 + 1/n, n, scale), и немного далее.Прошу прощения, но
И
Немного друг другу противоречат, бинарные сборки из коробки не могут иметь таких ключей.
Но по сути, да, BSD bc живой проект и принципиально более шустрый, чем мёртвый проект GNU bc.