warning loss of precision Double to Integer

General
1

I have a project with a lot of elementary mathematics.
My obsessive side does not like the literally thousands of warnings that I get when I analyze the project.
In many many places, I cast a Double as an Integer with the code

someInteger = Round(someDouble)

The line will fire up a warning - [quote]…leads to a possible loss of precision …[/quote]

The multitude of warnings obscures warnings that I might want to see including cases where I possibly am losing precision.
But there are so many of the warnings associated with the example cited that the whole warning system breaks down.

I could, I suppose,

someInteger = Round(someDouble) \\ 1

or possibly wrap the Round function with my own that returns an integer.

but that does not seem very clear. Is there a better, more straightforward, way to deal with this?

2

nope
Round returns a double
the assignment to an integer results in an implicit conversion - and hence the warning
Making an extension method that returns an Integer would avoid those since you’d no longer get implicit conversions

          Function ToInteger( extends d as double ) as Integer
               return round(d) \\ 1
          end function

maybe
at least this way you only get 1 warning on that line instead of every place you have the implicit conversion going on

3

I guess that you do not even need the \\ 1

It really doesn’t do anything. We can just accept the warning in this one location. So the below should suffice

Function ToInteger( extends d as double ) as Integer return round(d) end function

4

And if you want to get rid of the warning, then perform an explicit type conversion using CType:

Public Function ToInteger(Extends d As Double) As Integer
  Return CType(Round(d), Integer)
End Function
5

I like Palardy’s pushing me to Extends which I have never used in my code. Learned something by employing that.

But then things like Graphics.FillRectangle expect Doubles as Parameters.

If you do something as innocuous as Graphics.FillRectangle(0,0,20, 20) you will get one of these “precision” warnngs.
Trying to avoid them becomes more trouble than it is worth, at least in the project that I am working with. I have 4,500 of this type of warning.

It is interesting that you can select all 4,500 warnings and copy them into a text editor like BBEdit if you wanted to play games like using Regex to find some “important” warnings in the haystack. When you paste, you actually get, as a bonus, the name of the method where the error occurs even though you do not see that in the highlighted text you are copying. Sort of cool.

[quote]winLogicError.BestWidth, line 52
Converting from Double to Integer causes a possible loss of precision, which can lead to unexpected results
totWidth = totWidth * LITTLE_EXTRA

winLogicError.BestWidth, line 53
Converting from Double to Integer causes a possible loss of precision, which can lead to unexpected results
goldenHeight = goldenHeight * LITTLE_EXTRA

RtrnString.rsPercent, line 11
Converting from Int32 to Double causes a possible loss of precision, which can lead to unexpected results
If denominator = 0 Then

RtrnString.rsPercent, line 14
Converting from Int32 to Double causes a possible loss of precision, which can lead to unexpected results
percent = (numerator * 100) / denominator

RtrnString.rsPercent, line 29
Converting from Int32 to Double causes a possible loss of precision, which can lead to unexpected results
Elseif percent < 1 Then

RtrnString.rsPercent, line 33
Converting from Int32 to Double causes a possible loss of precision, which can lead to unexpected results
Elseif percent < 3 Then

…[/quote]

6

it need written as 0.0 20.0

as 100.0

7

Markus: It seems like a bother. But perhaps if my OCD is acting up I should do this. Thanks.

8

i do this sometimes with copy the .0 into clipboard and click with mouse at this place and do ctrl+v

9

Or you can write a graphics extension that takes integers :slight_smile:
since the signature is different its not ambiguous

10

Just be careful when you extend something and not use a word that may be used by Xojo in the future. That way you will not need to ‘fix’ your code to run on that new Xojo version.

11

Its impossible to know what they may / may not add in the future
Unless you have some magic 8 ball that can tell us ?

In fact this is one reason the “Xojo” namespace was created
So Xojo could create things in there and be sure they would not collide with whatever users created but …

12

I’ve posted a small module with conversion from double to the various integers and they will throw an exception of you try to convert a double that exceeds the range of the sized integer

13

[quote=482972:@Norman Palardy]Its impossible to know what they may / may not add in the future
Unless you have some magic 8 ball that can tell us ?

In fact this is one reason the “Xojo” namespace was created
So Xojo could create things in there and be sure they would not collide with whatever users created but …[/quote]
I was thinking a simple ToInteger_mo (mo for my own), then they can come with ToInteger for double without breaking my code.

This serves 2 purposes: 1) Xojo will not use something like that and 2) I (and others) can easily identify that the code is not a native Xojo function

14

Yeah I just dislike weird names like that
I know why Christian does it with MBS but still it just makes my code look odd :slight_smile:

15

<https://xojo.com/issue/59703>

16

Or read the release notes for a new version to see what methods/properties they added or (hopefully not) renamed that conflict with any of yours. Then search/replace those in the previous IDE before moving to the new one. Much like what many had to do / are doing with API 2.0 (though the sheer number of changes in API 2.0 makes this a sizable effort for some projects!).

17

That’s exactly why some may decide to add something at the end of their classes (like MBS) to avoid doing that. Take a look at this thread.

18

Yes, plugins or encrypted third-party classes should use unique names. But in your own code/classes, you can choose whichever way you prefer: nicer names but more possible work later, or weird unique names that should be safe.

19

hmmm,
do you need to display integers, or actually calculate them.
I discovered format(Variable,“0”) the other day