1. value
- Posted by Kat <kat at kogeijin.com> Oct 22, 2002
- 408 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Oct 22, 2002
- 384 views
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
- Posted by Kat <kat at kogeijin.com> Oct 24, 2002
- 359 views
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
- Posted by acran at readout.fsnet.co.uk Oct 24, 2002
- 397 views
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
- Posted by Sabal.Mike at notations.com Oct 24, 2002
- 380 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Oct 24, 2002
- 364 views
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