How would i round a floating point value in the FPU to a specific number of decimal places using the standard FPU rounding mode?
... shouldn´t be too hard to do, i guess, but i don´t get it.
Thanks
JK
I cheat, I truncate the display results but leave the FP number unmodified.
multiplication, rounding, division
x*0,1
x*1/100
x*10
x*100
Beware of rounding errors ;-)
include \masm32\include\masm32rt.inc
.data
f1 REAL10 123.45678901234567890
.code
start:
fld f1
fmul FP4(100.0)
frndint
fld FP10(0.01)
fmul
int 3 ; check here with your debugger
fstp f1
exit
end start
Quote from: jj2007 on February 10, 2023, 10:04:41 PM
Beware of rounding errors ;-)
:thumbsup: Perfect.
The default FPU rounding mode is round to nearest. You can change that.
Quote from: HSE on February 10, 2023, 11:33:20 PM
Quote from: jj2007 on February 10, 2023, 10:04:41 PM
Beware of rounding errors ;-)
:thumbsup: Perfect.
The default FPU rounding mode is round to nearest. You can change that.
start:
finitDefault? The finit instruction changes the rounding mode from near 53 to near 64.
Quote from: hutch-- on February 10, 2023, 09:34:03 AM
I cheat, I truncate the display results but leave the FP number unmodified.
thanks :thumbsup:
never thought of that simple ,invoke fptoascii and search for "." and mov zero termination into the string+ number of decimals
Quote from: jj2007 on February 11, 2023, 12:07:45 AM
Default? The finit instruction changes the rounding mode from near 53 to near 64.
:biggrin: What I can say?
:biggrin:
Magnus,
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
NOSTACKFRAME
truncate proc
; -----------------------------------------------------
; truncate the number of digits after the decimal point
; -----------------------------------------------------
; rcx = string address
; rdx = decimal place count
sub rcx, 1
@@:
add rcx, 1
cmp BYTE PTR [rcx], 0 ; exit on zero if no period
je bye
cmp BYTE PTR [rcx], "." ; scan until the decimal point
jne @B
test rdx, rdx ; if rdx not 0
jnz nxt ; bypass "0" settings
mov BYTE PTR [rcx], "." ; write decimal point
mov BYTE PTR [rcx+1], "0" ; a trailing 0
mov BYTE PTR [rcx+2], 0 ; terminate the string
ret ; return to caller
nxt:
add rdx, 1 ; correct for period
@@:
add rcx, 1
cmp BYTE PTR [rcx], 0 ; scan until rdx count
je bye
sub rdx, 1
jnz @B
mov BYTE PTR [rcx], 0 ; terminate string on rdx count
bye:
ret
truncate endp
STACKFRAME
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
.data
align 16
f1 REAL8 123.45678901234567890
align 16
f2 real8 100.0
align 16
f3 REAL8 0.01
.code
movsd xmm0,f1
invoke printf,CStr("%f",10),xmm0
movsd xmm0,f1
cvtsd2si rcx,xmm0
invoke printf,CStr("%d",10),rcx
movsd xmm0,f1
cvtsd2si rcx,xmm0
mulsd xmm0,f2
invoke printf,CStr("%f",10),xmm0
movsd xmm0,f1
cvtsd2si rcx,xmm0
mulsd xmm0,f2
cvtsd2si rax,xmm0
invoke printf,CStr("cvtsd2si: %d",10),rax
movsd xmm0,f1
cvtsd2si rcx,xmm0
mulsd xmm0,f2
cvttsd2si rax,xmm0
invoke printf,CStr("cvttsd2si: %d",10),rax
movsd xmm0,f1
cvtsd2si rcx,xmm0
mulsd xmm0,f2
mulsd xmm0,f3
invoke printf,CStr("%f",10),xmm0
movsd xmm0,f1
cvtsd2si rcx,xmm0
mulsd xmm0,f2
mulsd xmm0,f3
cvtsd2si rbx,xmm0
invoke printf,CStr("%d",10),rbx
ret
123.456789
123
12345.678901
cvtsd2si: 12346
cvttsd2si: 12345
123.456789
123
movsd xmm0,f1
mulsd xmm0,f2
cvtsd2si rcx,xmm0
cvtsi2sd xmm0, rcx
mulsd xmm0,f3
.data
align 16
f1 REAL8 123.45678901234567890
one dq 1
hundred dq 100
_1_100 dq 0 ;1/100
temp dq 0
.code
movsd xmm0,f1 ;123.45678901234567890
cvtsi2sd xmm1,one ;1
cvtsi2sd xmm2,hundred ;100
divsd xmm1,xmm2 ;1/100
movsd _1_100,xmm1
mulsd xmm0,xmm2 ;12345.6789...
cvttsd2si rcx,xmm0 ;12345
movsd temp,xmm0
invoke printf,CStr("%d",10),rcx
movsd xmm0,temp ;12345.6789...
mulsd xmm0,_1_100 ;1/100=0.01
cvttsd2si rcx,xmm0 ;123
invoke printf,CStr("%d",10),rcx
ret
12345
123
Advice 0-> 1/10 in decimal base can't fit exactly in binary base, precision lost. (1÷1010) == 0,0001100... (24 (float) or 53 (double) bits)
f real4 0.1 == 0,00011001100110011001100
d real8 0.1 == 0,000110011001100110011001100110011001100110011001100
Converting:
f real4 0.1 == 1.10011001100110011001100 * 10^−100 (2^-4)
d real8 0.1 == 1.100110011001100110011001100110011001100110011001100 * 10^-100 (2^-4)
Rounding:
f real4 0.1 == 1.10011001100110011001100"1" * 10^−100 (2^-4)
d real8 0.1 == 1.100110011001100110011001100110011001100110011001100"1" * 10^-100 (2^-4)
after rounding, that "1" (right most binary digit) will be rounded to the left side.
f real4 0.1 == 1.10011001100110011001101 * 10^−100 (2^-4)
d real8 0.1 == 1.100110011001100110011001100110011001100110011001101 * 10^-100 (2^-4)
Advice 1-> don't mix real4 with real8 while comparing.
.data
f real4 0.1 ;float
d real8 0.1 ;double
.code
movss xmm0,f
cvtss2sd xmm0,xmm0 ;convert float to double, so printf will work fine
invoke printf,CStr("%.15f",10),xmm0
movsd xmm0,d
invoke printf,CStr("%.15f",10),xmm0
movss xmm0,f
movsd xmm1,d
cvtss2sd xmm0,xmm0 ;float to double
ucomisd xmm0,xmm1 ;cmp xmm0,xmm1
je equal
ja bigger
jb lower
ret
equal:
invoke printf,CStr("float == double",10)
ret
bigger:
invoke printf,CStr("float > double",10)
ret
lower:
invoke printf,CStr("float < double",10)
ret
0.100000001490116
0.100000000000000
float > double
Quote from: mineiro on February 11, 2023, 05:31:36 AM
12345
123
Hi mineiro,
I've tried to test your code, which looks like Masm64 SDK code, but I get different results, see attachment. Where are printf and CStr defined? I can't find them in the Masm64 SDK, so I used vc_printf and chr$().
:thumbsup: JJ
I was making things complex but is a good idea to make a more simple code.
include \masm32\include64\masm64rt.inc
.data
f1 REAL8 123.45678901234567890
f2 real8 100.0
f3 REAL8 0.01
f4 REAL8 0.0
buffer db 248 dup (0)
pbuff qword offset buffer
.code
entry_point proc
movsd xmm2,f1
mulsd xmm2,f2
cvtsd2si rcx,xmm2
cvtsi2sd xmm2, rcx
mulsd xmm2,f3
movsd f4, xmm2
invoke vc_sprintf, pbuff, chr$("%f",10), f4
conout pbuff, lf
waitkey
invoke ExitProcess,0
entry_point endp
end
123.460000
Press any key to continue...
Sorry for the delay (no time yesterday) and thanks for your answers.
My first thought was multiply, round, divide with code like this:
.data
n qword 100 ;10^2 -> round to 2 decimal places
float1 real8 123.4567890
float2 real8 123.4567890E100
.code
int 3
finit ;set max. precision
FILD n ;10^(# of places)
FLD float1 ;float
FMUL ST(0),ST(1) ;x 10^(# of places)
FRNDINT ;round to integer
FDIVRP ;/ 10^(# of places)
FSTP ST(0)
FILD n ;10^(# of places)
FLD float2 ;float
FMUL ST(0),ST(1) ;x 10^(# of places)
FRNDINT ;round to integer
FDIVRP ;/ 10^(# of places)
FSTP ST(0)
... works lika charm in qword range, but as you can see fails miserably with larger numbers. This is where i´m stuck.
Mathematically seen large numbers can be rounded just as small numbers, there is no qword limit. So maybe i must cut off the exponent part, round the mantissa and then add the exponent again?
... and what if don´t want to round only the decimal places after the decimal point, but round to a total number of decimal places. I would have to normalize the number before rounding (e.g. 100.234 -> 1.00234E2, round to 4 places -> 1.002E3 = 100.2) - how would i do that?
Quote from: jj2007 on February 11, 2023, 11:21:41 AM
Hi mineiro,
I've tried to test your code, which looks like Masm64 SDK code, but I get different results, see attachment. Where are printf and CStr defined? I can't find them in the Masm64 SDK, so I used vc_printf and chr$().
Sorry sir jj2007, I was playing in Linux. Change in your attached file following lines and will work on win64:
.code
WinMain proc
LOCAL msg:MSG
movsd xmm0,f2 ;123.45678901234567890
cvtsi2sd xmm1,one ;1
cvtsi2sd xmm2,hundred ;100
divsd xmm1,xmm2 ;1/100
movsd _1_100,xmm1
mulsd xmm0,xmm2 ;12345.6789...
cvttsd2si rdx,xmm0 ;12345 ;<<<<<<<
movsd temp,xmm0
invoke vc_printf, chr$("%d",13,10), rdx ;<<<<<<<<
movsd xmm0,temp ;12345.6789...
mulsd xmm0,_1_100 ;1/100=0.01
cvttsd2si rdx,xmm0 ;123 ;<<<<<<<
invoke vc_printf, chr$("%d",13,10), rdx ;<<<<<<<
...
This is a win64 code:
;ml64 /c round.asm
;link /subsystem:console /entry:WinMainCrt round.obj
include \masm64\include64\masm64rt.inc ; *** Masm64 SDK window template ***
.data
align 16 ; [url=http://masm32.com/board/index.php?topic=10659.msg118268#msg118268]mineiro[/url]
f2 REAL8 123.45678901234567890
one dq 1
hundred dq 100
_1_100 dq 0 ;1/100
temp dq 0
.code
public WinMainCrt
WinMainCrt::
movsd xmm0,f2 ;123.45678901234567890
cvtsi2sd xmm1,one ;1
cvtsi2sd xmm2,hundred ;100
divsd xmm1,xmm2 ;1/100
movsd _1_100,xmm1
mulsd xmm0,xmm2 ;12345.6789...
cvttsd2si rdx,xmm0 ;12345 ;<<<<<<<
movsd temp,xmm0
invoke vc_printf, chr$("%d",13,10), rdx ;<<<<<<<<
movsd xmm0,temp ;12345.6789...
mulsd xmm0,_1_100 ;1/100=0.01
cvttsd2si rdx,xmm0 ;123 ;<<<<<<<
mov rax,0
invoke vc_printf, chr$("%d",13,10), rdx ;<<<<<<<
ret
end
Quote from: JK on February 11, 2023, 07:52:43 PM
... works lika charm in qword range, but as you can see fails miserably with larger numbers. This is where i´m stuck.
Precision loss. Using Real4 we have 8 decimal digits of precision (lossless), with real8 we have 15 digits (maybe 16 or 17). An example is when we print pi, loss occurs.
pi real8 3.141592653589793 238462643383279502884197169399
after print 3.141592653589793 1159979634685441851615906
This occurs because the number of digits in a continuous division always tends to increase. If we remove the integer part at each step:
3.1415
3.1415-3=0.1415 3
1/0.1415=7.067137809-7= 7
1/0.067137809=14.894736842-14= 14
1/0.894736842=1.117647059-1= 1
1/0.117647059=8.5-8=0.5 8
1/0.5=2 2
The reverse process:
Using integers Using floats
1/(2) = 1/2 | 1/2=0.5
2/(2*8+1) = 2/17 | 1/(0.5+8)=0.117647059
17/(17*1+2) = 17/19 | 1/(0.117647059+1)=0.894736842
19/(19*14+17) = 19/283 | 1/(0.894736842+14)=0.067137809
283/(283*7+19)= 283/2000 | 1/(0.06713780+7)=0.1415
2000/(2000*3+283) = 2000/6283 | 1/(0.1415+3)=0.318319274
6283/2000 = 3.1415
or 2000/6283 = 0.318319274 then 1/0.318319274 = 3.1415
Quote
Mathematically seen large numbers can be rounded just as small numbers, there is no qword limit.
Yes, but you may lose accuracy if you don't deal with some problems that will appear, it will depend on how you deal with the problem.
The answer is arithmetic coding.
We initially defined 3 variables: low, medium, high. (our range)
The low will start completely filled with zeros.
The high will start completely filled with the last digit of the base, in this case 9 for the decimal base.
The middle will be (low + ((high - low) / 2)), so we will echo digits in binary to remake the number again.
We write the 3 variables in order and see where our number fits:
low = 000
mid = 499
high = 999
step 1:
low = 000
our number fits here *31415, we are before the middle, we echo 0
mid = 499
high = 999
the number is before the middle, so the middle becomes high, we calculate new middle, see where our number fits:
step2:
low = 000
mid = 249
*31415, we are past the middle, we echo 1
high = 499
half turns low
step3:
low = 249
* 0
mid = 374
high = 499
half turns high
step 4:
low = 249
mid = 311
* 1
high = 374
half turns low
In this step a phenomenon happens, our number starts with 3, the middle starts with 3, the top starts with 3. This will never change in the future, hence we know that we have the initial number 3.
From here we have two options to continue:
-------------------------------------
In data compression they remove the number 3 from the high and low part (the bits are the same), insert a 0 in the low part, insert a 9 (infinity) in the high part, and continue the compression:
before
mid = 311
high = 374
after
low = 110
high = 749
The process is much more complex than that, just a notion. If you like this way, read about arithmetic coding + data compression.
It's necessary some adjusts (1/4) and (3/4) if numbers are getting so much closer but don't change (like 499 and 500).
One example is: Imagine that the next number is zero, and zero will not fit in that range!!! (will be before low)
The formula that I'm using also changes if dealing with data compression.
https://en.wikipedia.org/wiki/Arithmetic_coding
-------------------------------------
We are not compressing data, we can reset the process and start again from the starting point.
We just need to remove the 3 from our pi and advance to the next digit: 31415-"3" = 1415
step 1:
low = 000
our number fits here *1415, we are before the middle, we echo 0
mid = 499
high = 999
...
Having the bits echoed we can reconstruct the given number:
0101
We start the process by setting low, medium and high. We take a bit, if it's zero then it's between low and middle, if it's 1 then it's between middle and high.
step1: 0101
low = 000
mid = 499
high = 999
The first bit is 0, our number is between low and middle.
step2: 101
low = 000
mid = 249
hih = 499
The current bit is now 1, we are between the middle and high....
The process stops when we have the 3 upper digits equal.
So, you can play with floating number or unsigned integers number.
But same problem happens here:
The number 5 its the question. So, you need deal with (1/2) initially, but take into account (1/4) and (3/4) and do some verify.
Each radix base will have this problem. You need check numbers after our actual number.
--------------------------------
Other choice is, using 31415 as example, but subtracting 1 from high
set a range [00000,100000], divide this range by 10 (decimal base) (from 0 to 9 digits, equal probabilities).
00000 0 09999 1 19999 2 29999 3 39999 4 49999 5 59999 6 69999 7 79999 8 89999 9 999999
Where our number fits? Between [29999 3 39999]
and go on.
39999-29999=10000 / 10 = 1000
29999 30999 31999 32999 33999 34999 35999 36999 37999 38999 39999
Where our number 31415 fits? Between [30999 31999]
Ops, left most numbers are the same, we can throw them away and continue our process.
So:
before
[30999 31999]
after
[09990 19999] ;insert a zero in low, a 9 (infinite) in high, continue.
...
Thanks, i will need some time to digest that ...
Quote from: JK on February 11, 2023, 07:52:43 PM
Mathematically seen large numbers can be rounded just as small numbers, there is no qword limit.
:thumbsup: interesting. FPU limit is 1.8×10
19 (or 2
64 :biggrin:). Apparently numbers equals or less than this is are named "integral values".
Then number to round with mul,round,div must be less than 1.8x10
(19-decimal_positions).
What the purpose to round so big numbers?
HSE,
Quote from: HSE on February 13, 2023, 03:46:20 AM
What the purpose to round so big numbers?
sometimes this is necessary. It depends on the circumstances.
The SI unit of the amount of substance is the mole. It contains 6.02214076
. 10
23 elementary entities. That's a factor of 10 000 more than your 19 decimal places - for example.
Quote from: Gunther on February 13, 2023, 04:12:34 AM
The SI unit of the amount of substance is the mole. It contains 6.02214076 . 1023 elementary entities.
:thumbsup:
But perhaps you must use big integers for that, no FPU (like is JK question).
Quote from: HSE on February 13, 2023, 03:46:20 AM
:thumbsup: interesting. FPU limit is 1.8×1019 (or 264 :biggrin:). Apparently numbers equals or less than this is are named "integral values".
Then number to round with mul,round,div must be less than 1.8x10(19-decimal_positions).
What the purpose to round so big numbers?
Sorry to disappoint you but the largest number which can be represented with the FPU in REAL10 mode is 1.19x10
4932, but with only a maximum accuracy of 19 decimal digit or 64 binary bits mind you.
One should ALWAYS round the result of a computation to the accuracy of the least accurate component used for the computation. For example, if
6.02214076 is the least accurate component, ALL results should be rounded to AT MOST 9 total (integral and fractional) decimal digits.
Quote from: raymond on February 13, 2023, 04:38:03 AM
Sorry to disappoint you but the largest number which can be represented with the FPU in REAL10 mode is 1.19x104932, but with only a maximum accuracy of 19 decimal digit or 64 binary bits mind you.
Thanks Raymond, I was not forgetting that. :thumbsup:
Just FRNDINT will fail if number in st(0) is bigger than 2
64, returning same number in st(0) and C1 will be set to 0.
Quote from: raymond on February 13, 2023, 04:38:03 AMOne should ALWAYS round the result of a computation to the accuracy of the least accurate component used for the computation. For example, if 6.02214076 is the least accurate component, ALL results should be rounded to AT MOST 9 total (integral and fractional) decimal digits.
Good to remember. Perhaps JK idea is related to that.
Quoteleast accurate component
Yes, with scientific calculations you must have an eye on accuracy (aka digits of precision), otherwise you might calculate nonsense. Therefore rounding is a must in certain places. Of course this "integer" limit of FRNDINT comes from the fact that the FPU can hold integers up to 10^18. 64 bits don´t allow for larger integer values. On the other side much larger floating point values are possible (with a maximum accurracy of 18 digits). So how would i round such floating point number to a specific number of decimal digits?
My best bet currently is:
separate the fractional part (which should be possible with FPREM), subtract from original value, multiply fraction, round, divide again and add to the original value.
Rounding to a total number of digits:
save integers as float, load again, divide by ten (so it´s 0.xxx.....) and then do the same as above
added: is normalizing a number necessary at all?
I´m going to investigate this ...
Quote from: raymond on February 13, 2023, 04:38:03 AM
Sorry to disappoint you but ... but with only a maximum accuracy of 19 decimal digit or 64 binary bits mind you.
Raymond always make the point about things we often forget :thumbsup: :thumbsup: :thumbsup:.
If you number is bigger than 1.8x10
19 last part of number is lost by FPU, and you have no fractional part, only integers :biggrin:
Congratulation JK, your problem is solved :biggrin: :biggrin:
QuoteIf you number is bigger than 1.8x1019 last part of number is lost by FPU, and you have no fractional part, only integers :biggrin:
... and possibly truncated (specially if you look only at the 64 bits of the significand field).
But, you would rarely want to retain an accuracy even close to 19 decimal digits. And, your rounding procedure should detect such situations where the integer part exceeds the required accuracy and treat it separately anyway.
Here is the barbarian view from someone who counts with their fingers if it does the job. :biggrin:
1. Perform the calculation in whatever level of precision you require.
2. Truncate the display result at your predetermined decimal point range.
3. Read the next integer after the decimal point truncation end.
4. Depending on your preferred rounding method, move the last digit in the truncated end either UP or DOWN.
5. Leave the original calculation alone so you can reuse it. :icon_idea:
Purest Masm64 SDK code attached.
src1 REAL10 123.45678901234567890
src2 REAL10 123456789012345.678
...
Result=123.46
Result=123456789012345.69Same but with Print Str$("Result=%Hf\n", dest), where dest is REAL10: Result=123456789012345.68
Quote from: jj2007 on February 10, 2023, 10:04:41 PM
Beware of rounding errors ;-)
The FPU has its limits (and SIMD instructions are worse) :cool:
src1 REAL10 123.45678901234567890
src2 REAL10 123456789012345.678
From a purely mathematical point of view, if both those values must be rounded to the same accuracy, let's use 12 decimals digits as an example, the results should be:
src1 123.456789012 (or in the other standard way: 1.23456789012 x 102)
src2 123456789012000 (or as above 1.23456789012 x 1015)
@ JJ: Can you imagine reporting, as you suggested, the largest number which can be represented with the FPU in REAL10 mode (1.19x104932) with an accuracy of 3 decimal digits? :undecided: :azn:
Hutch great :thumbsup:
What happens with SendMessage string to gui control with restricted length of string displays can only fit 9.123 out of 9.123456789?
Does it display first or last part of digits?
Related problem is display fusion reactor million kelvin 150 millions kelvin instead of 150123456 kelvin or millions of dollars
Jochen packed SIMD might be useful for statistics with curves and tables
Also a weather map with lots of temperatures on it,from weather forecast sources like satellites, computer simulation etc to no display with no decimals
Raymond I thought infinity is biggest fpu number?
Quote from: raymond on February 13, 2023, 02:21:15 PM@ JJ: Can you imagine reporting, as you suggested, the largest number which can be represented with the FPU in REAL10 mode (1.19x104932) with an accuracy of 3 decimal digits? :undecided: :azn:
Raymond,
I can surely imagine that, but I didn't suggest that. As we both know, that would be utter nonsense. However, the whole thread deals with "two digits after the dot", and that's what the multiply by 100 method can do.
Achieving a given precision or number of valid digits is an entirely different story:
include \masm32\MasmBasic\MasmBasic.inc ; *** round to a given number of valid digits (http://masm32.com/board/index.php?topic=10659.msg118331#msg118331) ***
src1 REAL10 123.45678901234567890
src2 REAL10 123456789012345.67890
src3 REAL10 123.45678901234567890e-99
src4 REAL10 123456789012345.67890e99
Init
Print Str$("Result s14=%4f\t", src1), Str$("s19=%9f \t", src1), Str$("s1J=%Jf\n", src1)
Print Str$("Result s24=%4f\t", src2), Str$("s29=%9f\t", src2), Str$("s2J=%Jf\n", src2)
Print Str$("Result s34=%4f\t", src3), Str$("s39=%9f\t", src3), Str$("s3J=%Jf\n", src3)
Print Str$("Result s44=%4f\t", src4), Str$("s49=%9f\t", src4), Str$("s4J=%Jf\n", src4)
EndOfCode
Output:
Result s14=123.5 s19=123.456789 s1J=123.4567890123456789
Result s24=1.235e+14 s29=1.23456789e+14 s2J=123456789012345.6789
Result s34=1.235e-97 s39=1.23456789e-97 s3J=1.234567890123456789e-97
Result s44=1.235e+113 s49=1.23456789e+113 s4J=1.234567890123456789e+113
Well, using a sliding window!!!
123
23.
3.4
.45
...
When we read a text full of alphabetic digits, do we read the whole text at once or sequentially? Letter by letter, word by word...
Quote from: jj2007 on February 13, 2023, 11:55:32 AM
Same but with Print Str$("Result=%Hf\n", dest), where dest is REAL10: Result=123456789012345.68
The FPU has its limits (and SIMD instructions are worse) :cool:
FPU already have truncated that :biggrin:
fld src1
fmul x100
frndint
fld x001
fmul
fstp dest
invoke vc_printf, chr$("Result =%24f", 13, 10), dest
fld src2
fstp dest
invoke vc_printf, chr$("Result =%24f", 13, 10), dest
Result = 123.460000
Result = 123456789012345.670000
Press any key to continue...
Close to the limit You have to use same number:
fld src2
fmul x100
frndint
fdiv x100
fstp dest
because there is no guarantee that internally 0.01 equals 1/100 at full precision.
Quote from: HSE on February 14, 2023, 12:15:45 AMClose to the limit You have to use same number: fld src2
fmul x100
frndint
fdiv x100
fstp dest
because there is no guarantee that internally 0.01 equals 1/100 at full precision.
You may not have noted that I used two different multipliers, for a reason:
Quote from: jj2007 on February 10, 2023, 10:04:41 PM
Beware of rounding errors ;-)
include \masm32\include\masm32rt.inc
.data
f1 REAL10 123.45678901234567890
.code
start:
fld f1
fmul FP4(100.0)
frndint
fld FP10(0.01)
fmul
int 3 ; check here with your debugger
fstp f1
exit
end start
100.0 is ok as REAL4, but 0.01 requires a REAL10. Btw the correct result is 68, not 67; you are using a REAL8, I suppose.
Quote from: jj2007 on February 14, 2023, 12:21:20 AM
you are using a REAL8, I suppose.
Yes. FPU is not designed to store/retrieve REAL10 numbers, they are for internal use and external checks. If you need more precision than real8 you have to use big numbers libraries. :thumbsup:
Quote from: HSE on February 14, 2023, 12:39:09 AMFPU is not designed to store/retrieve REAL10 numbers
That is an interesting theory :thumbsup:
Quote from: jj2007 on February 14, 2023, 12:42:00 AM
Quote from: HSE on February 14, 2023, 12:39:09 AMFPU is not designed to store/retrieve REAL10 numbers
That is an interesting theory :thumbsup:
:biggrin: 30 years old. At that time I have an emulator, because you was having to buy FPU chip appart, and was so fantastic real8 precision that nobody was thinking in real10.
I never see that explanations again.
Quote from: HSE on February 14, 2023, 12:57:18 AM30 years old
In the meantime, real geniuses
TM at Intel and AMD have developed the fld and fstp instructions :thumbsup:
Quote from: jj2007 on February 14, 2023, 12:59:43 AM
In the meantime, real geniusesTM at Intel and AMD have developed the fld and fstp instructions :thumbsup:
I presume always were there to store/retrieve full internal FPU states, but I don't know.
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/printf-printf-l-wprintf-wprintf-l?view=msvc-170
Quote
Important
Starting in Windows 10 version 2004 (build 19041), the printf family of functions prints exactly representable floating point numbers according to the IEEE 754 rules for rounding. In previous versions of Windows, exactly representable floating point numbers ending in '5' would always round up. IEEE 754 states that they must round to the closest even digit (also known as "Banker's Rounding"). For example, both printf("%1.0f", 1.5) and printf("%1.0f", 2.5) should round to 2. Previously, 1.5 would round to 2 and 2.5 would round to 3. This change only affects exactly representable numbers. For example, 2.35 (which, when represented in memory, is closer to 2.35000000000000008) continues to round up to 2.4. Rounding done by these functions now also respects the floating point rounding mode set by fesetround. Previously, rounding always chose FE_TONEAREST behavior. This change only affects programs built using Visual Studio 2019 version 16.2 and later. To use the legacy floating point rounding behavior, link with legacy_stdio_float_rounding.obj.
hello sir JK;
I found an approximation for the first 400 digits of pi on the internet.
After arithmetically encoding it, I got the 181 bytes below:
51 fa 11 a8 43 67 0f d2 82 47 3e 43 e3 5b 92 51
f9 9f 8d cf 79 d9 d9 b5 09 1a 6d 36 01 b1 58 02
...
d4 cf 80 0e 3c
After decoding it, I got the digits of pi again.
I used 64-bit integer registers in the program, but nothing prevents you from updating the program to use 32-bit or 16-bit for this particular purpose.
This encoding/decoding demonstrates that we can simulate an infinite floating point using integers.
It is up to you, if you wish, to update the program to use floating point.
My level in the English language is poor, for a better understanding of the source code I recommend:
Arithmetic Coding revealed : A guided tour from theory to praxis
Eric Bodden, Malte Clasen, Joachim Kneis.
The text above is focused on data compression, however, I eliminated from the source code the part that "compresses" the data, resulting only in the arithmetic encoder.
Follow a win64 and linux64 source code and executables. I used uasm in both O.S.
Ok, after some reading, thinking and coding i now have this one (attached)
Summary: there are two methods you can go:
1.) round to a total # of digits
make mantissa an integer by fmul/fdiv 10^exp-> round mantissa (fdiv, frndint, fmul) + restore
In case of floats beyond 10^18 rounding to decimal places after decimal point doesn´t make sense in FPU, because such numbers require more than 19 digital places in total, the original number is just returned. It doesn´t do any harm, but it also has no effect!!! In scientific format there is always one digit before the decimal point and all the rest after it, you can round these numbers to a total number of digits.
2.) round to a # of places after the decimal point
round mantissa (fmul, frndint, fdiv)
This works works only in integer range (19 digits in total = 10^18), in this range rounding to decimal digits after decimal point is possible respecting the FPU´s internal accuracy of 19 digits, i.e. 1234567890.xxxx... can be rounded to a max of 8 decimal places. In case of "overflow" (digits before decimal point + digits to round to > 18) rounding is done as far as possible, numbers beyond 10^18 are returned unchanged.
Please tell me, if there are problems or errors
JK