День пятьсот шестьдесят девятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
56. Делайте Невидимое Видимым
Многие аспекты невидимости справедливо относят к важным принципам разработки программного обеспечения, которых необходимо придерживаться. Наша терминология богата метафорами невидимости: ссылочная прозрачность или сокрытие информации – лишь пара примеров. ПО и процесс его разработки могут быть по большей части невидимы:

- Исходный код не имеет физической сущности, поведения и не подчиняется законам физики. Он виден, когда вы загружаете его в редактор, но закройте редактор, и он исчезнет. Как дерево, которое падает, но этого никто не слышит, можно начать сомневаться, а существует ли оно вообще.

- Работающее приложение имеет сущность и поведение, но не раскрывает ничего о своём исходном коде. Домашняя страница Google приятно минималистична, но её функционал, несомненно, огромен.

- Если вы сделали 90% задачи, но застряли, пытаясь отладить последние 10%, то нельзя сказать, что продукт готов на 90%. Исправление ошибок не считается прогрессом. Вам не платят за отладку. Отладка - пустая трата времени. Хорошо бы сделать эти потери более заметными, чтобы вы могли сразу видеть, куда тратятся ресурсы, и думать о том, как этого не допускать.

- Если ваш проект всё время продвигался по плану, а через неделю уже опаздывает на шесть месяцев, у вас проблемы. И самая большая проблема даже не в том, что проект опаздывает на шесть месяцев, а том, что вы не заметили причины задержки до самого последнего момента! Отсутствие видимого прогресса является синонимом отсутствия прогресса.

Невидимость может быть опасной. Вы размышляете яснее, когда у вас есть что-то конкретное, с чем можно связать своё мышление. Вы лучше управляете вещами, когда видите их и видите, как они постоянно меняются:

- Написание модульных тестов свидетельствует о том, насколько легко блок кода поддаётся тестированию. Это помогает выявить наличие (или отсутствие) качеств, которые вы хотели бы иметь в коде, таких как низкая связанность и высокая связность.

- Выполнение модульных тестов свидетельствует о поведении кода. Это помогает выявить наличие (или отсутствие) качеств времени выполнения, которые вы хотели бы иметь в приложении, таких как надёжность и корректность.

- Использование общедоступного баг трекера делает прогресс видимым и конкретным. Задачи могут отображаться как «Не начата», «Выполняется» или «Выполнена», вне зависимости от наличия скрытого инструмента управления проектом и без необходимости преследовать программистов за недостоверные отчёты о выполненной работе.

- Инкрементальная разработка улучшает видимость прогресса (или его отсутствия) за счёт увеличения частоты релизов (свидетельств прогресса). Завершение и выпуск ПО показывает реальную картину, оценка прогресса - нет.

Лучше всего разрабатывать программное обеспечение с большим количеством регулярных видимых доказательств. Видимость даёт уверенность в том, что прогресс является подлинным, а не иллюзорным, запланированным, а не случайным, повторяемым и не разовым.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jon Jagger.

День пятьсот семидесятый. #TipsAndTricks
Повышаем продуктивность в Visual Studio.
31. Отслеживать или не Отслеживать Текущий Документ в Проводнике Решения
Может быть очень полезно переключаться на текущий файл в проводнике решения (Tools -> Options -> Projects and Solutions -> General -> Track Active Item in Solution Explorer). Последнее, что хочется делать, - это вручную искать его в дереве элементов вашего решения.
Проблема в том, что после работы с кучей файлов дерево проводника решения превращается в бардак. Всё развернуто и ничего не найти. Вместо автоматического отслеживания есть горячие клавиши для перехода к этому элементу.

