Create the type REAL like the type INTEGER

[Olli]

Hello, the type INTEGER solves the problem of adaptability between the X86 mode and the X64 mode, for the integer variables.

But, there is no generic type for floating variables. I imagine a new type, in example, named REAL which is 32-bits range on X86 (like FLOAT) and 64-bits range on X64 (like DOUBLE).

Here is a compiler directive demo code :

Code: Select all

CompilerIf SizeOf(INTEGER) = 4

 Macro REAL
  FLOAT
 EndMacro
 
 Macro R
  F
 EndMacro
  
CompilerElse

 Macro REAL
  DOUBLE
 EndMacro
 
 Macro R
  D
 EndMacro

CompilerEndIf

Example code :

Code: Select all

Debug SizeOf(REAL)

Define *A.REAL = AllocateStructure(REAL)
*A\R = 5.5

Define.R B = 6.7

Best regards

[mk-soft]

I wouldn't do it like that.

Always work with defined types, as there is no 100% international agreement here. Except for the standard of the matrix (IEEE774)

Purebasic: Float = 32 Bit, Double = 64 Bit
Automation Type Variant: fltVal = 32 Bit (Float), dlbVal = 64 Bit (Double)
MS SQL-Statement: Float = 64 Bit - float(53), Real = 32 Bit - float(24)
PLC programming (Siemens, Codesys, etc): Real = 32 Bit, LReal = 64 Bit

Real: 32 bit or 48 bit or 64 bit

[skywalk]

I hate Integer as a pass through.
There should be a POINTER type that is transparent if any at all.

[NicTheQuick]

Floats and Doubles are totally different things that Integers. They both use dedicated registers which have nothing to do with the word size of your CPU or the pointer size of the compiled application. It just depends on what you wanna do with it. So in my opinion there is no need for something like REAL.

[mk-soft]

I hate Integer as a pass through.
There should be a POINTER type that is transparent if any at all.

Code: Select all

;-TOP

Structure Any
  StructureUnion
    a.a
    b.b
    w.w
    u.u
    l.l
    i.i
    q.q
    f.f
    d.d
  EndStructureUnion
EndStructure

Define anyVal.Any

anyVal\a = 255
Debug anyVal\b

fltVal.f = 100.0
*pVal.Any = @fltVal

Debug *pVal\f
Debug Hex(*pVal\l)

[skywalk]

Yes, I use the structureunion in several places.
I am saying we Define all variables EXCEPT pointers.

Define *ptrToSomething.i ;<-- Allowed but not everywhere
Define ptrToSomething.i

There should be a POINTER type for consistency.
Define *ptrToSomething.p
I know '*' is the TYPE, but that is special.

[Olli]

For the name of the type, 'real' is an example, not a wish.

Now (for NicTheQuick),

on my computer, on X64 mode, there is no difference of performance between the floats and the doubles.

The code :

Code: Select all

x + 1
x * x
x / 2

... requires near 500 clock cycles to be executed, whatever the precision of the floating point variable (32 or 64 bits). Just the result changes : with doubles, I have a better precision.

What I want is a program which gives near the same results on different configurations.

If a Double precision requires more time to be executed on a 32-bits system (more than +100% of duration), this wish is right.

Else, if a double precision takes not lots of time, on a 32-bits system, this wish is useless.

[NicTheQuick]

Well, these are simple calculations. If you are using vector arithmetic there is quite a difference. But you will only see that difference if Purebasic uses the C-Compiler backend which is able to vectorize such calculations automatically.

[Olli]

Yes, you are right : it could be executed with SIMD.

I note yours answers have incited me to compare :
SIMD ops are very faster than co-processor...

[Olli]

I add a remark :

Add this strange feature, would allow a other new feature :

Code: Select all

; 2nd feature

Debug TypeOf(1) ; would return #PB_Integer value
Debug TypeOf(2.5) ; would return #PB_Real value
Debug TypeOf("hello") ; would return #PB_String value

Being established that this below would return ever one for the three next ways:

Code: Select all

Debug Defined(1, #PB_Immediate)
Debug Defined(2.5, #PB_Immediate)
Debug Defined("hello", #PB_Immediate)

The polymorphism should be available...