--- /dev/null
+Scheme can now run on aarch64 with the SVM backend.
+
+XXX Cross-compilation is currently busted even with the SVM backend, so
+making a release that runs on aarch64 requires some manual hacks.
--- /dev/null
+New procedures:
+
+. (log1p x) = log (1 + x) for any x in (-1, +\infty), -inf for -1.
+ [The primitive flo:log1p has a range restriction due to the Intel
+ i387 CPU instruction.]
+. (expm1 x) = e^x - 1 for any real x.
+ [The primitive flo:expm1 has a range restriction due to the Intel
+ i387 CPU instruction.]
+. (log1mexp x) = log (1 - e^x), for x < 0
+. (log1pexp x) = log (1 + e^x)
+. (logistic x) = 1/(1 + e^{-x}), inverse of logit
+. (logit p) = log p/(1 - p), inverse of logistic
+. (log-logistic x) = log 1/(1 + e^{-x}), inverse of logit-exp
+. (logit-exp t) = log e^t/(1 - e^t), inverse of log-logistic
+. (logit1/2+ p) = (logit (+ 1/2 p)), inverse of logistic-1/2
+. (logistic-1/2 x) = (- (logistic x) 1/2), inverse of logit1/2+
+. (logsumexp (list x y z ...)) = log (e^x + e^y + e^z + ...),
+ guaranteed not to overflow or underflow
--- /dev/null
+Bug fix: Floating-point primitives now raise floating-point exceptions,
+rather than signalling argument range errors, and trap (i.e., signal a
+condition) only if floating-point exceptions are trapped.
--- /dev/null
+Bug fix: The integer? procedure no longer returns true for infinities.
+
+A side effect of this bug was that the compile's common subexpression
+elimination would crash when handling infinities, either written
+literally or due to constant folding:
+
+; Compiling file: "./floenv.bin" => "./floenv.com"...
+;The object +inf.0, passed as the first argument to flonum-normalize, is not the correct type.
--- /dev/null
+Bug fix: `+nan.0' and `-nan.0' are now read as floating-point
+not-a-number; `nan.0' was incorrectly read as that, but is now read as
+a symbol as it should be.
--- /dev/null
+Bug fix: SF no longer incorrectly transforms (- x) into (- 0 x). This
+means when x is a floating-point zero, (- x) reliably changes its sign.
--- /dev/null
+Bug fix: The microcode is now compiled with -frounding-math so that the
+rounding mode can be reliably changed.
+
+Note: GCC >=7 sometimes miscompiles math under -O3 even if
+-frounding-math is specified. In particular, (floor 0.5) sometimes
+returns -0. instead of +0. as it should.
--- /dev/null
+New procedure (bytevector-zero-explicit! bv [start [end]]) intended not
+to be optimized away.
+
+This isn't correctly implemented yet -- an old copy of the data may
+remain elsewhere in memory after a GC -- but it may be useful to mark
+where you _would_ want to zero the bytevector if we fixed it in the
+future.
--- /dev/null
+New flonum-related definitions:
+
+. flo:radix - Floating-point radix. This is essentially always 2 but
+ useful for assertions if you want to future-proof code that assumes
+ it with a noisy failure in case we ever violate the assumption.
+. flo:error-bound - Greatest possible relative error in rounding to nearest.
+. flo:log-error-bound = (log flo:error-bound)
+. flo:ulp-of-one - Distance from 1 to next greater floating-point number.
+ Equal to twice flo:error-bound.
+. flo:log-ulp-of-one = (log flo:ulp-of-one)
+. (flo:ulp x) - Distance from x to the next floating-point number
+ larger in magnitude with the same sign.
+. flo:normal-exponent-max-base-2 - Exponent of greatest power of two
+ that is a floating-point number.
+. flo:normal-exponent-min-base-2 - Exponent of least positive power of
+ two that is a _normal_ floating-point number.
+. flo:normal-exponent-max-base-e, flo:normal-exponent-min-base-e,
+ flo:normal-exponent-max-base-10, flo:normal-exponent-min-base-10 -
+ Exponents of the greatest and least positive powers of e and 10 that
+ are normal floating-point numbers.
+. flo:subnormal-exponent-min-base-2 - Exponent of least positive power
+ of two that is a nonzero, subnormal floating-point number. This
+ number is the least positive floating-point number.
+. flo:subnormal-exponent-min-base-e, flo:subnormal-exponent-min-base-10 -
+ Exponents of least positive powers of e and 10.
+. flo:smallest-positive-subnormal - Smallest positive subnormal.
+. flo:smallest-positive-normal - Smallest positive normal.
+. flo:largest-positive-normal - Largest positive normal.
+. (flo:ldexp x e) = x * 2^e
+. (flo:scalbn x e) = x * b^e, where b is flo:radix
--- /dev/null
+Floating-point exceptions are now _not_ trapped by default.
+
+This follows IEEE 754's semantics for the default mode, and it has been
+the case on some platforms (e.g, macOS) for some time.
+
+If you want to trap on (e.g.) invalid-operation, you can do
+
+(flo:with-exceptions-trapped (flo:exception:invalid-operation)
+ (lambda ()
+ ...))
+
+You can also test for floating-point exceptions after a computation
+without trapping. Before you can do this for the first time in any
+thread, you must clear the floating-point exceptions (otherwise there
+may be residual garbage from past computations):
+
+(flo:preserving-environment
+ (lambda ()
+ (flo:clear-exceptions! (flo:all-exceptions))
+ (let ((x (do-big-computation)))
+ (if (not (zero? (flo:test-exceptions (flo:exception:underflow))))
+ (warn "underflow"))
+ x)))
--- /dev/null
+Added support for hexadecimal floating-point notation. Example:
+
+(parameterize ((param:printer-radix #x10))
+ (write-to-string (list #x1.5p10 1.5e10 0.1 (flo:nextafter 0.1 1.0))))
+;Value: "(#x1.5p+10 #x1.bf08ebp+33 #x1.999999999999ap-4 #x1.999999999999bp-4)"
--- /dev/null
+New IEEE 754 procedures:
+
+. (decompose-ieee754 x base emax precision if-zero if-subnormal if-normal if-infinite if-nan)
+. (decompoes-ieee754-binary x exponent-bits precision) -> [sign biased-exponent trailing-significand]
+. (decompose-ieee754-binary32 x) -> [sign biased-exponent trailing-significand]
+. (decompose-ieee754-binary64 x) -> [sign biased-exponent trailing-significand]
+. (decompose-ieee754-binary128 x) -> [sign biased-exponent trailing-significand]
+. (compose-ieee754-binary sign biased-exponent trailing-significand exponent-bits precision) -> real
+. (compose-ieee754-binary32 sign biased-exponent trailing-significand) -> real
+. (compose-ieee754-binary64 sign biased-exponent trailing-significand) -> real
+. (compose-ieee754-binary128 sign biased-exponent trailing-significand) -> real
+. (compose-ieee754-zero sign) -> real
+. (compose-ieee754-subnormal sign significand base emin precision) -> real
+. (compose-ieee754-normal sign exponent significand base emin precision) -> real
+. (compose-ieee754-infinity sign) -> real
+. (compose-ieee754-nan sign quiet payload) -> nan
+. (ieee754-binary32-exact? x) -> boolean
+. (ieee754-binary64-exact? x) -> boolean
+. (ieee754-binary128-exact? x) -> boolean
+. (ieee754-binary-hex-string x exponent-bits precision) -> string
+. (ieee754-binary32-hex-string x) -> string
+. (ieee754-binary64-hex-string x) -> string
+. (ieee754-binary128-hex-string x) -> string
--- /dev/null
+New pseudorandom number generator algorithm for random API.
+
+The PRNG algorithm is based on the stream cipher ChaCha. The state is
+a 32-byte seed s; each output x is obtained by breaking the 64-byte
+quantity ChaCha_s(0) into two 32-byte halves s' and x, and replacing
+the state s by s'.
+
+The state is a little smaller than the old algorithm, and we now
+implement random-source-pseudo-randomize! keyed by two 128-bit integer
+seeds which can safely be drawn from the random source itself to attain
+reproducible randomized subtrees of computation with no danger of
+collisions in the seeds.
+
+. (flo:random-unit state) is now deprecated: use flo:random-unit-open
+ if you must for essentially the same semantics, but prefer
+ flo:random-unit-closed.
+
+. (flo:random-unit-open state) samples from the uniform distribution on
+ real numbers in (2^{emin - p}/2, 1 - 2^p/2) rounded to the nearest
+ floating-point number. Previously, flo:random-unit and random-real
+ were limited to a narrower range and excluded many floating-point
+ numbers in that range.
+
+. (flo:random-unit-closed state) samples from the uniform distribution
+ on real numbers in [0, 1] rounded to the nearest floating-point
+ number. Effectively, though, it samples from (0, 1], because the
+ probability of getting 0 is smaller than 2^emin which is negligible
+ even for IEEE 754 binary32 (single-precision) where it is 2^-127,
+ whereas the probability of getting 1 is the small but nonnegligible
+ 2^{-p}/2, e.g. 2^-54 in binary64. Thus, it is safe to pass the
+ outcome to log, but not safe to pass the outcome to log1p.
+
+WARNING: The SRFI 27 and old MIT Scheme RNG API are not widely
+implemented as cryptographic PRNGs, so code written against them can't
+rely on them to be cryptographically secure in general. Further,
+anything involving random-integer, random-real, or bignums is likely to
+be vulnerable to timing attacks. But if you accidentally do use this
+API to generate cryptographic key material (like SRFI 27 suggests) then
+you might not be as bad off as you would have been before.
projects / mit-scheme.git / commitdiff