Горячие клавиши по умолчанию - Ctrl+[,S. Я стараюсь оставлять значения по умолчанию. Не самая простая для запоминания комбинация, но ко всему привыкаешь. Как бы то ни было, поменять можно в Tools -> Options -> Environment -> Keyboard. Начните вводить "SyncWithActiveDocument" в поле справа.

Источник: https://michaelscodingspot.com/productivity-tips-in-visual-studio/

День пятьсот семьдесят первый. #ЗаметкиНаПолях
Деревья выражений
Деревья выражений - чрезвычайно мощная часть .NET, но они также являются одной из самых плохо понимаемых частей. По сути, они позволяют вам обернуть лямбда-выражения, такие как Func<T> или Action<T>, и проанализировать их. Лучше всего проиллюстрировать это на примере. Метод расширения Where в LINQ to Objects принимает Func<T, int, bool> в качестве основного параметра:

static IEnumerable<TSource> WhereIterator<TSource>(IEnumerable<TSource> source, Func<TSource, int, bool> predicate) {
  int index = -1;
  foreach (TSource element in source) {
    checked { index++; }
    if (predicate(element, index)) yield return element;
  }
}

Он выполняет итерацию по IEnumerable и возвращает элементы соответствующие предикату. Однако очевидно, что это не будет работать в LINQ to SQL/Entity Framework, т.к. там необходимо перевести предикат в SQL! Так что сигнатура для версии IQueryable немного другая:

static IQueryable<TSource> Where<TSource>(this IQueryable<TSource> source, Expression<Func<TSource, int, bool>> predicate) {
  return source.Provider.CreateQuery<TSource>( 
    Expression.Call(
      null,
      GetMethodInfo(Queryable.Where, source, predicate),
      new Expression[] { 
        source.Expression, Expression.Quote(predicate) 
      }
    )
  );
}

Выглядит страшно, но главное тут в том, что функция теперь принимает делегат Func<T, int, bool>, завернутый в Expression, то есть позволяет LINQ провайдеру прочитать Func, проанализировать переданный предикат и перевести его в SQL. Таким образом, Expression позволяет вам проверять ваш код во время выполнения.

Давайте рассмотрим что-нибудь попроще. Допустим, у вас есть код, который добавляет настройки в словарь:

var settings = new List<Setting>();
settings.Add(
  new Setting(
    "EnableBugs",
    Settings.EnableBugs));
settings.Add(
  new Setting(
    "EnableFluxCapacitor",
    Settings.EnableFluxCapacitor));

Здесь нетрудно увидеть опасность: название параметра в словаре представляет собой строку, и опечатка здесь может вызвать проблемы. Если мы создадим новый метод, который принимает Expression<Func<T>> (т.е. лямбда-выражение, которое что-то возвращает), мы можем получить фактическое имя переданной переменной:

private Setting GetSetting<T>(Expression<Func<T>> expr) {
  var me = expr.Body as MemberExpression;
  if (me == null)
   throw new ArgumentException("Invalid expression.");
  //переводим выражение обратно в Func
  var func = expr.Compile();
  //выполняем func, чтобы получить значение
  var value = func();
  return new Setting(me.Member.Name,value);
}

Вызов:

var settings = new List<Setting>();
settings.Add(GetSetting(() => Settings.EnableBugs));
settings.Add(GetSetting(() => Settings.EnableFluxCapacitor));

Заметьте, что нужно проверить, передано ли выражение типа MemberExpression (обращение к свойству), т.к ничто не мешает вызывающему коду передать любой другой подходящий делегат, тогда нельзя будет обратиться к .Member.Name.

Очевидно, это только малая толика того, на что способны деревья выражений.

Источник: https://chrisstclair.co.uk/6-lesser-known-features-of-c-net-that-you-should-be-using/

День пятьсот семьдесят второй. #TipsAndTricks
Повышаем продуктивность в Visual Studio.
32. Хитрости Ctrl+T
Есть много способов навигации по вашему решению. Мой любимый способ - это сочетание клавиш Ctrl+T (Edit > Go To > Go To All…). Вы можете искать всё, что хотите: файл, класс, свойство, поле или метод.

В этом окне есть несколько хитростей:
- Обычный поиск использует простую логику «содержит». Если файл/класс/член содержит текст из поля для поиска, он появится в результатах.
- Для элементов, написанных с помощью camelCase (или PascalCase), можно вводить только инициалы. Например, asdc найдёт AnotherSearchDemoComponent.
- Вы можете сузить поиск до определенных типов результатов:
f [строка] ищет только файлы
r [строка] ищет в недавних файлах
t [строка] ищет в типах
m [строка] ищет в членах
# [строка] ищет в символах

Источник: https://michaelscodingspot.com/productivity-tips-in-visual-studio/

День пятьсот семьдесят третий. #ЗаметкиНаПолях
Класс Path
Многие разработчики до сих пор выделяют расширение файла из имени вручную, когда есть встроенный класс Path, который имеет удобные методы, чтобы сделать это за вас. Класс находится в пространстве имен System.IO и содержит множество полезных методов, которые сокращают объем стандартного кода, который вам приходится писать. Многим известны такие методы, как Path.GetFileName и Path.GetExtension, которые делают именно то, что вы ожидаете (извлекают имя файла и расширение соответственно). Рассмотрим несколько менее популярных.

Path.Combine
Этот метод принимает несколько строк пути и объединяет их в один путь. Обычно это делают, чтобы добавить имя файла к каталогу:

directoryPath + "\" + filename

Проблема в том, что вы предполагаете, что разделителем каталогов в системе, в которой работает ваше приложение, является обратный слеш. Но в Unix используется прямой слеш. Это становится серьезной проблемой, поскольку .NET Core позволяет запускать приложения на большом количестве платформ. Path.Combine будет использовать разделитель каталогов, используемый в операционной системе, а также разберётся с избыточными разделителями (удалит дублирующие).

Path.GetTempFileName
Довольно часто бывает необходимо создать временный файл. Вам не важно имя или место хранения, вам просто нужно записать что-то в файл и через некоторое время прочитать оттуда. Можно написать этот код самостоятельно, но это будет утомительно и подвержено ошибкам. Path.GetTempFileName не принимает никаких параметров, он создаёт пустой файл во временном каталоге пользователя, и возвращает вам полный его путь. Поскольку файл находится во временном каталоге пользователя, Windows автоматически удалит его при необходимости, и вам не придётся беспокоиться о засорении системы избыточными файлами.

Path.GetInvalidPathChars / Path.GetInvalidFileNameChars
Path.GetInvalidPathChars и его собрат Path.GetInvalidFileNameChars возвращают массив всех символов, которые недопустимы для пути / имени файла в текущей системе. Я видел много кода, который вручную удаляет некоторые наиболее распространённые недопустимые символы, например, кавычки, но не удаляет другие недопустимые символы, что создаёт бомбу замедленного действия. И, если мы говорим о кросс-платформенности, неверно предполагать, что то, что недопустимо в одной системе, будет недопустимо в другой. Единственная проблема с этими методами в том, что они не позволяют проверить, содержит ли путь недопустимые символы. Из-за этого приходится писать подобные шаблонные методы:

public static bool IsValidPath(string path) {
  if (path == null)
    throw new ArgumentNullException(nameof(path));

  return path.IndexOfAny(Path.GetInvalidPathChars()) < 0;
}

Источник: https://chrisstclair.co.uk/6-lesser-known-features-of-c-net-that-you-should-be-using/

День пятьсот семьдесят пятый. #ЧтоНовенького
Новые функции Visual Studio 2019 v16.8 Preview 2
Интеграция с Git
В некоторых репозиториях содержится более одного решения. Теперь, когда вы откроете такой репозиторий, в обозревателе решений отобразится список решений, из которых вы можете выбрать. См. рис. 1 ниже. По умолчанию вверху располагается пункт «Просмотр папки» (Folder View). Он откроет корневую папку репозитория. Двойной щелчок по одному из решений в списке откроет решение. Кроме того, вы можете использовать кнопку «Переключить представления» (Switch Views) на панели инструментов проводника решений, чтобы вернуться к списку представлений и легко переключаться между решениями в репозитории. Если в вашем репозитории только одно решение, Visual Studio покажет его, а если решений нет, откроется вид просмотра папки.

Повышение продуктивности в .NET
Visual Studio продолжает перенимать крутые фишки Rider'a. На этот раз добавили встроенные подсказки имён параметров перед каждым аргументом в вызовах функций. См. рис. 2 ниже. Чтобы получить доступ к этой функции, нужно включить её в Инструменты > Параметры > Текстовый редактор > C# > Дополнительно (Tools > Options > Text Editor > C# > Advanced) и выбрать «Показывать встроенные подсказки имён параметров» (Display inline parameter name hints).

Кроме того, теперь вы можете извлекать члены из выбранного класса в новый базовый класс с помощью нового вида рефакторинга «Выделить Базовый Класс» (Extract Base Class). Чтобы попробовать это, поместите курсор либо на имя класса, либо на выделенный член. Нажмите Ctrl+., чтобы вызвать меню быстрых действий и рефакторинга. Оттуда выберите «Выделить член(ы) в новый базовый класс» (Pull member(s) up to new base class). Откроется новое диалоговое окно «Выделить Базовый Класс», в котором вы можете указать имя базового класса, место его размещения, выбрать элементы, которые хотите передать в новый базовый класс, и сделать их абстрактными, установив флажок в столбце «Сделать абстрактным» (Make abstract). См. рис. 3 ниже.

Еще одна функция рефакторинга - преобразование typeof в nameof. Использование nameof вместо имени типа позволяет избежать использования рефлексии для извлечения объекта. Поместите курсор на выражение typeof(<QualifiedType>).Name, нажмите Ctrl+. и выберите «Преобразовать 'typeof' в 'nameof'» (Convert 'typeof' to 'nameof'). См. рис. 4 ниже.

Источник: https://devblogs.microsoft.com/visualstudio/visual-studio-2019-v16-8-preview-2/

День пятьсот семьдесят шестой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
57. Послание в Будущее
В течение многих лет я преподавала и работала бок о бок с программистами. И, возможно, поскольку большинство из них были умными людьми, мне всегда казалось, что они думали так: «Так как проблемы, с которыми они сталкивались, были трудными, то и решения должны быть так же сложны для понимания остальными (возможно, даже для самих себя через несколько месяцев после написания кода).»

Я помню один случай с Джо, студентом моего курса структур данных, который должен был зайти и показать мне, что он написал:
– Спорим, не сможете догадаться, что делает код! – с порога заявил он.
– Ты прав, – согласилась я, не тратя времени на разбор его кода, а думая, как донести до него важную мысль. – Я уверена, что ты много над этим работал. Но мне интересно, не забыл ли ты кое-что важное. Скажи-ка, Джо, у тебя ведь есть младший брат?
– Да, конечно! Фил. Он учится на вашем вводном курсе. Тоже учится программировать! – гордо ответил Джо.
– Замечательно, - сказала я. – Интересно, сможет ли он понять этот код.
– Ни за что! – сказал Джо. – Это сложно!
– А теперь представь себе, – предложила я, – что это настоящий рабочий код, и что через несколько лет Фил устроится на работу и получит задание его изменить. Что ты для него сделал?

Джо просто уставился на меня и моргал.

– Мы знаем, что Фил очень умный, верно? – Джо кивнул. – И я очень не люблю это говорить, но я тоже довольно умная! – Джо усмехнулся. – Так что, если я не могу быстро понять, что ты здесь сделал, то и твой очень умный младший брат, вероятно, будет ломать голову над этим.

Мне показалось, что Джо несколько иначе стал смотреть на свой код.

– Давай поступим так, – предложила я максимально дружелюбно. - Думай о каждой строке кода, которую ты пишешь, как о послании для кого-то в будущем. Кого-то, кто может оказаться твоим младшим братом. Представь, что ты объясняешь этому умному человеку, как решить эту трудную задачу.
Как ты себе это представляешь? Наверняка, что умный программист в будущем увидит твой код и скажет: «Вау! Это круто! Я прекрасно понимаю, что здесь происходит, и меня поражает, какой это элегантный и красивый фрагмент кода. Я хочу показать остальным в моей команде. Это шедевр!»
Джо, как ты думаешь, сможешь ли ты написать код, который решает эту сложную проблему, но будет настолько красив, что будет петь? Да, как навязчивая мелодия. Я думаю, что любой, кто может придумать очень сложное решение, как, например, твоё, также мог бы написать что-нибудь красивое. Хм… А может мне стоит ставить оценки за красоту? Что скажешь?

Джо взял свою работу и посмотрел на меня с легкой улыбкой:
– Я понял, профессор, я собираюсь сделать мир лучше для Фила. Спасибо.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Linda Rising.

День пятьсот семьдесят седьмой. #Оффтоп #ЗадачиНаСобеседовании
В пандан ко вчерашнему посту про простоту и понятность решений, сегодня задачка на выходные.

Прямоугольная любовь
Команда учёных-любителей создала новый сайт знакомств. Отличительной особенностью его является инновационный способ представления профилей людей в виде прямоугольников на плоскости. Чем больше пересечение прямоугольников, тем больше у них шансов на успешные отношения.
Команде нужна помощь в написании алгоритма, находящего пересечение прямоугольников. Как показано на картинке ниже, стороны прямоугольников параллельны осям x и y.

Метод должен получать на вход 2 объекта класса Rectangle, имеющего свойства:
- координаты левой нижней точки
- длина
- ширина
На выходе должен получаться такой же объект Rectangle, представляющий собой пересечение.

Особенность этой задачи не в оптимизации по времени или памяти, а в получении результата, который работает, а главное легко читается. Многие могут описать решение на высоком уровне, но спотыкаются, когда вникают в детали. Поэтому:
1. Продумайте и нарисуйте все возможные варианты.
2. Используйте конкретные и информативные имена переменных.

Как обычно, приглашаю всех предлагать варианты решения в чате.

День пятьсот семьдесят восьмой. #Оффтоп
Чтобы скрасить последнее воскресенье лета, предлагаю вам небольшой ютубовский плейлист (он в настоящее время пополняется) о производительности LINQ. Немного… хотя нет, много байтодрочерства и микрооптимизаций, но всё равно довольно интересное объяснение внутреннего устройства популярного механизма C#, а также советы, чего следует избегать и как в отдельных случаях можно повысить его производительность, переопределив стандартные методы.

К сожалению, видео на английском, а автор поляк, поэтому качество английского (да и его речи вообще) оставляет желать лучшего. Но, несмотря на это, если вам интересны милли- и наносекунды, бенчмарк и вотэтовсё, наслаждайтесь.

C# LINQ Performance

День пятьсот семьдесят девятый. #Оффтоп #ЗадачиНаСобеседовании
Ответ на субботнюю задачу

Задача не очень сложная, главное грамотно разбить её на части.
Мы можем рассматривать «горизонтальное» пересечение прямоугольников (по оси x) отдельно от пересечения «по вертикали» (по оси y). Например, мы рассмотрим ширину прямоугольников как отрезки на одномерной числовой прямой x. Какие возможные случаи расположения этих отрезков?
1) Пересекаются частично
2) Один отрезок полностью содержится в другом
3) Не пересекаются
4) "Касаются" в одной точке
См. рисунок ниже.

