# Convert Double to Integer?

Hello

how can i convert a double to a integer in a rule?

thx

`double.intValue` will do the conversion by stripping off the decimals. To round, add 0.5 first, `(double + 0.5).intValue`.

Or use `Math::round(decimal)`. Note that if you pass in a double you will get back a long. If you pass a float you will get back an int.

By default the Rules DSL stores everything as a BigDecimal which has intValue like Scott indicates. However, if you are explicitly using a primitive double you will have to use Math::round().

The correct answer will depend on context.

Hi Rich,

I tried to follow your suggestion with round, where m is 2 in this case

``````var Number hour = now.getHourOfDay
var float c = (((m * 24) + 12 - hour) / 3)
var int x = Math::round(c)
``````

This works to round e.g. a fixed value of 15.1 to 15.
But if I use c instead, I get:

``````2019-02-19 19:40:20.723 [INFO ] [smarthome.model.script.weather.rules] - hour: 19
2019-02-19 19:40:20.738 [INFO ] [smarthome.model.script.weather.rules] - c: 13.66666667
2019-02-19 19:40:20.744 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'daily forecast DayX (toda': An error occurred during the script execution: Could not invoke method: java.lang.Math.round(float) on instance: null
``````

EDIT:
It does not work if c is double:

``Rule 'daily forecast for DayX': An error occurred during the script execution: Could not invoke method: java.lang.Math.round(double) on instance: null``

If you look closely at the first error you will see that Math::round requires a float, not a double. Use c.floatValue.

Thanks - I will try that.
I thought, because c is defined as float above it is float already!?

But itâ€™s not working either:

``````var float c = (((m * 24) + 12 - hour) / 3)
``````

`An error occurred during the script execution: Could not invoke method: java.lang.Float.floatValue() on instance: 13.33333333`

but if I remove the float in the definition of c it works.

``````var c = (((m * 24) + 12 - hour) / 3)
``````

As a general Rule, it is better in Rules DSL not to be specific until you have to be. In this case, just let the type of c be whatever Rules DSL decides it should be after the calculation (which would be BigDecimal) and only convert it to a float (or anything else more specific) when you have to (e.g. the call to Math:round).

Besides strange type errors like you are seeing here, directly creating primitive variables can add minutes to your Rules parsing time on an RPi and should therefore be avoided.

Unlike what many of us were trained to do and what seems the right thing to do, in Rules DSL, not specifying type unless you have to is better than specifying the type everywhere.

@NCO, have you seen this? Looks like you may be doing the same thing.

Alright, thanks Rich.
I will keep this in mind and will review my code for similar potential improvements.

Hey, Scott.
Youâ€™re smart and recognized right away what I was after

Thanks, I know your thread, but would like to avoid the experimental rule stuff (which is mandatory for your approach, right?)
So I wanted to create a â€śregularâ€ť rule to simulate my daily forecast.

Yes, you would need the NGRE and Jython. Once the IDE setup is functional again, Iâ€™ll be able to complete Jython scripted Actions, make a bundle for Jython, and package the rule up as a template available in the marketplace. Will be much easier! IMO, it would be much less effort to setup Jython than rebuilding this in the DSL. Have you created the 600+ Items yet?! My script will do that for you.

Either way, good luck and let me know if you need anything. Iâ€™m actually sitting here testing an update where Iâ€™m iterating the Channels so that new Items will be created when the OWM binding is updated. So, my head is full of OWM ATM.

The real â€śexperimentalâ€ť part is defining Rules through PaperUI/JSON. The engine that runs both PaperUI/JSON Rules and JSR223 Rules is the same so it does become confusing. But defining Rules using .py files is supported quite well and not at all what Iâ€™d call experimental. And thanks to the efforts of Scott, becoming better every day.

I do not hesitate at all to recommend giving it a try.

Thanks guys. @rlkoshak @5iver

Isnâ€™t NGRE about creating rules in PaperUI?
I just use the regular like .rules to keep everything close together for better transparency.

Anyway, you are most probably absolutely right and I am just looking for a â€žBestâ€ś approach for me (and my capabilities

@5iver:
I did not create that many items, because I just focus on the crucial ones for me.
Temp, condition, rain and few others.

Be assured, that I will keep a close look on your progress.