Floats and Decimals 2

Any idea why my other thread 'Floats and Decimals' was locked without any explanation?
I'm simply saying that I liked the way B3D did the 'rounding' and why Bmax doesn't do it.

I was also very interested in that topic before it was unexpectedly and for no apparent reason LOCKED.

OT: Sorry for this TonyG: A big suggestion for all the MODERATORS / ADMINISTRATORS who ever you maybe. Could you in small text give a reason to why things get moved and locked. Instead of the normal happenings of TOPIC MOVED TO HERE of the usual silent treatment. This way it can help educate us all. Was it because it wasnt a bug?

Back to the matter in hand.

I always thought a Float was a decimal, plus used for turning Integars into decimals / floats. And What is the difference with floats in BMAX compared to the previous Blitz language? Pardon the pun, how'd we get around it.

It's because it isn't a bug, and there were more than enough explanations as to the behaviour.

I apologise for not giving a reason for locking. This one is being moved because it isn't a bug report.

I imagine the differences between Bmax and other versions of Blitz will probably be related to it being cross platform. But I might be wrong.

More info here:
http://www.blitzbasic.com/Community/posts.php?topic=43861

The reason Blitzmax probably doesn't round floats when printing, is because if it did then you couldn't print the real float value.

Hm.. I tried to make a round function or you, and it might work in Blitzmax, (assuming int rounds up/down... if not maybe there is a round commands in bmax) but it seems to work oddly in Blitzplus.

 x#=13.12345 
Print x#
Print Round#(X#, 1)
Print Round#(X#, 4)
Print (X# * 10.0^4)
Print Int(X# * 10.0^4)

WaitKey()

Function Round#(N#, DecimalPlaces)
	Return Int(N# * 10.0^DecimalPlaces) / 10.0^DecimalPlaces
End Function

The odd thing is the last two print statements.

The first one returns 131235.0 The second one returns 131234.

Here's why it's odd:

We start with:
13.12345

We multiply by 10^4 ... 10,000

Which should give us:
131234.5

So far so good. Now when we print X#, we get:
131235.0

Okay... that appears to be rounded up from 131234.5... Maybe that is intentional. No problem.

But wait!

If X# equals 131234.5, and print rounds it up, and int() is supposed to round floats up too, then why do we get:
131234

When we print int(x#) instead of x#?

I understand if Blitz rounds up when it prints values... But if INT is also supposed to round up, then why doesn't the value match the one printed without int, and presumably also rounded up?

I'll be using the method HERE

Bingo.

BlitzMax's float->string conversion attempts to produce the most accurate representation of the underlying value as possible.

So it should now be possible to write a float to a file, as a string, and read back exactly the same value - an oft. requested feature of Plus/B3D etc.

I didn't really give this much thought pre Max, but I now feel strongly that this is the only sane approach for a 'built-in' float->string conversion to take.

What Blitz could use is a 'print using' command that's present in most other BASIC's, which allows you to convert a number to a string using a specific pattern, e.g.

##,###.##

etc.