Если рассматривать первые два варианта, можно заметить, что пересечение отрезков всегда начинается в точке старта с бОльшей координатой. Поэтому чтобы найти начало пересечения, выбираем максимум из значений S1 и S2. Аналогично конец пересечения будет в меньшей из точек E1 и E2.
Таким образом, найдя начало и конец отрезка, нам остаётся только узнать его длину. Если она положительная (конечная точка больше начальной), то пересечение есть, отрицательная – отрезки не пересекаются, нулевая – отрезки касаются.

static Segment Overlap(Segment s1, Segment s2)
{
  // начальная точка (максимальная из начальных)
  double start = Math.Max(s1.StartPoint, s2.StartPoint);
  // конечная точка (минимальная из конечных)
  double end = Math.Min(s1.StartPoint + s1.Length, s2.StartPoint + s2.Length);

  // отрезки не пересекаются
  if (start > end)
    return null;

  return new Segment(start, end - start);
}

В результате мы найдём отрезки пересечения по оси x и по оси y. Всё, что нам остаётся сделать – это совместить их. Начальные точки отрезков будут координатами левой нижней точки прямоугольника пересечения, длина отрезка по оси x будет шириной, а длина отрезка по оси y – высотой.

Замечание: в зависимости от условий задачи надо рассмотреть, допустимы ли варианты нулевых ширины и высоты (когда прямоугольники касаются сторонами, либо касаются в одной точке).

