inccorect FLOAT or where ###.##?

[Hiller]

Guys!

Code: Select all

a.s = "344.23  355.78  4444.343   2.03" ;read from file
temp.s = Mid(a,1,7) ; 344.23

koef.f = ValF(temp) ; 344.22999999 - :(
...
    AddGadgetItem(2,-1,StrF(koef.f) +" /2 =  "+ StrF(koef/2))

result:
344.22999999 /2 = 172.11499995

need show:
344.23 /2 = 172.115

Question: how?

[GPI]

RTFM! (press F1 on STRF())

[Kale]

From the Manual:

Special information about Floats
A floating point number is stored in a way that makes the binary point "float" around the number, so that it is possible to store very large numbers or very small numbers. However, you cannot store very large numbers with very high accuracy (big and small numbers at the same time, so to speak). Another limitation of floating point numbers is that they still work in binary, so they can only store numbers exactly which can be made up of multiples and divisions of 2. This is especially important to realise when you try to print a floating point number in a human readable form (or when performing operations on that float) - storing numbers like 0.5 or 0.125 is easy because they are divisions of 2. Storing numbers such as 0.11 are more difficult and may be stored as a number such as 0.10999999. You can try to display to only a limited range of digits, but do not be surprised if the number displays different from what you would expect!
This applies to floating point numbers in general, not just those in PureBasic.

[Amiga5k]

Some Basics (and other languages, such as Fortran) have more types to work with (such as double float or 'currency' types) and can therefore maintain a higher degree of accuracy (at the cost of speed).

Double precision floating point (as opposed to PB's single precision) is a step in the right direction...

Maybe this will appear with 4.0 along with:
- unsigned byte (char, ".c" or ".ub")
- unsigned long (dword, ".d" or ".ul")
- fixed length strings (Dim string.s x 10, etc)

Who knows?

Russell

[GPI]

Maybe this will appear with 4.0 along with:
- unsigned byte (char, ".c" or ".ub")
- unsigned long (dword, ".d" or ".ul")
- fixed length strings (Dim string.s x 10, etc)

.c and .d don't make sense. About fixed length strings: Dim are for arrays...

[Amiga5k]

Sorry, GPI, I guess I just have some throwbacks from my PowerBasic days. This is how they do it:

Code: Select all

DIM fixedstring AS ASCIIZ * 255   ' string will be 255 bytes long, including the end zero

' OR

DIM fixedstring AS STRING * 255   ' string will be 255 bytes long, period

As far as ".c" and ".d" not making sense, ".c" stands for char, which is kind of the way they do it in C. And ".d", as you may have guessed, stands for double. It makes a lot more sense, if you ask me, than using weird symbols that you have to remember like in Blitz. I

(".ub" for "unsigned byte" is pretty straightforward, I think...)

In PowerBasic it's even more difficult. Here's a page from their data types explanation:
(The tab spacing looks great in the 'post a reply' edit window, but gets screwed up when it's put in quote or code blocks).

Code: Select all

Variable Type	Indicator	Element size	DEF type *	Type Keyword

Pointer	@ (leading)	4	N/A	PTR

Integers
Integer	%	2	DEFINT	INTEGER
Long Integer	&	4	DEFLNG	LONG
Quad Integer	&&	8	DEFQUD	QUAD

Unsigned Integers
Byte	?	1	DEFBYT	BYTE
Word	??	2	DEFWRD	WORD
Double Word	???	4	DEFDWD	DWORD

Floating Point
Single precision	!	4	DEFSNG	SINGLE
Double precision	#	8	DEFDBL	DOUBLE
Extended precision	##	10	DEFEXT	EXT

Currency
Currency	@	10	DEFCUR	CUR
Extended Currency	@@	10	DEFCUX	CUX

Strings **
String	$	4	DEFSTR	STRING
ASCIIZ string	N/A	N/A	N/A	ASCIIZ
Fixed-length string	N/A	N/A	N/A	STRING * x

(sorry the tabs don't line up in this window...)

I can't honestly see where there would be any confusion... Can you imagine having to remember "!,# or ##" for float, or "?,?? or ???" for unsigned intergers, etc? I think PureBasic can do better than that (although it is very nice to have so many different type to use in PowerBasic...)

Russell

[GPI]

Sorry, GPI, I guess I just have some throwbacks from my PowerBasic days. This is how they do it:

Code: Select all

DIM fixedstring AS ASCIIZ * 255   ' string will be 255 bytes long, including the end zero

' OR

DIM fixedstring AS STRING * 255   ' string will be 255 bytes long, period

And VB use dim for declaration of variables. And it sound soo bad...

[Amiga5k]

One thing I like in languages is consistancy. And you're right, DIM'ing non-dimensioned variables doesn't really make sense.

From a syntax point of view, what would be the best and most logical way to declare a fixed length string in PB?

If we say, "fixed.s x 10" then that's no good. Nor is "fixed.s[10]".

Maybe the curly brackets? "fixed.s{10}". I'm game for almost anything as long as it partially makes sense.

Russell

[Dare2]

CompilerExplict ; directive all variables must be declared.

Variable aString.s, aFixedString.s[99]

Global gloString.s, gloFixedString.s[99]

Dim arrString.s(27), arrFixedString.s[99](27)

[Amiga5k]

Aren't square brackets "[ ]" reserved for one dimensional arrays within structures? If so, that could cause some confusion.

The Option Explicit (or DIM ALL) has been talked about before, of course, and is a good idea I think.

I think "fixedvar.type[length](indexes)" might be a little strange, though. But I'm willing to learn

Russell

[freak]

> Variable aString.s, aFixedString.s[99]

there is allready "DefType" for that.

Timo

[blueznl]

amiga5k, fixed length strings are also one of my favourites, but to let the syntax match the regular struct syntax i'd like to see them as:

fixed.c[10]
fixed = "0123456789"

[Amiga5k]

amiga5k, fixed length strings are also one of my favourites, but to let the syntax match the regular struct syntax i'd like to see them as:

fixed.c[10]
fixed = "0123456789"

I don't think we can use the square brackets, as they are already used for one-dimensional arrays within structures, I think.

Although I suppose the compiler could determine if the declaration is inside a structure or not and choose one or the other (but this could cause some confusion).

Russell

[blueznl]

i think the square brackets are exactly what we need

in a struct:

byte.b[100]

vs.

string.c[100]