[Implemented] Doubles

geoff · Post by **geoff** » Wed Jun 11, 2003 9:15 pm

OK, I know this has been mentioned a thousand times before but the myriad of games functions introduced this last 6 months leave me wondering why maths has such a low priority.

PureBasic may be great for games, I am not qualified to judge, but without accurate maths the language is not a serious contender for many applications. I was asked recently whether I would recommend PureBasic for a commercial application a friend was planning and I couldn't do so because of this single shortcoming.

Fred has promised doubles for version 4.0 but have we any idea when this will be released? Can we be certain it will be released?

Post by **freak** » Wed Jun 11, 2003 10:59 pm

Just a question...

Why do you bring this up again?
You know this has been discussed a lot, an you know all the answers.
So what do you think, will be different this time?

I'm just curious...

Timo

geoff · Post by **geoff** » Thu Jun 12, 2003 4:08 pm

and you know all the answers

Not really Timo, I've no idea when we will see 4.0.

IMO accurate floating point is the single feature that will transform PureBasic into a general purpose programming language. I can't understand why so many things have taken priority over this.

There are several compilers that are only suitable for games application. Why relegate PureBasic to this role for the sake of a single missing feature? Alternatively, Fred could add another hundred games features over the next year and users would still be asking for more or claiming one of the other games languages had something extra or was faster or whatever.

Fast, accurate maths is essential for many applications, there is no practicable work-around for this omission.

I'm trying to be constructive here.

gnozal · Post by **gnozal** » Thu Jun 12, 2003 4:24 pm

I agree ; waiting for reliable floats since PB2.30

tinman · Post by **tinman** » Thu Jun 12, 2003 4:27 pm

geoff wrote:Fast, accurate maths is essential for many applications, there is no practicable work-around for this omission.

The solution is simple: tell Fred you are writing a 3D game and you need doubles because of the precision and that the other compiler XYZ already does this ;p

fsw · Post by **fsw** » Thu Jun 12, 2003 6:18 pm

tinman wrote:
geoff wrote:Fast, accurate maths is essential for many applications, there is no practicable work-around for this omission.
The solution is simple: tell Fred you are writing a 3D game and you need doubles because of the precision and that the other compiler XYZ already does this ;p

OK

Here it goes:

Fred, I'm not writing a 3D game but I need doubles anyway because of the precision and the other compiler (XBasic and XBlite) already does this for free.

There I have:
SBYTE Signed byte (8-bits)
UBYTE Unsigned byte (8-bits)
SSHORT Signed short (16-bits)
USHORT Unsigned short (16-bits)
SLONG Signed long (32-bits)
ULONG Unsigned long (32-bits)
XLONG Natural long (32/64-bits)
GIANT Signed giant (64-bits)
SINGLE IEEE Single Precision Floating Point (32-bits)
DOUBLE IEEE Double Precision Floating Point (64-bits)
STRING String of unsigned bytes (characters)
SCOMPLEX Single Precision Complex (Two SINGLEs)
DCOMPLEX Double Precision Complex (Two DOUBLEs)

8O

BTW: was this funny enough

XBasic and XBlite are open source and they compile to assembler - maybe some asm guru could look how it's done...

freedimension · Post by **freedimension** » Wed Jun 25, 2003 1:28 pm

fsw wrote:SBYTE Signed byte (8-bits)
UBYTE Unsigned byte (8-bits)
SSHORT Signed short (16-bits)
USHORT Unsigned short (16-bits)
SLONG Signed long (32-bits)
ULONG Unsigned long (32-bits)
XLONG Natural long (32/64-bits)
GIANT Signed giant (64-bits)
SINGLE IEEE Single Precision Floating Point (32-bits)
DOUBLE IEEE Double Precision Floating Point (64-bits)
STRING String of unsigned bytes (characters)

FullACK. We definitely need these types. Let's start with the 64-Bit Types.
I too don't need those fancy 3D-Functions etc. as long as there's no stable basis implementing large numbers.

As to Freak: This is supposed to be like in the open market: Demand determines Supply. So we can't overemphasize it.

wcardoso · Post by **wcardoso** » Wed Jun 25, 2003 5:33 pm

Fsw:
Sorry, but XBasic isnÂ´t a really compiler to assembler code to create a native exe file, he need the xb.dll at runtime to work together.
In spite of it, his support for number types and math is superb !. Nice tool

Post by **freak** » Wed Jun 25, 2003 6:33 pm

@freedimension:

I'm not going to start this discussion again.
I don't like repeating myself...

Timo

fsw · Post by **fsw** » Wed Jun 25, 2003 6:44 pm

wcardoso wrote:Fsw:
Sorry, but XBasic isnÂ´t a really compiler to assembler code to create a native exe file, he need the xb.dll at runtime to work together.
In spite of it, his support for number types and math is superb !. Nice tool

XBasic and XBlite create assembler files (with the file extension .s).
These assembler files are compiled to exe under Windows with spasm.exe.

So these are native exe files (not p-code that must been interpreted...).
But as you mentioned they need a DLL, because the Commands are not linked into the main exe.
XBasic's needed DLL brings all commands and a complete GUI in it. This DLL is really huge ~2.5MB.
XBlite uses a DLL with ~180KB and it has only the most important commands in it.
Other commands are stored in different smaller DLL's.
But you can (if you wish) link the xb.obj into your main exe, this said an exe would have ~200KB minimum.
It uses Windows API for the GUI (runs only on Windows). So you need a good knowledge of this API.

As you can see, these Basics create real native exe files.
The use of these DLL's is like you would code a program in PureBasic but you need let's say MODBASS.DLL for your application.
Your PureBasic exe is still native (not interpreted...) but needs a DLL.

I suppose this is the best you can get for free.

If PureBasic would have all goodies from these Basics,
than supposedly PureBasic would rule the BASIC world...
I hope it's only a matter of time