public static Rectangle RectangularOverlap(Rectangle r1, Rectangle r2)
{
  // пересечение по оси x
  Segment xOverlap = Overlap(
    new Segment(r1.StartPoint.X, r1.Width),
    new Segment(r2.StartPoint.X, r2.Width));
  // пересечение по оси у
  Segment yOverlap = Overlap(
    new Segment(r1.StartPoint.Y, r1.Height),
    new Segment(r2.StartPoint.Y, r2.Height));

  if (xOverlap?.Length >= 0 && yOverlap?.Length >= 0)
    return new Rectangle(
        new Point(xOverlap.StartPoint, yOverlap.StartPoint),
          xOverlap.Length,
          yOverlap.Length
        );

  // не пересекаются
  return null;
}

PS: я в коде использовал новый тип записи. Вот весь код объявления:

public record Point(double X, double Y);
public record Segment(double StartPoint, double Length);
public record Rectangle(Point StartPoint, double Width, double Height);

Можно использовать класс или структуру, но их описание со свойствами и конструкторами гораздо длиннее)))
PPS: да, в коде не хватает валидации исходных данных.
PPPS: строго говоря, решение можно слегка оптимизировать, не проверяя пересечение по y, если нет пересечения по x.

Источник: https://www.interviewcake.com/question/csharp/rectangular-love

