something useful here
result = CType (value, datatype)
https://documentation.xojo.com/api/language/ctype.html#ctype
if me use a float math i input values always with at least .0
usually float * float result in float
automatic type conversion should be optional.
My dear, read the thread, specifically what Iâve wrote and the examples. The âintegerizationâ is a silly thing only existing here due to a defective and incomplete expression evaluator missing RTTI to take care of dynamic parts as Variants.
We donât need workarounds to fix broken apps, we need the system doing what universally is expected and not silently breaking apps. That can be reached as already explained if we get:
Iâm not sure what makes you think I havenât read the thread. Xojo state that the default for variant, without a specifier is to match the type. I am explaining the difference between an integer constant and a floating point one.
It is not a bug. It is clearly documented behaviour. It is also something that would happen in FORTRAN. Which has the same constant type distinction. If you care for your outcome never use a variant without a type specifier.
Repeating a debunked silly argument.
in Xojo speech âby designâ
This another silliness was already debunked too.
Quoting your own opinion as fact is not a good look, buy yet you persist.
From Fortran - Data Types
Implicit Typing
Older versions of Fortran allowed a feature called implicit typing, i.e., you do not have to declare the variables before use. If a variable is not declared, then the first letter of its name will determine its type.
Variable names starting with i, j, k, l, m, or n, are considered to be for integer variable and others are real variables. However, you must declare all the variables as it is good programming practice. For that you start your program with the statement
So in fact using v = 6.77 is considered a real variable (not integer nor variant). You can change your code to use j, k, l, m or n and the result will be different (6000).
You are correct, so to avoid mistakes like that allowing unexpected silent fails thereâs an statement that we put on top of the program, likewise as what I proposed for Xojo and Variants, that does not allow such kind of mistakes
And Xojo documentation shows what we need to do to avoid silent fails when an operator is a variant and the other is an integer (and we expect double).
Letâs say we all agree this is a bug.
Xojo instead of fixing the bug decided to put in the documentation the workaround.
For me, that means that they will not change this behavior. More so that it is working like this for many years.
Good luck to you in trying to change this.
You guys need to stop acting like slaves. Sometimes we are the teachers here, not the pupils, and Xojo should learn, and not dictate what you should blindly abide (and many of you are bovinely used to it) even if such thing is completely wrong.
This preconceived âthey wonât listenâ will kill the community.
There are ways to fix, the easy one is above, forbidding it. The best one is fixing the evaluator, but we can wait a bit for it with that switch alerting the potential problem being done first.
As I noted in the Issue, this also happens with doubles, so itâs not specific to the Currency data type:
dim c as double = 1.56
dim v as variant = c
dim d as double = v * 1000 // result is 1000, not 1560
That has been said before in the thread.
Interesting, if you turn on all Analysis Warnings⊠you do get a warning, but it seems incorrect:
I wonder if the expression evaluator has a bug, where itâs defaulting to Int64 for Variant parameters?
Easy fix by following the documented workaround:
dim c as double = 1.56
dim v as variant = c
dim d as double = v * 1000.0 // result is 1560
I donât get that warning if I use 1000.0 instead of just 1000
Using 1000:
Using 1000.0:
So I guess the Analyze Project knows that v will be converted to Integer as the documentation says (if using 1000 instead of 1000.0)
I suggested making it an Error that can be enabled or not. Once enabled, it should not run or build as it does today.
I agree with @Rick_Araujo that this is very weird, unexpected and dangerous behavior. I also agree with @AlbertoD that the documentation does address this:
âVariants used in an expression convert themselves to the type of the other operand, no matter what kind of data they contain, instead of deferring the type-conversion until runtime. This only affects expressions involving a Variant operand and an operand of some other type, not expressions in which both operands are variantsâ
(emphasis mine)
However, I think thereâs a documentation bug here, because it says:
Consider the following example:
Var v As Variant = 0.5
The comparison:
If v > 0 Then
returns False since v is being treated as an Integer and will round down to 0.
This implies that the interger conversion is rounding.
But if you do a simple test, the integer conversion is clearly Truncating:
var v as variant = 1.6
var n as integer = v // v is 1 here, not 2 as you might expect if the double was rounded to integer
So, does Variant to Integer conversion Round or Truncate?
Yes, using round down is not clear. I could expect that it always âround downâ (1.6 became 1) but how about -1.6 (the conversion will be -1)