1. 11 Dec, 2013 1 commit
  2. 08 Dec, 2013 2 commits
  3. 23 Nov, 2013 1 commit
  4. 08 Nov, 2013 1 commit
  5. 25 Jan, 2013 1 commit
  6. 24 Jan, 2013 1 commit
  7. 04 Nov, 2011 1 commit
  8. 25 Sep, 2011 1 commit
  9. 28 Feb, 2011 1 commit
  10. 20 Apr, 2010 1 commit
  11. 19 Apr, 2010 1 commit
  12. 19 Mar, 2010 1 commit
  13. 11 Dec, 2009 1 commit
  14. 18 Mar, 2009 1 commit
    • rtoy's avatar
      code/irrat-dd.lisp: · 8bd5d96d
      rtoy authored
      o Declare POLY-EVAL and POLY-EVAL-1 as maybe-inline functions so they
        can be semi-inlined.
      
      code/irrat.lisp:
      o I don't think there's any real reason to make the local function
        REAL-EXPT inline.  It's very big and local function call is already
        good enough.
      
      compiler/float-tran.lisp:
      o Change some functions to be maybe-inline instead of inline to save
        on space for the the larger double-double functions:  SUB-DD,
        SUB-D-DD, SUB-DD-D, SPLIT.  Semi-inline should be good enough for
        these large functions, saving on cache memory, local function
        calling sequence should be good enough.
      8bd5d96d
  15. 12 Nov, 2008 1 commit
  16. 22 Oct, 2008 1 commit
    • rtoy's avatar
      o Add new condition type for exceeding the intexp maximum exponent. · c28ddc17
      rtoy authored
      o Instead of a continuable error, use a restart to allow the user to
        continue the calculation with the option of updating the limit to
        the new power.
      
      Should we also increase the initial limit to something larger?  Should
      we just eliminate this altogether?  Or maybe allow the
      *intexp-maximum-exponent* to be nil to mean no limit at all?
      c28ddc17
  17. 08 Oct, 2008 1 commit
    • rtoy's avatar
      Ticket #24. · f169d3f0
      rtoy authored
      Take the rule of float precision contagion (CLHS 12.1.4.4) to also
      mean that the result should be as accurate as the most accurate
      argument.  Effectively, all args are coerced to the highest precision
      first before computing expt.
      
      There's a simple test program to check that every case is covered with
      the expected precision.  (I think).
      
      (defun test-expt ()
        (dolist (base '(2 2f0 2d0 2w0) t)
          (dolist (power '(1/2 .5f0 .5d0 .5w0))
            (flet ((test-it (b p a eps expected)
      	       (let* ((res (expt b p))
      		      (absdiff (abs (- res a))))
      		 (unless
      		     (or (typep (realpart res) (type-of expected))
      			 (<= absdiff (* 10 eps)))
      		   (format t "FAILED: ~A^~A = ~A (~A)~%" b p res a)))))
      
      	;; Compute base^power.
      	(let* ((expected-type
      		(let ((prod (* base power)))
      		  (if (rationalp prod)
      		      1f0
      		      prod)))
      	       (eps (etypecase expected-type
      		      ((or rational single-float)
      		       single-float-epsilon)
      		      (double-float
      		       double-float-epsilon)
      		      (double-double-float
      		       1w-31)))
      	       (answer (sqrt (float base expected-type))))
      	  (test-it base power answer eps expected-type)
      	  (test-it base (complex power) answer eps expected-type)
      	  (test-it (complex base) power answer eps expected-type)
      	  (test-it (complex base) (complex power) eps answer expected-type))))))
      f169d3f0
  18. 31 Jan, 2008 1 commit
  19. 28 Jan, 2008 1 commit
    • rtoy's avatar
      Add new interface to ieee754_rem_pio2. No longer need to pass in an · a459a234
      rtoy authored
      array. The new function returns 2 new output values.
      
      code/irrat.lisp:
      o Rename the original %ieee754-rem-pi/2 to %%ieee754-rem-pi-2.
      o Define the new %ieee754-rem-pi/2 function.  This returns the output
        as two output values instead of an array.
      o Use the new function.  We should have wrapped the original with
        without-gcing, but we don't have to anymore.
      
      lisp/ppc-arch.c:
      lisp/x86-arch.c:
      o Implement the new C interface to __ieee754_rem_pio2
      
      lisp/Config.linux_gencgc:
      o Use -ffloat-store when compiling e_rem_pio2.c and k_rem_pio2.c, just
        to be sure.
      a459a234
  20. 03 Aug, 2007 1 commit
  21. 18 Jan, 2007 2 commits
  22. 19 Jul, 2006 4 commits
  23. 30 Jun, 2006 1 commit
  24. 15 May, 2006 1 commit
  25. 03 May, 2006 1 commit
  26. 20 Oct, 2005 1 commit
    • rtoy's avatar
      Fix some issues with two-arg log function. (log 17 10f0), (log 17f0 · 0f17dd30
      rtoy authored
      10), and (log 17 10) returned different single-float results.  I think
      this is allowed by ANSI CL, but I think it's unfortunate.
      
      Therefore, try to apply float contagion to the arguments before
      computing the log function.  Also, if both args are single-floats or
      rationals, we coerce them to double-floats before computing the
      result.  This makes (log 17 10) = (log 17.0 10).
      
      There are other cases still to be considered.
      0f17dd30
  27. 25 Aug, 2005 1 commit
  28. 19 Oct, 2004 1 commit
    • rtoy's avatar
      CMUCL was computing the values of asin, acos, and atanh on the branch · fc58f500
      rtoy authored
      cuts on the real line incorrectly.  This shows up when calling these
      functions with real-valued args, not complex.  The problem was the
      computed values were not continuous with the quadrants specified by
      ANSI CL.
      
      Issue noted by Bruno Haible, cmucl-imp, 2004-10-11.
      
      See also some tests on cmucl-imp, 2004-10-19.
      fc58f500
  29. 09 Jun, 2004 1 commit
  30. 04 Jun, 2004 1 commit
  31. 12 May, 2004 1 commit
    • rtoy's avatar
      Fix some issues with the complex functions with signed zeroes. See · 3e0a1c82
      rtoy authored
      comment for full details, but the issue is that Lisp says mixing a
      real and a complex requires converting the real to complex before
      doing the operation.  But Kahan's algorithms assume that this doesn't
      happen, like z-1 should not be computed as z-(1+0*i).
      
      One place where this was wrong was for acos(2 +/- 0i).  Kahan says
      acos(2+0i) is +0 - i*acosh(2) and acos(2-0i) is +0 + i*acosh(2).  We
      had this backwards for the above reason.
      
      I think this was caused by the erroneous deftransforms for real op
      complex which were removed sometime ago, causing these function to
      compute the wrong thing.
      3e0a1c82
  32. 29 Jan, 2003 1 commit
  33. 10 Jan, 2003 1 commit
  34. 08 Jan, 2003 1 commit
  35. 31 Dec, 2002 1 commit