День пятьсот восьмидесятый.
Вот и осень. С днём знаний всех причастных.

В юбилейный пятисотый день я рассказал об идее создания опенсорс проекта и спросил у вас, интересно ли вам в нём поучаствовать. Тогда я рассчитывал, что к осени я «разберусь» с экзаменом по ASP.NET MVC, но вот уж осень, а до экзамена мне ещё, как до Китая р… в общем, сейчас не об этом. Откликнулись очень многие, поэтому, как обещал, выкладываю подробности проекта.

Итак.

Часто у изучающих программирование вообще и С# и .NET в частности возникают подобные вопросы:
- «Я изучил основы (прочитал книгу XXX, посмотрел курс YYY), что дальше, куда копать?»
- «Стоит ли читать книгу A (проходить курс B)?»
- «Почему все ругают сайт M?»
Кроме того, меня уже не раз просили как-нибудь систематизировать посты на канале.

Так вот, у меня возникла идея проекта (веб-сайта) с рабочим названием «Путь разработчика». На сайте визуально будет представлен путь от стажёра до… не буду говорить сеньора... до профессионала в определённой области. На этом пути по шагам будут расписаны темы, обязательные для изучения, желательные, либо сторонние, но тоже полезные. Для каждой темы будет приведено краткое описание (если возможно) и набор источников, по которым её можно изучить, в виде ссылок: книги, статьи, руководства, курсы, видео и т.п. Помимо этого система позволит пользователям оценить качество каждого источника, оставить комментарий, а более «продвинутым» предложить свои источники.

