проблема округления
Ещё раз попрошу птичку нашу не обижать. Я с этими инт-базед нумериками сам-то избегаю связываться, но счас поисследовал вопрос с учётом исправления путаницы со значениями PROC_STO и PRICE_K в исходном посте, и возникли сомнения.
Сдаёццо, что фигня-то имеет место быть при пхании этих инт-базед в дабл-базед в последний момент, причём только в недрах арифмометра. Тогда бага. Или вообще что-то с последовательностью выполнения операций и последний промежуточный результат оказывается в смаллинте. Насчёт того что в FB1.5 работало - это художественный свист, именно на ём и проделал.
Код: Выделить всё
Create Procedure Atomuliadalato
Returns (Temp Numeric (15,2), S SmallInt, N92 Numeric (9,2), N95 Numeric (9,5), D Numeric (15,2))
As
Declare Variable M3 Numeric (9,2);
Declare Variable STO Smallint;
Declare Variable days Smallint;
Declare Variable hours Smallint;
Declare Variable PROC_STO Numeric(9,2);
Declare Variable PRICE_K Numeric(9,5);
Begin
M3=1.22;
STO=1;
days=31;
hours=8;
PROC_STO=1.00;
PRICE_K=1.11666;
S=STO*Days;
Suspend;
S=S*hours;
Suspend;
N92=S*M3;
Suspend;
N92=N92*PROC_STO;
Suspend;
N95=N92*PRICE_K;
Suspend;
D=N95;
temp=STO*days*hours*M3*PROC_STO*PRICE_K;
Suspend;
temp=null; S=Null; N92=Null; N95=Null; D=Null;
Suspend;
S=STO*Days;
Suspend;
S=S*hours;
Suspend;
N92=S*M3;
Suspend;
N95=N92*PRICE_K;
Suspend;
N92=N95*PROC_STO;
D=N92;
Suspend;
temp=STO*days*hours*M3*PRICE_K*PROC_STO;
Suspend;
End
Work Committed
select * from Atomuliadalato
TEMP S N92 N95 D
=========== ====== =========== ===========
<null> 31 <null> <null> <null>
<null> 248 <null> <null> <null>
<null> 248 302.56 <null> <null>
<null> 248 302.56 <null> <null>
<null> 248 302.56 337.85665 <null>
337.86 248 302.56 337.85665 337.86
<null> <null> <null> <null> <null>
<null> 31 <null> <null> <null>
<null> 248 <null> <null> <null>
<null> 248 302.56 <null> <null>
<null> 248 302.56 337.85665 <null>
<null> 248 337.86 337.85665 337.86
338.00 248 337.86 337.85665 337.86
Попробуй вычислять справа на лево. Я сейчас не могу проверитьMerlin писал(а):Сдаёццо, что фигня-то имеет место быть при пхании этих инт-базед в дабл-базед в последний момент, причём только в недрах арифмометра. Тогда бага. Или вообще что-то с последовательностью выполнения операций и последний промежуточный результат оказывается в смаллинте. Насчёт того что в FB1.5 работало - это художественный свист, именно на ём и проделал.
Спорить не буду, раньше значение 1,11666 было равно 1,12, а потому глюки не встречались. Переход на версию 2,0 совпал со сменой значения на 1,11666, но это не меняет факта присутствия странного поведения птички.это художественный свист, именно на ём и проделал.
Справа на лево все считает правильно, но откудово мне знать что в птичке результат зависит от перестановки операндов.Попробуй вычислять справа на лево. Я сейчас не могу проверить
Не подумайте что грешу на птичку. Я всема руками и ногами буду бить тех кто обижает ее, но все таки хочетса быть застрахованым от таких сюрпризов.
Если внимательно читать правила вычисления масштаба и не городить десятки вычислений в одной строке, то сюрпризов не будетDedal писал(а):Спорить не буду, раньше значение 1,11666 было равно 1,12, а потому глюки не встречались. Переход на версию 2,0 совпал со сменой значения на 1,11666, но это не меняет факта присутствия странного поведения птички.это художественный свист, именно на ём и проделал.
Справа на лево все считает правильно, но откудово мне знать что в птичке результат зависит от перестановки операндов.Попробуй вычислять справа на лево. Я сейчас не могу проверить
Не подумайте что грешу на птичку. Я всема руками и ногами буду бить тех кто обижает ее, но все таки хочетса быть застрахованым от таких сюрпризов.