From e97fd75357d10ac9d0a8ec43a77673461999d14f Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Sat, 17 Nov 2018 09:14:14 +0000 Subject: [PATCH] Add a directory of pending release notes. These are in separate files in no particular order so that we don't have merge conflicts when people merge branches with their own release notes. When a release goes out we can just clear the directory and start over. Some of these actually went out in 10.1 but didn't make it into the release notes (and a couple may have been slightly broken in 10.1 anyway). --- src/relnotes/aarch64 | 4 ++++ src/relnotes/arith | 18 ++++++++++++++++ src/relnotes/bug-floexcept | 3 +++ src/relnotes/bug-integerp | 8 +++++++ src/relnotes/bug-nan-notation | 3 +++ src/relnotes/bug-negate | 2 ++ src/relnotes/bug-rounding | 6 ++++++ src/relnotes/bvzero | 7 +++++++ src/relnotes/flonum | 30 +++++++++++++++++++++++++++ src/relnotes/flotrap | 23 +++++++++++++++++++++ src/relnotes/hexpoint | 5 +++++ src/relnotes/ieee754 | 23 +++++++++++++++++++++ src/relnotes/rng | 39 +++++++++++++++++++++++++++++++++++ 13 files changed, 171 insertions(+) create mode 100644 src/relnotes/aarch64 create mode 100644 src/relnotes/arith create mode 100644 src/relnotes/bug-floexcept create mode 100644 src/relnotes/bug-integerp create mode 100644 src/relnotes/bug-nan-notation create mode 100644 src/relnotes/bug-negate create mode 100644 src/relnotes/bug-rounding create mode 100644 src/relnotes/bvzero create mode 100644 src/relnotes/flonum create mode 100644 src/relnotes/flotrap create mode 100644 src/relnotes/hexpoint create mode 100644 src/relnotes/ieee754 create mode 100644 src/relnotes/rng diff --git a/src/relnotes/aarch64 b/src/relnotes/aarch64 new file mode 100644 index 000000000..6f318216d --- /dev/null +++ b/src/relnotes/aarch64 @@ -0,0 +1,4 @@ +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. diff --git a/src/relnotes/arith b/src/relnotes/arith new file mode 100644 index 000000000..20e36b040 --- /dev/null +++ b/src/relnotes/arith @@ -0,0 +1,18 @@ +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 diff --git a/src/relnotes/bug-floexcept b/src/relnotes/bug-floexcept new file mode 100644 index 000000000..46ffbb049 --- /dev/null +++ b/src/relnotes/bug-floexcept @@ -0,0 +1,3 @@ +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. diff --git a/src/relnotes/bug-integerp b/src/relnotes/bug-integerp new file mode 100644 index 000000000..8216ca74d --- /dev/null +++ b/src/relnotes/bug-integerp @@ -0,0 +1,8 @@ +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. diff --git a/src/relnotes/bug-nan-notation b/src/relnotes/bug-nan-notation new file mode 100644 index 000000000..3ef0a6fba --- /dev/null +++ b/src/relnotes/bug-nan-notation @@ -0,0 +1,3 @@ +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. diff --git a/src/relnotes/bug-negate b/src/relnotes/bug-negate new file mode 100644 index 000000000..d4b9c0376 --- /dev/null +++ b/src/relnotes/bug-negate @@ -0,0 +1,2 @@ +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. diff --git a/src/relnotes/bug-rounding b/src/relnotes/bug-rounding new file mode 100644 index 000000000..2e748d087 --- /dev/null +++ b/src/relnotes/bug-rounding @@ -0,0 +1,6 @@ +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. diff --git a/src/relnotes/bvzero b/src/relnotes/bvzero new file mode 100644 index 000000000..fc2554609 --- /dev/null +++ b/src/relnotes/bvzero @@ -0,0 +1,7 @@ +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. diff --git a/src/relnotes/flonum b/src/relnotes/flonum new file mode 100644 index 000000000..bedc759ac --- /dev/null +++ b/src/relnotes/flonum @@ -0,0 +1,30 @@ +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 diff --git a/src/relnotes/flotrap b/src/relnotes/flotrap new file mode 100644 index 000000000..e946c3dba --- /dev/null +++ b/src/relnotes/flotrap @@ -0,0 +1,23 @@ +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))) diff --git a/src/relnotes/hexpoint b/src/relnotes/hexpoint new file mode 100644 index 000000000..bfeb13c9d --- /dev/null +++ b/src/relnotes/hexpoint @@ -0,0 +1,5 @@ +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)" diff --git a/src/relnotes/ieee754 b/src/relnotes/ieee754 new file mode 100644 index 000000000..6855f2bfc --- /dev/null +++ b/src/relnotes/ieee754 @@ -0,0 +1,23 @@ +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 diff --git a/src/relnotes/rng b/src/relnotes/rng new file mode 100644 index 000000000..c7a8d7c23 --- /dev/null +++ b/src/relnotes/rng @@ -0,0 +1,39 @@ +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. -- 2.25.1