В вашем тоже есть, только вы, может быть, не знаете, как его указать в визуальном интерфейсе.

Если при создании поля в конструкторе таблицы выбрать тип поля "числовой" и размер поля "двойное с плавающей точкой" - то то,
что получится в итоге - будет полем фиксированного размера с типом binary_double

А если в типе поля указать "числовой", а в размере сказать "действительное",
то ему можно задавать "точность" вплоть до 28, и тогда то, что получится, будет Numeric полем.

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

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




просто number создастся как binary_double, а p1 и p2 как "действительные" .

с просто указанием numeric/decimal есть одна проблема - оно тогда создается как numeric(18,0)
Хотя надо учесть что с ними были ранее проблемы ( районе access 2000-2003) с сортировкий и выгрузкой в текстовый формат.
Насчет varbinary(28) в общем это перехлест, в любом случае должно хватать и 17 байт для хранения любого значения,
вычисленного в cdec-арифметике.
Дальше весь вопрос в том - нужны ли они вам именно как числа при манипуляции с записями в таблице бд.


PS
В некоторых других системах указание Numeric без указания точности и шкалы, приводит к тому, что можно записывать вообще любое вычислимое в типе значение, но ms access в этом месте ведет себя иначе.

Иван FXS,

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

Успехов в трудах.

Нет, трепет "шумящего железа", когда был, сводился, главным образов к битве между тупоконечниками и остроконечниками по вопросу о том, как правильно писать циклы.
Надо ли формулировать условие завершения while i < n, разрешив программе вернуть недостоверный результат расчета суммы массива,
в результате преждевременного "шумящего" перескока i через n,
или правильно написать while i <> n, разрешив при таком происшествии программе впасть в бесконечный цикл,
может быть, вплоть до авоста по перебору разрядности i.
Тогда становится "совершенно понятно", что такой перескок несомненно был, и расчет надо запустить заново.
Такой спор вряд ли может завершиться за разумное время.

Касательно чисел двойной точности, примерно так история лежала, и vba самого по себе она не касается,
а касается написания программ на c/c++,
но все-таки это история, о которой хотя бы из любопытства можно иметь какое-то представление:

В какой-то момент, если не ошибаюсь, в районе разработки pentium-5, в стандарт были внесены дополнения, касающиеся специального представления особо малых числе в районе нуля.
Сопроцессорная часть этого процессора, с самого начала разрабатывалась под эти "уточнения".
А дальше получилось вот что - математика для binary double всегда имела две реализации - "библиотечную" и "машинную".
традиционно в компиляторах c/c++ если не использованы прагмы, выбор определялся выбором уровня оптимизации кода при компиляции.
"библиотечную" часть к выходу процессора никто не правил.
А способ сохранения значения регистров при вызове функции из текущего куска кода зависел от того, какая математика использовалась.
Вы могли получить два равных малых значения, вычисленных в другой библиотеке, скомпилированной под использование
"машинной" арифметики, затем вызвать любую функцию и затем зачем-то сравнить снова два ранее уже сравнивавшихся значения.
В зависимости от того, что происходило с регистрами, содержащими эти значения - вытеснялись их предыдущие значения или нет,
вы могли получить что угодно - они могли сохранить свои исходные значения, оба обнулиться или обнулиться только какой-то один из них.

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

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

где-то оно может и "просто биты", но не в числах двойной точности.

"просто биты" - не имеют типа, и, в этом смысле, сами по себе не являются значением .

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

Иван FXS,

8-байтный double и на 16 и на 32 разрядной машине занимает более одного регистра.
вот 32 разрядная машина, занято два регистра, а вам нужен сейчас, допустим, всего один из них для вызова дочерней функции, в кишках которой может потребоваться и второй.
В общем случае, вы не можете в такой ситуации сохранять 64-битное значение, сидящее в 2х регистрах кусками,
и кто-то должен сказать - "эй, это значение сломается, если освободить только один регистр".

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

И да, проверка типа при присвоении несомненно происходит, весь вопрос когда.
В компилируемых языках - на этапе компиляции, в интерпретируемых на этапе фактического присвоения.
В норме, кстати это не может происходить с помощью Move - move связан с передачей владения значением.
Присвоение значений простых типов всегда осуществляется копированием.

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

субнормальные числа.
И, с версией сопроцессора я ошибся, это был еще 8087

https://ru.wikipedia.org/wiki/Денормализованные_числа

Не равно самому себе, это когда a <> a

В полной мере vba не даст вам насладиться этой этой темой, но на коротке, путем подглядывания в содержимое переменных на панели locals, можно, например, так:

Собственно классическая история про этот тип выглядит так:
запустить в пошаговом режиме test_double_calc и наблюдать за происходящим:



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

Код в предыдущем посте получился с дефектом, не влияющим на фактическое поведение, но вот замена с добавлением пары фрагментов.
он, конечно, хрупкий, благодаря "особой безопасности" vba, но в самый общий курс дела приблизительно вводит.

Иван FXS,

для NaN по стандарту не существует понятия равенства самому себе.
Но это нельзя показать в Vba

Он настроен на то, что при обращении с ним без "хакерства", NaN не может быть получен ни при каких обстоятельствах.
У вас там точно все без "хакерства"?