abcalex12
Участник-
Постов
61 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о abcalex12
-
Звание
Участник
Информация
-
Город
Array
Посетители профиля
Блок последних пользователей отключён и не показывается другим пользователям.
-
Плюс много. Конечно IP меняют, по самым разным причинам. Сетевая часть вообще может быть покупным сервисом, оказываемый третьими лицами. Так что ваш полезный функционал будет даже не в курсе, что там что-то поменялось. В общем, если явно не сказано обратное, IP адрес -- не часть публичного контракта и не должен использоваться.
-
Конечно не производит. Но ответственность за согласование батарей в сборке берет на себя.
-
То есть не зря платим за фирменные сборки от APC.
-
А они разные же бывают, и фоторезисторы и диоды.
-
Ну, традиционно фотоэффект и фотопроводимость это два разных слова. Процитированный гост говорит только о фотоэффекте..
-
Про регистрацию подумать надо, вряд ли конечно: 1 МГц очень малоэнергетичный фотон, упрется в красную границу. Но, к слову, вынужденное излучение впервые сделали на мазере, 24 ГГц. Гост рассказывает нам про терминологию внутри полупроводниковых средств регистрации. Из него не следует, что термин отсутствует в других стандартах например. Кстати, а куда по этой логике попадают приемники на фотопроводимости PbS/PbSe, HgCdTe? Они не ФЭПП и сборки с ними не ФПУ?
-
Если вы будете измерять ее, например, температуру и использовать результат в расчетах, связанных с поглощенным ею излучением -- то будет фотоприемником конечно. В паре с градусником. Спор довольно бессмысленный, утвержденной терминологии нет. Мой бэкграунд (ЛГУ, ЛОМО) не мешает мне считать болометр за ФПУ. Или вот например: http://www.mathnet.ru/php/archive.phtml?wshow=paper&jrnid=qe&paperid=14148&option_lang=rus
-
Это не общепринятая классификация. Когда занимался спектрометрией, в нашей тусовке за ФПУ считалось любое покупное изделие в корпусе и с хоть каким-то интерфейсом (в противовес лабораторной самоделке)
-
Оптосимистор на 0.8A и 600V без детектора нуля?
abcalex12 опубликовал тема в Вопросы аналоговой техники
Что-то не ищется, присоветуйте? хочу заменить Z00607(0.8A 600V 20A/us) опторазвязанным компонентом, но что-то все с детектором нуля попадаются. Надо коммутировать обмотки вентилятора, детектор нуля там лишний. неужто брать отдельный оптрон и обычный симистор? -
Опыт предоставления пользователю скриптовых языков. Крайне сложная задача, как по мне. Получается либо слишком сильно и они все ломают, либо слишком беззубо и ничего нельзя толком сделать. В последнее время намечается некий консенсус в индустрии, всякие "Rule Engine"-ы. Но по-моему еще не устоялось.
-
В принципе все так и есть. У жавы есть возможность вызвать функцию, написанную на С/С++ и так далее, называется JNI. Его можно использовать для обработки прерываний. Самый нижний обработчик прерывания пишется на С, и просто обеспечивает передачу управления в жаву и обратно. ПДП по такой нет смысла делать, а вот если надо как-то развесисто с сетью покоммуницировать, то вполне. Не любят этого не по причине высокоуровневости даже, а потому что это непереносимо. Так-то jar файл исполнится на любой машине с любой архитектурой -- если есть jvm, то все нужное имеется. А прерывание очень специфично.
-
Видимо, в джаву вы не слишком заглядывали. Вот не-техническое описание древнего(10 лет) JRockit: https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/underst_jit.html Компилируется не сорец, а байткод. Машинное время конечно уходит, на начальном этапе, но речь о классических серверных приложениях. Они запускаются один раз, и работают до аварии в датацентре.
-
Вы ошибаетесь. JIT в яве есть и очень давно, и благодаря ему в серверном применении ява не сильно уступает нативному коду. После "прогрева" этого самого jit-а, конечно, когда все основные ветки программы исполнились и откомпилировались. Посмотрите в сторону Rust.
-
Это не просто так отсохло. Основное ускорение джавы сейчас происходит за счет Just-In-Time компиляции. Это когда рантайм смотрит на наиболее выполняемые куски кода и заменяет их оптимизированным нативом. С этой точки зрения аппаратное выполнение байт-кода не нужно. Для маленьких-старых vm-ок может и было полезно, но не в полновесном JDK.