Activity
From 25 Jul 2014 to 23 Aug 2014
01 Aug 2014
-
10:56 Feature #484: Evaluate in other ring (was called :: in CoCoA-4)
- the CoCoA-4 operator "::" is now in another specific issue.
For the time being I think that *ReadExpr* may be good e... -
-
- CoCoA-4 has the *@::@* operator which evaluated expressions in a given ring:...
-
- Everything for the release
finalize cvs
make
make doc
make ManExamples
in snapshot dir:
cd src/CoCoA-5/re... -
- Done, tested, documented
Different from the cocoa-4 version: more flexible (see manual) -
- Redesign CoCoA-4 function CheckArgTypes (for checking argument types, of course...)
31 Jul 2014
-
- Even though I had closed this issue saying:
> Even though CoCoAHelp.xml isn't all written like that (too dangerous t... -
- Duplicates #169: "Font for parameters in manual".
Design is all set there.
Closing this issue. -
- As said in another issue:
- parameters should have the same name as in <syntax>
- <syntax> should be moved before <... -
- Is the new approach in BuiltInFunctions good enough?
I think so: it is not a one-liner but it's very readable (look f... -
- Now all functions work. A proper clean-up and re-design is in another issue.
30 Jul 2014
-
- We are also working an efficient algorithm for implicitization.
Keep that in mind for this issue, or make a new issue. -
- There are many tools to deal with subalgebras (see @toric@ and @normaliz@), so it would make sense to design a nice i...
-
- Resumed package (slight design change, documented)
It will be imrpoved, but that's beyond this task scope.
-
- The function in CoCoA-5 is already done and called @RingSet@ (see manual) but I'm not happy with the name: should I c...
29 Jul 2014
-
- the error message was indeed a bit puzzling in some cases now it is:...
-
12:31 Design #403: Misuse of dot-dot operator
- Giulia's problem could be neatly resolved by allowing the following syntax *@L[2..4]@* to mean @[L[k] | k in 2..4]@. ...
-
- My main concern is the (possibly) unexpected behaviour illustrated in example *@(B)@* in comment 1. However, for a l...
-
- The main action taken was to clarify the manual entry for ".."; it is now quite clear, and even mentions Giulia's inc...
-
- I suggest to reject this issue.
@A..B@ works for A and B integers or indeterminates in the order of their definition... -
-
28 Jul 2014
-
- This is no longer a problem (after resolving issue #190). Closing.
PS I have added the example to @exbugs.cocoa5@. -
-
- Compilations flags are given by @VersionInfo()@
-
- The clean solution would be to have @intersect@ doing what @Intersection@ used to do.
Problem is @intersect@ for IDE... -
- Documented as obsolescent
-
- It is now officially documented as OBSOLETE, so I close this issue.
-
- the general @init@ file now works well.
I don't think there is a particular need for a user init file.
I regard thi... -
-
- I don't think we should eliminate it.
In time, we can see what can be useful and advertized (low priority) -
- Undecided, needs more thinking. Not urgent
-
-
- There are a few more @WrongTypeException@ left in @Interpreter.C@.
Those are of a slightly different nature and shou... -
- Changed also also PtrCast into RefTo<..>
cvs-ed
25 Jul 2014
-
- added templates for @RefTo<..>@.
-
- Now all @switch@ following @EvalArgAsT1or...@ have a default case giving and error.
This is good for maintenance: if... -
- Another possible name is *@UnwrapBigInt@*. I think it conveys the idea that the @BigInt@ is hidden inside the object...
-
- First pass is mostly done (BigIntValue --> INT, and similar).
I'm a bit undecided about a few other types like @OSTR... -
- John Abbott wrote:
> I'm not entirely convinced by the names @PtrCastIDEAL@ etc.
> It is true that the arg is a "po... -
- I started the change: there is no name clash problem with the class @INT@ :-)
... at least with gcc :-/
Anyway: in ca... -
- John Abbott wrote:
> I'd like a name which more clearly expresses that it is for converting "old" C4 code to C5.
Ind...
Also available in: Atom