It is currently Mon Jun 24, 2019 6:53 pm

All times are UTC + 1 hour




Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Comparing integer and float (or double) variables
PostPosted: Thu May 29, 2014 5:05 pm 
Offline
Addict
Addict
User avatar

Joined: Sat Apr 26, 2003 8:26 am
Posts: 2916
Location: Planet Earth
Demivec wrote:
The only description I found in an official reference was in the help manual:
Help file under 'General Rules' wrote:
Expressions

An expression is something which can be evaluated. An expression can mix any variables, constants, or functions, of the same type. When you use numbers in an expression, you can add the Keyword $ sign in front of it to mean a hexadecimal number, or a Keyword % sign to mean a binary number. Without either of those, the number will be treated as decimal. Strings must be enclosed by inverted commas.


That seems to say that comparisons of different types is already inviting trouble. An easy solution to this is to convert the types to a common type. Suggestions to do this have included using the function Int() or Round(), instigating automatic conversion by adding 0.0, and using assembly to invoke the FPU.

That's it, thanks for clarification.


Top
 Profile  
Reply with quote  
 Post subject: Re: Comparing integer and float (or double) variables
PostPosted: Thu May 29, 2014 5:22 pm 
Offline
Addict
Addict
User avatar

Joined: Wed Aug 31, 2005 11:09 pm
Posts: 3694
Location: Italy
To make life easy for the language, and for the compiler, all expressions should contain data of the same type, it's intuitive why.
Operations involving the same type of data are consistently predictable and you don't have to stipulate some rule to choose what to convert and what not, and you don't have to face the problem of what to do when you can potentially lose data during the conversion because something doesn't fit somewhere else.

Since this requirement can be relaxed by sensible implicit casting 90% of the time, usually languages provides for that in some form.

Implicit casting poses some risks but knowing how the implicit casting works in a specific language the programmer can think about those risks and build the expressions accordingly by storing the appropriate range of values in the appropriate data type. When all is done well all works smoothly and you can happily mix data types.

But the compiler, being a compiler, and so by definition accessing those expressions at compile time and not at run time, doesn't know if you are storing sensible values in the variables involved in the expression, and so someone invented warnings (ok not just for this). When an implicit conversion made by the compiler to make possible to evaluate a mixed expression could lead to data loss, the compiler emit a warning. The programmer can ignore them because he knows the range of values stored at runtime will not give problems, can use explicit casts to silence them if possible/appropriate, or he can make adjustment in the code or data type if this is something he hadn't considered and the compiler just saved him with its warning.

Now, there are rules well accepted on how implicit conversions should work. Books were written about it, compilers used not only by indie/hobbyist programmers has been written following those rules for the last 40 years. They follow a common pattern which work well.

In the case exposed in the original post, again is intuitive that if you want to do some implicit casting (instead of stopping the compilation cold complaining the data types are not the same)

If [7] < [7.4]

should be treated by converting the 7 to 7.0 and then performing the comparison and not by mutilating the 7.4 coercing it to an integer.

The literature on the subject agrees on that, this example viewtopic.php?p=445209#p445209 agrees. PB does not.

So, all boils down to this:

PB it's a very simple and rigid compiler. Keeping this in mind why Fred adopted this simple left to right rule for implicit casting instead of evaluate the actual types involved one sub-expression at the time and going on from there ?
Probably because it was the easiest way to implement some kind of casting, just to not force the programmer to write expressions composed by only a single data type.

The shortcomings of this apparently arbitrary rule are what we see here.

Also see the similar case with the shift ( << ) of the integer resulting in a error because the leftmost variable is a float.

Emphasis should be given in the manual about these peculiarities, and this left to right implicit conversion rule should be printed in BOLD between two WARNING red banners, so that an aspirant PB adopter could

1) run away screaming and later talk about it in another language forum to the disbelief of his peers
2) accept it because he can live with it and write software despite it, shaking his head from time to time
3) say "So what ?" because this does not really mean anything to him and it's just happy with all the other positives PB offers, not last its simplicity.

_________________
[ My little PureBasic review ]