Короче говоря, я хочу создать что-то похожее на довольно широко известную и, к сожалению безвременно покинувшую нас (но интернет всё помнит) «Карту знаний .NET Web программиста». А визуально это представить в виде интерактивного дерева, подобно проекту от Moien Tajik.

Можно начать с пути для ASP.NET, но расширять, конечно, можно до бесконечности, как по технологиям семейства .NET, так и в другие технологии, языки и системы. Кроме того, поскольку подавляющее большинство доступной информации на английском, есть идея сделать сайт мультиязычным с английским в качестве основного.

Важные замечания
1) Проект учебный, поэтому будет создаваться на .NET5, C#9 и Blazor (детали ещё обсудим) с целью изучения новых технологий на практике.
2) Проект учебный, "по обмену премудростями", читай некоммерческий (по крайней мере пока). Поэтому участие добровольное и бесплатное (в обе стороны). Зачем вам это может быть нужно, я описал в первоначальном посте.

Остальные детали можно обсудить. Но поскольку заинтересовавшихся было много, предлагаю делать это не в чате, а в более долговременном хранилище информации. Я не нашёл ничего лучше, чем GitHub (надеюсь, аккаунт есть у подавляющего большинства из вас). Подробное описание проекта будет здесь https://github.com/sbzenenko/DeveloperPathAbout/
Обсуждение предлагаю вести в Issues. Там уже открыто несколько тем. Если ваш вопрос не относится ни к одной из них, создавайте новую.

Жду ваших отзывов.

