1. value
Rob, regarding this snippet:
sequence x, y
-- assign something to y
x = value(y)
Is there any length-limit to what can be assigned to y? Can y be max_integer
long?
Kat
2. Re: value
Kat writes:
> sequence x, y
> -- assign something to y
> x = value(y)
>
> Is there any length-limit to what can be assigned to y?
> Can y be max_integer long?
There's no limit. But keep in mind:
- There is a 200-character limit on a line of source code,
so if you are using a literal string of digits, you'll
have that limit. If you read the string of digits from
a file, or compute it somehow, you'll be ok.
- You might eventually produce +/- INF.
- Internally, things are stored in at most 64-bit floating-point, so
you'll have a limit of about 15 decimal digits of accuracy.
Extra digits beyond that will not accomplish anything.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: value
On 22 Oct 2002, at 12:43, Robert Craig wrote:
>
> Kat writes:
> > sequence x, y
> > -- assign something to y
> > x = value(y)
> >
> > Is there any length-limit to what can be assigned to y?
> > Can y be max_integer long?
>
> There's no limit. But keep in mind:
> - There is a 200-character limit on a line of source code,
> so if you are using a literal string of digits, you'll
> have that limit. If you read the string of digits from
> a file, or compute it somehow, you'll be ok.
>
> - You might eventually produce +/- INF.
>
> - Internally, things are stored in at most 64-bit floating-point, so
> you'll have a limit of about 15 decimal digits of accuracy.
> Extra digits beyond that will not accomplish anything.
What about leading zero stripping, without decimal points? Like:
value("00000000000000000000000000000000000000000000000001")? Is
there a limit there? I'd try all my questions, and not be bothering you, but i
can't seem to come up with all possible failure possibilities myself. Which is
why i am so delayed with the bignum.e lib. I haven't hit this yet, but i can see
the possibility of it happening.
Kat
4. Re: value
Hello Kat,
At 13:33 24/10/02 -0500, you wrote:
<snip>
>What about leading zero stripping, without decimal points? Like:
>value("00000000000000000000000000000000000000000000000001")?
</snip>
My approach to dealing with cases such as these is to make a judgement call
on how likely such a case might be. If it is likely then check for many
leading zeroes yourself. If they exist remove them and then pass the
modified argument to the value function. If you think the case is unlikely
then just pass the argument to the value function. If it blows up or gives
a bad result then this _should_ show up somewhere along the line. If the
code is part of a game then sometimes the game might crash. If the code is
controlling a lathe then the lathe might jam and result in a repair bill of
four figures. Use your judgement to make the right call.
The concept is if you feel a function isn't robust enough with extreme
inputs (are these called boundary conditions?) then do the "extreme case"
checks yourself before using the function.
<snip>
>I haven't hit this yet, but i can see
>the possibility of it happening.
</snip>
Very true but you also should make a call on how much defensive programming
to put into an application. How many of us check to see if a write to a
file actually succeeded? Disks do run out of space or the permissions on
the file you want to write to can change to deny you write access.
Bad applications do little or no error checking. Good applications do
enough error checking to catch the "common" error conditions. No
application can do any amount of error checking to guarantee 100% that the
right result has been achieved.
An experienced programmer (and former boss way back when) said to me that
good programs consisted mainly of code for preventing errors and/or for
handling them. Personally I think that is still true but everything is
relative.
Regards,
Andy Cranston.
5. Re: value
Exactly why we need a crash_routine. Not to remove the responsibility
from the programmer, but to catch the other 5% gracefully.
>>> acran at readout.fsnet.co.uk 10/24/02 04:47PM >>>
Bad applications do little or no error checking. Good applications do
enough error checking to catch the "common" error conditions. No
application can do any amount of error checking to guarantee 100% that
the
right result has been achieved.
Regards,
Andy Cranston.
6. Re: value
Kat writes:
> What about leading zero stripping, without decimal points?
> Like:
> value("00000000000000000000000000000000000000000000000001")?
> Is there a limit there?
No.
value() will just eat up all the 0's,
no matter how many you give it.
> I'd try all my questions, and not be bothering you, but i
> can't seem to come up with all possible failure possibilities myself.
> Which is why i am so delayed with the bignum.e lib.
> I haven't hit this yet,
> but i can see the possibility of it happening.
I don't think value() will give you any surprises.
The source code for value() is in euphoria\include\get.e
Just remember that floating-point arithmetic is not
infinitely precise, and only has a finite range before you
end up with +/- INF. Those issues shouldn't affect you though
if you are storing big numbers as sequences of digits.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
