Теория. Работа с размерностями знач. в переменных программ

[resident]

Будешь хранить как килограммы на кубометры? или килограммы на килограммы?

Не будешь, а уже храню [кг/кг] и бед не знаю.

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

Пусть будет пол квадрата = 0.5e-6.
Вас пугает такое число?

ТС хочет сперва рассчитать размеры между электронами отдельного атома, а затем, внезапно, подсчитать сколько времени потребуется улитке, чтобы доползти до края галактики.

Это уже не инженерка.
Никогда не лез в такие границы. Посмотрим:
Атом

Соответственно, самый маленький атом — это атом гелия, имеющий радиус 32 пм

32е-12 [м]
Галактика

Самая большая известная (на 2012 год) галактика IC 1101 имеет диаметр более 600 килопарсек

3е19 [м]

Паскаль - Variables and Data Types

Extended 1.9E-4932 .. 1.1E4932

Т.е. тип данных Паскаля может хранить длины с СИ размерности в
100000000000000000000000000000...и т.д. 4919 нулей! раз меньше размера электрона и в тоже время в
100000000000000000000000000000...и т.д. 4911 нулей! раз больше размера самой большой галактики.

Или я чет не понимаю, или тут собрались дикие теоретики, незнающие в какую сторону отвинчивается гайка, или вся тема и обсуждение - провокация.

[Лекс Айрин]

Или я чет не понимаю, или тут собрались дикие теоретики, незнающие в какую сторону отвинчивается гайка,

например, в точности. Иногда, манипулирование в диапазоне 0,0000...тысяча и один нуль...002 /0,0000...тысяча и один нуль...09 чревато как ошибками (например, тупо при копипасте или перекодировании), так и излишним размером переменной под хранение. И не забываем, что тип реал, если что не всегда обеспечивает достаточную точность -- это приблизительный тип, а при вычислениях хотелось бы сохранять как можно большую точность. Особенно, для малых величин.

Не будешь, а уже храню [кг/кг] и бед не знаю.

угу... а то, что 0,0004 кг/кг, допустим, требует минимум single (4 байта), а 4 промиле всего лишь байта(реже слова, смотря где сменять размерность) это, конечно так, фигня. И ладно, если у тебя 5-10 значений... а если сотни?

[resident]

тупо при копипасте

Ошибки при копипасте? Нет, не знаю

перекодировании

Точно такие же ошибки будут при перекодировании в другой системе автора, основанной на записях, дженериках или еще чем-либо.

так и излишним размером переменной под хранение

Не вирусы же пишем.
Ок. Цена разработки продукта, экономящего ОЗУ, против цены самого ОЗУ. Тут уж автору/работодателю видней.
Но 2016 год. Не компьютеры, сотовые телефоны с 8 гектарами оперативки являются стандартом.

[wavebvg]

А почему никто не рассматривает практическое решение?

Видятся следующие возможных решения:

1. Через Variant - там будет немного неудобно получать текущую единицу измерения, будут некоторые условности и код не очень прозрачный получится.
2. Через Object
Задаем типы и методы работы с ними

Код: Выделить всё

type
TWayDim = (wdM, wdMM);
TWay = object
private
FValue: Double;
FDim: TWayDim;
procedure SetDim(const AValue: TWayDim);
public
procedure Assign(const ASource: TWay);
property Value: Double read FValue write FValue;
property Dim: TWayDim read FDim write SetDim;
end;
function GetWay(const AValue: Double; const ADim: TWayDim = wdM): TWay;


Переопределяем стандартные операции, чтобы размерность в получателе не изменялась (а значение, по умолчанию, бралось в СИ)

Код: Выделить всё

operator := (constref AArg: TWay): TWay;
operator := (constref AArg: Double): TWay;
operator := (constref AArg: TWay): Double;


3. Через создание своего типа для каждой единицы измерения:
type
TWayDimM = record
Value: Double;
end;
TWayDimMM = record
Value: Double;
end;
И переопределение стандартных операций:

Код: Выделить всё

operator := (constref AArg: TWayDimM): TWayDimMM;
operator := (constref AArg: TWayDimMЬ): TWayDimM;
operator := (constref AArg: Double): TWayDimMM;
operator := (constref AArg: TWayDimMM): Double;


