Jump to content

    

abcalex12

Участник
  • Content Count

    61
  • Joined

  • Last visited

Community Reputation

0 Обычный

About abcalex12

  • Rank
    Участник

Информация

  • Город
    Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Плюс много. Конечно IP меняют, по самым разным причинам. Сетевая часть вообще может быть покупным сервисом, оказываемый третьими лицами. Так что ваш полезный функционал будет даже не в курсе, что там что-то поменялось. В общем, если явно не сказано обратное, IP адрес -- не часть публичного контракта и не должен использоваться.
  2. Конечно не производит. Но ответственность за согласование батарей в сборке берет на себя.
  3. А они разные же бывают, и фоторезисторы и диоды.
  4. Ну, традиционно фотоэффект и фотопроводимость это два разных слова. Процитированный гост говорит только о фотоэффекте..
  5. Про регистрацию подумать надо, вряд ли конечно: 1 МГц очень малоэнергетичный фотон, упрется в красную границу. Но, к слову, вынужденное излучение впервые сделали на мазере, 24 ГГц. Гост рассказывает нам про терминологию внутри полупроводниковых средств регистрации. Из него не следует, что термин отсутствует в других стандартах например. Кстати, а куда по этой логике попадают приемники на фотопроводимости PbS/PbSe, HgCdTe? Они не ФЭПП и сборки с ними не ФПУ?
  6. Если вы будете измерять ее, например, температуру и использовать результат в расчетах, связанных с поглощенным ею излучением -- то будет фотоприемником конечно. В паре с градусником. Спор довольно бессмысленный, утвержденной терминологии нет. Мой бэкграунд (ЛГУ, ЛОМО) не мешает мне считать болометр за ФПУ. Или вот например: http://www.mathnet.ru/php/archive.phtml?wshow=paper&jrnid=qe&paperid=14148&option_lang=rus
  7. Это не общепринятая классификация. Когда занимался спектрометрией, в нашей тусовке за ФПУ считалось любое покупное изделие в корпусе и с хоть каким-то интерфейсом (в противовес лабораторной самоделке)
  8. Что-то не ищется, присоветуйте? хочу заменить Z00607(0.8A 600V 20A/us) опторазвязанным компонентом, но что-то все с детектором нуля попадаются. Надо коммутировать обмотки вентилятора, детектор нуля там лишний. неужто брать отдельный оптрон и обычный симистор?
  9. JAVA IDE

    Опыт предоставления пользователю скриптовых языков. Крайне сложная задача, как по мне. Получается либо слишком сильно и они все ломают, либо слишком беззубо и ничего нельзя толком сделать. В последнее время намечается некий консенсус в индустрии, всякие "Rule Engine"-ы. Но по-моему еще не устоялось.
  10. JAVA IDE

    Зря вы так. В жабе это довольно удобно, быстро привыкаешь и обратно -- ну можно конечно, но лучше не. Как автомат после ручки. ОООоооо... какая это боль.
  11. JAVA IDE

    В принципе все так и есть. У жавы есть возможность вызвать функцию, написанную на С/С++ и так далее, называется JNI. Его можно использовать для обработки прерываний. Самый нижний обработчик прерывания пишется на С, и просто обеспечивает передачу управления в жаву и обратно. ПДП по такой нет смысла делать, а вот если надо как-то развесисто с сетью покоммуницировать, то вполне. Не любят этого не по причине высокоуровневости даже, а потому что это непереносимо. Так-то jar файл исполнится на любой машине с любой архитектурой -- если есть jvm, то все нужное имеется. А прерывание очень специфично.
  12. JAVA IDE

    Видимо, в джаву вы не слишком заглядывали. Вот не-техническое описание древнего(10 лет) JRockit: https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/underst_jit.html Компилируется не сорец, а байткод. Машинное время конечно уходит, на начальном этапе, но речь о классических серверных приложениях. Они запускаются один раз, и работают до аварии в датацентре.
  13. JAVA IDE

    Вы ошибаетесь. JIT в яве есть и очень давно, и благодаря ему в серверном применении ява не сильно уступает нативному коду. После "прогрева" этого самого jit-а, конечно, когда все основные ветки программы исполнились и откомпилировались. Посмотрите в сторону Rust.
  14. JAVA IDE

    Это не просто так отсохло. Основное ускорение джавы сейчас происходит за счет Just-In-Time компиляции. Это когда рантайм смотрит на наиболее выполняемые куски кода и заменяет их оптимизированным нативом. С этой точки зрения аппаратное выполнение байт-кода не нужно. Для маленьких-старых vm-ок может и было полезно, но не в полновесном JDK.