BASIC PRINT atpercent

With BASIC module 1.65 @% goes wrong when set to display one decimal place.

This test shows the problem.

a=12.345
@%=&02020A
PRINT ~@%,a
@%=&02010A
PRINT ~@%,a
@%=&02000A
PRINT ~@%,a
END

Module is: BBC BASIC V     1.65 (30 Mar 2017)
     2020A     12.34
     2010A   1.2E1  
     2000A    1.E1  
*


Module is: BBC BASIC V     1.64 (04 Mar 2017)
     2020A     12.34
     2010A      12.3
     2000A       12.
*

So the problem with using the BASIC64 number formatting code is that you inherit all of its bugs and quirks :-)

Module is: BBC BASIC VI 1.05 (12 Mar 1992)
     2020A     12.35
     2010A  1.2E1   
     2000A   1.E1  

Now I just need to work out which bit of code is responsible for the logic…

Wow, that has been around for a long time then!

A little archaeology found the the issue has been seen previously and written up in Archive, January 1999, vol12 no4, “Hint and Tips”. The description is more general than mine was.

<quote>
Setting @%=“F20.3” would print numbers in a 20≠digit field with three digits to the right of the decimal point. This works very well in Basic5, but fails in Basic64 if the integer component is either zero or has more digits than the fixed setting. Thus 0.1 or 1234.123 would fail if @% is set as above. Instead, the number will be displayed in ‘E’ format. Sounds crazy, but it’s absolutely true!
</quote>

@%="F20.3"
a=0.1
PRINT ~@%,a
a=1234.123
PRINT ~@%,a

Module is: BBC BASIC VI    1.64 (04 Mar 2017)
               20314          1.000E-1  
               20314          1.234E3

It is a bit late now, but you will find the problems with BASIC VI number formatting flagged as WARNINGs in my StrongHelp BASIC manual, which has also been around for quite a long time. ;-)

I did write a more reliable (I hope) number formatting routine for 64-bit floats, using VFP instructions, in my Float module.

It is a bit late now, but you will find the problems with BASIC VI number formatting flagged as WARNINGs in my StrongHelp BASIC manual

Not necessarily. This bug was only spotted because I’ve been going round fixing and tweaking things after spotting that A <> VAL(STR$(A)) for quite a few numbers (for both BASIC and BASIC64). And if there are more issues then those are probably worth investigating too.

After a bit of work I’ve been able to produce a rough specification for the behaviour of BASIC V’s number formatting. There are more rules to the formatting than you might expect; I suspect some of them only exist as a consequence of the way the code was originally written, rather than as the result of any conscious design decision. One of the “fun” things I’ve been thinking about doing is seeing how well the BBC Micro versions of BBC BASIC handle number formatting, so maybe that could provide some clues as to where some of the behaviour has come from.

Nevertheless, from the specification I’ve been able to produce a reference model for the number formatting in BASIC, and wrapped that up in a testbed which compares the interpreter to the reference model. From that I’ve been able to fix up the broken BASIC V 1.65 to format numbers correctly. Now I just need to extend the reference model to work with double-precision floats so I can test it against BASIC VI (which I’m hoping will just work, since both versions are using the same code now). This should also mean the death of all the BASIC VI specific formatting quirks.

Well done for chasing some of the formatting anomalies down.

It has always struck me as odd (and sometimes annoying) that when BASIC is asked to print a real number ‘with no decimal places’ it leaves the decimal point at the end. To me, 12.345 with no decimal places should be “12” not “12.”

Is there a way to get BASIC to print a whole number with no decimals, and a non-whole number limited at two?
My weather app creates a web page and when the wind blows it often results in stuff like 6.788888889 km/h which just looks silly. I tried playing with @% but never got the result I was looking for… Is it possible?

Whole number with no decimals is easy: add 0.5 (assuming you want rounding to nearest) and cast to integer:

number% = number+0.5 : PRINT number%

If there’s a problem with @% doing the two decimal places thing, you play a messy game with integers and strings, and a “.” character. I’m sure you can work out how – or if you really want me to I’ll write the nasty thing for you…

It isn’t THAT nasty. :)

   10 a=12.5
   20 PRINTFNstrf(a,"+F9.0")
   30 END
   40 DEF FNstrf(i,f$)
   50 LOCAL @%
   60 @%=f$
   70 =LEFT$(STR$i,LENSTR$i-1)

Is there a way to get BASIC to print a whole number with no decimals, and a non-whole number limited at two?

There’s no builtin way of doing it. However you should be able to get pretty close with the following:

DEF FNfmt(i)
LOCAL @%,A$
@%="+F0.2"
A$=STR$i
IF RIGHT$(A$,3)=".00" THEN =LEFT$(A$,LEN(A$)-3)
=A$

The exception being that for large numbers (e.g. > 2^32) the ‘F’ format will actually revert to ‘E’ format (the code will produce a sensible number, but not in the format you want). But if the wind is that strong you’ve probably got bigger problems on your hands.

Whole number with no decimals is easy: add 0.5 (assuming you want rounding to nearest) and cast to integer:

number% = number+0.5 : PRINT number%

Assuming you’re happy with negative numbers being rounded incorrectly :-)

I think this is OK:

DEFFNformat(n)
LOCAL @%
IF n<>INTn THEN @%="+F.2" ELSE @%="+G"
=STR$a

However, that will possibly include “.00” when n is not truly an integer, which may not be what you want.

This works for 2 decimal places:

a%=number+0.005 : b%=(number-a%)*100+0.5 : PRINT a%;“.”;b%

which is only a little bit nasty, and has the virtue of being completely independent of @% behaviour.

This works for no decimal places:

a%=number+0.5 : PRINT a%

Remove the +0.5s and +0.005 if you want rounded down rather than rounded to nearest.

And of course don’t use those silly sexed quotes that Textile has so kindly provided.

@% now good in both BASIC V and BASIC VI (bonus!) 1.66.

Many thanks.