Is :Float and object?

EDIT: Title should be 'Is :Float *an* object'

Actually, are any of the built-in types objects (other than String and arrays, which we know are objects).

Syntactically, they seem to be objects since they are declared with the ':' operator like any other object. But I'm wondering what happens under the hood when you, for example, multiply two objects together.

For example, if :Int is an object, how does the compiler handle something like this:

Local a:Int, b:Int = 3, c:Int = 2
a = b * c

..how are the objects multiplied together?

The reason I ask, is because I'm wondering if it would be possible to create some other low level variable (such as a float variable that acts differently from the built-in one). An exact float representation variable, such as PowerBasic's 'Currency' variable is an example (which uses Binary Coded Decimal - 80 bits - internally to represent floating point variables). The advantage to this variable type is that there is virtually no data loss. For example, 3.2 will be represented internally as 3.2, not 3.200000345 or whatever.

Any ideas?

Thanks,
Russell

The numerical types are not objects.

If they were, with all the baggage that goes along with objects, it would kill performance.

And if you really need a currency data type then I would suggest that BlitzMax is not the appropriate language.

I don't know about PowerBasic, but in Visual Basic currency is not binary coded decimal. It's just a 64-bit integer which represents a value in hundredths of a penny. For example, $28.35 would be represented internally by a long integer value of 283500.

The problem with that approach is that it limits where the decimal can be to some extent.

I guessed that they were not objects for the very reason you state, but thought I'd throw that out there anyway.

You see, what I want to do is write a Frac() function in the style of other basics where it returns the fractional portion of a number. For example, Print Frac(3.2) would print ".2". I've found this difficult to do in BM for several reasons. The main reason is, the floating point number gets converted internally to something else before it even reaches the function (i.e. 3.2 becomes 3.2000345 or whatever) so that if the user sends 3.2 to the function expecting a ".2" back, they instead get ".2000345" etc back.

So I thought maybe I could receive the float by reference instead and examine the number internally, but like I said, it gets "mangled" before it even reaches the function. So then I thought maybe if :Float was an object I could somehow get to the original value through some object property, variable or method. Guess not :(

As far as hurting performance goes, if arrays can remain lean and mean (and they are), then a float/double object could as well since they would not have much functionality needed.

Oh well. Some day I hear BM's source code will be released to the community and maybe something will happen then, if not sooner.

Russell

All the sources are already within the BM directories ... at least all you get.