Float Expression Bug

Please report bugs in this group. We will maybe populate a list of known bugs with a possibly modified description at a later time.

Moderator: Support

Post Reply
User avatar
Naggar
Posts: 138
Joined: 22 Dec 2016, 14:02
Location: Dubai, United Arab Emirates

Float Expression Bug

Post by Naggar » 23 Sep 2017, 13:19

Hi team

I encountered a bug with the float expression node. please see attached screenshot.
If I use numbers (1920/1080) instead of the variables (A/B) in the expression : I get integer instead of float in the result output.

Best Regards.
Attachments
Float Expression - Error.jpg

User avatar
lerou
Posts: 334
Joined: 06 Sep 2013, 07:14
Location: Hamburg, Germany

Re: Float Expression Bug

Post by lerou » 25 Sep 2017, 08:38

Hi,

that's not a bug. If you're writing

Code: Select all

1920 / 1080
you're using integer - the result will then be cast to float - after it's already truncated. If you're using the parameter fields - they are defined as float, so they are implicitly cast to float. You could do:

Code: Select all

1920.0f / 1080.0f
to use floats or

Code: Select all

1920.0 / 1080.0
to use doubles (the result will be cast to float).

cheers,
rou

User avatar
Naggar
Posts: 138
Joined: 22 Dec 2016, 14:02
Location: Dubai, United Arab Emirates

Re: Float Expression Bug

Post by Naggar » 26 Sep 2017, 06:32

Ok, I was unaware of that.

Thanks :)

chriss0212
Posts: 665
Joined: 18 Jan 2012, 20:56
Location: wuppertal
Contact:

Re: Float Expression Bug

Post by chriss0212 » 26 Sep 2017, 08:21

But what is not realy consequent is, that 10/A is possible ;)

Greetings

Christian

User avatar
Götz_B
Posts: 180
Joined: 21 May 2013, 13:01

Re: Float Expression Bug

Post by Götz_B » 26 Sep 2017, 09:30

chriss0212 wrote:But what is not realy consequent is, that 10/A is possible ;)
That is because input property A is explicitly defined as float.

User avatar
lerou
Posts: 334
Joined: 06 Sep 2013, 07:14
Location: Hamburg, Germany

Re: Float Expression Bug

Post by lerou » 27 Sep 2017, 07:04

It is super consistent - IF you know that the input field is basically interpreted as C# code. And in C# the casting behaves as it does in most languages :)

User avatar
Eric_RD
Posts: 103
Joined: 04 Jun 2014, 14:01
Contact:

Re: Float Expression Bug

Post by Eric_RD » 27 Sep 2017, 15:12

sorry christian i am with rou in this point ;)

chriss0212
Posts: 665
Joined: 18 Jan 2012, 20:56
Location: wuppertal
Contact:

Re: Float Expression Bug

Post by chriss0212 » 28 Sep 2017, 09:46

Hi...

i haven't said, that it is not consistent! It's just not easy to understand for a beginner that A/B is ok even if A and B is an int, but A/10 is not allowed ;)

I am really happy that Ventuz is doing all the conversions by using nodes... but i think a lot beginners (and sometimes me too) would be happy, if an int used in a expression would be converted too ;)

For the moment i can't see any disadvantage because in both cases the expression node is dealing with 2 integer's. But maybe there is?

Greetings

Christian

User avatar
lerou
Posts: 334
Joined: 06 Sep 2013, 07:14
Location: Hamburg, Germany

Re: Float Expression Bug

Post by lerou » 28 Sep 2017, 12:44

I get your point, I do. Two reasons to keep it this way:

1. it's like in coding languages, so every coder knows. I'm a coder, so I'm biased ;) I know that beginners find it more difficult. BUT: You should always use the inputs - that's just cleaner than typing in 1920/1080 :)

2. To achieve your behaviour, Ventuz would have to write their own parser/compiler. Currently they most likely don't and just use C# - which is the better solution (far safer in terms of errors and standard behaviour).

But again, I get where you're coming from.

cheers,
rou

User avatar
Karol
Posts: 603
Joined: 10 Jan 2012, 12:07

Re: Float Expression Bug

Post by Karol » 28 Sep 2017, 13:46

Rou is right!
And he listed the arguments why we won't change this behaviour.

Cheers
Karol

Post Reply