Finilized 1.6.3 release. release_1-6-3
authorRichard Kreckel <kreckel@ginac.de>
Thu, 27 Nov 2014 21:29:39 +0000 (21:29 +0000)
committerRichard Kreckel <kreckel@ginac.de>
Thu, 27 Nov 2014 21:29:39 +0000 (21:29 +0000)
Updated NEWS file, moved some comments so Doxygen won't be confused.

NEWS
ginac/crc32.h
ginac/hash_seed.h

diff --git a/NEWS b/NEWS
index 2a6e50d..c9399c3 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -1,7 +1,6 @@
 This file records noteworthy changes.
 
-
-1.6.3 (20 October 2014)
+1.6.3 (27 November 2014)
 * New expand_options::expand_transcendental. GiNaC will apply additional
   rules when expanding expressions if this option is specified, i.e.
   log(a*b) -> log(a) + log(b)
@@ -9,15 +8,15 @@ This file records noteworthy changes.
 * Functions can define a custom expand() and info() now.
 * Automatically rewrite (x^{-1})^c -> x^{-c} for positive c.
 * Transform abs(x)^n -> x^n if x is real and n is even.
-* improve power::info(): power with a real base and even exponent
+* Improved power::info(): power with a real base and even exponent
   reports that it's non-negative.
 * Fixed spurious match failure due to expairseq::match() bug:
   > match(sin(y)*exp(b)+sin(x)*exp(a), sin($0)*exp(a)+exp(b)*sin($1))
   FAIL
-* fixed power::is_polynomial() and mul::is_polynomial() computation.
+* Fixed power::is_polynomial() and mul::is_polynomial() computation.
 * factor_univariate correctly handles polynomials over rationals (no
   segfaults any more).
-* fixed an infinite loop in factor_multivariate due to incorrect handling
+* Fixed an infinite loop in factor_multivariate due to incorrect handling
   of polynomials having a leading coefficient being a sum with a non-trivial
   integer content.
 * Fixed numeric evaluation of generalized multiple polylogarithms for real
@@ -30,14 +29,12 @@ This file records noteworthy changes.
 * Avoid infinite recursion in series expansion of logarithm.
 * numeric::info(info_flags::nonnegative) correctly handles complex numbers
   with non-zero imaginary part.
-* power::is_polynomial(), mul::is_polynomial(): fix miscomputations.
 * Fixed several build issues:
   - libreadline and dlopen() misdetection.
   - multiple definition of symbol on MinGW.
   - auto* tools and texinfo being unhappy in various ways.
 * GiNaC can be built with CMake now.
 
-
 1.6.2 (6 November 2011)
 * Fixed the parser to read GiNaC::lst again.
 * Fixed a compile warning (relevant to openSUSE build).
index 6edd5c6..0974e42 100644 (file)
@@ -1,8 +1,10 @@
+/** @file crc32.h
+ *
+ * CRC32 hash function. Shamelessly stolen from GNU coreutils (cksum.c). */
+
 #ifndef GINAC_CRC32_H
 #define GINAC_CRC32_H
-/**
- * CRC32 hash function. Shamelessly stolen from GNU coreutils (cksum.c)
- */
+
 namespace GiNaC
 {
 static unsigned const crctab[256] =
index 32b057f..6cf65ac 100644 (file)
@@ -1,5 +1,19 @@
+/** @file hash_seed.h
+ *
+ * Type-specific hash seed. */
+
 #ifndef GINAC_HASH_SEED_H
 #define GINAC_HASH_SEED_H
+
+#include <typeinfo>
+#include <cstring>
+#include "crc32.h"
+#include "utils.h"
+#ifdef _WIN32
+#define GINAC_HASH_USE_MANGLED_NAME 1
+#endif
+namespace GiNaC
+{
 /**
  * We need a hash function which gives different values for objects of
  * different types. Hence we need some unique integer for each type.
  * collisions (and slower evaluation as a result), but being a bit slower
  * is much better than being wrong.
  */
-#include <typeinfo>
-#include <cstring>
-#include "crc32.h"
-#include "utils.h"
-#ifdef _WIN32
-#define GINAC_HASH_USE_MANGLED_NAME 1
-#endif
-namespace GiNaC
-{
 #ifndef GINAC_HASH_USE_MANGLED_NAME
 static inline unsigned make_hash_seed(const std::type_info& tinfo)
 {
-       // this pointer is the same for all objects of the same type.
-       // Hence we can use that pointer 
+       // This pointer is the same for all objects of the same type.
+       // Hence we can use it.
        const void* mangled_name_ptr = (const void*)tinfo.name();
        unsigned v = golden_ratio_hash((p_int)mangled_name_ptr);
        return v;