标签: floating-point

对于一个项目，我创建了一个带有列的表price MONEY NOT NULL。而且我认为它会正确处理小数，与浮点数（即 IEEE 舍入问题）不同，但我最终$9.94从数据库返回了像（字符串）这样的值，而不是9.94（数字）。必须通过删除美元符号来手动操作字段值是愚蠢的；有没有办法让一MONEY列没有货币符号？

如果不是，处理货币价值的最佳数据类型替换是什么？

让我说出显而易见的拳头：我完全理解浮点类型不能准确表示十进制值。这不是关于那个！尽管如此，浮点计算应该是确定性的。

既然这已经解决了，让我向您展示我今天观察到的奇怪案例。我有一个浮点值列表，我想总结一下：

CREATE TABLE #someFloats (val float);
INSERT INTO #someFloats (val) VALUES (1), (1), (1.2), (1.2), (1.2), (3), (5);

SELECT STR(SUM(#someFloats.val), 30, 15) FROM #someFloats;

DROP TABLE #someFloats;

-- yields:
--   13.600000000000001

到目前为止，一切都很好 - 这里没有惊喜。我们都知道1.2不能用二进制表示来精确表示，所以“不精确”的结果是意料之中的。

现在，当我左加入另一个表时，会发生以下奇怪的事情：

CREATE TABLE #A (a int);
INSERT INTO #A (a) VALUES (1), (2);

CREATE TABLE #someFloats (val float);
INSERT INTO #someFloats (val) VALUES (1), (1), (1.2), (1.2), (1.2), (3), (5);

SELECT #A.a, STR(SUM(#someFloats.val), 30, 15)
  FROM #someFloats LEFT JOIN …

double precision从( float8) 到numeric四舍五入到 15 个有效小数位的转换，从而丢失信息。显然，更高的精度是可能的。转换为bigint（对于其范围内的值）可以保留更高的精度：

SELECT f8          AS float8
     , f8::bigint  AS to_bigint
     , f8::numeric AS to_numeric
FROM  (
   VALUES
     ('8217316934885843456'::float8)
   , ('8217316934885843457')
   , ('8217316934885844479')
   , ('8217316934885844480')   
   , ('8217316934885845503')
   , ('8217316934885845584')   
   ) t(f8);

        float8         |      to_bigint      |     to_numeric      
-----------------------+---------------------+---------------------
 8.217316934885843e+18 | 8217316934885842944 | 8217316934885840000
 8.217316934885844e+18 | 8217316934885843968 | 8217316934885840000
 8.217316934885844e+18 | 8217316934885843968 | 8217316934885840000
 8.217316934885845e+18 | 8217316934885844992 | 8217316934885840000
 8.217316934885845e+18 | 8217316934885844992 | 8217316934885840000
 8.217316934885846e+18 | 8217316934885846016 | 8217316934885850000
(6 rows)

db<>在这里摆弄 …

我有一个特定的表，列数据类型为 float(53)，非空。根据Microsoft 文档，可以存储在此数据类型中的 0 以上的最小值是 2.23E-308。但是，我能够存储一个小得多的值，小到 4.94065645841247E-324。请参阅下图，证明 SQL Server 可以存储和检索文档中指定范围之外的值：

当我运行如下查询时：

select 4.7E-309

SQL Server 说： Warning: the floating point value '4.7E-309' is too small. It will be interpreted as 0.

截图中插入的值是通过 C++ ADO 接口使用记录绑定插入的。

我有几个问题：

为什么 SQL Server 处理文档中指定范围之外的值？同样，当查询中存在“超出范围”值时，为什么 SQL Server 会发出警告，而数据库显然可以存储超出该范围的值？

浮点数是如何存储在 SQL 数据库表上的，是否有任何 SQL 服务器设置会严格执行一个 SQL 服务器而不是另一个 SQL 服务器上的范围？

我正在尝试解决 ADO 记录绑定（可能）由于值超出范围而被拒绝的问题，但是我所有重现该问题的测试（在不同的 SQL 服务器实例上）表明 SQL 接受的值远远超出文档中指定的限制。任何有关如何在 SQL 中存储和处理浮点的信息（特别是与 .NET 或 C++ 之类的东西有关）将不胜感激。

我已经使用 SQL Server 2005 和 2008 对此进行了测试，结果相同。

尝试这个：

create table test (f float);
insert into test values (330.0);
commit;

select (8 + 330.0/60)::int; --14
select (8 + f/60)::int from test; --14
select (9 + 330.0/60)::int; --15
select (9 + f/60)::int from test; --14

有人可以解释为什么最后一个查询返回 14 而不是 15 吗？

PostgreSQL 9.3.9 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
12.04.5 LTS (GNU/Linux 3.2.0-63-virtual x86_64)

我有一张如下表：

order_item
------------
serial      | id (PK)
integer     | order_id
????        | quantity
integer     | unit_of_measure_id (PK) --> ml, l, kg, mg, mm, m, etc.

我正在做一个应用程序，我需要存储化学分析中使用的材料量。有时材料的用量很小，如微升，有时则更多，如一两升。

它的numeric数据类型是否足够好？

我读过将值转换为最小度量单位是个好主意。所以如果我有 10 升，我必须传递到 10000000 微升。但是，如果您将来需要使用更低的度量单位怎么办？像皮升？不可避免地，我认为应用程序将不得不使用浮点数。

阅读有关数字数据类型的Postgresql 文档 让我想到了这个问题：为什么在 Postgresql 中使用数据类型Float（SQL 标准）会得到这些意外的结果Numeric？

例如：

CREATE TEMP TABLE testnum (a numeric, b float);
INSERT INTO testnum VALUES (100,100);
INSERT INTO testnum VALUES (9*9*9,9*9*9);
INSERT INTO testnum VALUES (9^9^9,9^9^9);
SELECT (a/3)*3 AS numeric, (b/3) * 3 AS float FROM testnum;
SELECT (a/5)*5 AS numeric, (b/5) * 5 AS float FROM testnum;

然后运行

SELECT (a/3)*3 AS numeric, (b/3) * 3 AS float FROM testnum;

numeric                                     |         float          
                        99.9999999999999999 |                    100
                       729.0000000000000000 |                    729

在这个测试中Float …

我有一个数据库，其中包含存储为浮点数的财务数据。自然地，这可能会在随机时间出现真正的问题（例如，当存在无法使用浮点算法足够接近地近似的精确值时）。

我的问题是：

• ALTER TABLE table MODIFY field fixed(10,2)选择字段时使用会 保留 MySQL 当前显示的固定值吗？
• 有没有可能价值不是这个？

我使用以下查询创建了包含小浮动值的表

create table temp_data (val float)

但是当它给出非常小的值的警告消息时 (e-314)

insert into temp_pce_rank_data values(2.466987305926227e-314)

数据被插入并带有值'0'警告消息是：The floating point value '2.466987305926227e-314' is out of the range of computer representation (8 bytes).

如何在 SQL Server 数据库中存储和检索非常小的值 (E-314)？谢谢

我有一个 Laravel 应用程序需要存储最小和最大权重。目前，我们使用整数值来存储数据，但我需要修改它以使用浮点存储数据值。为了获得良好的准确性，我必须使用什么数据类型？

我正在开发一个 PHP 应用程序，我需要在其中存储大于 100 万的值，但具有浮点的灵活性。我知道传统的 float 和 double。我希望最多存储两个小数点，并且只处理具有 2 个小数的数字的操作。

我选择了 double 和 unsigned 的列类型，但是每当我存储值大于一百万的行时，它就会被截断为 999999.99

为什么是这样？我正在寻找正确的数据类型/解决方案。如果您能指出我正确的方向，我将不胜感激！

提前感谢您的时间！

干杯。

我有很多情况需要将带有许多小数位的大浮点数转换为带有 2、1 或根本没有小数位的四舍五入数字。

我一直在这样做的方式如下所示：

declare @t table ( [rows] float )


insert into @t 
select 1.344
union all select 32.3577
union all select 65.345
union all select 12.568
union all select 12.4333

select * from @t

现在我将进行转换并将它们全部保存到临时表中，然后我们将查看临时表的结构。

begin try
   drop table #radhe
end try
begin catch
end catch


select 
[Rows Formated] = REPLACE(CONVERT(VARCHAR(50),CAST(sp.[Rows] AS MONEY),1), '.00','')
into #radhe
from @t sp


select * 
from #radhe

一切都很好，效果很好，它做了我想要的，但是，当我查看表的结构时，我得到以下信息：

use tempdb
go

sp_help '#radhe'

您可以在图片上看到 varchar(8000)。我们可以避免吗？

我会很高兴使用 varchar(50)

我遇到了一些奇怪的行为：在将浮点值传递到 varchar 列时，这些值正在从整数转换为科学记数法，而正是这种科学记数法存储为字符串。

    if OBJECT_Id('tempdb..#whydis') is not null begin drop table #whydis end
    if OBJECT_Id('tempdb..#ImSeriously') is not null begin drop table #ImSeriously end

    create table #whydis (bigID float)
    create table #ImSeriously (bigID varchar(255))

    insert into #whydis(BigID)
    values(1495591),
    (1495289),
    (1495610),
    (1495611),
    (1495609),
    (1495592),
    (1495686)

    INSERT INTO #ImSeriously (bigID)
    SELECT BigID from #whydis

    select * from #ImSeriously

结果如下所示：

1.49559e+006

以字符串形式存储的科学记数法。通过转换为 int 很容易解决：

    INSERT INTO #ImSeriously (bigID)
    SELECT cast(BigID as int) from #whydis

但整件事让我摸不着头脑。

问题：以这种方式存储它们的浮点数是怎么回事？