1. scientific.e
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
2. scientific.e
scientific_to_atom() crashed with an input of "1"
slice upper index is less than 0 (-1)
s = {49'1'}
dp = 0
e = 0
exp = 1
int_bits = <no value>
frac_bits = <no value>
mbits = <no value>
ebits = <no value>
sbits = {0}
Line 278 is:
s = s[1..e-1] - '0
Just seems that non-scientific input should be rejected.
Moving on...
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
3. Re: scientific.e
I suggest, we create a new type even if it is a local type: scientific_string
that would check to makesure that this function can convert the type. Instead
of crashing the program in the conversion function it should crash with a
type check error.
Shawn Pringle
4. Re: scientific.e
Shawn Pringle wrote:
>
> I suggest, we create a new type even if it is a local type: scientific_string
> that would check to makesure that this function can convert the type. Instead
> of crashing the program in the conversion function it should crash with a
> type check error.
>
> Shawn Pringle
Huh?
I was just pointing out a bug in Matt's scientific.e, which I was using to try
and illustrate a different point. It's a case that should be handled by the
library or should be documented.
Other than a string type, I am wholly opposed to creating new built-in types for
Euphoria.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
5. Re: scientific.e
Jason Gade wrote:
>
> scientific_to_atom() crashed with an input of "1"
<snip>
> Just seems that non-scientific input should be rejected.
>
> Moving on...
It assumes that you're passing it good data. I blame you. :P
Matt
6. Re: scientific.e
Jason Gade wrote:
>
> I was just pointing out a bug in Matt's scientific.e, which I was using to try
> and illustrate a different point. It's a case that should be handled by the
> library or should be documented.
It is documented:
--/topic Scientific Notation
--/func scientific_to_float64( sequence s )
--
--Takes a string reprepresentation of a number in scientific notation
--/topic Scientific Notation
--/func scientific_to_atom( sequence s )
--
--Takes a string reprepresentation of a number in scientific notation
http://blogs.msdn.com/oldnewthing/archive/2008/05/05/8459022.aspx
Matt
7. Re: scientific.e
Matt Lewis and Jason Gade:
I don't think it is clear what is going on
to everyone here.
The scientific_to_float64 probably expects a
string of the form (+-)d\.d\+e(+-)dd.
Therefore if you have no 'e' the function
crashes. You want to pass 1 it should be
"1e+0".
I suggest you use a type for your function
for the sake of illistration let us suppose
there is a regex.e in the archive and a
regex_match that does what perl's // operator
does. Then the following is what you
could use as a type.
include regex.e
type scientific_string( sequence s )
return regex_match( s, "(+-)\d\.\d\+e(+-)\d\d" )
end type
Then you declare scientific_to_float64 as:
atom scientific_to_float64( scientific_string s )
If the user enters garbage he is told it is his
bad data instead of getting an error in the body
of your function and no I am not talking about
adding builtins.
Shawn Pringle
8. Re: scientific.e
Shawn Pringle wrote:
>
> Matt Lewis and Jason Gade:
>
> I don't think it is clear what is going on
> to everyone here.
> The scientific_to_float64 probably expects a
> string of the form (+-)d\.d\+e(+-)dd.
> I suggest you use a type for your function
> for the sake of illistration let us suppose
> there is a regex.e in the archive and a
> regex_match that does what perl's // operator
> does. Then the following is what you
> could use as a type.
Yes, I understood what you were saying.
> include regex.e
> type scientific_string( sequence s )
> return regex_match( s, "(+-)\d\.\d\+e(+-)\d\d" )
> end type
I think a correct regex would be (including capturing all of the interesting
substrings):
"(-?)(\\d+)(?:\\.(\\d+))?[eE][+\\-]?(\\d+)"
Matt
9. Re: scientific.e
Matt Lewis wrote:
>
> Jason Gade wrote:
> >
> > I was just pointing out a bug in Matt's scientific.e, which I was using to
> > try
> > and illustrate a different point. It's a case that should be handled by the
> > library or should be documented.
>
> It is documented:
>
> --/topic Scientific Notation
> --/func scientific_to_float64( sequence s )
> --
> --Takes a string reprepresentation of a number in scientific notation
>
> --/topic Scientific Notation
> --/func scientific_to_atom( sequence s )
> --
> --Takes a string reprepresentation of a number in scientific notation
>
> <a
> href="http://blogs.msdn.com/oldnewthing/archive/2008/05/05/8459022.aspx">http://blogs.msdn.com/oldnewthing/archive/2008/05/05/8459022.aspx</a>
>
> Matt
Oh, sure, just assume that I've diligently read all of the documentation!
:P
(But thanks.)
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
10. Re: scientific.e
Matt Lewis wrote:
>
> Shawn Pringle wrote:
> >
> > Matt Lewis and Jason Gade:
> >
> > I don't think it is clear what is going on
> > to everyone here.
> > The scientific_to_float64 probably expects a
> > string of the form (+-)d\.d\+e(+-)dd.
>
> > I suggest you use a type for your function
> > for the sake of illistration let us suppose
> > there is a regex.e in the archive and a
> > regex_match that does what perl's // operator
> > does. Then the following is what you
> > could use as a type.
>
> Yes, I understood what you were saying.
>
> > include regex.e
> > type scientific_string( sequence s )
> > return regex_match( s, "(+-)\d\.\d\+e(+-)\d\d" )
> > end type
>
> I think a correct regex would be (including capturing all of the interesting
> substrings):
>
> "(-?)(\\d+)(?:\\.(\\d+))?[eE][+\\-]?(\\d+)"
>
> Matt
Sorry, I /hadn't/ understood. My reading comprehension skills seem to be lacking
a little lately.
My apologies.
As Matt pointed out in another post, this behavior is documented and I missed
it. The other numbers I passed the function were in the form "x.xxxxxxxxxxxxxxx"
without an 'e' and those were parsed just fine.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
