Page 2 of 3
Posted: Sat Feb 11, 2006 1:25 pm
by El_Choni
BTW, Psychophanta (this uses jack's procedures to show the result):
Code: Select all
!FLD tword [l_a]
;b.e=0.57823984700423848847388532e-11
!FLD tword [l_b]
;c.e=a.e+b.e
!FADDP
!FSTP tword [l_c]
MessageRequester("Result:", xFtoA(?c))
End
!section '.data' code readable writeable
a:
!dt 6.938827757238428549483e-9
b:
!dt 0.57823984700423848847388532e-11
c:
!dt 0.0
Posted: Sat Feb 11, 2006 1:29 pm
by jack
this is strange, i get same result either way maybe different cpu's get different results?, my cpu is AthlonXp (32-bit)
btw the following tip by Lance Edmonds may be faster than finit, have not timed it.
put the following at the top of your source
Code: Select all
Global CtrlWrd.w = 4927;&B0001001100111111
then whenever you need to ensure that the fpu is in 80-bit mode
Code: Select all
! fldcw [v_CtrlWrd] ; this guarantees extended precision
Posted: Sat Feb 11, 2006 1:39 pm
by El_Choni
You're right; apparently, you can set the precision to which the FPU rounds the result after an arithmetic instruction (real4, 8 or 10). But the operations themselves are always done with real10.
Posted: Sat Feb 11, 2006 1:58 pm
by Fred
Another important point is about other processors. Does them all support this 80 bit format ?
Posted: Sat Feb 11, 2006 1:58 pm
by Psychophanta
El_Choni wrote:BTW, Psychophanta (this uses jack's procedures to show the result):
Code: Select all
!FLD tword [l_a]
;b.e=0.57823984700423848847388532e-11
!FLD tword [l_b]
;c.e=a.e+b.e
!FADDP
!FSTP tword [l_c]
.......
Right, and that means that working with 80bit floats, the code would be slower than using 64bit floats.
Because this example would be:
Code: Select all
!FLD qword [l_a]
;b.e=0.57823984700423848847388532e-11
!FADD qword [l_b]
;c.e=a.e+b.e
!FSTP qword [l_c]
.......
[/quote]
You are saving about 1 instruction and a stack push-pop per each operation !
Posted: Sat Feb 11, 2006 2:01 pm
by Psychophanta
Fred wrote:Another important point is about other processors. Does them all support this 80 bit format ?
Doesn't PPC allow 80bit, or more float widths?
Posted: Sat Feb 11, 2006 2:16 pm
by El_Choni
Psychophanta: right, but using 80 bit variables also saves time because no conversion to 80 bits is needed. Test this (better without debugger):
Code: Select all
time = ElapsedMilliseconds()
For i=0 To 1000000000
!FLD tword [l_at]
;b.e=0.57823984700423848847388532e-11
!FLD tword [l_bt]
;c.e=a.e+b.e
!FADDP
!FSTP tword [l_ct]
Next i
tt = ElapsedMilliseconds()-time
time = ElapsedMilliseconds()
For i=0 To 1000000000
!FLD qword [l_aq]
;b.e=0.57823984700423848847388532e-11
!FADD qword [l_bq]
;c.e=a.e+b.e
!FSTP qword [l_cq]
Next i
tq = ElapsedMilliseconds()-time
MessageRequester("Results:", "Tword operation: "+Str(tt)+Chr(10)+"Qword operation: "+Str(tq))
End
!section '.data' code readable writeable
at:
!dt 6.938827757238428549483e-9
bt:
!dt 0.57823984700423848847388532e-11
ct:
!dt 0.0
aq:
!dq 6.938827757238428549483e-9
bq:
!dq 0.57823984700423848847388532e-11
cq:
!dq 0.0
Posted: Sat Feb 11, 2006 2:24 pm
by Psychophanta
ooops!!!
That's right!
Fred, one more vote for this wish.

Posted: Tue Aug 01, 2006 11:51 am
by Psychophanta
Hi,
I would like to know if this feature is in "to do" list.

Posted: Sun Aug 06, 2006 12:02 pm
by Helle
I vote also for a 80-bit-variable (4 digits more), but see the "power" of alignment in the example of El_Choni:
Code: Select all
time = ElapsedMilliseconds()
For i=0 To 1000000000
!FLD tword [l_at]
;b.e=0.57823984700423848847388532e-11
!FLD tword [l_bt]
;c.e=a.e+b.e
!FADDP
!FSTP tword [l_ct]
Next i
tt = ElapsedMilliseconds()-time
time = ElapsedMilliseconds()
For i=0 To 1000000000
!FLD qword [l_aq]
;b.e=0.57823984700423848847388532e-11
!FADD qword [l_bq]
;c.e=a.e+b.e
!FSTP qword [l_cq]
Next i
tq = ElapsedMilliseconds()-time
MessageRequester("Results:", "Tword operation: "+Str(tt)+Chr(10)+"Qword operation: "+Str(tq))
End
!section '.data' code readable writeable
at:
!dt 6.938827757238428549483e-9
bt:
!dt 0.57823984700423848847388532e-11
ct:
!dt 0.0
aq:
!dq 6.938827757238428549483e-9
bq:
!dq 0.57823984700423848847388532e-11
!Align 4
cq:
!dq 0.0
Greeting
Helle
P.S.: Or:
Code: Select all
!section '.data' code readable writeable ;Big-Alignment
at: ;0
!dt 6.938827757238428549483e-9
!nop ;Or DATA or... ; 6 Bytes
!nop
!nop
!nop
!nop
!nop
bt: ;16
!dt 0.57823984700423848847388532e-11
!nop
!nop
!nop
!nop
!nop
!nop
ct: ;32
!dt 0.0
!nop
!nop
!nop
!nop
!nop
!nop
aq: ;48
!dq 6.938827757238428549483e-9
bq: ;56
!dq 0.57823984700423848847388532e-11
cq: ;64
!dq 0.0
Posted: Wed Aug 23, 2006 9:26 pm
by Psychophanta
I will bump here until we get it
I have a good reason now, look:
Code: Select all
Define .d
Macro ParticleAndBarbellShock(l=0.1,R=0.65,W=0.91,m1=0.3411,m2=0.1411,V1=0.0,V2=0.0,e=1.0,K=/3.0)
I=m2#*R#*R#K#
CRV=e#*(V1#-V2#-W#*l#):omeold=W#:Iover2m1l=I/2/l#:Iover2m2l=Iover2m1l/m2#:Iover2m1l/m1#
W#=(V1#-V2#+W#*(Iover2m1l+Iover2m2l)+CRV)/(Iover2m1l+Iover2m2l+l#)
V2#+Iover2m2l*(W#-omeold)
V1#=V2#+W#*l#-CRV
EndMacro
m1=Random(1000000)/10000
m2=Random(1000000)/10000
v1=Random(1000000)/10000-50
v2=Random(1000000)/10000-50
ome=Random(1000000)/10000-50
R=Random(1000000)/10000
l=R/Random(1000000)/100000
I=m2*R*R/3
value1=m1*V1+m2*V2
value2=(m1*V1-m2*V2)*l+I*ome
value3=m1*V1*v1+m2*V2*v2+I*ome*ome
ParticleAndBarbellShock(l,R,ome,m1,m2,V1,V2)
Debug value1
Debug m1*V1+m2*V2
Debug "--------"
Debug value2
Debug (m1*V1-m2*V2)*l+I*ome
Debug "--------"
Debug value3
Debug m1*V1*v1+m2*V2*v2+I*ome*ome
The debugged values should be equal one to one.
Using doubles, sometimes you will see a difference of more than one unit.
Using float (just change first line to Define .f) it is a complete disaster.
I guess using 80bit floats it would be more precise.
Posted: Wed Aug 23, 2006 10:21 pm
by Guimauve
Fred wrote:Another important point is about other processors. Does them all support this 80 bit format ?
In theory, all modern processors can support 256 bit format. But this format is used for precisions, not for speed.
For bigger format you need to have a Super Computer, the computers used in astronomy or astrophysics for exemple. And you will not use PureBasic to write program for these computers. (Sorry Fred)
For many purpose 32 or 64 bit format are good. But sometime we need to have 128 and 256 bit format. (Float and Integer number)
@Fred
No one will ask you any more about this if you add a 128 and 256 bit format for PB V5.00.
But the 80 bit format is already available in the old C language. I think it can be added to PB V4.10.
Just to make sure, the 80 bit format in C is :
Type : long double
Bit : 80
Range : From 3.4e-4932 to 3.4e4932
Regards
Guimauve
Posted: Thu Aug 24, 2006 9:12 am
by Guimauve
After a simple search in Wikipedia I have found this :
http://en.wikipedia.org/wiki/Quad_precision
(128 bits format)
I will continue my investigation.
See you soon.
Regards
Guimauve
Posted: Thu Aug 24, 2006 11:10 am
by Psychophanta
I request only for what intel called "extended double floats", which for intel means 80 bit.
I would like 128bit or 256bit floats, but intel i686 (and i think PPC G4) has a FP unit whose registers have a width of 80bit.
Thus i am requesting to Fred to take advantage of the complete width of the fpu.
So i think we must not request for use full mmx or full SSE, etc, but at least i think we must request for a full advantage of the intel fpu for the PB compiler.
Posted: Thu Aug 24, 2006 3:34 pm
by freak
> I will bump here until we get it
Your request has been heared.. bumping the thread will only serve to annoy us.
It won't help you get this feature any sooner.