From: Robert D. <rob...@gm...> - 2009-01-06 06:53:21
|
Hello, I have Clisp 2.46 on Linux, compiled by gcc 3.3.2. I get the following: (format t "~e~%" most-positive-double-float) *** - SYSTEM::FLOAT-SCALE-EXPONENT: floating point overflow I didn't try any other floating point values but it seems like FORMAT should never trigger a floating point error. Thanks for your help, Robert Dodier |
From: Sam S. <sd...@gn...> - 2009-01-06 16:41:04
|
Hi, Robert Dodier wrote: > > I have Clisp 2.46 on Linux, compiled by gcc 3.3.2. > I get the following: > > (format t "~e~%" most-positive-double-float) > *** - SYSTEM::FLOAT-SCALE-EXPONENT: floating point overflow > > I didn't try any other floating point values but it seems like > FORMAT should never trigger a floating point error. thanks for your bug report. I fixed it in the CVS. note that the long limits cannot be printed using format because they represent numbers which cannot be represented as integers in clisp. Sam |
From: Raymond T. <ray...@er...> - 2009-01-06 21:09:36
|
Sam Steingold wrote: > note that the long limits cannot be printed using format because they represent > numbers which cannot be represented as integers in clisp. > > That's unfortunate, considering that print works for most-positive-long-float. I guess that would require changing the algorithm for floating-point printing? Ray |
From: Raymond T. <ray...@er...> - 2009-01-07 15:21:37
|
Sam Steingold wrote: > Raymond Toy wrote: >> Sam Steingold wrote: >>> note that the long limits cannot be printed using format because >>> they represent numbers which cannot be represented as integers in >>> clisp. >>> >>> >> That's unfortunate, considering that print works for >> most-positive-long-float. > > http://clisp.podval.org/impnotes/num-concepts.html#long-float-wider-than-bignum > > >> I guess that would require changing the algorithm for floating-point >> printing? > > PTC Sorry, I don't know what PTC means. You could steal the guts of cmucl's float printer. It's mostly portable, and, I think, only needs integer-decode-float, and the minimum exponent. The current version won't work because it uses a table of powers of ten from least float to biggest float. An older version didn't need the table. Ray |
From: Sam S. <sd...@gn...> - 2009-01-07 15:27:57
|
Raymond Toy wrote: > Sam Steingold wrote: >> PTC > Sorry, I don't know what PTC means. this is a common abbreviation on some mailing lists. http://www.cygwin.com/acronyms/#PTC |
From: Sam S. <sd...@gn...> - 2009-01-07 15:07:37
|
Raymond Toy wrote: > Sam Steingold wrote: >> note that the long limits cannot be printed using format because they represent >> numbers which cannot be represented as integers in clisp. >> >> > That's unfortunate, considering that print works for > most-positive-long-float. http://clisp.podval.org/impnotes/num-concepts.html#long-float-wider-than-bignum > I guess that would require changing the algorithm for floating-point > printing? PTC |
From: <don...@is...> - 2009-01-08 18:52:56
|
Raymond Toy writes: >>>> note that the long limits cannot be printed using format because >>>> they represent numbers which cannot be represented as integers in >>>> clisp. I've been trying to understand why this is required. I see no hint in http://clisp.podval.org/impnotes/num-concepts.html#long-float-wider-than-bignum Would it make sense to start with (with-output-to-string (s)(princ long-float s)) and then massage it to fit into the format parameters? BTW that says that MOST-POSITIVE-LONG-FLOAT is about 2^(2^32) whereas I see 2^(2^31) |
From: <don...@is...> - 2009-01-08 19:58:42
|
> > >>>> note that the long limits cannot be printed using format because > > >>>> they represent numbers which cannot be represented as integers in > > >>>> clisp. > > I've been trying to understand why this is required. This question remains unanswered. Perhaps something could be added to http://clisp.podval.org/impnotes/num-concepts.html > > Would it make sense to start with > > (with-output-to-string (s)(princ long-float s)) > > and then massage it to fit into the format parameters? > string operations are expensive. but, I would think, still preferable to unnecessary errors You could check whether the value is large enough to cause an error and use the string version only in that case. |
From: <don...@is...> - 2009-01-08 22:08:28
|
Sam Steingold writes: > the printing algorithm tries to divide Xd+Y by 10^Y. I'm guessing that the failure is trying to compute 10^Y as an integer. Is there any reason not to do it as a float? If you point me to the right source file I'll be more likely to understand the problem and supply a proposed patch either to the code or the doc. |
From: Raymond T. <ray...@er...> - 2009-01-08 17:26:43
|
Sam Steingold wrote: > Raymond Toy wrote: >> Sam Steingold wrote: >>> note that the long limits cannot be printed using format because >>> they represent numbers which cannot be represented as integers in >>> clisp. >>> >>> >> That's unfortunate, considering that print works for >> most-positive-long-float. > > http://clisp.podval.org/impnotes/num-concepts.html#long-float-wider-than-bignum > > >> I guess that would require changing the algorithm for floating-point >> printing? > > PTC Hmm. cmucl's algorithm also needs to be able create very large bignums, so it won't work either. An interesting problem.... Ray |
From: Sam S. <sd...@gn...> - 2009-01-08 19:33:10
|
Don Cohen wrote: > Raymond Toy writes: > >>>> note that the long limits cannot be printed using format because > >>>> they represent numbers which cannot be represented as integers in > >>>> clisp. > I've been trying to understand why this is required. > I see no hint in > http://clisp.podval.org/impnotes/num-concepts.html#long-float-wider-than-bignum > Would it make sense to start with > (with-output-to-string (s)(princ long-float s)) > and then massage it to fit into the format parameters? string operations are expensive. I once decided to be cute and replace the name of a form in compile-file from (write-to-string form :level 2 :length 3 :pretty nil) to sys::write-to-short-string (used in describe et al). the compilation speed went down by a factor of 2-3. > BTW that says that MOST-POSITIVE-LONG-FLOAT is about 2^(2^32) > whereas I see 2^(2^31) thanks, fixed (I forgot the sign bit) |
From: Sam S. <sd...@gn...> - 2009-01-08 20:44:25
|
Don Cohen wrote: > > > >>>> note that the long limits cannot be printed using format because > > > >>>> they represent numbers which cannot be represented as integers in > > > >>>> clisp. > > > I've been trying to understand why this is required. > This question remains unanswered. the printing algorithm tries to divide Xd+Y by 10^Y. > Perhaps something could be added to > http://clisp.podval.org/impnotes/num-concepts.html http://www.cygwin.com/acronyms/#PTC > > > Would it make sense to start with > > > (with-output-to-string (s)(princ long-float s)) > > > and then massage it to fit into the format parameters? > > string operations are expensive. > but, I would think, still preferable to unnecessary errors > You could check whether the value is large enough to cause an error > and use the string version only in that case. http://www.cygwin.com/acronyms/#SHTDI I do not have time. |
From: Sam S. <sd...@gn...> - 2009-01-09 18:50:23
|
Don Cohen wrote: > Sam Steingold writes: > > > the printing algorithm tries to divide Xd+Y by 10^Y. > I'm guessing that the failure is trying to compute 10^Y as an integer. > Is there any reason not to do it as a float? accuracy? saving memory? > If you point me to the right source file I'll be more likely to > understand the problem and supply a proposed patch either to the code > or the doc. lisparith.d and format.lisp PS. I am still waiting for the rawsock checksum fixes. |
From: <don...@is...> - 2009-01-09 21:03:50
|
Sam Steingold writes: > > If you point me to the right source file I'll be more likely to > > understand the problem and supply a proposed patch either to the code > > or the doc. > lisparith.d and format.lisp I begin to see stack overflows everywhere I look. For instance [75]> 1.0L23000000 *** - Program stack overflow. RESET [76]> 1.0L2300000 1.0L2300000 [77]> (expt 10.0L0 23000000) 9.999999999999865677L22999999 [78]> Is this a bug in the reader? |
From: <don...@is...> - 2009-01-10 07:39:28
|
Sam Steingold writes: string operations are expensive. I now notice that print to string is a lot cheaper than format ~e ! [11]> (time (format nil "~e" 1L1000000)) Real time: 1.237739 sec. Run time: 1.236812 sec. Space: 1188552 Bytes GC: 2, GC time: 0.004 sec. "1.0L+1000000" [13]> (time (format nil "~e" 1L3)) Real time: 3.13E-4 sec. Run time: 0.0 sec. Space: 9472 Bytes "1.0L+3" [17]> (time (with-output-to-string(s)(princ 1L3 s))) Real time: 1.28E-4 sec. Run time: 0.0 sec. Space: 1984 Bytes "1000.0L0" [18]> (time (with-output-to-string(s)(princ MOST-POSITIVE-LONG-FLOAT s))) Real time: 2.04E-4 sec. Run time: 0.0 sec. Space: 5432 Bytes "8.8080652584198167656L646456992" So the current algorithm not only generates errors when the arguments get very large, but for large arguments that do not cause errors, takes orders of magnitude more time and uses orders of magnitude more space than one that simply does string processing on the output of princ. Granted that format is extremely complicated, and for small numbers this probably justifies its extra expense. BTW, Am I correct in thinking that the string output of princ under default settings contains all the information needed to do format? I'm less depressed by the performance of format than I am IMPRESSED at the performance of princ on large numbers. BTW, it's not only ~E but also ~F and ~G that generate unnecessary errors. And these occur at even smaller limits than ~E : [4]> (time (format nil "~F" 1L1000000)) *** - ASH: shift 3321865 is too large [6]> (time (format nil "~G" 1L1000000)) *** - ASH: shift 3321865 is too large And the errors come even before we have to start using long floats! [21]> (time (format nil "~e" MOST-POSITIVE-DOUBLE-FLOAT)) *** - SYSTEM::FLOAT-SCALE-EXPONENT: floating point overflow Break 1 [22]> (time (format nil "~e" MOST-POSITIVE-SINGLE-FLOAT)) *** - SYSTEM::FLOAT-SCALE-EXPONENT: floating point overflow Break 2 [23]> (time (format nil "~e" MOST-POSITIVE-SHORT-FLOAT)) *** - SYSTEM::FLOAT-SCALE-EXPONENT: floating point overflow |