Понятно, что не имеет смысла (это только строго математически важно). Я скорее для понимания хотел добавить, что то, что выглядит разным в десятичном представлении, может быть одинаковым в двоичном.
double d = 0.1f;
float f = 0.1f;
Assert.True(d == f);//значения равны
Assert.False(d.ToString() == f.ToString());//представления не равны
Доброго дня, мне кажется есть небольшая путаница при разборе таких чисел в 10-м представлении таких чисел. (Разберу для double) Рассмотрим ряд для 52 бит в двоичной системе: 0.1, 0.11, 0.111 ... 0.111..11{52 еденицы} им соответствуют десятичные: 0.5, 0.75, 0.875 ... 0,999..75{тоже 52 цифры!!!} то есть каждый бит в двоичной дроби - добавляет разряд в десятичной системе. И здесь и есть точное равенство двоичного представления. Но представление в десятичное системе (как в статье) - обрежет и округлит их до 16 цифр в десятичном представлении. Это мы и видим во всем операциях-представлениям в статье все выводы в консоль - это десятичные представления округленные. Точность в 16 знаков говорит о том, что изменяя любые цифры в числе выше (0,999..75) после 16-го знака в двоичной системе, нам будет давать то же самое число в переводе в двоичную систему. (На примере из статьи - можно сколько угодно добавлять знаков к десятичному представлению после 16-го символа). Поэтому для все конвертеры в десятичную строку и занимаются округлением.
Если отметить, как в статье, 0.1 в десятичной - бесконечная дробь в двоичной системе, то понятно почему 0.1f != 0.1d. (т.к. 0.00011001100..001{24 цифры для float} != 0.00011001100..001 {52 цифры для double}).
Может немного муторно написал, но хотел пояснить вот что: 0.1f - после перевода компилятором в двоичную будет выглядеть так: 0.000110011001100110011001101. Оно же в 10-й (в точности): 0.100000001490116119384765625 Представим, как это делает ToString(): 0.1 - это округление для float 0.10000000149011612 - округление для double, хотя число одно и тоже в двоичном виде и целиком влезает во float и double. (можно проверить (double)(0.1f) == 0.1f).
У военных есть тысячные (в нато схожие милы). И там по угловым размерам объектов (их можно в биноклях, прицелах смотреть как насечки) и их реальным размерам можно высчитывать расстояния.
На скриншоте .doc - закрытый, проприетарный формат. А в комментариях про .docx - открытый и поддерживаемый большинством офисных программ - по идее давно пора документы на него перевести.
PS .doc - зачастую тоже отвратительно в Libre открывается, таблицы и картинки едут.
А почему неподвижный наблюдатель не может быть неподвижен относительно центра масс? Зачем выбирать другой центр координат, который еще и по каким-то правилам (каким, например?) движется относительно центра масс? Траектория в любом случае будет неподвижной — это фиксация точки в момент времени. В другой системе координат она просто будет другая, но все еще неподвижная.
Все точки траектории в системе координат относительно центра масс, почему должна сместиться любая точка траектории тела в момент времени t0, с координатами x0, y0, z0?
Интересное отношение числа резюме к вакансии. Сначала я подумал, что кадров больше, чем рабочих мест. Но думаю, что многие «резюме» сейчас работают, и закрытие одной вакансии с высокой вероятностью откроет другую. Поэтому пока не понял назначения этой цифры.
Согласен — такое объяснение сработает только в целых числах. В случае деления километров и бананов превратиться в:
Итого первую тысячу (5 бананов на км) мы потратим за 200 км. вторую за 333.(3), ну и последнюю 1000 везем оставшиеся 466.(6) км, значит с тысячи довезем 533,(3). При условии «непрерывного потребления» в конце.
Про бананы мне кажется можно проще объяснить, чем через функции. Пока условно предположим, что перевозим максимум на 1 км. потом возвращаемся. На первые километры тратится по 5 бананов на километр (пока не останется 2000, или потратить 1000), затем по 3 (пока не останется 1000 или снова потратить 1000) и дальше по одному.
Итого первую тысячу (5 бананов на км) мы потратим за 200 км. вторую за 333 (1 банан теряем так как его перевозка дороже его самого) ну и последнюю 1000 везем оставшиеся 467км, значит с тысячи довезем 533.
Стрелочки работают в прямом и обратном направлении. Если я публикую открытый ключ -то все им шифруют, а расшифровать могу только я. При этом, когда я что-то шифрую закрытым ключом, то все могут расшифровать сообщение открытым и убедиться, что это именно я зашифровал.
Они станут синхронизированными, только когда скорости уравняются
Да этот момент не указал, конечно разбор возможен после того как флеш выключит свои способности и будет стоять и сверять часы с оппонентом
Поскольку именно Флэш разгоняется и тормозит, то окажется, что по его часам пройдёт меньше времени, чем по часам обычного наблюдателя.
Утрируя на часах флеша показал пару секунд, на часах наблюдателя на земле пару дней.
Само способности — могут противоречить, а вот их эффект (замедление времени) — нет.
Тогда почему замедление времени не противоречит СТО? То есть он побегал в своем времени пару секунд, по комиксу у остальных (на часах) -прошли микросекунды, по СТО пару дней.
Здесь мог бы только согласиться с предыдущим комментарием, про то, что флеш и 10% скорости света не достигает тогда релятивистских эффектов вообще не получается. Но статься про обратное.
Судя по комиксам, как по мне, все вокруг флеша медленное, он двигается быстро, а вокруг — все как бы тормозит. С точки зрения СТО, если я (как флеш) двигаюсь быстро (около световой скоростью), то в моей СО я только поднял руку (пара секунд), а на земле несколько лет прошло. Поэтому не совсем понял как эффект замедления не противоречит СТО?
Чтобы оставаться недалеко от горизонта событий, нужно двигаться почти со скоростью света, чтобы не пройти внутрь случайно. Мне интересен другой вопрос: Для достаточно крупной массы при приближении к черной дыре я своей гравитацией буду делать "ямку" на ее горизонте. Ну по крайней мере на видео симуляциях слияний черных дыр горизонт немного "смещается" к центру. Почему нельзя рассматривать такой способ заглянуть за горизонт?
Сколько же мы намучились с ним.
Техподдержка действительно не адекватна, мы отправляли несколько примеров исходного кода с проблемой, но проблему как ни странно не признали, хотя и предложили перейти на старшую версию (тогда 7.1), переход исправлял только мелкие косяки, но ни одного существенного для нас.
Обновления выпускались раз в 3-4 года.
Проблемы с памятью (при подключении некоторых библиотек, работающих с не managed памятью, регулярно начинают лететь Win32Exception) и зависания — это главный косяк, для него мы тоже оправляли сценарий в поддержку, и ничего.
Некоторые варианты работы со стилями — сильно отличают его от десктоп версии MapInfo — одни и те же слои просто выглядят по разному (например, если в стилях есть полупрозрачность).
С 8-й версией не работали, но ребята счастливы, что слезли с него.
Еще и проблемы с лицензированием,, оплата за каждую установленную версию (тогда было около $600, плюс очень недешевая разработческая), и сам способ этой регистрации отбил у нас все желание продолжать с ним работать.
Среди прочего не было локализации.
Итого нестабильная библиотека, с проблемной регистрацией, довольной дорогая, и неэффективной техподдержкой, бегите от них.
У меня на одной литиевой батарейке уже два года работает датчик наружной температуры. Показывал до -38 и может и больше бы показал, но видимо не было холоднее.
Понятно, что не имеет смысла (это только строго математически важно). Я скорее для понимания хотел добавить, что то, что выглядит разным в десятичном представлении, может быть одинаковым в двоичном.
double d = 0.1f;float f = 0.1f;Assert.True(d == f);//значения равныAssert.False(d.ToString() == f.ToString());//представления не равныДоброго дня, мне кажется есть небольшая путаница при разборе таких чисел в 10-м представлении таких чисел. (Разберу для double)
Рассмотрим ряд для 52 бит в двоичной системе:
0.1, 0.11, 0.111 ... 0.111..11{52 еденицы} им соответствуют десятичные:
0.5, 0.75, 0.875 ... 0,999..75{тоже 52 цифры!!!} то есть каждый бит в двоичной дроби - добавляет разряд в десятичной системе. И здесь и есть точное равенство двоичного представления.
Но представление в десятичное системе (как в статье) - обрежет и округлит их до 16 цифр в десятичном представлении. Это мы и видим во всем операциях-представлениям в статье все выводы в консоль - это десятичные представления округленные.
Точность в 16 знаков говорит о том, что изменяя любые цифры в числе выше (0,999..75) после 16-го знака в двоичной системе, нам будет давать то же самое число в переводе в двоичную систему. (На примере из статьи - можно сколько угодно добавлять знаков к десятичному представлению после 16-го символа). Поэтому для все конвертеры в десятичную строку и занимаются округлением.
Если отметить, как в статье, 0.1 в десятичной - бесконечная дробь в двоичной системе, то понятно почему 0.1f != 0.1d. (т.к. 0.00011001100..001{24 цифры для float} != 0.00011001100..001 {52 цифры для double}).
Может немного муторно написал, но хотел пояснить вот что:
0.1f - после перевода компилятором в двоичную будет выглядеть так:
0.000110011001100110011001101. Оно же в 10-й (в точности):
0.100000001490116119384765625
Представим, как это делает ToString():
0.1 - это округление для float
0.10000000149011612 - округление для double, хотя число одно и тоже в двоичном виде и целиком влезает во float и double. (можно проверить (double)(0.1f) == 0.1f).
У военных есть тысячные (в нато схожие милы). И там по угловым размерам объектов (их можно в биноклях, прицелах смотреть как насечки) и их реальным размерам можно высчитывать расстояния.
На скриншоте .doc - закрытый, проприетарный формат. А в комментариях про .docx - открытый и поддерживаемый большинством офисных программ - по идее давно пора документы на него перевести.
PS .doc - зачастую тоже отвратительно в Libre открывается, таблицы и картинки едут.
Еще есть такая связь у времен суток: "Утренник" - мероприятие, "Дневник" - тетрадь, "Вечерник" - ученик, "Ночник" - светильник.
Не будет, 746.6 и 747.4 разброс при округлении тот же.
Все точки траектории в системе координат относительно центра масс, почему должна сместиться любая точка траектории тела в момент времени t0, с координатами x0, y0, z0?
Приложение госуслуги, рейтинг 4.6 (на Play Market). Похоже они считают, что их приложение единственное.
Итого первую тысячу (5 бананов на км) мы потратим за 200 км. вторую за 333.(3), ну и последнюю 1000 везем оставшиеся 466.(6) км, значит с тысячи довезем 533,(3). При условии «непрерывного потребления» в конце.
Итого первую тысячу (5 бананов на км) мы потратим за 200 км. вторую за 333 (1 банан теряем так как его перевозка дороже его самого) ну и последнюю 1000 везем оставшиеся 467км, значит с тысячи довезем 533.
Да этот момент не указал, конечно разбор возможен после того как флеш выключит свои способности и будет стоять и сверять часы с оппонентом
Утрируя на часах флеша показал пару секунд, на часах наблюдателя на земле пару дней.
Тогда почему замедление времени не противоречит СТО? То есть он побегал в своем времени пару секунд, по комиксу у остальных (на часах) -прошли микросекунды, по СТО пару дней.
Здесь мог бы только согласиться с предыдущим комментарием, про то, что флеш и 10% скорости света не достигает тогда релятивистских эффектов вообще не получается. Но статься про обратное.
Судя по комиксам, как по мне, все вокруг флеша медленное, он двигается быстро, а вокруг — все как бы тормозит. С точки зрения СТО, если я (как флеш) двигаюсь быстро (около световой скоростью), то в моей СО я только поднял руку (пара секунд), а на земле несколько лет прошло. Поэтому не совсем понял как эффект замедления не противоречит СТО?
Чтобы оставаться недалеко от горизонта событий, нужно двигаться почти со скоростью света, чтобы не пройти внутрь случайно. Мне интересен другой вопрос: Для достаточно крупной массы при приближении к черной дыре я своей гравитацией буду делать "ямку" на ее горизонте. Ну по крайней мере на видео симуляциях слияний черных дыр горизонт немного "смещается" к центру. Почему нельзя рассматривать такой способ заглянуть за горизонт?
Техподдержка действительно не адекватна, мы отправляли несколько примеров исходного кода с проблемой, но проблему как ни странно не признали, хотя и предложили перейти на старшую версию (тогда 7.1), переход исправлял только мелкие косяки, но ни одного существенного для нас.
Обновления выпускались раз в 3-4 года.
Проблемы с памятью (при подключении некоторых библиотек, работающих с не managed памятью, регулярно начинают лететь Win32Exception) и зависания — это главный косяк, для него мы тоже оправляли сценарий в поддержку, и ничего.
Некоторые варианты работы со стилями — сильно отличают его от десктоп версии MapInfo — одни и те же слои просто выглядят по разному (например, если в стилях есть полупрозрачность).
С 8-й версией не работали, но ребята счастливы, что слезли с него.
Еще и проблемы с лицензированием,, оплата за каждую установленную версию (тогда было около $600, плюс очень недешевая разработческая), и сам способ этой регистрации отбил у нас все желание продолжать с ним работать.
Среди прочего не было локализации.
Итого нестабильная библиотека, с проблемной регистрацией, довольной дорогая, и неэффективной техподдержкой, бегите от них.