Re: [fricas-devel] Deprecated operations in scene.spad

On 12/04/2024 09:23, Ralf Hemmecke wrote: I do not understand why you think that not both graphics systems can live besides each other (as they do now)? Well, I think that the interactive graphics should work seamlessly with the things that scene.spad can do such as outputting to various file

Re: [fricas-devel] Deprecated operations in scene.spad

I don't mind, I have given up with this software now. When I wrote the code I was hoping that this approach would replace old boot and C code with something much more maintainable and flexible. Also the scenegraph architecture makes it much easier to export to 2D and 3D graphics files like SVG

Re: [fricas-devel] improve "dbReadLines"

On 07/04/2024 13:28, Qian Yun wrote: I wonder if i-output.boot is a good target to port to Spad first. About 10 years ago I wrote some SPAD code to implement the functionality of the 2D output (algebraFormat) code in 'i-output.boot':

Re: [fricas-devel] Convertion of types to OutputFrom

If you did this it would enable the use of infix notation for Boolean implies (I don't remember ever actually using the implies function so its not important for me). from prefix notation implies : (%, %) -> % to infix notation% => % -> %

Re: [fricas-devel] Convertion of types to OutputFrom

It seems a bit sad that your effort needs to be spent on boot code rather than converting it to SPAD? Martin On 18/10/2023 01:05, Waldek Hebisch wrote: Attached is my attempt to do proper coercion. 'nformat.boot' contains main new function, that is 'constructor_to_OutputForm' and patch to

Re: [fricas-devel] Why are inflexible data structure lengths not always encoded in the type?

On 30/10/2020 17:29, Ralf Hemmecke wrote: > In FriCAS they are not (also not in Aldor). > The reason is that no computation is done at compile time. > Of course that could be changed if there were a sublanguage that the > compiler could execute at compile time. > > But why would you believe that

Re: [fricas-devel] Why are inflexible data structure lengths not always encoded in the type?

On 29/10/2020 21:10, Neven Sajko wrote: My guess would be that it would be better if Vector's constructor had a length parameter, because that would enable greater type safety (i.e. I couldn't pass a Vector of the wrong length to a function). For me one of the great advantages of static types

Re: [fricas-devel] new TexFormat

Ralf Back in 2014 I wrote some SPAD code to output 2D text with the same sort of interface as i-output but it could easily be adapted for other interfaces: https://github.com/martinbaker/multivector/blob/master/monospace.spad.pamphlet It is documented here:

Re: [fricas-devel] Group presentation

On 08/05/18 13:19, Waldek Hebisch wrote: Hmm, have you looked at: https://sourceforge.net/p/fricas/code/HEAD/tree/trunk/src/doc/htex/GROUPP.htex Do you think that this is "hidden"? It is hidden for me, I turn off HyperDoc in the start up script and I use fricas.github.io. I think its

Re: [fricas-devel] Group presentation

way where new users cant find it. Martin On 07/05/18 10:34, Waldek Hebisch wrote: Martin Baker wrote: If I was scanning through this very quickly I would probably have assumed that the free group was a presentation without relations and this function was adding the relations (that is the f

Re: [fricas-devel] Group presentation

Waldek, Thank you for that explanation I, at least, found it really helpful, especially the Mathieu group example. > However, it is not really task of _reference_ documentation to > provide education to such users. First, much of needed > background knowledge can be found in existing

Re: [fricas-devel] Group presentation

On 04/05/18 19:43, Waldek Hebisch wrote: > Group presentation can be defined as a set of elements of > a free group and frequently published group presentations > are written in this way. Below is a little package to > convert from list of generators and list of elements > of free group to group

Re: [fricas-devel] html.spad

On 29/03/18 14:12, oldk1331 wrote: On Wed, Mar 28, 2018 at 5:43 PM, Martin Baker <ax87...@martinb.com> wrote: However something looks funny about the patch, do you need both => and return void()$Void ? is the 'return' redundant? Its been a long time and I may have forgotten something

Re: [fricas-devel] html.spad

On 29/03/18 14:12, oldk1331 wrote:> You see, without explicity a "return void()$Void", some other value may be returned, but again, there's nothing interesting to do with a value of Void type. That's not my point. You have changed the code to this: every?(leaf?, c) => s : String := concat

Re: [fricas-devel] html.spad

Hi oldk1331, (should I call you oldk1331?) I tried it and it seems to work OK. Here is a test case: )set output algebra off )set output html on a=b Without this condition 'a','=' and 'b' would appear on separate lines but both with and without the patch they are correctly combined onto one

