Martin Baker wrote:
>
> On 27/08/16 17:05, Waldek Hebisch wrote:
> > Martin, what gave you idea that cochain complex is obtained
> > by inverting matrices? Chain complex requires that product
> > of two consequtive matrices is 0, so normally matrices
> > are noninvertible (some may be
On 27/08/16 17:05, Waldek Hebisch wrote:
Martin, what gave you idea that cochain complex is obtained
by inverting matrices? Chain complex requires that product
of two consequtive matrices is 0, so normally matrices
are noninvertible (some may be invertible, but this is an
exception).
I
Martin, what gave you idea that cochain complex is obtained
by inverting matrices? Chain complex requires that product
of two consequtive matrices is 0, so normally matrices
are noninvertible (some may be invertible, but this is an
exception).
You could obtain cochain complex by transposing
oldk1331 wrote:
>
> This is a preliminary patch. I think there is no need to call
> "normalize" in hashUpdate! ?
>
> diff --git a/src/algebra/float.spad b/src/algebra/float.spad
> index 3996e67..0f06e64 100644
> --- a/src/algebra/float.spad
> +++ b/src/algebra/float.spad
> @@ -977,6 +977,9 @@
>
AFAICS problems with building trunk on Windows are due
to testing in PREGENERATED is an absolute path.
On Windows absolute paths may take strange form
and current test falsy claim that the path is not
absolute. Greg Vanuxem in his patch gave test
which accepts some Windows absolute paths, but
The "book" target in Makefile.in exists since the beginning
of FriCAS, however the file it referenced -- book.pamphlet,
never existed in th repo. I assume it's safe to remove this
part from Makefile.in ?
--
You received this message because you are subscribed to the Google Groups
"FriCAS -
This is a preliminary patch. I think there is no need to call
"normalize" in hashUpdate! ?
diff --git a/src/algebra/float.spad b/src/algebra/float.spad
index 3996e67..0f06e64 100644
--- a/src/algebra/float.spad
+++ b/src/algebra/float.spad
@@ -977,6 +977,9 @@
(q0, q1) := (q1, q2)
I think finding a good way to hash Float is important, not because of
the domain Float itself but rather when Float is used in the
construction of domains that one really might want to hash. E.g.
Expression Float.
I any case it should not be left unimplemented, rather it should at
least default
>
> On Fri, 17 Jun 2016, Waldek Hebisch wrote:
> > Hmm, OrderedSet is fine. However, OrderedRing, AbelianMonoid etc
> > is a lie: operations are only partial.
> apparently UnivariatePuiseuxSeriesWithExponentialSingularity relies on
> this lie:
> OrderedCompletion being an OrderedRing and
So what's your opinion?
1. Leave this function unimplemented,
2. or implement this function and hopefully
users don't run into trouble.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and
10 matches
Mail list logo