День пятьсот восемьдесят первый. #ЧтоНовенького
Полутип
Тип Half – это 16-битное число с плавающей точкой (эквивалент binary16 в спецификации IEEE 754). То есть это половина от float, и может представлять значения в диапазоне ±65504. Один из основных вариантов использования типа Half - экономия места для хранения, когда вычисленный результат не нужно сохранять с полной точностью. Многие системы уже используют преимущества типа Half: машинное обучение, графические карты, новейшие процессоры, нативные библиотеки SIMD и т.д.

16 бит в типе Half делятся на:
- Знак: 1 бит
- Экспонента: 5 бит
- Значимые биты: 10 бит (с 1 неявным битом, который не хранится)
Несмотря на то, что значение состоит из 10 бит, общая точность на самом деле составляет 11 бит. Предполагается, что формат имеет неявный начальный бит, равный 1 (если в поле экспоненты не все нули, в противном случае 0).

Вот так в формате Half представляется число 1:

0 01111 0000000000 = 1

- Ведущий бит (знак) равен 0 – положительное число.
- Биты экспоненты равны 01111 или 15 в десятичной системе. Биты экспоненты не представляют экспоненту напрямую. Вместо этого определяется смещение экспоненты, которое позволяет формату представлять как положительные, так и отрицательные значения экспоненты. Для типа Half смещение экспоненты равно 15. Истинная экспонента получается вычитанием:

e = 01111(или 15) - 15(смещение) = 0.

- Значение равно 0000000000. Оно представляет собой числитель дроби, в знаменателе которой 1024 (2^10). В нашем случае числитель равен 0. Но, если бы значение было, например, 0000011010 (26 в десятичной системе), то дробь представляла бы собой 26/1024 или 0,025390625.
- Наконец, поскольку биты экспоненты (01111) не все равны 0, у нас есть неявный ведущий бит 1.

Итого:

0 01111 0000000000 = 2^0 * (1 + 0/1024) = 1

Общая формула значения Half:

-1^(знак) * 2^(экспонента - 15) * (неявный бит + (значение/1024))

Особый случай для экспоненты 00000:

-1^(знак) * 2^(-14) * (0 + (значение/1024))

Примеры
Наименьшее положительное значение

0 00000 0000000001 = -1^(0)*2^(-14)*(0 + 1/1024) ≈ 0,000000059604645

Наибольшее число

0 11110 1111111111 = -1^(0)*2^(15)*(1+1023/1024) ≈ 65504

"Бесконечность"

1 11111 0000000000 = -Бесконечность
0 11111 0000000000 = +Бесконечность

Особенность формата в том, что он определяет как положительный, так и отрицательный 0:

1 00000 0000000000 = -0
0 00000 0000000000 = +0

Преобразования в/из float/double

float f = (float)half;
Half h = (Half)floatValue;

Любое значение Half может быть представлено как float/double без потери точности. Однако обратное неверно.

В .NET 5.0 тип Half - это прежде всего промежуточный тип, для которого не определены арифметические операторы. Он поддерживает только парсинг, форматирование и сравнение. Для всех арифметических операций потребуется явное преобразование в float/double. В будущих версиях будет рассмотрено добавление арифметических операторов непосредственно в Half и использование его в вычислениях напрямую.

Источник: https://devblogs.microsoft.com/dotnet/introducing-the-half-type/

День пятьсот восемьдесят второй. #TipsAndTricks
Повышаем продуктивность в Visual Studio.
33. Фильтр Решения
В крупном корпоративном приложении у вас может быть и 20, и 30 проектов, и иногда вам не нужно загружать их все. В Visual Studio 2019 вы можете выгрузить эти проекты, затем щелкнуть правой кнопкой мыши на решении, и выбрать пункт «Сохранить как Фильтр Решения» (Save as Solution Filter). Укажите имя, и сохраните файл. Если вы откроете файл фильтра решения, студия не загрузит выгруженные проекты.

34. Повторное использование кода
Допустим, вы хотите повторно использовать фрагмент кода. Это легко сделать, выбрав соответствующий фрагмент, и сохранить его на панели инструментов (Toolbox). Чтобы открыть Toolbox, нажмите Ctrl+Alt+X, выберите фрагмент кода и просто перетащите его туда.

Источник: https://devsuhas.com/2020/01/19/visual-studio-2019-tips-and-tricks/