[fricas-devel] html.spad

oldk1331, Thanks for fixing the typos in html.spad but I'm not sure about the americanisation of the word 'customise'! Martin -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop

Re: [fricas-devel] what RetractableTo should actually export

On 14/10/17 11:43, oldk1331 wrote: go beyond that and specify axioms seems even more impossible. "Specify axioms"? Do you mean theorem prover? Like Coq or Isabelle? Well the human-readable way to Specify axioms in category theory is diagrams that commute but I suspect the computer-readable

Re: [fricas-devel] what RetractableTo should actually export

On 14/10/17 02:01, oldk1331 wrote: On Sat, Oct 14, 2017 at 5:16 AM, Bill Page wrote: I am sorry but I do not see how to view this as a natural transformation in the sense of category theory or as the term is applied in Haskell. Could you explain? I mean it

Re: [fricas-devel] Maybe preview

On 01/10/17 04:49, oldk1331 wrote: Again, I think this is a small problem, because 1. there's no point of using Maybe(Maybe(XXX)). I have not followed this thread closely so apologies if my thoughts here are off track. I get the impression that you now agree that monads are not currently

[fricas-devel] default 'T()' and "_|_" in Logic

Waldek, I see that you have added default 'T()' and "_|_" in Logic. It just seems a bit wasteful to hardwire the two notations to be exactly the same. Where one seems to be logic terminology and the other seems to be lattice terminology: T == true ___|__ == false especially since, in

Re: [fricas-devel] T and _|_ : how to use them

On 22/03/17 13:57, Waldek Hebisch wrote: For me it looks as another aspect of "monoid problem": in various context there is strong mathematical tradition to use specific symbols with different symbols in different context. FriCAS domains have fixed operation names so it is hard to fit all

Re: [fricas-devel] Re: About Travis CI

On 04/04/17 17:33, Waldek Hebisch wrote: oldk1331 wrote: I mean, if Waldek don't want to include this travis CI script for now, you can set up a branch that does travis CI testing. I is not clear for me what actually we gain from travis CI. My understanding is that travis CI is run _after_

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

On 31/03/17 14:08, Bill Page wrote: Perhaps one of the things that makes this resistance to such changes seem sound is that FriCAS lacks anything approaching a comprehensive test system. This makes it quite possible that changes such as we propose could have far reaching effects which are not

Re: [aldor-devel] Re: [fricas-devel] interpreter/spad/aldor grammar for atom

