/я до этого херню написал здесь/

Перевести можно вообще без проблем одинаково, смысл всей фразы один и тот же, я просто показываю, что конкретно may be и maybe - разные единицы

так а разница кроме пробела и разных частей речи все же есть?

Видимо, примерно как у “возможно” и “может быть”

Ну по внутреннему ощущению так

Если придёт лингвист и расскажет, в чём я неправа, буду рада оказаться в курсе

я и тут разницу не вижу) а вдруг она есть
*пошел в угол медленно сходить с ума*

хз я сразу нагуглил вполне разумное объяснение для раздельного варианта. без ощущений

поделись плиз

да первая же ссылка

а я тупой - видел ее превью в результатах запроса в гугле, но открывать не стал

ну, там тоже просто написано "так пиши, а вот так не пиши". Почему только с can такое не указано

я написал знакомому лингвисту, интересно что ответит

Don’t use can not when you mean cannot. The only time you’re likely to see can not written as separate words is when the word “can” happens to precede some other phrase that happens to start with “not”

это для кого написано то?

вы молодец

It may be that you maybe should not use can not when you do not want to confuse it with `cannot`)

#wanted_tw

Всем привет!

Позиция: Руководитель группы технической документации
Город: Санкт-Петербург
Компания: ЦРПТ (Честный знак) https://crpt.ru/

Наша компания создает первую в мире единую систему маркировки и прослеживаемости товаров Честный Знак. С ее помощью мы можем на всех этапах от производства и логистики до реализации, отследить любую единицу товара и проверить его подлинность.

Ищем в свою команду сильного лидера в группу технической документации. Данная команда отвечает за разработку, ведение и актуализацию пользовательской документации и пользовательских инструкций для сотен тысяч наших клиентов, а также за документацию для разработчиков и интеграторов (описание API). В том числе и на английском языке.

Задачи:
 •Организация и координация работы подразделения (в подчинении 5 чел);
 •Ведение полного цикла разработки документации,
 •Согласование планов работ группы с общим планом работ команды разработки;
 •Активное взаимодействие с бизнес-подразделениями, разработчиками, тестировщиками и аналитиками компании в рамках создания документации.

Наши ожидания от кандидата:
 •Опыт документирования API и создания пользовательской документации;
 •Знание стандартов описания жизненного цикла, архитектуры и интерфейсов информационных систем;
 •Опыт работы с системами управления версиями (Git, Сonfluence), владение языками разметки AsciiDoc или Markdown;


Отклики и рекомендации можно присылать сюда:
e.kosovets@crpt.ru
tg: @ekaterinakosovets

Спасибо и хорошего всем дня 🙂

Ну надо потом медианную просто посмотреть. Кто вообще по средней сравнивает)

Медиана это тоже показатель с потенциальной ошибкой. Если после ранжирования середина попала на 10 тысяч, будет 10, если на соседние 100 тысяч --- 100.

Лучше тупо моду с весами считать.

совершенно согласна, но медиана все же лучший показатель, чем среднее, ну и это попроще, чем моду с весами считать