Top
 Profile  
Reply with quote  
 Post subject: Re: Comparing integer and float (or double) variables
PostPosted: Fri May 30, 2014 2:47 am 
Offline
Enthusiast
Enthusiast

Joined: Mon Nov 25, 2013 5:38 am
Posts: 250
Location: Australia
If going by the leftmost value means faster compile time then I vote in favor of it. One simple does not have time to wait around for slow compiles. It is the main reason I chose PB for its speed.


Top
 Profile  
Reply with quote  
 Post subject: Re: Comparing integer and float (or double) variables
PostPosted: Fri May 30, 2014 10:56 am 
Offline
Addict
Addict
User avatar

Joined: Wed Aug 31, 2005 11:09 pm
Posts: 3694
Location: Italy
Absolutely, and removing other stuff would make it even faster. Are parenthesis that useful ?

_________________
[ My little PureBasic review ]


Top
 Profile  
Reply with quote  
 Post subject: Re: Comparing integer and float (or double) variables
PostPosted: Fri May 30, 2014 11:54 am 
Offline
Addict
Addict
User avatar

Joined: Sat Apr 26, 2003 8:26 am
Posts: 2916
Location: Planet Earth
We need to use something like this:
Code:
EnableExplicit

Procedure.b ToByte(byte.b)      :ProcedureReturn byte   :EndProcedure
Procedure.a ToAscii(asc.a)      :ProcedureReturn asc    :EndProcedure
Procedure.c ToCharacter(char.c) :ProcedureReturn char   :EndProcedure
Procedure.w ToWord(word.w)      :ProcedureReturn word   :EndProcedure
Procedure.u ToUnicode(uni.u)    :ProcedureReturn uni    :EndProcedure
Procedure.l ToLong(lng.l)       :ProcedureReturn lng    :EndProcedure
Procedure.i ToInteger(int.i)    :ProcedureReturn int    :EndProcedure
Procedure.q ToQuad(quad.q)      :ProcedureReturn quad   :EndProcedure
Procedure.f ToFloat(flt.f)      :ProcedureReturn flt    :EndProcedure
Procedure.d ToDouble(dbl.d)     :ProcedureReturn dbl    :EndProcedure

Procedure.b Byte(byte.b)        :ProcedureReturn byte   :EndProcedure
Procedure.a Ascii(asc.a)        :ProcedureReturn asc    :EndProcedure
Procedure.c Character(char.c)   :ProcedureReturn char   :EndProcedure
Procedure.w Word(word.w)        :ProcedureReturn word   :EndProcedure
Procedure.u Unicode(uni.u)      :ProcedureReturn uni    :EndProcedure
Procedure.l Long(lng.l)         :ProcedureReturn lng    :EndProcedure
Procedure.i Integer(int.i)      :ProcedureReturn int    :EndProcedure
Procedure.q Quad(quad.q)        :ProcedureReturn quad   :EndProcedure
Procedure.f Float(flt.f)        :ProcedureReturn flt    :EndProcedure
Procedure.d Double(dbl.d)       :ProcedureReturn dbl    :EndProcedure

Macro       ToString(number)    : ""+number             :EndMacro
Macro       String(number)      : ""+number             :EndMacro


Define int.i = 1
Define flt.f = 2.5

Debug flt + (int + int)
;Debug flt + (int << 3)
Debug flt + Integer(int + int)
Debug flt + Integer(int << 3)


Define a.i, x.f
a = 7
x = 7.4
If Float(a) < x : Debug "OK" : Else : Debug "Wrong" : EndIf
a = 7
x = 7.00001
If Float(a) < x : Debug "OK" : Else : Debug "Wrong" : EndIf
a = 7
x = 7.00000
If Float(a) < x : Debug "Wrong" : Else : Debug "OK" : EndIf
a = 7
x = 6.99999
If Float(a) < x : Debug "Wrong" : Else : Debug "OK" : EndIf
a = 12345
x = 12345.0005
If Float(a) < x : Debug "OK" : Else : Debug "Wrong" : EndIf

