Converting variable types

[User_Russian]

I propose to add functions, converting variable types.
For example.

Code: Select all

a.f=10.5
x.l = 10 * 2 + Long(a/2)

The expression "a / 2" is calculated as a Float, and the rest as Long.
Currently, PureBasic calculated such an expression as Float.

This comparison also occurs as a Float.

Code: Select all

a.f=10
x.l = 10

If a=x
  Debug "OK"
EndIf

Reliable explicitly convert Float to Long, and compare.

Code: Select all

a.f=10
x.l = 10

If Long(a)=x
  Debug "OK"
EndIf

Type conversion, as well to avoid mistakes comparison with unsigned types. http://www.purebasic.fr/english/viewtop ... 95#p296495

[Danilo]

Reliable explicitly convert Float to Long, and compare.

Code: Select all

a.f=10
x.l = 10

If Long(a)=x
  Debug "OK"
EndIf

You can do this with Int():

Code: Select all

a.f=10.5
x.l = 10 * 2 + Int(a/2)

;-----------------------

a.f=10
x.l = 10

If Int(a)=x
  Debug "OK"
EndIf

[Michael Vogel]

Would also like things like Integer(), Long() etc. from time to time, which would allow easier control when combining different variable types in a formula.

[luis]

Could be nice to have casting, also for structured pointers.
All this was already requested in the past but I think it's not very meaningful asking for this kind of things when the compiler generate wrong code as it is in some occasions, and all this would just add further complications when evaluating expressions.

[skywalk]

As Danilo said, we have Int() and IntQ() and Procedures() for the rest?

Code: Select all

Procedure.l D_L(x.d)
  ProcedureReturn x
EndProcedure

[blueznl]

In the beginning I was struggling also with type casting, but I'm not so sure anymore it actually matters. Once you got the logic of PureBasic's 'expression evaluation' down it starts making some sense.

Though I (from an intellectual point of view) KNOW that 2.5 and 3.5 are internally converted to binary floating point, I'm still puzzled by the fact that in good ol' GFAbasic the following code would output 1.4 (and that's what my calculator outputs as well) whilst in PureBasic it would output 1.39999997615814.

a.f = 3.5
b.f = 2.5
c.f = a.f / b.f
Debug c.f

In the opposite direction the output is as expected...

a.f = 2.5
b.f = 1.4
c.f = a.f * b.f
Debug c.f

Now Fred is perfectly right. When converting floats to binary floating point, some numbers might not be exactly representable by the binary floating point expression.

This, however, begs the question: how do other languages pull that trick? Why would they be able to pull the proper divide whilst PureBasic cannot?

I sometimes suspect that this is done by manipulation the mantissa as opposed to the exponent (I hope I got the expressions right), ie.

14x10^-1 is the same as 1.4x10^0, but one might be expressed in FP binary whilst the other might not? (This is not my field, so I might be entirely talking nonsense ) Nevertheless, fact is: some languages report 3.5 / 2.5 as 1.4, and PureBasic does not. (Frankly, it's a bit of a bummer, and does cause some concern when doing financial stuff.)

[Michael Vogel]

Skywalks idea using procedures is quite good and seems to work fine...

Code: Select all

Procedure.i Long(a.i)
	ProcedureReturn a
EndProcedure

d.d=2.50
f.f=d
Debug Long(f)<<1
Debug Long(d)<<1

I also agree to Blueznl, that PB's calculating abilities are not perfect, I often have to use doubles to get acceptable results in PB when using formulas tested with lower precision on other systems (Aribas, GFA etc.).

As far as I remember, there's not a big problem with the binary representation of numbers like 2.5 so the dividing routine seems to be the only reason for the observed results...

Code: Select all

Procedure ShowFloat(n.f)

	Protected i
	Protected s.s

	For i=0 To SizeOf(n)-1
		s+RSet(Hex(PeekB(@n+i)&$FF,#PB_Byte),2,"0")+" "
	Next i

	Debug s

EndProcedure

a.f = 3.5
b.f= 2.5

ShowFloat(a)
ShowFloat(b)

For i=1 To 5
	Debug a/b
	a/10
	b/10
Next i

[coco2]

One can assume that PB is using pure binary floating point datatypes which means its working correctly . Youll need to write your own decimal floating point routines or put a request in to Fred for PB to natively support it.

Edit2:

Code: Select all

Debug 0.1
Debug 0.2
Debug 0.3
Debug 0.4
Debug 0.5
Debug 0.6
Debug 0.7
Debug 0.8
Debug 0.9

Outputs:
0.10000000000000001
0.20000000000000001
0.29999999999999999
0.40000000000000002
0.5
0.59999999999999998
0.69999999999999996
0.80000000000000004
0.90000000000000002
1.1000000000000001

Edit3:
The early computers all had exact decimal floating point arithmetic because they were all marketed at the home user to do financial calculations, as are desk calculators. PureBasic is marketed as a game programming language. Even a lot of scientific and engineering software could get away with binary floats to a degree, it's only financial software that requires absolute decimal precision.

[Danilo]

PureBasic is marketed as a game programming language.

LOL

[coco2]

Haha I know

Maybe it's a translation thing but this in English:

- Easy but very fast 2D game support through dedicated libraries (DirectX, SDL, ...)

Strongly implies it was based around creating games by implying the main use of those libraries is for games.

A better way to put it would be:

- Easy but very fast 2D multimedia support (including games) through dedicated libraries (DirectX, SDL, ...)

[Danilo]

Of course PB is a game programming language, if you ignore all libs for application developers.

[coco2]

I looked but they all went "404" when I clicked on them

[coco2]

Also need to move general discussion to be ABOVE game programming in the forum :/

But anyway I agree it's not all about games, I hope (and believe) one day it will be widely recognised.