On 30/03/17 23:25, Ralf Hemmecke wrote: On 03/30/2017 10:59 PM, Peter Broadbery wrote: Sorry - somewhat unclear.. The plugin is fairly good for spad files and shows ++ comments for domains, without any pre-processing.. In the java world the corresponding /** comments are turned into html with a

Re: [fricas-devel] interpreter/spad/aldor grammar for atom

On 30/03/17 16:48, Bill Page wrote: I have been playing with defining a language package for atom to provide syntax highlighting and other edit functions for spad. I have a few simple things working. Is anyone else interested in using atom this way? Does anyone have more experience with doing

Re: [fricas-devel] [PATCH] documentation for permgrps.spad

On 29/03/17 21:51, Waldek Hebisch wrote: Martin Baker wrote: I don't think it is good enough to say that, in FriCAS, the only documentation for an important topic like group theory is an out-of-print book. I am not sayng that. Just that claiming that there is no good documentation is wrong

Re: [fricas-devel] [PATCH] documentation for permgrps.spad

3) Coming back to specific question of Schreir-Sims algorithm. This algorithm is described in A. Seress book "Permutation group algorithms". IMO this is quite good description. AFAICS think this book is not freely available. Once somebody understands the algorithm tracking code

Re: [fricas-devel] [PATCH] documentation for permgrps.spad

On 27/03/17 04:49, Waldek Hebisch wrote: some passage look completely wrong, like: +The use of the Vector domain for this does seem to be stretching +the FriCAS type system a bit. For instance elements of subgroup are +coded as a vector of a vector (Vector Vector NNI) which would not be

Re: [fricas-devel] [PATCH] documentation for permgrps.spad

On 24/03/17 02:06, oldk1331 wrote: By 'literate' I mean formatted text. Do you mean '\spad{}' markup? No I meant the LaTeX formatted text between ')if false' and ')endif'. I think the term should really be used for the methodology that Tim is using in Axiom rather that what it has become

[fricas-devel] [PATCH] documentation for permgrps.spad

I have added some documentation to permgrps in patch here: https://github.com/martinbaker/fricasAlgTop/blob/master/permgrps2.patch This contains documentation only, no code changes. By 'documentation' I mean comments + literate. By 'literate' I mean formatted text. I have not tried to follow

Re: [fricas-devel] T and _|_ : how to use them

On 21/03/17 11:26, Ralf Hemmecke wrote: On 03/21/2017 11:50 AM, Martin Baker wrote: Yes, but Boolean can only return true or false, there is only confusion in logics where variable/proposition names can also be returned. Look at what I have done to help with the evaluation

Re: [fricas-devel] T and _|_ : how to use them

On 21/03/17 09:23, oldk1331 wrote: Martin, I noticed that in logic.spad, _|_ is used zero times in code, it only appears in comment and docs. So _|_ is actually not implemented, right? Yes, its in BoundedJoinSemilattice and I thought it was implemented in ILogic, I don't know if it got lost?

Re: [fricas-devel] T and _|_ : how to use them

On 21/03/17 08:35, Ralf Hemmecke wrote: On 03/21/2017 09:26 AM, Martin Baker wrote: What I'm trying to say is that in, say, intuitionistic logic we have variables (in the mathematical sense - can range over all values). For example, proposition("a") here: (1) -> proposition(&

Re: [fricas-devel] T and _|_ : how to use them

On 21/03/17 07:43, Ralf Hemmecke wrote: On 03/21/2017 08:34 AM, Martin Baker wrote: In ILogic T and _|_ are required as top and bottom of lattice. In Boolean I guess they should give true and false? Certainly, because these are the only values in Boolean. I think its only when logic

Re: [fricas-devel] T and _|_ : how to use them

On 21/03/17 03:21, oldk1331 wrote: T and _|_ is exported from category Logic and domain Boolean, are they intended to be used by user? (1) -> T()$Boolean The function T is not implemented in Boolean . (1) -> __|__()$Boolean The function _ is not implemented in Boolean . In ILogic T

[fricas-devel] FriCAS SPAD Style

On 05/03/17 18:45, Waldek Hebisch wrote: I worked with various code and IME it is much easier to work with generous whitspace. When lines are getting to long just break them up. One should try to make code simpler and smaller, but squeezing more code in small space is counterproductive. It

Re: [fricas-devel] [PATCH] tweak the output of AGGLST

On 05/03/17 13:09, oldk1331 wrote: The output of "[1,2]" is "[1,2]", I think adding a space after a comma is better. And multiline list already does this: [1,2,10^100]. I don't know what the issues are in this particular case but, as a general principle, I don't like adding spaces in

[fricas-devel] development environment using git

On 02/02/2017 11:59 AM, Ralf Hemmecke wrote: On 02/02/2017 11:51 AM, Martin Baker wrote: When I'm working on a given subject area, say AlgTop, I like to have a small flat directory with all the working files in one place so I can just type things like: )co gpresent )r gpresent )r someLocalTest

Re: [fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation

On 02/02/2017 10:11 AM, oldk1331 wrote: Hi Martin, because you don't commit to fricas directly, you have to merge the changes back to your master branch, that causes problem when Waldek commits a slightly different version of your patch. And your master branch history will be messy. The

Re: [fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation

On 02/01/2017 11:17 PM, Kurt Pagani wrote: Hi Martin Running the risk to give false alarm again, I can't compile gpresent.spad after your merge with trunk. Neither after removing the surplus paren on line 1467 : + relatorTables(state,rs)) Hi Kurt, Thank you for letting me know about that,

Re: [fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation

On 01/31/2017 06:33 PM, Waldek Hebisch wrote: Kurt Pagani wrote: @Martin: gpresent.input now reports: unexpected failures: 3 relationsInGenerator? Which ones? For ma all tests passed. Note: you need to use latest version of both: gpresent.spad permgrps.spad If I update gpresent but not

Re: [fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation

Waldek, This is great, thank you for this. I have a patch here to add to this code: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent7.patch or full code is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent.spad The patch does the following: 1) I have

Re: [fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation

On 01/29/2017 01:41 PM, Dima Pasechnik wrote: Well, e.g. Todd-Coxeter is pretty much domain-specific; one could also choose to interface a stand-alone coset enumeration routine like ACE (see http://staff.itee.uq.edu.au/havas/ and https://gap-packages.github.io/ace/). Producing toy

Re: [fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation

On 01/26/2017 09:04 PM, Kurt Pagani wrote: Hi Martin I've also tried your code and must confirm Waldek's statements. I guess there are some pitfalls which are known for some time. Did you read "Implementation and Analysis of the Todd-Coxeter Algorithm" by Cannon et al.? Old but still

[fricas-devel] [PATCH] update documentation for alg_top.spad

I have updated documentation/comments for alg_top.spad to correspond to recent code changes. This patch contains no code changes: https://github.com/martinbaker/fricasAlgTop/blob/master/alg_top4.patch Martin B -- You received this message because you are subscribed to the Google Groups

[fricas-devel] [PATCH] update documentation for gpresent

This patch contains changes to documentation+comments only, no changes to code. https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent6.patch Comments are changed to correspond to recent change to code in gpresent.spad. Martin B -- You received this message because you are

Re: [fricas-devel] Vector which implements AbelianGroup

On 01/23/2017 06:33 PM, Ralf Hemmecke wrote: On 01/23/2017 06:52 PM, Martin Baker wrote: I would like a Vector domain which implements AbelianGroup. http://fricas.github.io/api/DirectProduct.html Ralf Thanks Ralf, just what I was looking for. I did look on fricas.github.io but I only

[fricas-devel] Vector which implements AbelianGroup

I would like a Vector domain which implements AbelianGroup. Unfortunately Vectors in FriCAS don't appear to implement AbelianGroup because it needs to implement 0:% which it can't because the nearest function in Vector is zero: NonNegativeInteger -> % but this needs to know the number of

Re: [fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation

On 01/23/2017 04:58 PM, Waldek Hebisch wrote: Note: I used wordInStrongGenerators as a helper I find it hard to understand the functions in PermutationGroup. Partly because I cant find any documentation (I searched the usual places but its easy to miss things) and its hard to follow the code

Re: [fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation

On 01/23/2017 05:37 AM, Waldek Hebisch wrote: Martin Baker wrote: Patch is here: https://github.com/martinbaker/fricasAlgTop/blob/master/permgrps1.patch I have tried it now. AFAICS it is _extremally_ inefficient: coerce(symmetricGroup(4))@GroupPresentation crashes due to running out of memory

[fricas-devel] [PATCH] Improvements to algebraic topology

Waldek, I would be grateful if you could consider this patch before the next FriCAS release. It is a patch to alg_top.spad, this brings it up to 3 pending patches from me. Patch is here: https://github.com/martinbaker/fricasAlgTop/blob/master/alg_top3.patch Full file is here:

Re: [fricas-devel] FriCAS status

On 01/16/2017 01:30 PM, Waldek Hebisch wrote: There are also improvements that I would like to add (in particular I have to look at Martin's Baker patch). Yes, there are 2 outstanding patches. The first one is here: https://groups.google.com/forum/?hl=en#!topic/fricas-devel/EtLwgd2dWNU This

Re: [fricas-devel] Group domains in FriCAS

On 07/12/16 01:01, Waldek Hebisch wrote: About your proposal: note that notion of permutation group is closely related to notion of subgroup (and at categorical level with final object of a category). Finitely presented groups are related to quotients (and first object of a category). As a

[fricas-devel] Group domains in FriCAS

My initial thoughts about group domains related to homotopy in FriCAS is that there is a need for at least 4 group domains shown at each corner of this square: PermutationGroup <-equivalent-> GroupPresentation |if finite | |

[fricas-devel] [PATCH] group conversions

I have put an implementation of Todd-Coxeter algorithm here: Patch is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent5.patch Full code is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent.spad This goes together with the conversion in the opposite

[fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation

Patch is here: https://github.com/martinbaker/fricasAlgTop/blob/master/permgrps1.patch File is here: https://github.com/martinbaker/fricasAlgTop/blob/master/permgrps.spad It is used like this: permgp := dihedralGroup(3)$PermutationGroupExamples (1) <(1 2 3),(1 3)>

Re: [fricas-devel] [PATCH] More simplifications in GroupPresentation

Kurt and Bill, Thanks for your ideas so far. I had an idea to try to combine what you said with what I am trying to do. It seems to me that there is a very approximate design pattern here since each of these algebraic structures seem to be defined by two domains by pseudo code like this:

Re: [fricas-devel] [PATCH] More simplifications in GroupPresentation

On 12/11/16 17:37, Bill Page wrote: I think I know what you mean however in FriCAS % always represents a domain - not an element of a domain. In the category 'Group' % represents a domain whose operations satisfy group axioms. Perhaps it is unexpected that so few domains in FriCAS satisfy Group

Re: [fricas-devel] [PATCH] More simplifications in GroupPresentation

On 10/11/16 16:46, Kurt Pagani wrote: On 10 November 2016 at 10:37, Martin Baker <ax87...@martinb.com <mailto:ax87...@martinb.com>> wrote: Hi Kurt, > Your "GroupPresentation" actually isn't a group, so I wonder whether it wouldn't > be favourabl

Re: [fricas-devel] [PATCH] More simplifications in GroupPresentation

On 10/11/16 16:46, Kurt Pagani wrote: I'm definitely encouraging you to implement T-C. Thats my plan. > Then we will rely on (permgrps.spad): Well it will have to be like this: toPermutationIfCan(GroupPresentation):Union(PermutationGroup S, "failed") because it needs to fail for infinite

Re: [fricas-devel] [PATCH] More simplifications in GroupPresentation

Hi Kurt, > Your "GroupPresentation" actually isn't a group, so I wonder whether it wouldn't > be favourable to implement a domain, e.g. "FinitelyPresentedGroup" which could > be reused elsewhere. If you take on the burden to augment some group theory to > Fricas anyway, you might consider

[fricas-devel] [PATCH] More simplifications in GroupPresentation

This patch contains the following changes to GroupPresentation: 1) Improve simplify function to remove duplicate relations. 2) Rename subgroup to quotient. In simplify, relations are now considered duplicates if they are identical or if they are the same after being cycled or if they are the

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

It seems to me that there are two possible reasons for implementing category theoretic structures in FriCAS: 1) Because FriCAS should implement as many mathematical structures as possible and because much of modern mathematics is done in the language of categories and FriCAS should reflect

[fricas-devel] [PATCH] fix urls

Here is a patch to fix URLs (no code changes): https://github.com/martinbaker/multivector/blob/master/fixUrls.patch This is mostly removing invalid spaces but there are some other changes. The changes affect the following files: src/algebra/alg_top.spad src/algebra/clifford.spad

Re: [fricas-devel] [PATCH] fix and improvements to gpresent.spad

On 10/10/16 00:40, Waldek Hebisch wrote: Commited (after edit). OK thanks, I will rename the subgroup functions to quotient. Before I make any changes I will do some reading on Todd-Coxeter algorithm which may take some time. BTW Do you know of any existing code in FriCAS that would help

Re: [fricas-devel] [PATCH] fix an indexing bug in bezout.spad

On 09/10/16 09:47, oldk1331 wrote: I would like to add some comments for subSylvesterMatrix, I'd prefer add a reference to the book which this algorithm is based on, like "-- Page 20, Definition 1.4.2, Symbolic Integration Transcendental Functions, second edition", instead of repeating the

Re: [fricas-devel] [PATCH] fix and improvements to gpresent.spad

On 08/10/16 12:54, Waldek Hebisch wrote: Some statements there look wrong. For example: +We can generate a subgroup by either removing a generator or +adding a relation. By adding a relation you form _quotient_ group. Maybe you think about kernel of quotient map, which indeed is a subgroup.

Re: [fricas-devel] [PATCH] fix and improvements to gpresent.spad

Waldek, Thank you for committing this. Here is associated, documentation-only update (no code changes). Patch is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent3.patch File is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent.spad Martin B -- You

[fricas-devel] [PATCH] fix and improvements to gpresent.spad

Here is a patch for gpresent.spad to: 1) Fix regression bug to output, see note below. 2) New functions such as: directProduct and subgroup. 3) Better simplification including ability to eliminate a generator by substituting one relation in another. 4) Some re-factoring and tidyups. 5) Add

Re: [fricas-devel] Regression testing

On 27/09/16 18:55, Waldek Hebisch wrote: Since sometimes there are good reasons for irregularity I do not insist on rigid structure. But I would like to avoid irregularities which are just due to slightly different preferences. Yes, its a difficult dilemma. I really appreciate lack of

Re: [fricas-devel] Regression testing

On 25/09/16 23:31, Waldek Hebisch wrote: Concerning 'randomSimplicialComplex': random testing has some advantages and drawbacks. Main drawback is that results change, so checking for correctness is harder. Normal random tests have advantage that they can generate large number of examples

[fricas-devel] Alg Top - Issue 2 - homotopy of delta complex

On 30/08/16 16:43, Waldek Hebisch wrote: Concening future developement, we need to rethink some basics. First, current DeltaComplex looks fine for homology (except for lack of vertices in representation). But it is underspecified for homotopy. As I wrote, there should be enough information to

[fricas-devel] [PATCH] fix regression bug gpresent to OutputForm

Waldek, A small bug fix for you. patch is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent1.patch code is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent.spad Martin B -- You received this message because you are subscribed to the Google Groups

[fricas-devel] Regression testing

On 24/09/16 22:33, Waldek Hebisch wrote: Since in similar way one can build projective space I have replaced projectivePlane() by projectiveSpace(n) where n is the dimension. I also made a few other changes to make code more efficient. Thank you for improving and committing. > ATM I have

Re: [fricas-devel] [PATCH] alg top - new factory functions.

On 24/09/16 17:56, Martin Baker wrote: Apart from Homotopy (which I will look at next) the only anomaly is projective plane, see line 19 below. Just realised whats wrong with projective plane, it should have 2 vertices like this: -- generate a minimal projective plane. projectivePlane

Re: [fricas-devel] [PATCH] computation.spad Documentation Issues.

On 22/09/16 10:35, Ralf Hemmecke wrote: Hi Martin, Because different browsers can render SVG slightly differently I tend to export to a raster format (PNG) for the web. I think this is as standards based as I can get. I have seen that font-related stuff can differ from computer to computer,

Re: [fricas-devel] [PATCH] computation.spad Documentation Issues.

On 22/09/16 10:25, Ralf Hemmecke wrote: What exactly is meant by "FriCAS IO"? I meant your website: https://fricas.github.io/ Do you think it would be viable, when browsing the Category/Domain/Package API, that the information about each individual structure might additionally link out to

Re: [fricas-devel] [PATCH] computation.spad Documentation Issues.

On 21/09/16 20:56, Waldek Hebisch wrote: Martin Baker wrote: Usually I first produce documentation in HTML and put it on my website. I then copy it into code file, this copy is inferior to the HTML version because it does not have diagrams. What do you use to create diagrams? In other words

[fricas-devel] [PATCH] computation.spad Documentation Issues.

on the online documentation? It would be really good if Fricas IO could be the hub for all the various types of online documentation for all categories, domains, etc. If there were to be a standardised way to embed URLs in ++ comments like this: ++ Author: Martin Baker ++ Date Created: March 2011

Re: [fricas-devel] Algebraic Topology Issue 1

On 19/09/16 20:25, Kurt Pagani wrote: However, you can get the current handbook from github if you are interested: https://github.com/gheber/kenzo/raw/master/doc/Kenzo-Doc.pdf https://github.com/gheber/kenzo I have only just skimmed through so far but Kenzo does look very interesting. It

Re: [fricas-devel] Algebraic Topology Issue 1

On 20/09/16 16:06, Waldek Hebisch wrote: > You are confused. It happens! I have tried the patch and AFAICS it works fine, I would be happy if it were applied. > As a face (part of simplical complex) (1,3) and > (3, 1) are the same face. And problem is not due to wrong > orientation of input:

Re: [fricas-devel] Algebraic Topology Issue 1

On 19/09/16 11:17, Waldek Hebisch wrote: AFAICS code which allows omiting lower dimensional faces is buggy, if we include lower dimensional faces we get duplicate simplices. In particular, all faces of triangle are duplicated and we get three extra loops. Are sure this is buggy? AFAICS we

Re: [fricas-devel] Algebraic Topology Issue 1

On 19/09/16 12:00, Ralf Hemmecke wrote: I can only speak for firefox, but you should note that forging a http connection is easier than forging a https connection. If you allow Firefox to do an exception for the above site (note that you don't need to accept that exception "permanently" --

Re: [fricas-devel] Algebraic Topology Issue 1

On 19/09/16 04:59, Kurt Pagani wrote: Hello Martin As promised (before vacation) below two examples which I'm unable to interpret (otherwise I recognized that you've improved your code and that it's now included in fricas -- great :). A lot more examples work now (i.e same results as Kenzo).

Re: [fricas-devel] [PATCH] Minor code changes to computation.spad

On 18/09/16 18:41, Waldek Hebisch wrote: Martin Baker wrote: Thanks for applying previous patch. When you did this you made some changes and one of these changes introduced a bug, so here is a fix for this bug: I got caught by Spad weirdness. In Spad "string"::OutputForm i

Re: [fricas-devel] [PATCH] Minor code changes to computation.spad

On 17/09/16 06:00, oldk1331 wrote: I want to have print "a string" insead of print("a string"::OutputForm) when I am debugging. I tried to add a "print : String -> Void", but not successful. What's the right way to do it? I also asked about something like this in thread here:

Re: [fricas-devel] [PATCH] Minor code changes to computation.spad

On 15/09/16 19:49, Waldek Hebisch wrote: Martin Baker wrote: Minor code changes to computation.spad 1) Change sayMsg to print. 2) Improve OutputForm, don't use string. 3) implement CoercibleTo(OutputForm). I see that you have a lot of code like: str::Symbol::OutputForm If you want

[fricas-devel] [PATCH] Minor code changes to computation.spad

Minor code changes to computation.spad 1) Change sayMsg to print. 2) Improve OutputForm, don't use string. 3) implement CoercibleTo(OutputForm). new file is here: https://github.com/martinbaker/multivector/blob/master/computation.spad patch is here:

[fricas-devel] [PATCH] update URLs in computation.spad

This patch only modifies URLs, no other changes. Spaces are removed and URLs updated, invalid URLs removed. new file is here: https://github.com/martinbaker/multivector/blob/master/computation.spad and patch is here: https://github.com/martinbaker/multivector/blob/master/computation.patch

[fricas-devel] [PATCH] updates to graph code

Waldek, Here are some updates to graph.spad, the new file is here: https://github.com/martinbaker/fricasScene/blob/master/graph.spad Or patch is here: https://github.com/martinbaker/fricasScene/blob/master/graph.patch The changes are: 1) Improve output from UndirectedGraph to SVG and to

[fricas-devel] [PATCH] updates to scenegraph code

Waldek, I have a patch for the scenegraph code, the new file is here: https://github.com/martinbaker/fricasScene/blob/master/scene.spad Or, if you prefer, the patch is here: https://github.com/martinbaker/fricasScene/blob/master/scene.patch The changes are: 1) Better scaling of fonts when

Re: [fricas-devel] Algebraic Topology Issue 1

On 05/09/16 01:17, Waldek Hebisch wrote: No. My suggestion is to have: FiniteSimplicialComplex(VS : SetCategory) ... Rep := Record(VERTSET : List(VS), SIMP : List(OrientedFacet)) SIMP can use numbers from 1 to n. VERTSET gives correspondence between numbers and vertices. I can see

[fricas-devel] Algebraic Topology Issue 1

Waldek, Thank you for including the algebraic topology in 1.3.0 despite some remaining issues. I thought the best way to tackle those issues is to look at them, one at a time, then try to work out a separate patch for each one. I guess I could send you some patches and see if you accept

[fricas-devel] github questions

You are quite correct about me being a github novice. With the latest release of FriCAS I thought now would be a good time to try and track future updates better. Currently I have a very old (330 commits behind fricas:master) clone here: https://github.com/martinbaker/fricas This is setup

Re: [fricas-devel] algebraic topology code

On 30/08/16 16:43, Waldek Hebisch wrote: I now commited your files (with several changes). Thank you very much for checking/correcting the code and including in FriCAS. Concening future developement, we need to rethink some basics. I will work through everything that you have said.

Re: [fricas-devel] algebraic topology code

Hi Waldek, I don't think the DeltaComplex to SimplicialComplex coercion is crucial so if you are not happy with it then it could be omitted. The main reason I wrote it is to use in a regression test for SimplicialComplex to DeltaComplex which is much more important. so: SimplicialComplex

Re: [fricas-devel] algebraic topology code

On 28/08/16 01:27, Waldek Hebisch wrote: 'cochainComplex' in ChainComplex is doing this. I think that ATM it is best to delete this routine. Of course if you later work out working version, then we can re-add it. Agreed, I have removed this for now. You could obtain cochain complex by

Re: [fricas-devel] algebraic topology code

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

Re: [fricas-devel] programming guidelines

On 12/08/16 09:53, Ralf Hemmecke wrote: On 08/12/2016 10:37 AM, oldk1331 wrote: foo bar.fieldname OT a little, I think "bar.fieldname" equals to "bar fieldname"? Then one can still write "foo bar fieldname". True. Semantically, it's the same. But fields are (at least in our context)

[fricas-devel] algebraic topology code

I think I have addressed the issues that Waldek raised. I have merged in the spelling correction from trunk. I have also tried to match the style issues that Waldek uses (such as removing 'date last changed' from header) although I have not seen these style standards documented so I'm not

  1   2   3   4   >