Restored from previous forum. Originally posted by geoff.
At the moment it is difficult to use large and small numbers in Purebasic
because the routines for conversion from string to number and from number
to string are rudimentary. However, Purebasic does not yet allow the use
of doubles (64 bit floats). Maybe the suggestions below, or something
similar could be implemented at the same time doubles are implemented.
In my opinion this is the greatest single omission from the language and
effectively excludes Purebasic from technical application. This is
a pity because Purebasic is fast and has simple access to the Windows API
and therefore could have wide application by technical people who do
not have the time or training to use complex languages like C++
Number Entry
We need scientific notation to enter large and small numbers.
For example:
Ce=1.602e-19 ; electron charge
c=2.997e8 ; speed of light
p=3.085e16 ; parsec
Number Display
The function str() should display an integer or float to the full accuracy
available, about 7 digits for a float, 10 for a long, and about 15 for a double.
The format of the display should depend upon the size of the number.
Below is the result you get for str(pi*n) in a different language.
3.14159265358979E+015
31415926535.8979
314159.265358979
3.14159265358979
0.0000314159265358979
3.14159265358979E-010
3.14159265358979E-015
3.14159265358979E-020
Notes:
1) Their is a maximum string length in all cases, this is useful.
2) The exponent always occupies 4 characters, this is useful for subsequent
string processing.
3) Scientific notation is used for numbers that would otherwise require more
characters than the maximum to give the full accuracy.
4) In my opinion all numbers smaller than 0.1 are better displayed in
scientific notation (ie different from the above)
Choice of floating point type
On this forum I have heard comments about 80 bit and 128 bit variables.
I don't see any urgent need for these and I don't want Fred to be diverted
from providing doubles (and the things above) because he is worrying about
even more accurate maths that very few people will use. I have made the
case for doubles and for the entry and display functions that are essential.
When we have these as part of Purebasic, let those who believe we need
even more accurate functions, explain why they think them necessary.
I doubt they will get much support for their arguments.
A final point, I don't believe we need floats and doubles. Since we
all have an 80 bit hardware floating point unit that is very fast
we could make all floating point numbers 64 bit.
Some other languages do this.
String to float and float to string
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by MrVainSCL.
hi geoff,
we all can only hope that fred will implent asap the double stuff to use long numbers and double floats! As i remeber, we all are still waiting for this feature since something like one year!? ;(
greetz
MrVainSCL! aka Thorsten
PIII450, 256MB Ram, 80GB HD + 6,4 GB, RivaTNT, DirectX9.0, SB AWE64, Win2000 + all Updates...
hi geoff,
we all can only hope that fred will implent asap the double stuff to use long numbers and double floats! As i remeber, we all are still waiting for this feature since something like one year!? ;(
greetz
MrVainSCL! aka Thorsten
PIII450, 256MB Ram, 80GB HD + 6,4 GB, RivaTNT, DirectX9.0, SB AWE64, Win2000 + all Updates...
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by geoff.
I'd be interested to see anyone's opinions on my suggestions, especially
from Fred.
What I'm suggesting is pretty standard stuff, but I asume Fred would
like to hear our ideas before it's too late.
For example, does anyone disagree that we don't really need 32 bit floats
if we have 64?
And what about string format? Is the above suggestion acceptable
or do people want to force scientific notation, or maybe even
want a formatted display like in Fortran?
I'd be interested to see anyone's opinions on my suggestions, especially
from Fred.
What I'm suggesting is pretty standard stuff, but I asume Fred would
like to hear our ideas before it's too late.
For example, does anyone disagree that we don't really need 32 bit floats
if we have 64?
And what about string format? Is the above suggestion acceptable
or do people want to force scientific notation, or maybe even
want a formatted display like in Fortran?
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by gnozal.
> the routines for conversion from string to number and
> from number to string are rudimentary.
Yes, I agree. In Purebasic you have Str, StrF (and StrU). In any other basic dialect, you have only Str$. And so it should be.
You don't always know if a string is an integer like '125' or a float like '1.25' (user input for example), and it's a pain to have to test what a string looks like before using the right Str function.
I think Purebasic deserves a decent Str$ function.
> the routines for conversion from string to number and
> from number to string are rudimentary.
Yes, I agree. In Purebasic you have Str, StrF (and StrU). In any other basic dialect, you have only Str$. And so it should be.
You don't always know if a string is an integer like '125' or a float like '1.25' (user input for example), and it's a pain to have to test what a string looks like before using the right Str function.
I think Purebasic deserves a decent Str$ function.
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by tinman.
Val() would be the command you want only one version of.
--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + all updates, PB3.51, Ed3.53)
Seeing as Str?() is for converting from a number to a string then you will always know what type of value you are passing in.Originally posted by gnozal
> the routines for conversion from string to number and
> from number to string are rudimentary.
Yes, I agree. In Purebasic you have Str, StrF (and StrU). In any other basic dialect, you have only Str$. And so it should be.
Val() would be the command you want only one version of.
--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + all updates, PB3.51, Ed3.53)
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by freak.
> In Purebasic you have Str, StrF (and StrU)
That can't be changed so easy.
I Purebasic, There is only a small part of code created by the compiler directly. All other Stuff is pre-compiled and stored in the PB Librarys, which is quite a good way of doing this.
And because Str, StrF and StrU are Functions, they can only accept one type of Variable.
If it was Compiler generated code, the Compiler could _see_ that there is a Float as Argument, and then generate the needed code, but since it is not, you'll have to make this choise.
What's so bad, if the coder has to think (at least) a little bit? Isn't that, what the coder is there for ?
Anyway, i don't think this has to be changed. (also the fact that Val() doesn't check, if there is a Number passed to it)
It is a bit more work for the coder, but in return, we have small and fast Code, which I like very much.
Well, but that's just my opinion...
Timo
> In Purebasic you have Str, StrF (and StrU)
That can't be changed so easy.
I Purebasic, There is only a small part of code created by the compiler directly. All other Stuff is pre-compiled and stored in the PB Librarys, which is quite a good way of doing this.
And because Str, StrF and StrU are Functions, they can only accept one type of Variable.
If it was Compiler generated code, the Compiler could _see_ that there is a Float as Argument, and then generate the needed code, but since it is not, you'll have to make this choise.
What's so bad, if the coder has to think (at least) a little bit? Isn't that, what the coder is there for ?
Anyway, i don't think this has to be changed. (also the fact that Val() doesn't check, if there is a Number passed to it)
It is a bit more work for the coder, but in return, we have small and fast Code, which I like very much.
Well, but that's just my opinion...
Timo
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by Manolo.
>Seeing as Str?() is for converting from a number to a string then you will always know what type of value you are passing in.
>Val() would be the command you want only one version of.
STR(num.l or num.f or num.w) convert to strinf format (Only one STR)
VAL(num.s) convert to NUMERIC VALUE inverse to STR.
This is possible in All Basics... b$=STR(VAL(HEX($100)))
And this... b$=STR(VAL(a$)*(3.141592e8)/1.36))
Only one VAL and only one STR
Manolo
>Seeing as Str?() is for converting from a number to a string then you will always know what type of value you are passing in.
>Val() would be the command you want only one version of.
STR(num.l or num.f or num.w) convert to strinf format (Only one STR)
VAL(num.s) convert to NUMERIC VALUE inverse to STR.
This is possible in All Basics... b$=STR(VAL(HEX($100)))
And this... b$=STR(VAL(a$)*(3.141592e8)/1.36))
Only one VAL and only one STR
Manolo
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by tinman.
Sorry, I quoted the wrong part of gnozal's post, which made my reply out of context. I meant to reply to this bit:
I should also point out that you will already have decided what version of the conversion functions you will be using. Consider what happens when the user needs to enter some numbers on your GUI. You will already have decided whether they will be able to enter integers or fractional numbers, by the purpose of your program. You will also say "variable = ...." and your variable will have some type. Therefore you will also know what variant of the conversion function to use.
If you really want you could use ValF all the time, as long as your numbers can be represented by 23 bits, since this will convert integer numbers just as well as Val. This way you will never lose accuracy for large integers and you will only sometimes need to think about what Val to use.
--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + all updates, PB3.51, Ed3.53)
Sorry, I quoted the wrong part of gnozal's post, which made my reply out of context. I meant to reply to this bit:
My point being that having to know what a string will be like before calling Str is a ludicrous idea.Originally posted by gnozal
You don't always know if a string is an integer like '125' or a float like '1.25' (user input for example), and it's a pain to have to test what a string looks like before using the right Str function.
I think Purebasic deserves a decent Str$ function
Sure, I kind of agree with that, with one minor problem. PureBasic has no unsigned data types so there is absolutely no way that your single STR function could ever work until Fred implements unsigned data types.STR(num.l or num.f or num.w) convert to strinf format (Only one STR)
I'd prefer the option of having the current commands plus ABigFatStr() and ABigFatVal() which would convert anything. Using ABigFatVal() to parse a few MBs of data would be a fair bit slower than using the correct Val() for your data format.Only one VAL and only one STR
I should also point out that you will already have decided what version of the conversion functions you will be using. Consider what happens when the user needs to enter some numbers on your GUI. You will already have decided whether they will be able to enter integers or fractional numbers, by the purpose of your program. You will also say "variable = ...." and your variable will have some type. Therefore you will also know what variant of the conversion function to use.
If you really want you could use ValF all the time, as long as your numbers can be represented by 23 bits, since this will convert integer numbers just as well as Val. This way you will never lose accuracy for large integers and you will only sometimes need to think about what Val to use.
--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + all updates, PB3.51, Ed3.53)
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by geoff.
OK, whether we use Str() or StrF() is an issue. But what about my
original post concerning entry and display of numbers?
Fred has agreed to do doubles but without sensible input and output routines what use will they be?
At the moment the line a.f=10000000000 (ie 1e10) produces Numeric overflow, too big a number.
So how do I enter the US GDP, $1e13 or the size of a hard disk 6.4e10 bits?
These are everyday numbers in use. This isn't rocket science.
A program result of a.f=1.23e24 gives StrF(a)=1230000071797337700000000
And the result a.f=1.23e-6 gives StrF(a)=0.000001
To call this rudimentary is just being polite because this is a public forum,
it's not the first adjective which came to mind.
So I made suggestions for improvements. Doesn't anyone else have an opinion on this?
Are you happy with the current routines?
Do you agree completely with my suggestions?
Does anyone else want Fred to do something about this?
Geoff
OK, whether we use Str() or StrF() is an issue. But what about my
original post concerning entry and display of numbers?
Fred has agreed to do doubles but without sensible input and output routines what use will they be?
At the moment the line a.f=10000000000 (ie 1e10) produces Numeric overflow, too big a number.
So how do I enter the US GDP, $1e13 or the size of a hard disk 6.4e10 bits?
These are everyday numbers in use. This isn't rocket science.
A program result of a.f=1.23e24 gives StrF(a)=1230000071797337700000000
And the result a.f=1.23e-6 gives StrF(a)=0.000001
To call this rudimentary is just being polite because this is a public forum,
it's not the first adjective which came to mind.
So I made suggestions for improvements. Doesn't anyone else have an opinion on this?
Are you happy with the current routines?
Do you agree completely with my suggestions?
Does anyone else want Fred to do something about this?
Geoff
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by tinman.
--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + all updates, PB3.51, Ed3.53)
Only that we need to be able to enter and display in scientific and/or fixed notations. I think it needs to be more flexible (regarding lengths of produced strings) than you suggest and I think PB should keep floats even if it gets doubles.Originally posted by geoff
Do you agree completely with my suggestions?
--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + all updates, PB3.51, Ed3.53)
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by geoff.
Thanks tinman,
That seems reasonable to me.
OK, we all agree these are silly:
a.f=1.23e24 gives StrF(a)=1230000071797337700000000
a.f=1.23e-6 gives StrF(a)=0.000001
We need an intelligent Str()that handles integers and floats of any size, with full accuracy.
Fred, will you add this along with doubles in version 4.0 ?
Any idea when? I'm desperate for this.
Thanks,
Geoff
Thanks tinman,
That seems reasonable to me.
OK, we all agree these are silly:
a.f=1.23e24 gives StrF(a)=1230000071797337700000000
a.f=1.23e-6 gives StrF(a)=0.000001
We need an intelligent Str()that handles integers and floats of any size, with full accuracy.
Fred, will you add this along with doubles in version 4.0 ?
Any idea when? I'm desperate for this.
Thanks,
Geoff
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by Stan.
Hi,
While we are at it why not ask for something like :
str_f( "format string", number ), where "format string" would describe
the output format ? ( C convention could be used there ... ).
Bests.
Stan.
PS : BTW I for one badly need doubles for scientific computation.
Since I attended an MS course, my programs no longer have bugs ... just hidden "features" !! [ PB. registered user ]
Hi,
While we are at it why not ask for something like :
str_f( "format string", number ), where "format string" would describe
the output format ? ( C convention could be used there ... ).
Bests.
Stan.
PS : BTW I for one badly need doubles for scientific computation.
Since I attended an MS course, my programs no longer have bugs ... just hidden "features" !! [ PB. registered user ]