4. Через интерфейсы

Код: Выделить всё

type
TWayDim = (wdM, wdMM);
IWay = interface
[GUID]
...
procedure SetDim(const AValue: TWayDim);
...
procedure Assign(const ASource: IWay);
property Value: Double read GetValue write SetValue;
property Dim: TWayDim read GetDim write SetDim;
end;
function GetWay(const AValue: Double; const ADim: TWayDim = wdM): IWay;


[Лекс Айрин]

Точно такие же ошибки будут при перекодировании в другой системе автора, основанной на записях, дженериках или еще чем-либо.

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

Не вирусы же пишем.
Ок. Цена разработки продукта, экономящего ОЗУ, против цены самого ОЗУ.

не вирусы... там "стандарты" еще строже. И не стоит считать, что ОЗУ такая уж дешевая вещь. С учетом того, что программа работает не одна и манипулировать приходится тысячами переменных... может случиться и так, что экономия вполне рентабельна.

[azsx]

тут собрались дикие теоретики,

Вот потому я в тему и не лез, я чуял, что истина где то рядом. Мне также не нужны такие огромные цифры, но если бы мне понадобилось решать такую задачу - то в данном виде я решил бы ее через СИ + форматированный вывод (можно через функции). Спасибо за расчеты.
Проблема по сложности меньше, чем о ней написано в топике. Экономия памяти не аргумент, требуется удобный инструмент для программиста, никто не писал, что надо на 64 кб Вояджер запустить.

[Лекс Айрин]

Экономия памяти не аргумент, требуется удобный инструмент для программиста, никто не писал, что надо на 64 кб Вояджер запустить.

угу.. "640 килобайт хватит всем и для всего."...Если что, то есть шанс начать писать операционку для нанопыли. А это снова ограничение памяти для отдельного пикоядра... причем, как раз в строительстве ее применение оправдано уже вчера.

[zub]

Т.е. тип данных Паскаля может хранить длины с СИ размерности в
100000000000000000000000000000...и т.д. 4919 нулей! раз меньше размера электрона и в тоже время в
100000000000000000000000000000...и т.д. 4911 нулей! раз больше размера самой большой галактики.

Или я чет не понимаю, или тут собрались дикие теоретики, незнающие в какую сторону отвинчивается гайка, или вся тема и обсуждение - провокация.

Тут важно не конкретное количество нулей, а диапазон участвующих в вычислениях величин. Т.е. грубо говоря в диапозоне [10..11] и [10000000000..10000000001] разрешающая способность очень разная и в результате элементарного 10000000000+0.1 погрешность будет гораздо больше чем в результате 10+0.1
Погрешность начинает копится гораздо раньше чем подходишь к границе типа данных - это нужно учитывать когда хочешь сделать вычисления нечувствительными к большому диапазону входных значений.
Но это не значит что нужно хранить размерности вместе со значениями, нужно оптимизировать расчетные формулы минимизируя погрешности и переполнения

[resident]

в результате элементарного 10000000000+0.1 погрешность будет гораздо больше чем в результате 10+0.1

Чего то я вас не пойму. Почему вы рассматриваете различные цифры, в смысле почему в первом сложении участвуют цифры отличающиеся в 100000000000, а во втором в 100 раз?
Тогда уж второе сложение будет выглядеть 10+0.0000000001, и чем тогда первое будет отличаться от второго?
1е10+1е-1
1е1+1е-10

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

Мантиса слагаемых одинакова и при 1е10+1е-1 и при 1е1+1е-10? Если одинакова, тогда о чем речь.

Что нужно знать про арифметику с плавающей запятой

С ошибками из-за погрешностей округления в современной арифметике с плавающей запятой встретиться сложно, особенно если использовать двойную точность.

Так что лучше не ниже Double использовать. А Single, у него в названии уже намек на AS IS. Если уж и заморачиваться, то над этим:

Для многих широко распространенных математических формул математики разработали специальную форму, которая позволяет значительно уменьшить погрешность при округлении. Например, расчет формулы «x2-y2» лучше вычислять используя формулу «(x-y)(x+y)».