Define s1.s = String(a)
Define s2.s = String(x)
Debug s1
Debug s2

Maybe PB could add such casting functions. Could be inlined/virtual, so the procedure call is not done.

EDIT: Added more.


Last edited by Danilo on Fri May 30, 2014 12:51 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: Comparing integer and float (or double) variables
PostPosted: Fri May 30, 2014 12:23 pm 
Offline
Addict
Addict
User avatar

Joined: Wed Aug 31, 2005 11:09 pm
Posts: 3694
Location: Italy
Danilo wrote:
Maybe PB could add such casting functions. Could be inlined/virtual, so the procedure call is not done.


I agree, the "manual" approach of explicit casting would not require modifications to the way the compiler works (off the table I fear) and would leave the decision of what to convert and how to the programmer eliminating further bugs due to a possible poor judgement from the compiler. :wink:

It's vital they are made like inline functions. Somewhat similar to the Bool() recently added.

_________________
[ My little PureBasic review ]


Top
 Profile  
Reply with quote  
 Post subject: Re: Comparing integer and float (or double) variables
PostPosted: Fri May 30, 2014 4:38 pm 
Offline
Administrator
Administrator

Joined: Fri May 17, 2002 4:39 pm
Posts: 13594
Location: France
It looks like a bug, the whole expression should be considered as float when a float is encountered.


Top
 Profile  
Reply with quote  
 Post subject: Re: Comparing integer and float (or double) variables
PostPosted: Sat May 31, 2014 11:31 am 
Offline
Addict
Addict
User avatar

Joined: Thu Jun 07, 2007 3:25 pm
Posts: 3577
Location: Berlin, Germany
I'm sorry for the delay in replying, I've been out of town for some days.
Many thanks to all for this vivid and interesting discussion.

Fred wrote:
[...] the whole expression should be considered as float when a float is encountered.

I think most PB users would expect it to work that way, thus making this change probably will reduce the bugs in our programs.
Thank you, Fred!

_________________
Please excuse my flawed English. My native language is PureBasic.
Search
RSBasic's backups


Top
 Profile  
Reply with quote  
 Post subject: Re: Comparing integer and float (or double) variables
PostPosted: Mon Jun 02, 2014 6:11 am 
Offline
Enthusiast
Enthusiast

Joined: Mon Nov 25, 2013 5:38 am
Posts: 250
Location: Australia
luis wrote:
Absolutely, and removing other stuff would make it even faster. Are parenthesis that useful ?


My sarcasm meter is twitching slightly. Just to clarify so this is normal compiler behaviour to cast the type to float? I believe some compilers I used previously just rejected the whole thing and refused to go any further.


Top
 Profile  
Reply with quote  
 Post subject: Re: Comparing integer and float (or double) variables
PostPosted: Mon Jun 02, 2014 11:10 am 
Offline
Addict
Addict
User avatar

Joined: Wed Aug 31, 2005 11:09 pm
Posts: 3694
Location: Italy
coco2 wrote:
My sarcasm meter is twitching slightly.


Ummmm.... :wink:

coco2 wrote:
Just to clarify so this is normal compiler behaviour to cast the type to float? I believe some compilers I used previously just rejected the whole thing and refused to go any further.



There is no law. But somewhere some type of casting is needed. Implicit / explicit in expressions, a conversion when assigning a var type to another, the use of a library functions like Int() to do something similar to what casting does, etc ...
Usually compilers do implicit casting as described in this discussion, following the rules sketched here. When a language is ANSI defined or similar (so well defined) and casting is specified as a requirement of the language every compiler must adhere to that if it wants to be compatible with the other compilers and to be considered a valid compiler for the language. If not, could depend on the compiler. For BASIC dialects for example any compiler do as it please, even if exists an ANSI for BASIC, but it's just followed as a starting point or not at all by the current BASICs I know. BASIC in practice is not exactly standardized as C.

_________________
[ My little PureBasic review ]


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

 


Powered by phpBB © 2008 phpBB Group
subSilver+ theme by Canver Software, sponsor Sanal Modifiye