Author |
Topic: 64 bit floats (Read 691 times) |
|
hellomike
New Member
member is offline


Gender: 
Posts: 46
|
 |
64 bit floats
« Thread started on: Jun 5th, 2014, 12:16pm » |
|
Hi,
Some time ago I wrote a BBC Basic version for the Rosetta Code problem "Hickerson series of almost integers" task.
See: http://rosettacode.org/wiki/Hickerson_series_of_almost_integers
1: Since BB4W V5.95a only has 40 bit float numeric precision I made use of the BB4WMAPMLIB. See REMmed code below. This worked fine. I.e. only the result for 16 & 17 are NOT almost integers, the rest is.
2: When Richard made BB4W V6 Beta available I rewrote the FNHickerson() function using native floating point calculations. This worked fine too in V6.
3: Then I thought, wait a minute! With *FLOAT 64, I can force V5.95a to use the same precision as V6 defaults precision.
It however doesn't work correctly in version 5.95a.
I.e. next code works in version 6 but not (floating point precision insufficient) in version 5.95a. Code:
*FLOAT 64
INSTALL @lib$+"FNUSING"
REM INSTALL @lib$+"BB4WMAPMLIB"
REM MAPM_DllPath$="lib\BB4WMAPM.DLL"
REM PROCMAPM_Init
REM MAPM_Dec%=30
@%=2
FOR I%=1 TO 17
HIC$=FNHickerson(I%)
PRINT "H(" I% ") = " HIC$ " which is ";
IF MID$(HIC$,20,1) <> "0" AND MID$(HIC$,20,1) <> "9" PRINT "NOT ";
PRINT "an almost integer."
NEXT
END
REM DEF FNHickerson(n%)
REM LOCAL tmp$
REM tmp$=FNMAPM_Multiply("2",FNMAPM_Pow(FNMAPM_Ln("2"),STR$(n%+1)))
REM tmp$=FNMAPM_Divide(FNMAPM_Factorial(STR$n%),tmp$)
REM =RIGHT$(STRING$(17," ")+FNMAPM_FormatDec(tmp$,3),22)
DEF FNHickerson(n%)
LOCAL i%,f
f=1:FOR i%=1TOn%:f*=i%:NEXT
=FNusing("##################.###",f/(2*LN2^(n%+1)))
I suspect that I'm confused about 64 bit float storage and actual 64 bit calculations that only BB4W version 6 is capable of.
Mike
|
|
Logged
|
|
|
|
DDRM
Administrator
member is offline


Gender: 
Posts: 321
|
 |
Re: 64 bit floats
« Reply #1 on: Jun 5th, 2014, 1:34pm » |
|
Hi Mike,
I think it is because BB4W version 6 uses 80 bit floats, which is (just) enough to do the problem (it fails for n=18, which needs 20 sig figs).
In the manual, Richard says 64 bit floats give you about 15 sig figs, and in Yahoo message 21051 he says the 80 bit floats give about another 3 - and then quotes Pi to 19 places, consistent with getting the right answer for Hickerson 17, but not 18.
Here's my code, which fails at H(15) - needs 16 digits - using FLOAT64, but makes it to H(17) in V6. Code:
*FLOAT64
@%=&1515
l2=LN(2)
FOR x=1 TO 20
h=FNfac(x)/(2*(l2^(x+1)))
PRINT x;" ";h
NEXT
END
:
DEFFNfac(n)
IF n<3 THEN=n ELSE =n*FNfac(n-1)
Best wishes,
D
|
|
Logged
|
|
|
|
rtr
Guest
|
 |
Re: 64 bit floats
« Reply #2 on: Jun 5th, 2014, 2:20pm » |
|
on Jun 5th, 2014, 12:16pm, hellomike wrote:Then I thought, wait a minute! With *FLOAT 64, I can force V5.95a to use the same precision as V6 defaults precision. |
|
As David says, that's not right. BB4W v6 works internally with long-doubles, i.e. 80-bit floats (64-bit mantissa) whereas BB4W v5 (in *FLOAT64 mode) works internally in doubles, i.e. 64-bit floats (53-bit-equivalent mantissa). The equivalent decimal precision is a little under 16 significant figures in v5, and a little over 19 significant figures in v6.
Richard.
|
|
Logged
|
|
|
|
hellomike
New Member
member is offline


Gender: 
Posts: 46
|
 |
Re: 64 bit floats
« Reply #3 on: Jun 5th, 2014, 3:57pm » |
|
Ah, OK. So v6 works by default with 80 bits. Thanks
So *FLOAT 64 overrides v5x default precision but not v6 default precision.
|
|
Logged
|
|
|
|
|