[Лекс Айрин]

Мантиса слагаемых одинакова и при 1е10+1е-1 и при 1е1+1е-10? Если одинакова, тогда о чем речь.

а при чем тут мантисса? Это лишь удобная форма записи некоторых чисел, не более. И не всегда его так можно записать без округления. Иногда довольно сильного.

С ошибками из-за погрешностей округления в современной арифметике с плавающей запятой встретиться сложно, особенно если использовать двойную точность.

http://pandia.ru/text/79/517/8625.php

...
Рассматривается ошибка в FPU процессоров Intel Pentium Pro

и Intel Pentium II, названная Dan-0411 (в Intel Corporation – Flag Erratum) и связанная с преобразованием 80-и разрядного

числа в формате с плавающей запятой в форматы 16-и и 32-х

разрядных целых чисел. Описана суть данной ошибки, а также история обнаружения и исследования. Выполняется исследование на наличие этой ошибки в вышеуказанных процессорах, а также в процессорах, популярных в нашей стране сегодня. Описывается основная идея создания программы на языке ассемблера для исследования этой ошибки. Приведен текст одного из вариантов такой программы, а также результаты ее выполнения на компьютерах с различными процессорами. Данная статья поможет подробно узнать об ошибке Dan-0411, позволит иследовать ее наличие в выбранном процессоре с помощью приведенной программы. При обнаружении этой ошибки статья поможет учесть результаты ее проявления при написании приложений.
...

Если уж и заморачиваться, то над этим:

ключевые слова :

значительно уменьшить погрешность при округлении.

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

Даже в математических пакетах, где вычисления производятся после упрощения формул, ответ не всегда верен.

[azsx]

(640*1024)/4 = 163840 переменных. Скажите, пожалуйста, 1. зачем в нано пыли столько переменных? 2. Почему в нано пыли мы юзаем лазарус, а не С?

[Лекс Айрин]

azsx, потому что нанопыль должна программироваться на двух уровнях. Первый на уровне наноядра, а второй уровень это полноценное управляющее ядро, под которым можно запускать нормальное ядро и программировать его через внешний интерфейс хоть в си, хоть в паскале, хоть напрямую мозгом. Но так как обработка все равно будет проводиться в отдельных ядрах, то нужно как минимум, реализовать в каждой пылинке достаточный объем памяти для текущих нужд и обработки. И неизвестно сколько связей понадобится для поддержки связности метаОС.

И, кстати, не стоит так принижать паскаль... В конце-концов, на нем писали, как минимум, один из компиляторов С. Да и когда писали винду, то она не была настолько уж глючной.

[azsx]

кстати, не стоит так принижать паскаль...

Извините, но я не принижаю паскаль. Просто констатирую факт. Сегодня априори считается, что ентерпрайз веб сервис должен быть на джава, а встраиваемые устройства должны быть на С. Есть устройства на других языках, но 1. они всё равно поддерживают С; 2. это какие-то весьма редкие устройства.
По мне ОС на нано пыль - это фантастика, её можно обсудить за литром. А вот программирование взаимодействующих устройств - это вполне интересно. Нужны какие-то недорогие устройства с поддержкой паскаль и идея, что ними сделать.

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

два раза, да ладно??? Можно хоть названия, чего искать.

[Лекс Айрин]

Сегодня априори считается, что ентерпрайз веб сервис должен быть на джава, а встраиваемые устройства должны быть на С.

По большому счету, это все мода. С надно... а вот ява вполне может пошатнуться в ближайшие лет пять.

По мне ОС на нано пыль - это фантастика, её можно обсудить за литром.

Зря... перспективы оченно широкие... особенно в медицине. Конечно, не на начальном этапе, но все же...

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

Собственно, все зависит от размера устройств и их универсальности. А диапазон применений велик -- от контроллера утюга, до видеостен.

[Снег Север]

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

Как человек отдавший около десятка лет жизни научным расчетам и дискретной математике замечу, что методы, позволяющие бороться с накоплением ошибок округления были разработаны еще во времена БЭСМ-2... Надо только их знать и правильно применять. Не складывать, например, нанометры с мегаметрами - это не имеет физического смысла.