I have been developing a BigFloat class for Xojo and need the capability of converting both Xojo Doubles and Integers to the BigFloat class. I have created an operator_convert method for doubles, integers, and strings. The issue that I am having relates to having an operator_convert for both doubles and integers. When I compile the compiler complains that it is unable to decide which convert method to use regarding doubles and floats. This occurs even when a constant has a decimal point, which I thought surely would be considered a double. Am I doing something wrong or is it impossible to have convert methods for both integer and double in the same class without conflict? For the present I have left only the double operator_convert method in and am explicitly calling a method to convert from integers. This was a hard choice to make since I have many many places where conversions take place. Letting the conversions from integer to double go without calling a conversion routine would result in wrong computations in the many cases where integers do not convert exactly to doubles.
Anyone else have experience in this regard or have suggestions? I really wish Xojo behaved more like C++ sometimes.
Bill
Ok, I found a solution that seems to work for integer, double and string (see code block at the end). It appears that if the only method in your operator_convert is a conversion from variant you can handle all data types in one go.
I still have an issue with converting items stored in a ‘pair’. For example, the following lines create an illegal cast exception at the fourth line.
dim pair1 as pair
pair1 = 1 : 2
dim bigfloat1 as apm_float
bigfloat = pair1.right
Changing as follows works.
dim pair1 as pair
pair1 = 1 : 2
dim bigfloat1 as apm_float
bigfloat = ctype(pair1.right, integer)
At runtime I get the illegal cast exception before I enter either a constructor or operator_convert method so it appears that the compiler is generating code that is preventing the conversion.
Note that the above code also works if I convert from an integer variable. Filling a pair with an integer variable however still does not work.
Has anyone had experience with converting items in pairs to another class?
// construct a new APM_Float from variant
me.digits = new MemoryBlock(0)
dim vtype as integer
dim d as double
dim i as int64
dim s as string
vtype = num.Type
if vtype = variant.TypeDouble then
d = num.DoubleValue
s = str(d)
me.from_string(s)
elseif vtype = variant.TypeInteger or vtype = variant.TypeLong then
i = num.Int64Value
s = str(i)
me.from_string(s)
elseif vtype = variant.TypeString then
s = num.StringValue
me.from_string(s)
end if
return
If it’s not any of those, should you throw an Exception?
Yes, I should, but in the case of getting a value from a pair, I am not even getting to the operator_convert method. The illegal cast exception is getting thrown when I ‘step in’ in the debugger.
The problem is passing in a Variant to Operator_Convert(v As Variant). Seems that would be the perfect type, but I guess the Runtime gets confused somehow.
[code]dim c As Class1 //has Operator_Convert(v As Variant)
dim v As Variant = 2
c = v //illegal cast[/code]
[quote=20099:@doofus]The problem is passing in a Variant to Operator_Convert(v As Variant). Seems that would be the perfect type, but I guess the Runtime gets confused somehow.
[code]dim c As Class1 //has Operator_Convert(v As Variant)
dim v As Variant = 2
c = v //illegal cast[/code][/quote]
Thanks, you are absolutely correct. I have filed a feedback report since it appears to be a bug. From doing a feedback search there appears to be many outstanding problems with variants.
<https://xojo.com/issue/28146>
Unless there is some reason that you must create this BigFloat class yourself, have you looked at Bob Delaney’s plugins. In particular the “fp Plugin” which adds four new data types to Xojo. BigInteger, BigFloat, BigComplex (made with two BigFloats) and BigFraction. He doesn’t charge anything for his plugins. You can see them at:
delaneyrm.com
Sorry, I tried the link function and never got anything that looked like a proper link, probably because I am not a forum guru.
The “fp Plugin” datatypes have no limit as to their size other than memory if I remember correctly.
[quote=20272:@Harrie Westphal]Unless there is some reason that you must create this BigFloat class yourself, have you looked at Bob Delaney’s plugins. In particular the “fp Plugin” which adds four new data types to Xojo. BigInteger, BigFloat, BigComplex (made with two BigFloats) and BigFraction. He doesn’t charge anything for his plugins. You can see them at:
delaneyrm.com
Sorry, I tried the link function and never got anything that looked like a proper link, probably because I am not a forum guru.
The “fp Plugin” datatypes have no limit as to their size other than memory if I remember correctly.[/quote]
I actually have collaborated with Bob quite a bit and have sent him a few bug reports on RBCalc and have discussed algorithms on several occasions. My intent is to have two very good math packages available (his and mine). I started my project quite a few years ago just to satisfy my curiosity on how arbitrary precision worked. My first attempt was to build a Realbasic plugin but could not understand the plugin framework well enough to do so. I ended up building a plugin for Livecode ( a Xojo competitor) based on another code base (Mikes Arbitrary Precision Math Library). It worked well enough that I decided to make another try to port it over to Realstudio which I did. Then after my abilities with Realstudio improved I became to believe that it would be possible to develop a library from pure Realbasic (now Xojo) code and it would be fast enough to be useful. I have done that now and am pleased to say that the module that I have created has many methods that are as fast or faster than in Bob’s plugins. One of my goals was to use no external libraries or plugins. I don’t have anything against plugins but wanted to cater to those who want pure Xojo code with no externals. My Bigfloat equivalent is finished with 80+ functions and I am now beginning a Biginteger class that I should have an initial cut at in a few weeks. In a few months I intend to make another post on this forum to see if there is interest in supporting this capability as free open source. I am excited about the proposition of LLVM and the speedup that it may provide. I expect that LLVM could be a game changer for Xojo and could result in other developers moving more of their code base from plugins to pure Xojo code.