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 formats and having much more control over the output. For all this to work together without duplication it all needs to be written in SPAD. The problem is interactive graphics require multi-threading and I can't see anyone agreeing to a limitation that SPAD can only work on top of some specialised lisp with multi-threading. I suspect that is the reason for the C code to allow multi-threading. People usually suggest using their favorite 3rd party graphical front end but I can't see Waldek making FriCAS totally reliant on some 3rd party software. Another problem is that graphic interfaces, hardware, file formats change rapidly and these interfaces need more maintainable code. For example will FriCAS support X11 to wayland transition? 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/9d8ebbb8-c155-4c0f-87f6-ca0bf5158106%40martinb.com.
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 and X3D and being written in SPAD it would have been easy to add other graphics formats. I'm not critisising because I don't see the big picture but it seems to me that going from boot code to SPAD in lots of small steps rather than one big step is impossibly slow and and risks replacing messy boot code with messy SPAD code. Martin On 12/04/2024 01:59, Waldek Hebisch wrote: scene.spad contains several operators marked as deprecated. In about 8 years there were no siginficant changes to scene.spad. I think that there is time to either remove the depreciated operations or decide that thay should stay indefinitely and remove depreciacation notice. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/33aeefee-b6a3-4961-b5b5-03e3dbb5a105%40martinb.com.
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': https://github.com/martinbaker/multivector/blob/master/monospace.spad.pamphlet Waldek was not interested in this at the time. I think because, even if you debugged it extremely carefully you could never 100% guarantee to be identical with the output of the boot code. I assume this requirement is the reason that progress is so slow. 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/2e825980-89b3-436f-9eac-710b9fdf878b%40martinb.com.
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% => % -> %
https://github.com/fricas/fricas/blob/master/src/algebra/boolean.spad#L63
The double lined arrow is used for implies here, for instance, to avoid
clash with function symbol:
https://en.wikipedia.org/wiki/List_of_logic_symbols
Martin
On 28/10/2023 23:00, Waldek Hebisch wrote:
On Sat, Oct 28, 2023 at 10:47:54PM +0200, Ralf Hemmecke wrote:
On 10/28/23 03:33, Waldek Hebisch wrote:
I think that in OutputForm "->" should be a binary operator.
Agreed.
And the meaning should be "mapping between types/sets", not mapping of
values.
Yes.
Change to i-output.boot looks easy. Also, it is easy to modify
'tex.spad' to handle this. There is question what various formats
should output for "TAG" and "->".
First of all, I think TAG is a rather strange name. I think, we can
agree that TAG stands for "mapping of values", i.e. what is usually
denoted via \mapsto in LaTeX. Can we?
Well, is the following "mapping of values"?
(1) -> iO := IDPO(Integer, Symbol)
(1) IndexedDirectProductObject(Integer,Symbol)
Type: Type
(2) -> monomial(1, x)$iO
(2) [x -> 1]
Type: IndexedDirectProductObject(Integer,Symbol)
(3) -> monomial(1, x)$iO + monomial(2, y)$iO
(3) [y -> 2, x -> 1]
Type: IndexedDirectProductObject(Integer,Symbol)
Currently in my test version 'tex.spad' outputs '\rightarrow' and '\to'
respectively, which seem to be reasonable.
This is where I do not agree. Why is this reasonable, when TAG actually
denotes the mapping of values? When I denote a function, then I write
\begin{gather}
f : Z \to Z,\qquad x \mapsto x^2
\end{gather}
See above: we give map for each value separately, not a formula
for a function. Also "reasonable" does not mean very good,
but '\rightarrow' is different symbol than both '\to' and '\mapsto'.
There is trouble that '\rightarrow' looks identical to '\to',
I thought that they look different. So '\rightarrow' probably
should be replaced by differently looking arrow.
Using '\rightarrow' (or rather some different arrow) is reasonable in
sense of preserving distinction. You somewhat argue that TAG and
'+->' are the same thing, and I think that they are not the same.
The current usage of rarrow in MoebiusTransform(F) is clearly in the
meaning of denoting the mapping of values.
I.e. moebius: F^4 -> (F -> F),
(a,b,c,d) +-> (x +-> (a*x+b)/(c*x+d))
For moebius "+->" could be reasonable, but I have some doubts
about "clearly": arguably we give value of mapping at single
(generic) point.
If FriCAS would print it like this, it would agree with the usual
mathematical notation..
fmtlatex.spad outputs '\to' for "TAG", which to me looks wrong, as
'\to' seem to be used for domain/codomain of mapping, that is types
and not for values.
Right, \to for TAG is wrong.
But put the attached files into your fricas checkout (with your patches) and
run "bash outputtest.sh". You will get the attached outputtest.pdf.
Look at the second output for moebius. The OutputForm contains TAG and not
only fmtlatex translates this to \to, but all other formatters produce the
equivalent of "->" or \rightarrow (in TexFormat). So it is not a problem of
fmtlatex alone.
That is why I am wishing for a new function (besides rarrow) in OutputForm.
It would be a little confusing to use rarrow for \mapsto, since rarrow seems
to suggest \rightarrow, but was probably meant (just my guess) to denote the
mapping of values.
I want to change the output for moebius to +->, because it actually denotes
the value mapping. Currently, it defeats the intention of Format1D, namely
that one can cut&paste the output in Format1D form as input into FriCAS.
Yes, Format1D is not perfect, but close.
The OutputForm operators TAG and +->, as well as rarrow are not used in many
places, so I think we can make incompatible changes.
My suggestion for OutputForm:
Introduce functions
mapsto(a, b)== convert [eform("+->"::Symbol, a, b]
rarrow(a, b)== convert [eform( "->"::Symbol, a, b]
How the internal OutputForm operators are called, I actually do not care
much about, the could also be 'MAPSTO and 'RARROW.
What I care about is a distinction between the type mapping and the value
mapping, i.e., I want to see Integer -> Integer and x+->x^2.
What's your wish?
I would like to have 3 different OutputForm-s. AFAICS currently
two of them, that is "->" and "+->" are produced only by
interpreter code. The third one is used by algebra.
If we use of TeX arrows for third form, than 'rarrow' is reasonable
name.
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To un
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 'i-output.boot' uses this function. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/09844512-9153-4429-8a84-f0b231ac2b95%40martinb.com.
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 3 is the same as 1 + 2? I can surely > program NonNegativeInteger in such a way that 1+2 gives 6 (or perhaps > 0). Would you then also claim that the type of a and b are the same? Yes, that is the reason that Idris has a proof system built into the language, it is completely separate from language constructs like: if 1+2=3 then ... where the user can define equality in different ways. Instead it uses Martin-Löf equality types which only has one constructor: Refl. 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/116f4a2d-e8b3-200a-c761-ad485b4d2def%40martinb.com.
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 is that more errors are found at compile time rather that runtime. When we combine this with dependent types it means that we can detect, for example, attempts to add vectors of different lengths at compile time rather than runtime. So why doesn't Axiom/FriCAS use dependent types for vectors and matrices? Surely, if we want to make our code as reliable as possible, we want to take every opportunity to catch errors at compile time? If carrying around the length at the type level is a problem for Axiom/FriCAS when using vectors then surely the situation will be even worse for more complicated dependent types. One issue is that, in the general case, we cant determine if two values are equal at compile time but in many (most?) cases we can. If Axiom/FriCAS can't determine that the two lengths are equal then it can fall back to checking at runtime. I assume this issue would be the same for any use of dependent types so I guess this is not a special issue for vectors. I think there are genuine reasons why the original designers chose not to do this and I would like to investigate this here. I think the reason comes down to limitations in the type system in Scratchpad/Axiom/FriCAS and that languages like Idris are only now coming up with type systems that make this sort of thing practical. (I am not criticising here, quite the opposite, its amazing that after so many decades only now have the type systems in a few other programs caught up in some respects) So to help me think through the issues I will try to work out how this might be done. So we could define a type VectorFL (for vector fixed length) like this: VectorFL(R : Ring, Len : NNI) : Exports == Implementation where So now we can define an addition function: + : (%, %) -> % So we want this to type match if the lengths are all the same. Imagine we have instances of the following types, which ones can we add? a: (VectorFL Double 3) b: (VectorFL Double (1 + 2)) c: (VectorFL Double x) d: (VectorFL Double (0 + x)) e: (VectorFL Double (x + 0)) f: (VectorFL Double (x + y)) (Where x & y are variables that can't be assigned a value at compile time.) a + b should compile because numeric values can be normalised to a single number which is equal in this case (in Idris they are definitionaly equal). c + d would compile in Idris because they normalise to the same thing (again they are definitionaly equal) I don't know about FriCAS. c + e would not compile automatically in Idris but they can be made to compile by manually providing a proof that x = x + 0 (in Idris they are propositionaly equal). (note the importance of having a proof system built into the language - I like Tim's aim of making things provable but I think this is a strong argument that this needs to be built into the language and not a separate language) e + f we may not be able to determine this at compile time if y depends on some complex recursion. Perhaps the program could drop back to checking at runtime however in Idris if the above version won't compile then an alternative form needs to be provided like this: + : (%, %) -> Maybe % I think this is a much better way of doing it only for the case where equality of lengths cant be proven. So far we have just considered + which is relatively simple because all we have to do is check that all types are the same. However when we are working with different length vectors in the same signature we move up to a higher complexity. For example consider concat: concat : ((VectorFL Double x), (VectorFL Double y)) -> (VectorFL Double (x + y)) Here we can't use % because each vector has a different length. We need to check that the length of the result is the sum of the lengths of the two operands. This sort of thing may not be needed much for vectors but when we go to matrices it is more important. For example when we are multiplying two matrices the operands can have different dimensions provided the number of rows in one is the same as the number of columns in the other. The Idris language can handle all these sort of things very simply without any extra syntax. So my conclusion from this (unless you tell me otherwise) is that Axiom/FriCAS needs a more powerful type system (like Idris) to be able to do this sort of thing simply. 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/f816ae04-a52a-d45d
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: http://www.euclideanspace.com/prog/scratchpad/mycode/system/output/monospace/index.htm As the time I thought there was a need to improve these things as described here: http://www.euclideanspace.com/prog/scratchpad/mycode/system/output/index.htm At the time everyone on this group was against it, or not interested, so it didn't go anywhere. Martin On 29/03/2020 13:05, Ralf Hemmecke wrote: Hi everyone, the following text is part of a private discussion following my offer of TexFormat (and other formatters to come). On 3/27/20 4:55 PM, Waldek Hebisch wrote: Well, I would like to avoid having a lot of output streams and similar but not identical formatters. If one really needs several output streams then having domain like OutputStream with could be paired with appropriate formatter looks better. Unfortunately, we don't have a 2D formatter written in SPAD. If someone is able to translate the features of i-output.boot for the algebra output that would be great. Any volunteers? Anyway, the current situation is that OutputForm is, in fact, an intermediate (not perfect) structure that encodes enough information of the respective expression to make it look nice in several different formats. We have formatters for TeX, HTML, MathML, TeXmacs written in SPAD, but their main functions are coerce: OutputForm -> % display: % -> Void display: (%, Integer) -> Void But that means that the formatter operates with side effects, i.e., writes the (formatted) expression to a certain stream. In the sense of what Waldek writes above, I'd propose a change. A formatter should not know about an (output) stream but rather provide functions coerce: OutputForm -> % format: % -> List String format: (%, Integer) -> List String where with the meaning that format(x, linelength) outputs a list of strings that are meant to be put onto a stream with newlines between them. Of course, also a package that provides the functionality format: (OutputForm, Integer) -> List String can be an option or something like format: (String -> Void) -> (OutputForm, Integer) -> Void where the first argument is a function that takes a string and writes it with a newline to an output channel. Waldek, do you have something like this in mind or to you have more precise ideas of how we make FriCAS more independent of Lisp streams? Ralf PS: I am somewhat more in favour of letting a formatter be a function OutputForm -> List String because it is more flexible to let the context decided whether the last string in the list should be written with or without a newline. On the other hand first producing list of strings might waste a lot of internal memory for big output. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/b8e8c202-c57e-5e18-0561-4eebac7cef01%40martinb.com.
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 about time HyperDoc was got rid of. I think its clunky, old fashioned and off-putting for users and hard to write for developers. 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] Group presentation
Waldek,
As I said before, I'm not suggesting that the reference documentation
tries to teach the mathematics but I do think it should allow potential
users to match the mathematics to the code. I think my ideal would be to
allow both short and long explanations in the '++' comments.
Try to look at this from the point of view of a potential new user:
convert : (List(S), List(FreeGroup(S))) -> GroupPresentation
++ convert(lg, lr) builds group presentation from list
++ of generators \spad{lg} and list of relations \spad{lr}.
Is it really as obvious as you suggest what this does?
If I was a potential new user and I was scanning through lots of files
and lots of functions and I had a quick scan of the above my first guess
would be that it might be adding a list of relations to a free group.
Especially as a new user they might not know how the domains are defined
(is an instance an element of the group or the whole group). So the user
has to do all this work when they don't even know if this is a function
they are looking for.
I think the explanation of this code that you gave earlier in this
thread is excellent but you seem determined to hide it away 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 free group was the
generators and not the relations). Its obviously not that when you look
at the code but should a new user have to trace though the code for
every function they are considering using?
If you go to obvious place, that is Wikipedia, at:
https://en.wikipedia.org/wiki/Presentation_of_a_group
the fifth statement (so just at the start) says:
: Formally, the group G is said to have the above presentation if it
: is isomorphic to the quotient of a free group on S by the normal
: subgroup generated by the relations R.
We do not have resources to match Wikipedia math articles, so
we should direct our efforts to documenting things specific to
FriCAS or maybe computer algebra for which there is no adequate
documentation elsewere.
I think this information needs to be part of the reference documentation
(Its explaining what the code does not the maths) and I think it needs
to be somewhere where it can be automatically picked up by Ralfs
program: https://fricas.github.io/api/index.html and other programs like
this.
Is it too much to reqest that users do a Google search and go to
relevant pages? For most topics that will lead to Wikipedia.
In other words, for all parts of FriCAS you should consder
implicit link to Wikipedia.
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
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 mathematical > texts. Second, beginning users need tutorials and tutorials > are written in quite different way than reference documentation. True, but I think the reference documentation needs to be more than the '++' comments and the function signature. In thinking about these things I try to put myself in the position of someone who may be unfamiliar with everything in the code library. They are looking for existing functions that may help them, there is a lot of library code to scan through. 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 free group was the generators and not the relations). Its obviously not that when you look at the code but should a new user have to trace though the code for every function they are considering using? I think this information needs to be part of the reference documentation (Its explaining what the code does not the maths) and I think it needs to be somewhere where it can be automatically picked up by Ralfs program: https://fricas.github.io/api/index.html and other programs like this. 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 presentation. Yes, I think this is a good idea. What I like about Axiom/FriCAS is the way that the domains/categories are richly interconnected so, for me, the more interconnections the better. My issue is with documentation. Its not entirely clear to me why it is useful to characterise each relation as a free group rather than a word (I can see they are both a sequence of products) I just think it needs more explanation about the motivation. Do you think this would be obvious to all potential users? If not, can I persuade you to add a bit more explanation with the commit? 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] html.spad
On 29/03/18 14:12, oldk1331 wrote: On Wed, Mar 28, 2018 at 5:43 PM, Martin Baker 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. Martin There's actually a little difference between "return void()$Void" and lack thereof. --- )abbrev package TEST Test Test() : Exp == Imp where Exp == with f1 : Integer -> Void f2 : Integer -> Void Imp == add f1 x == x f2 x == void()$Void --- (1) -> f1(3) Type: Void (2) -> f1(3) pretend SEX (2) 3 Type: SExpression (3) -> f2(3) Type: Void (4) -> f2(3) pretend SEX (4) "()" Type: SExpression 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. Yes I know void()$Void is needed but is 'return'? 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 [value c1 for c1 in c] sayHt s if value(t) ~= "" then sayHt concat[""] return void()$Void It seems to me that the point of => is to return from a block but it will never return from the block because it reaches the return first. So although the code works fine it is potentially confusing for people reading the code. You are just using => as an if-then so I would prefer that the code used if-then explicitly like this: if every?(leaf?, c) then s : String := concat [value c1 for c1 in c] sayHt s if value(t) ~= "" then sayHt concat[""] return void()$Void either that or allow the code to exit from the block like this: every?(leaf?, c) => s : String := concat [value c1 for c1 in c] sayHt s if value(t) ~= "" then sayHt concat[""] void()$Void but not both. It does not really matter but I would rather optimise for understandability rather than minimising code or insignificant speed changes. 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 line. (although whitespace is not relevant for html it make it easier to work with). 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. Martin On 28/03/18 03:16, oldk1331 wrote: Sorry about that. Can you review a small cleanup in html.spad? --- a/src/algebra/html.spad +++ b/src/algebra/html.spad @@ -380,12 +380,8 @@ if enableGrid then if tagName = "table" then enableGrid := false if tagName = "tr" then enableGrid := false - b : List Boolean := [leaf?(c1) for c1 in c] -- if all children are strings then no need to wrap in table - allString : Boolean := true - for c1 in c repeat if not leaf?(c1) then allString := false - if allString then -s:String := "" -for c1 in c repeat s := concat(s, value(c1)) + every?(leaf?, c) => +s : String := concat [value c1 for c1 in c] sayHt s if value(t) ~= "" then sayHt concat[""] -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 version would be equations of functions? So this: F > || GG || VV F > would be: FG = GF -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 transforms (objects and morphisms of) a functor of S to another functor of S. See chapter 17 of Category Theory for Programmers. Excuse me if I indulge in 'blue sky thinking' as opposed to the tiny incremental changes that might actually be possible in FriCAS. So (in the Bartosz Milewski document you referenced p164) a function like this which has parametric polymorphism: alpha :: F a -> G a This would tend to be a natural transformation if it is true for all 'a' where 'a' is a type. Also types like 'List' and 'Maybe' tend to have natural transformations because they are defined over all types. But this all seems a bit imprecise and handwavy, what I would like is a way to specify the axioms (like the naturality condition) in FriCAS. It seems impossible, in FriCAS, even to specify the type signatures as powerfully as in Haskell to go beyond that and specify axioms seems even more impossible. If we could do that sort of thing in FriCAS, not only would it be very powerful but it would help me(us?) to talk about these things more rigorously. If FriCAS does not have any realistic prospect of doing this sort of thing, does anyone know of any projects that do? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] Maybe preview
On 07/10/17 10:30, oldk1331 wrote: Your project is very interesting. But how do you generate static type language from a dynamic type language? I mapped functions in boot to functions in SPAD. For convenience I just put them in packages one for each boot file. Variables in boot can map to variables which are instances of SExpression. This instance of SExpression can have have common lisp functions like '+' defined. At runtime this function would add if its a number and fail if its not. So its checking the type dynamically at runtime - just like boot/lisp. My thoughts on this matter: 1. clean up src/interp. Eliminate special/dynamic variables. Make the functions more modular As I said before, I think it would be hard to change one function at a time because all these functions are linked by lots of global variables. I suspect it would only be possible to untangle all that mess if you have a very deep understanding of the interpreter and of boot. Since I would like to remove boot code I would rather not spend a lot of time learning about it. One thing that I can easily do, since I have an AST, is generate tables showing which functions use which variables and another showing which variables are used in which functions. But I think it would take more knowledge than I have to untangle them. I might even be able to infer which variables only get assigned to one type (int,float,string..) so that they could be assigned those types in SPAD. However many boot variables could be polymorphic or complicated list structures. and add necessary documentation. Good luck getting Waldek to agree to that! Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] Maybe preview
On 07/10/17 00:59, oldk1331 wrote: > Monad is practical in FriCAS. But just like this time, we couldn't agree > on a lot of things. So instead of introducing Monad first, Maybe later; > I think introducing Maybe first, then add Monad later will be easier. But if you cant agree the form of monad how can you be sure that any maybe code you introduce will be compatible with it? It seems to me that, to avoid reworking the library code multiple times, it would be better to have an overall plan first? If you can't agree that perhaps it would be better to leave the library code as it is? > There's another set of natural transformations for Monad: > > return : X -> Maybe X >>> = : (Maybe X, X -> Maybe X) -> Maybe X Yes, I get the impression that there are two forms of monad: 1) The mathematical form. 2) The form used in Haskell to chain impure code. I seem to remember that Haskell supports both, but the second version is the main form, used in the prelude. Perhaps FriCAS should also support both forms but since FriCAS is all about mathematics then it should differ in this respect and the mathematical form should be the main form. >> For me the most important thing is to optimise for simple and readable code >> rather than optimising for performance. Perhaps if Fricas were simplified it >> would be easier to move to a better type system. In fact I have issues with >> all this diminishing returns performance optimisation. If things could be >> made simpler perhaps Fricas could be built on top of other languages than >> Lisp. I thought Krystian s project might move things in that direction? > > Waldek has this plan that the compiler should be written in Spad, > so targeting other languages is a matter of new code generator and runtime. > That is a far far goal though. Is it? I did some experiments to compile the interpreter boot code (src/interp/*.boot) using a more conventional compiler: https://github.com/martinbaker/fricas2aldor I guess Waldek would just modify the existing compilers? but I find them far too messy to work with. I managed to compile this boot code to an Abstract Syntax Tree (AST) I then wrote a code generator to write AST back to boot code. This code was different from the original (because the AST does not store format information) but when I compiled to Lisp the code generated was identical - all lines (except those starting with ';') were identical. So I am sure my AST contains all the information from the boot files. Its then not difficult to generate SPAD or Aldor or any other language from this AST. But the problems are: 1) how to handle global variables, especially dynamic variables. I think each function would have to have an additional parameter to pass around the runtime values of these dynamic variables. 2) The boot 'where' keword seems to hold inner fuctions and variables. How should inner functions be converted to SPAD? SPAD has lambdas but can SPAD lambda capture variables (closures)? 3) The native Lisp code would have to be translated by hand, to handle input/output to console, files and database (which would be different for each language). Perhaps another option would be to just translate boot to SPAD manually but that's hard because Boot/Lisp passes everything around in global variables whereas well written SPAD should encapsulate information in domains. This means you cant just translate one function at a time and check if it works before going on to the next. > Yes. Common Lisp can do parallel computing but it's not standardized. > I think provide a parallel version "map" solves 50% problems. I get the impression that Waldek will not make any changes to library code that is not supported by all Lisps? Is that correct? I get the impression there is a lot of natural parallelism in mathematical code, for instance: vectors, would 'map' make use of all of that? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 practical in Fricas? However I still have hopes that, in the future, the type system in Fricas may be enhanced to allow monads (am I wrong to hold out hopes for this?). If this might be possible in the future then I think maybe should be implemented in such a way that it could be made an instance of monad to avoid re-working the library code a second time. Also the terminology is well known from Haskell (where maybe is an instance of monad) so its best not to diverge from that unless necessary for a genuine mathematical reason. I believe that monads are an (endo) functor with two natural transformations: M M X -> M X X -> M X In the maybe instance: Maybe Maybe X -> Maybe X X -> Maybe X So I think Maybe Maybe X is a fundamental mathematical requirement. This seems to be about how Maybes are chained which is the practical purpose. So when chaining this things you could write: Some partial function if "failed" then handle error next partial function if "failed" then handle error next partial function if "failed" then handle error ... This seems very messy with lots of repetitive code. What I would like to do is this: Some partial function next partial function next partial function if "failed" then handle error I'm not sure about the practicalities but perhaps to chain something like subtractIfCan would require a signature like: (Maybe X,Maybe X) -> Maybe X rather than: (X,X) -> Maybe X but I have not really thought this through. Does anyone know how Maybe is used in Haskell? For me the most important thing is to optimise for simple and readable code rather than optimising for performance. Perhaps if Fricas were simplified it would be easier to move to a better type system. In fact I have issues with all this diminishing returns performance optimisation. If things could be made simpler perhaps Fricas could be built on top of other languages than Lisp. I thought Krystian s project might move things in that direction? The way computer hardware is evolving with more core it seems to me that, if you really want to optimise for speed, then multithreaded code is the real future. So we need to move away from Lisp rather than optimise around what Lisp happens to do fast now. Martin B. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 denotational semantics, we may want them to mean different things at the same time: T / \ / \ true false \ / \ / _|_ I think it is in ILogic (intuitionistic logic) that the clash is strongest because, in the above diagram 'T' represents a contradiction, in ILogic 'false' often represents a contradiction. So would it make more sense to connect the two notations which represent contradiction like this: T == false ___|__ == true If this is the wrong way round then I realise this is my fault as that is what I did originally. Its just that I like to draw 'true' at the top because it makes /\ and \/ (meet and join) look right in diagrams: A B \ / \ / (A \/ B) But perhaps its more important that the notation for contradiction should coincide? 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 traditions. Are you suggesting that we should use true/false instead of T/_|_? Or implement T/_|_ by true/false in Boolean? 1) In general true and false are different from lattice top and bottom, so it seems that we need separate functions 2) For now moving true and false to Logic and implementing T/_|_ by true/false is probably good enough. There are potential problems due to Spad compiler and interpreter, so I am not sure if this will work. 3) I affraid that deciding what to do with T/_|_ and exact details of lattices need more time to decide. I've been thinking about this. One subject where T/_|_ and true/false are different is denotational semantics. In denotational semantics textbooks Boolean algebra is shown like this: T / \ / \ true false \ / \ / _|_ where lines in this lattice mean: 'top end is more defined than bottom end' So _|_ is less defined than true and false so it is like a variable which can range over all values. 'T' is more defined than true and false, but true/false are fully defined, therefore this is taken to be a contradiction. Therefore 'T' is usually left out of the diagram, so we usually work with a join semilattice with bottom element. I think this meaning of _|_ is also how it is used in 'Topology Via Logic' Vickers 1989. This interests me because I want to link this back to topology. Of course lattices are used more widely in mathematics so perhaps the notation that we use should depend on whether we are working in terms of logic or lattices, like this: logic(semi)lattice -- true _|_ falseT and /\ or \/ But this distinction does not seem to work either because its often both. So I don't really have a conclusion yet. 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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_ commit. FriCAS tests should be run _before_ each commit. So much of testing would be redundant. After commit tests can catch things like forgetting to commit a file, but that should be rare, show up quickly and be easy to diagnose. In principle we could gaim testing on more platforms, but I do not know how well this would work in practice. Concerning including travis CI script: we have a few scripts that are supposed to be useful for all developers in 'src/scripts'. We have some other helper stuff in 'contrib'. Then there are various helper scripts that each developer creates when needed. ATM travis CI script seem to be in last category: personal tools. I think it would be a good thing if this script were in FriCAS and all its cloned repositories. Then if someone modifies their repository and submits it as a patch at least you can see immediately that it passes some minimal level of tests. You may do other tests but at least this might cut your workload by weeding out dud patches without even having to look at them. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 possible to detect. I notice on the stuff that Krystian is doing that SPAD code appears to be built and tested from within Github using something called Travis-ci. I don't know much about this but, at first glance, it looks like an interesting way of doing it? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 bit more markup. This could potentially happen for spad, would "just" be a question of being able to generate the appropriate markup and link to it. As I understand it, the api docs on the .io site contain the right html. This may be irrelevant or off topic but, since you mention ++ comments and fricas.github.io, I have some views on the content if not the markup. In my recent attempts to understand permgrps.spad I have thought about what meta information would be useful to someone new to the code, both user or developer. One of the most important things for me, in understanding a function, is information about the parameters and return value of a function. If I am very clear about the inputs and outputs I can often work out the bits in-between. This information can be coded in the /** comments of java so I guess the java language designers agree with me on this issue. Another thing I would really like is links (coded as URLs) to other sources of information about a given domain, function, etc. In FriCAS there are so many potential places where documentation/tutorial/explanation may, or may not be, found. It is a time consuming process just to find out if there is any information known. Even if (as often happens) the only explanation is a post from Waldek then I think there should be a link to it. Another thing I would like coded in ++ comments and picked up by .io is local in addition to exported metadata. I suspect this would be harder to do and get away from the original intention. However I would like to be able to drill down to information about Rep and local functions. Sorry if this is off-topic but if there is any chance of some of this happening then its worth mentioning it. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 this sort of thing in atom? I think it could eventually provide a good modern alternative to emacs mode. I am curious, what are the pros and cons of using a hackable editor to do this rather than an IDE as Peter Broadbery is doing: https://github.com/pbroadbery/aldor-eclipse https://github.com/pbroadbery/aldor-idea-plugin I am guessing that an editor is easier to start with but an IDE would ultimately be more powerful, is this guess correct? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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. Both academic honesty and benefits to potential readers require mentioning Seress book as one of resources. Well the flavor that I got from you original message was that any user/developer to FriCAS needs: 1) Access to a university library where they can get out-of-print books. 2) The ability to look at undocumented SPAD code and immediately relate it to theoretical algorithms. 3) A deep understanding of the mathematics of group theory. If a potential user/developer user meets these requirements then there is no problem, they don't need documentation. If they don't meet these requirement I guess they should use some other code? This is fine if you see FriCAS continuing as a sort of research project but I was sort of hoping that FriCAS would have a future with more actual users/developers. I think that FriCAS (and pan-axiom generally) deserves more users and developers but I don't think it is going to get them with this sort of attitude. I tried to make a start with some documentation, far from perfect as I said myself, it would be nice if others could contribute and make it better, rather than just reject it. IME to get somewhat readable text requires several revisions and wilingness to scap or correct defective parts. I am not looking for a job documenting other peoples code. I don't specially enjoy it, I don't claim to be good at it and here it would just be a thankless task. Nevertheless I tried to make a start in this patch because it seems (to me but not to others) to be badly needed. Since people here don't seem too bothered about this, I guess the best thing to do is forget it. If people were serious about this then it would have to evolve and improve, I'm not willing to do all this myself other people (especially project owner) would need to revise and improve (not via me). > I pointed out two such places. Yes there were lots of negative comments, it just came over as an attempt to rubbish any attempt at documentation. This is not about 'literate coding' it is about having information where it is needed. For instance, if the Vector domain is being used in a context where vector addition and scalar multiplication are not valid, I think that might confuse readers of the code, is it not reasonable to explain this in the code? If I explained this badly then why not improve the wording, instead you imply its all wrong and I don't know what I am talking about. Concerning start: look at our wiki. If you look at the patch: https://github.com/martinbaker/fricasAlgTop/blob/master/permgrps2.patch you will see that most of it is about things that directly relate to the code. If someone is reading the code and they find a Vector being used in an unusual way then they need to have the explanation where they will see it, not hidden away on a wiki. I don't think a wiki is a suitable store for reference information. When I am trying to understand code like this, with lots of local/exported functions all calling each other is difficult to know where to start to make sense of it all. What I find is that the most important things do explain are: 1) The coding of Rep, exactly what it holds, what are valid values and so on. 2) For each function (exported or local), the coding of the parameters and the output of the function. For instance, not just that a parameter has type List NNI but that NNI is an index into other values, that duplicate NNI values are not allowed in the list, what are the maximum values and so on. If I have a clear idea what the purpose of a function is and what its input and output values are that I can usually work out the bit in between. Otherwise it just makes things very difficult for someone struggling to understand it. This is the sort of information that I tried to put in the patch. I hope this does not come over as a rant. This patch was intended to be helpful as a starting point to provide information that was otherwise missing, I don't want an ideological war but I was quite disappointed by your response. In the past I have also been disappointed by the response to Ralfs https://fricas.github.io/ project because I think that if a project like that were encouraged then it could become a central hub where users/developers go to find the sort of information in this patch. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this
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 should be relatively easy -- code basicaly is doing what algorithm prescribes. There are few implementation choices, concerning how to efficiently implement some steps. Seress discusses possible alternatives. I have no access to Sims article, but my Univerity have Seress book. So there is good documentation for the permgrps, just it is not freely available. 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 think that FriCAS (and pan-axiom generally) deserves more users and developers but I don't think it is going to get them with this sort of attitude. I tried to make a start with some documentation, far from perfect as I said myself, it would be nice if others could contribute and make it better, rather than just reject it. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 +valid if the type system were fully checked but presumably gets away +with it because vectors are defined over Type. Vector(NNI) stores nonnegative integers and provides 1 based indexing. We do not need most operations provided by Vector, in particular we do not need vector addition or multiplication by scalars but that is OK: we use what Vector provides and nothing more. In other words, we could probably just use arrays here (but IIRC there was some useful function that only accepted vectors and did not work on arrays). And using arrays or vectors to store permutations is a standard trick allowing resonably fast operations on permutations. So what have I said that is wrong here? I know that some languages, like java, have vector types which are really a type of array. However I suspect that someone trying to understand an algebra program might expect that when they find a instance of a Vector domain then it would represent an element of a vector space. That is it has valid vector addition and scalar multiplication, they might even think that the type system would enforce that. Put yourself in the mind of a potential user or contributor to permgrps.spad. You come across a structure (Vector) being used in an unusual way would it not help you to see some explanation that might warn you of that? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 here.
Is there a better word than 'literate' that I can use for this type of
documentation since the word 'literate' has lots of baggage that I don't
want to rake up here.
Martin B
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
[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 literate methodology, that is, I have not tried to make a linear story. This is purely intended as reference information which would otherwise go in comments. This just saves lots of lines starting with '--'. I don't know how you feel about a third party (me) writing comments for other peoples code? Although people here are very good at replying to requests for information on this forum there does not seem to be much enthusiasm for adding to documentation in a more permanent and easily found way? I don't feel qualified to try to speak for the original authors but I don't think they provided enough information to be able to use or develop the software without spending a lot of time tracing through the code to discover its secrets. I think it is very wasteful for every potential user to have to do this. I was therefore motivated to write these notes. Such information (or better if you can improve it) needs to be in a place where users and developers can find it. I did find some other sources for information about the Schreier-Sims algorithm such as this: https://en.wikipedia.org/wiki/Schreier%E2%80%93Sims_algorithm Waldek Hebisch referred to these notes by A. Hulpke which contain a sketch of the algorithm. http://www.math.colostate.edu/~hulpke/CGT/cgtnotes.pdf Waldeks description on FriCAS forum here: https://groups.google.com/forum/?hl=en#!topic/fricas-devel/EtLwgd2dWNU I find it improves the documentation to use diagrams, I have therefore put much better documentation on the web page here: http://www.euclideanspace.com/prog/scratchpad/mycode/discrete/finiteGroup/ I think it is worth studying permgrps.spad even if someone is not interested in developing group related code, this still looks to me like a good case study in how to design code to scale up to very large structures. So perhaps it is worth documenting for that reason alone. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 of the the signature conditions. https://github.com/hemmecke/fricas/blob/master-hemmecke/src/doc/api.spad#L160 I haven't implemented a general graph with /\ and \/, but rather my elements are always in "normal form", saying that I don't have an expression tree, but the elements are always stored as DNF's. There is a top and bottom element, called 'true' and 'false', but my DisjunctiveNormalForm does not work over Boolean, but over a general set S. You can let S be Integer, (or Symbol) and you would have disjunctive normal forms with variables. Look a bit further down, I use DisjunctiveNormalForm(SExpression). https://github.com/hemmecke/fricas/blob/master-hemmecke/src/doc/api.spad#L377 Shouldn't ILogic() be similar to DisjunctiveNormalForm(S). In ILogic you have no such parameter S, but rather restrict to Symbol. To me it looks a bit like you are just creating an SExpression where only IMPLY, AND, OR, NOT, OTHER can appear as opType (and I cannot even create "OTHER". What do you think is the advantage to DisjunctiveNormalForm(Symbol) (except that DisjunctiveNormalForm is currently only in my private branch)? I guess this relates to another recent thread about how FriCAS domains are usually represented in a simplified form? I appreciate that principle but I'm not sure about the consequences in this case. So in the same way that a polynomial might be stored as a sum of products (I realise its more complicated than that in FriCAS) a lattice might be stored as a join of meets. Different logics would need different rules, for instance 'Law of excluded middle' does not apply to ILogic, and so any use of 'not' has to be treated with care. A Boolean algebra is a full lattice but this does not apply to Heyting algebras which may have say bottom but no top like BoundedJoinSemilattice So I'm not sure these types of logics could be stored in a simplified form like this? The impotent thing for me is that I would like these structures to link to the stuff I'm doing in algebraic topology, using ideas in: "Topology Via Logic" Vickers 1989. Im not sure if/how this could be done but I would like to avoid making changes at this stage until I've a better idea about how this could be done. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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? I suspect at some stage _|_() got changed to logicF() in ILogic but not in BoundedJoinSemilattice? The category hierarchy is quite complicated, I drew some diagrams here: http://www.euclideanspace.com/prog/scratchpad/mycode/discrete/logic/ Or Waldek drew it in 'ASCII art' part way down this thread: https://groups.google.com/forum/?hl=en#!topic/fricas-devel/Cy-RHn_g6RY So _|_ has never been used in input in Spad. And as Ralf said, '_' is escape char in Spad, so using _|_ as input will be very awkward. As your argument that "'top' and 'bottom' could be variable/proposition", well, true/false doesn't clutter boolean operations. Yes, but Boolean can only return true or false, there is only confusion in logics where variable/proposition names can also be returned. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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("a") /\ logicT()
(1) a
Type : ILogic
(2) -> proposition("a") /\ logicF()
(2) _|_
Type : ILogic
I don't think it would be correct for this to return 'false'.
Exactly. Because 'false' is not an element of ILogic.
Interestingly, even here you export logicF, logicT instead of relying on
the functions/constants T and _|_ whose signatures you get from
BoundetMeetSemilattice and BoundedJoinSemilattisc.
Yes, in a ideal world (and I agree existing code is not ideal) I think
that T and _|_ (or unicode equivalent) should be used for both input and
output. This is because 'top' and 'bottom' could be variable/proposition
names but T and _|_ are less likely to be.
Martin B
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
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 becomes algebraised (when we have symbols
for logical variables) that we need to make a distinction between
top/bottom and true/false.
Sorry, but I don't understand this. What algebra do you mean so that T()
and true are both values of the domain that are not the same? Not that
if they are not equal then true cannot be at the top of the lattice.
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("a") /\ logicT()
(1) a
Type : ILogic
(2) -> proposition("a") /\ logicF()
(2) _|_
Type : ILogic
I don't think it would be correct for this to return 'false'.
On 21/03/17 08:05, oldk1331 wrote:
> I meant how to call these two functions?
>
> Besides, ")dis op T" doesn't return this signature, maybe
> 'T' conflict with lisp symbol 'T'?
>
> Also, _|_ can't be called, maybe FriCAS lexer don't recognize it?
>
> If so, change their name to top/bottom is more appropriate.
OK you are just talking about a lexer issue which I can't answer. As a
general principle though I think it would be good to use _|_ for
input/output wherever possible. Or unicode would be even better.
In the above example I think its much clearer that _|_ is a special
value 'bottom' could just be a variable name.
Martin B
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
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 and _|_ are required as top and bottom of lattice. In Boolean I guess they should give true and false? I think its only when logic becomes algebraised (when we have symbols for logical variables) that we need to make a distinction between top/bottom and true/false. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 not a big issue for me, I can go along with whatever you prefer, I just find it easier to work out what a function does if it all fits in one screen so I don't have to keep scrolling. Perhaps functions should also be broken up into smaller functions if they are over a certain size? Anyway here are my views on such issues in case it might help to codify things. Martin B FriCAS SPAD Style Guide -- The rules on these things seem to evolve over time but I have not seen them written down in one place. So here is my attempt to do so - along with my views and questions which may be controversial. Regardless of whats decided, it might be helpful to have it written down in one place where it might be seen by potential programmers. Whitespace around punctuation - ':' space before and after. (I prefer not) ',' space after (but not before). (I prefer not) '+' spaces optional for most arithmetic infix operations '-' no space after for unary operations Maximum Line Length --- No firm rule but about 70 characters unless that causes problems? I think this is to make it easier to work with files, for instance merging with kdiff3. Block Indentation - 4 characters (no tabs) Personally I would prefer 2-space indents rather than 4. The combination of the above 3 rules seems to make line wrapping much more common. I prefer code to be compact rather than have lots of whitespace. I find it is much easier to understand a function if it all fits on my screen at once. I would therefore prefer not to have unnecessary whitespace added. Continuation Lines -- I prefer explicit '_' even when not required. This makes it clear to the reader that the line has been wrapped. Function signature -- I prefer explicit types, that is: func(a:Integer) : Integer == rather than: func(a) == This is because it avoids having to jump between function export and definition to get all information about it. I like to have all information all in one place. Empty list -- use []$T rather than empty()$T => -- Which is better: e := (v > 0 => 1; -1) vs. e := if v > 0 then 1 else -1 I find the second much more readable, is it less efficient than the first? Dangling 'else' --- If there is space then the best option is all on one line: if then else Otherwise it should be like this: if then else Or is this a valid option? if then else elt vs. qelt I prefer better error messages over speed. _= vs. "=" -- When to use: _=(a : %, b : %) : Boolean == or should I use: "="(a : %, b : %) : Boolean == reverse vs. reverse! Even if it harms performance I would prefer non-mutable option. Surely it would have to be a very long list for the longer time to be noticeable. Function size - One big function or lots of small (local) functions? -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 command line output if there is any danger that the extra width will trigger line wrapping. Personally I would rather optimise for better looking output for complicated values than better output for small values. Martin B PS I don't like adding spaces in source code for the same reason. For example I would prefer 2-space indents rather than 4. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] Announce: FriCAS 1.3.1 has been released
Waldek,
Thank you for this release, especially your work on Todd-Coxeter algorithm.
I am curious about the following error which compiled without error on
previous releases.
This is not a problem (might even be be an advantage) because it forces
me to write:
print (message "value of a is " << a)
instead of:
print ("value of a is " << a)
There is also a change to runtime, I suspect this may be change in Lisp?
In the last release display of quotes around strings was suppressed in
bash output (even without 'message' function) but not in this release.
As I say, this is not important feel free to ignore, just interested to
know if it was deliberate or due to unpredictability of compiler.
)abbrev domain TESTO TestOut
TestOut() : Exports == Impl where
x< hconcat(x::OutputForm, y::OutputForm)
Exports ==> with
testOut:(a:Integer) -> Integer
Impl ==> add
testOut(a:Integer):Integer ==
"value of a is " << a
a
compiling into NRLIB TESTO
compiling exported testOut : Integer -> Integer
** comp fails at level 3 with expression: **
error in function testOut
(SEQ
(|hconcat| | << | (|::| "value of a is " (|OutputForm|)) | >> |
(|::| |a| (|OutputForm|)))
(|exit| 1 |a|))
** level 3 **
$x:= (:: value of a is (OutputForm))
$m:= $EmptyMode
$f:=
|a| # #) (* #) (+ #) (- #) ...)))
>> Apparent user error:
Cannot coerce value of a is
of mode (String)
to mode (OutputForm)
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
[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 )co gpresentOldVersion That is, files that I find useful but may not be part of FriCAS. Oh. I have not really followed deeply, but I had the impression that gpresent.spad should become part of FriCAS. No? Yes, I find it useful to have a place where I can develop and publish patches and code related to this topic (which may, or may not, make it into the FriCAS library). At the moment this is in step with FriCAS trunk but Waldek is improving it here: http://www.math.uni.wroc.pl/~hebisch/fricas/gpresent.spad As you say, during development of library code, we don't always need a full recompilation of all fricas. All I need is a single flat directory holding all related spad and input files. I think this also applies to anyone who would like to test out the code at an early stage, it seems better if there is a quick and easy way to just download the relevant files without searching for them in a big tree. So I will investigate git rebase and think about symlinks to see if they fit in with this way of working. I will also look at Git Gui to see if this is less likely to cause these errors than command line. 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 solution is to use feature branch and rebase (and then push --force). When you successfully carry out a rebase, you'll know how it works and can't live without it. And you will no longer need a separate repo fricasAlgTop. Hi Qian and Ralf, Thanks I'll look into this. 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 )co gpresentOldVersion That is, files that I find useful but may not be part of FriCAS. So it just seemed simpler to have repo s that reflect my local structure. I have thought that I should do this with branches but I do quite like the idea of having all the directories visible at the same time (so I can use conventional utilities like Dolphin to copy between them). I suspect I would find what you suggest better in the long term but when I have something that works already like live to evolve the changes slowly. Thanks, 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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, I've corrected it now. I don't know what happened there, it was driver error on my part in using git. All I was trying to do was use the latest version from FriCAS. I successfully downloaded it like this: cd fricas git checkout trunk git pull git push origin but it went wrong when I tried to merge it like this: git checkout master git merge trunk If it reports a problem then I run git mergetool but, if I remember correctly, this time I don't think it did (There were no files inserted which happens when mergetool is needed). Anyway somehow it inserted 3 lines from an old version. The reason I have gone into this long explanation is just in case a git expert might see what I'm doing wrong. Note: this all happens in: https://github.com/martinbaker/fricas I then copy the file to: https://github.com/martinbaker/fricasAlgTop to work on code etc. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 permgrps then I see 3 errors. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 taken the liberty of adding extra comments to your code. I hope its not to verbose for you. 2) Tidy up the trace print routines, for example, does not display empty rows. 3) Some minor code additions. Martin B On 01/30/2017 05:18 PM, Waldek Hebisch wrote: I have now commited improved version of Todd-Coxeter. It now handles coincidencies and is much faster than previus version. Scaling is not great, but much better than before: I was able to do enumeration for Mathieu 11 (using second presentation from Canon et all paper) in 211 seconds. Currently coincidencies are handled using union-find and table of equivalents. It seems that we could handle them more directly by careful updating of coset table. But that is potentially error-prone so I am using simpler implementation now. Coset with respect to a subgroup are still to do. AFAICS still quite a lot of work goes into redundant scanning of coset table. We probably could get large speedup by having some kind of agenda with current work, so that after adding a point we could quickly restart work waiting for this point. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 implementations of coset enumeration is of course fun, but is limited to (self)teaching purposes---I'm saying this as someone who uses coset enumeration in research quite a bit. Hi Dima, I'm sure the approach of gluing together mature implementations is very powerful but if I wanted to work that way I think I would work with SAGE. I like the approach of having implementations richly interconnected and written in a common language (SPAD) which is designed for mathematics and is statically typed. I guess its good that both approaches exist and we can choose what is best for each application. I also think it is good to introduce what you may consider toy implementations. I assume most mature implementations must have started small. If we took the above approach to its most extreme then would anything ever be added to FriCAS? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 beneficial. http://staff.itee.uq.edu.au/havas/1973cdhw.pdf Maybe you should alo have a look at sympy: http://docs.sympy.org/dev/modules/combinatorics/fp_groups.html where the article above is also cited. Otherwise I see much progress. Kurt Hi Kurt, Yes, lots more to do but I'm encouraged by progress so far. I had not seen the Cannon et al. paper. This looks very useful especially for thinking about variations in the algorithm and what its ultimate limitations might be. Mostly for Todd-Coxeter Algorithm I looked at this paper by Akos Seress: http://www.ams.org/notices/199706/seress.pdf because it has a worked example. For the other direction (PermutationGroup to GroupPresentation) I did not find a published algorithm for this so I just did a tree search for loops in the Cayley graph. Initially a was just happy to find algorithms that worked in each direction albeit for small groups. However now, of course, I am keen to get these implementations to scale up as much as possible. Before I look at the above paper in more detail I think I need to get the basics right and to absorb the information that Waldek posted about cosets and strong generators and to modify the code to remove 'coincidences'. By the way, I think the posts from Waldek about GroupPresentation are very useful. I think it would be good if all that information could be put together somewhere where it can be found by potential developers in the future. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation
On 01/25/2017 05:23 AM, Waldek Hebisch wrote: I also noticed that Todd-Coxeter (toPermutationIfCan) may produce something strange. Namely, the following (junky) relations: Do you think there is a need for a simplifier for PermutationGroup like this: http://dracos.co.uk/maths/permutations/ Or does representation in terms of strong generators make this unnecessary/difficult? Either way I guess it would be more efficient and scalable if some simplification could also be done inside the Todd-Coxeter algorithm. I know that the Todd-Coxeter code does not yet detect and remove 'coincidences', that is, duplicated points. So this in the next improvement that needs to be made. Thank you for the useful and interesting information about PermutationGroup and the algorithms in this and previous posts. I will work through this and hopefully the code can be improved. Thanks, Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 searched for something with 'vector' in the name so I missed this. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 dimensions. So I think what is needed is a version of Vector which has the number of dimensions built in to the type (as a type parameter) rather than having a variable dimension. This could then implement AbelianGroup. I need this for the cochain code that I previously posted. This allows a (AbelianGroup) value to be associated with a point (or higher simplex). For example we could have real (Float) values associated with each point representing say voltage or height or some other quantity for each point. Perhaps the most obvious quantity we could associate with each point is position, given by a vector relative to some origin and coordinate system. However the type (domain) needs to implement AbelianGroup. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 because Rep is so complicated. For example, how does wordInGenerators work? I sort of expected that the generators would be represented by a single element in the word. So I expected that the following would give [[1],[2]]: dg3 := dihedralGroup(3) (1) <(1 2 3),(1 3)> Type: PermutationGroup(Integer) g := generators(dg3) (2) [(1 2 3),(1 3)] Type: List(Permutation(Integer)) [wordInGenerators(x,dg3) for x in g] (3) [[1,2,2],[2]] Type: List(List(NonNegativeInteger)) I realise this is the same as [[1],[2]] because 2 is self inverse but it would be good if it could do some simplification. wordsForStrongGenerators is different from wordInGenerators in that it does not seem to use indexes. sg := strongGenerators(dg3) (4) [(2 3),(1 3)] Type: List(Permutation(Integer)) w := wordsForStrongGenerators(dg3) (5) [[1,2],[2]] Type: List(List(NonNegativeInteger)) Now that I have your example hopefully I will now be able to understand it better. Thanks, 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 (tested on sbcl with default 1GB limit), coerce(dihedralGroup(7))@GroupPresentation works but takes a lot of time and produces large presentation. Waldek, Thank you for looking at this. I did not find a published algorithm for this so I just worked out a simple algorithm myself, I did not think much about efficiency I was just happy to hit on a method that worked. The main issue is finding the relations. It seems to me that each relation corresponds to a loop in the Cayley graph. So I just wrote an algorithm that found all the relations (loops) by doing a tree search of the Cayley graph. Obviously this finds a lot of redundant rules (loops). Am I correct in thinking that the algorithm that you are proposing is more efficient because it uses a stabilizer chain (sequence of subgroups, each containing the next and each stabilizing one more point). So when we work out the loops in the subgroup we implicitly encode information about the loops in the cosets so we consider less loops? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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: https://github.com/martinbaker/fricasAlgTop/blob/master/alg_top.spad I have modified bugs2016.input to match the code changes here: Patch for this file is here: https://github.com/martinbaker/fricasAlgTop/blob/master/bugs2016.patch Full file is here: https://github.com/martinbaker/fricasAlgTop/blob/master/bugs2016.input These changes address some of your earlier comments about the algebraic topology code. The changes include: * Remove SPAD test code. * Remove existing vetexset domains * Add numpoints parameter to rep of FiniteSimplecticalComplex and display this in output. * Change representation of DeltaComplex to indicate each point and reverse order of map. * Add cochain * Add type parameter to factory domains. * Rename boundary function from delta to boundary. Note: the order of the Maps in DeltaComplex is reversed in constructor, output and Rep so I had to change bugs2016.input to match this. In accordance with your preference I have not yet changed the documentation (well I have changed some -- and ++ comments, I don't know if they count as documentation?) With this code we can now convert from FiniteSimplicialComplex to DeltaComplex and back and the points are correctly translated regardless of whether they are included in higher order facets or not. Or even if the points are not used at all, like this: (5) -> ASIMP := FiniteSimplicialComplex(Integer) (5) FiniteSimplicialComplex(Integer) Type: Type (6) -> v1:List(List(NNI)) := [[1::NNI,2::NNI],[4::NNI]] (6) [[1,2],[4]] Type: List(List(NonNegativeInteger)) (7) -> sc1 := deltaComplex(simplicialComplex([],4,v1)$ASIMP) (7) 1D:[[1,- 2]] 0D:[[0],[0],[],[0]] Type: DeltaComplex(Integer) (8) -> d1 := simplicialComplexIfCan(sc1) (8) points 1..4 (4) (1,2) Type: Union(FiniteSimplicialComplex(Integer),...) The new cochain code allows us to assign AbelianGroup values to vertices and then calculate differences like this: (1) -> FACTORY := SimplicialComplexFactory(Integer) (1) SimplicialComplexFactory(Integer) Type: Type (2) -> b1 := sphereSolid(2)$FACTORY (2) points 1..3 (1,2,3) Type: FiniteSimplicialComplex(Integer) (3) -> d1 := deltaComplex(b1) (3) 2D:[[1,- 2,3]] 1D:[[1,- 2],[1,- 3],[2,- 3]] 0D:[[0],[0],[0]] Type: DeltaComplex(Integer) (4) -> c1 := chain(d1) + 110 + + 1 + | | | | (4) [0 0 0],|- 1 01 |,|- 1|,[] | | | | + 0 - 1 - 1+ + 1 + Type: ChainComplex (5) -> cc1 := coChain(d1) +1 - 1 0 + +0+ | | | | (5) [],[1 - 1 1],|1 0 - 1|,|0| | | | | +0 1 - 1+ +0+ Type: CoChainComplex(Integer) (6) -> cb1 := coboundary(cc1,2::NNI,_ [3::Integer,4::Integer,5::Integer]) (6) [1,2,1] Type: List(Integer) (7) -> cb2 := coboundary(cc1,3::NNI,cb1) (7) [0] Type: List(Integer) Thanks, Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 converts from PermutationGroup to GroupPresentation. The second one is here: https://groups.google.com/forum/?hl=en#!topic/fricas-devel/j0ZJUXqOT3I This goes in the opposite from GroupPresentation to PermutationGroup (Todd-Coxeter algorithm). I am also working on a 3rd patch to algebraic topology which is intended to resolve the issues involving VertexSet discussed here: https://groups.google.com/forum/?hl=en#!topic/fricas-devel/rqxQZbw3ar4 This 3rd patch also has lots of other improvements so I hope this can be included in the next release. I believe I can have it ready in a week or 2 which seems to be within your timescale. 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 receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 little remark note that in both cases we natuarally get semigroup first, in case of permutations semigroup of all mappings from a set to itself, in case of free group we get free semigroup. Then we "correct" deficiency, in case of permutations taking subsemigroup of invertible maps, in case of free group taking quotient (declaring some generators of free semigroup as inverses of group generators). Now, one natural thing would be a way to produce group given group presentation. There is very strong obstacle to this due to unsolvability of word problem. IMO the right way to go forward it to look at cases when word problem is solvable. This happens if we know something special about groups, for example for abelian groups word problem is solvable. This happens if presentation has special form, like for result of Knuth-Bendix completition. We could try postpone solving hard problems and require that to create finitely presented group the user has to provide solver for word problem Concerning structure on Type: currently this is done by declaring specific categories/domains. Union represets /implements sum. There is Product domain. There is Subdomian. Each are very special I do not see how to "generalize" them at computational level. In principle we could try to add "quotient" constructor. Namely, to get quotient we need equvalence relation and we could have something like: Quitient(S : Type, = : (S, S) -> Boolean) : but that would be of limited use, because for products there are important features which are preserved, while for quotients everything depends on equivalence relation. Existing algebra cheats in some cases, uncoditionaly declaring features which are valid only if special conditions are satisfied. For quotient I do not think cheats are appropriate -- we can not even claim that features are preserved "in most interesting cases". And I would like to get rid of cheating. Orbits need extra structure for example semigroup structure. Orbits of group actions have specific properties, so they probably should be studied separately from more general notions of orbits. And efficient computations with orbits are possible only in some specific situations. So no, I think that currently it is not possible to put more _useful_ general structure on Type. Waldek, Thank you very much for this reply, it is very clear. So we need to keep the groupPresentation domain because we can't add the functionality to FinitelyPresentedGroup domain. Its therefore worth me taking time to improve the documentation and content of groupPresentation domain. To widen the scope a bit, is it worth filling in the gaps in this table of domains in the FriCAS library? outer algebra: PermutationGroup GroupPresentation GroupRepresentation inner algebra: Permutation Word SquareMatrix It seems to me that there is merit in having a common design pattern for this sort of thing since it might help users and developers find the functionality they need, minimise overlaps and make it easier to convert between them. In fact why not have a design pattern (as a hint to developers) which goes beyond groups to any algebra where we need functions on both elements and functions on the whole '(sub)type'. Perhaps something like this pseudo code: Outer Algebra Design Pattern OuterAlgebra(S : SetCategory) : public == private where public ==> SetCategory with function signatures which act on whole 'type' go here or in separate category. private ==> add Rep := Record(List InnerAlgebra S, constraints : ...) function definitions which act on whole 'type' go here Note 1) List here is just computationally efficient set. Note 2) constraints make algebra less free, example relations. Note 3) The names 'OuterAlgebra' and 'InnerAlgebra' are replaced by the actual domain names. Note 4) When I use the word 'type' here I mean whole inner algebra. Inner Algebra Design Pattern InnerAlgebra(S : SetCategory) : public == private where public ==> InnerAlgebra S with function signatures which act on single element go here or in separate category. Such as: *: (%, %) -> % 1: % inv: % -> % private ==> add -- representation of the object: Rep := representation of single element function definitions which act on single element go here Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@goo
[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 | || contains set ofcontains set of || VV Permutation <---> Word The domains at the bottom of the diagram are implementations of Group category. So in these cases % will contain something representing a single element of the group such as a single permutation or a single word. Functions will be from Group such as '*'. The domains at the top of the diagram have % which holds information about the whole group so it identifies it as say 'cyclic group 5' or 'dihedral group 3'. The functions will be functions on the whole group such as: sum, product, quotient, subgroup, order, orbit, etc. (I don't think Bill likes this way of describing it? I think the distinction is valid but can you think of a more mathematical way to describe the distinction? Perhaps in terms of initial and terminal algebras?) So how does FinitelyPresentedGroup fit in this? It seems to me that FinitelyPresentedGroup is of type: Type whereas GroupPresentation is of a specific type: (1) -> F:=FPG([x,y,z],[]) (1) FinitelyPresentedGroup([x,y,z],[]) Type: Type (2) -> F2 := groupPresentation([1,2,3],[]) (2) Type: GroupPresentation Given this, is it possible to construct functions like sum, product, quotient, subgroup, order, orbit, etc. on something of type: Type? If it is possible to do this, why is PermutationGroup not constructed this way? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 direction which I already posted here: https://groups.google.com/forum/?hl=en#!topic/fricas-devel/EtLwgd2dWNU Patch for regression tests of these conversions is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresentRegression5.patch Full regression test code is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent.input So when we compose these two functions we should get back to the same point like this: (1) -> c5a := cyclicGroup(5)$PermutationGroupExamples (1) <(1 2 3 4 5)> Type: PermutationGroup(Integer) (2) -> c5b := c5a::GroupPresentation (2) Type: GroupPresentation (3) -> c5c := toPermutationIfCan(c5b) :: PermutationGroup(Integer) (3) <(1 2 3 4 5)> Type: PermutationGroup(Integer) As discussed before, anything more complicated than this wont get back to the same point but somewhere isomorphic like this: (4) -> d3x := dihedralGroup(3)$PermutationGroupExamples (4) <(1 2 3),(1 3)> Type: PermutationGroup(Integer) (5) -> d3y := d3x::GroupPresentation (5) a*a*a, a*a*b*a*a*b, a*a*b*a*a*-b, a*b*a*b, a*b*a*-b, b*b, a*a*b*-a*b , a*b*-a*-a*b, b*a*a*-b*-a, a*a*b*-a*-b, a*a*-b*a*a*-b, a*-b*a*-b > Type: GroupPresentation (6) -> d3z := toPermutationIfCan(d3y) :: PermutationGroup(Integer) (6) <(1 2 4)(3 6 5),(1 3)(2 5)(4 6)> Type: PermutationGroup(Integer) If you wish to see how the algorithm works (or does not work) try calling the function like this: (7) -> toPermutationIfCan(d3a,true) This will display the relatorTables at each stage and the deductions being made from the tables. The conversions in both directions can be improved by implementing better simplifications but since there is no canonical form the simplifications can never be perfect. The Todd-Coxeter does not yet detect and remove 'coincidences', that is, duplicated points. So this in the next improvement that needs to be made. I would like to get back to homology and homotopy so I am hoping that this is good enough for the FriCAS library for now? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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)> Type: PermutationGroup(Integer) permgp::GroupPresentation (2) a*a*a, a*a*b*a*a*b, a*a*b*a*a*-b, a*b*a*b, a*b*a*-b, b*b, a*a*b*-a*b , a*b*-a*-a*b, b*a*a*-b*-a, a*a*b*-a*-b, a*a*-b*a*a*-b, a*-b*a*-b > Type: GroupPresentation As discussed before, improvements to simplification in GroupPresentation would be good but that is not part of this code. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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: OuterDomain Rep := List innerDomain innerDomain Rep := *: (%, %) -> % 1: % inv: % -> % For instance: PermutationGroup(S:SetCategory) Rep := List Permutation Set Permutation(S : SetCategory) Rep := Vector List Set Could FreeGroup be made to fit in this pattern somehow? What I need is a domain that can calculate things like orbits where a knowledge of the whole group is required? ListMonoidOps(Set,E:AbelianMonoid, un:E) Rep := List Record(gen : S, exp : E) FreeGroup(S : SetCategory) Rep := ListMonoidOps(S, Integer, 1) In this design pattern, the algebraic structure of the outer domain is defined by the representation, the algebraic structure of the inner domain is defined by the functions on the representation. These cases must be the two extremes, there could be possible domains in between where the algebra is defined by some other combination of rep and functions. A bit like initial algebra vs. terminal algebra (Kleisli vs. Eilenberg-Moore). In the outer domain the functions tend to involve the whole algebra and in the inner domain the functions can only involve the elements. For homotopy and homology the current GroupPresentation domain gives me a relatively simple way to do the things I need. I'm not sure if the extra complexity of the FreeGroup domain would be justified? It seems to me that these subjects need to define the structures 'upto isomorphism' or 'upto equivalence' and this is best done by the OuterDomain only in the pattern above. I think its probably best if I continue to work with GroupPresentation for now then I, or someone else, could convert the code to use FreeGroup if that becomes useful or more general. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 but the requirement is that every value of this type must have a multiplicative inverse, literally an inverse for the operation *. Bill, Should I have said Rep rather than % ? In one case Rep holds something which represents the whole group. In the other case Rep holds an element of that group. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] [PATCH] More simplifications in GroupPresentation
On 12/11/16 17:30, Kurt Pagani wrote: > That's what had I in mind. I erroneously assumed that your "GroupPresentation" > implements a group in the literallly sense, e.g. to get answers to queries like > a*b^2=b*a^2? > If you inherit from Group then you will get *,1,inv for free. So the domain > "Word" will actually be a group. Well I started coming at this from the Algebraic Topology point of view. That is the relationship between various topologies and various algebras. It seems to me that is about a whole topology being related to a whole algebra (group). I therefore need an entity like GroupPresentation (or something with that structure) to represent the whole group, not an element of the group. Inside that, individual calculations still seem to involve individual elements. Unless there is a way to do Algebraic Topology purely from the outside (in a category theoretic way)? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 mailto:ax87...@martinb.com>> wrote: 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 doing it along the lines of GAP: > http://www.gap-system.org/Manuals/doc/ref/chap47.html <http://www.gap-system.org/Manuals/doc/ref/chap47.html> > > (1) -> GroupPresentation has Group > >(1) false Well in Fricas terms PermutationGroup isnt a group either: (1) -> PermutationGroup(Integer) has Group (1) false Type: Boolean I'm surprised, indeed :( I had a look in permgrps.spad where we find the explanation: <https://github.com/hemmecke/fricas/blob/master-hemmecke/src/algebra//permgrps.spad#L1> -- PermutationGroup implements permutation groups acting on a set S, i.e. all subgroups of the symmetric group of S, represented as a list of permutations (generators). Note that therefore the objects are not members of the Language category /Group/ <http://fricas.github.io/api/Group.html#l-group>. Using the idea of base and strong generators by Sims, basic routines and algorithms are implemented so that the word problem for permutation groups can be solved. Hi Kurt, In simpler terms: PermutationGroup and GroupPresentation are never going to implement the category 'Group' because in PermutationGroup and GroupPresentation % represents the whole group whereas in Group % represents an element of the group. However, we could implement category 'Group' by having a domain called 'Word' (over Symbols or Permutations) where the multiplication operation is the concatenation of words with simplification given by the relations. It seems to me that such a proposed domain would help simplify existing and proposed code as follows: 1) Tidy up some of the local functions in PermutationGroup which work with words in an ad hoc and messy way. 2) Would simplify my conversion from PermutationGroup to GroupPresentation which uses words. 3) Be a basis for examples such as LyndonWord Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 groups. Also I will continue to use GroupPresentation for homotopy because the format produced by these conversions is just too unpredictable. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 doing it along the lines of GAP: > http://www.gap-system.org/Manuals/doc/ref/chap47.html > > (1) -> GroupPresentation has Group > >(1) false Well in Fricas terms PermutationGroup isnt a group either: (1) -> PermutationGroup(Integer) has Group (1) false Type: Boolean Hopefully they are all equivalent for *finite* groups, that is, the round trip: PermutationGroup -> GroupPresentation -> PermutationGroup and GroupPresentation -> PermutationGroup -> GroupPresentation may not get back to exactly the same place but it gets back to somewhere isomorphic to where it started. The problem seems to be simplifying the relations, the simplest case may not be computable? I have added a coercion from PermutationGroup to GroupPresentation to permgrps.spad here: https://github.com/martinbaker/fricasAlgTop/blob/master/permgrps.spad (relies on above patch) This was not hard and it works fine: permgp := dihedralGroup(3)$PermutationGroupExamples (1) <(1 2 3),(1 3)> Type: PermutationGroup(Integer) permgp::GroupPresentation (2) a*a*a, a*a*b*a*a*b, a*a*b*a*a*-b, a*b*a*b, a*b*a*-b, b*b, a*a*b*-a*b , a*b*-a*-a*b, b*a*a*-b*-a, a*a*b*-a*-b, a*a*-b*a*a*-b, a*-b*a*-b > Type: GroupPresentation The problem, as you can see, is that it does not produce a simplest or canonical solution (if such a thing exists). That is there are redundant relations. In the above example it is probably easy to see extra rules that would simplify to a minimal solution but I cant see a general strategy for reduction rules even for very simple cases like this. Going in the opposite direction it is easy to implement Todd-Coxeter, the problem again is simplifying the resulting permutations. I am planning (already started as you can see) to implement two-way conversions between these 'group like' structures. I don't see a problem in having lots of equivalent structures (permutation, presentation, representation, multiplication table, etc.) in fact I think its a positive advantage. I don't feel I understand a structure unless I can approach it from different directions and I don't trust a calculation unless I get the same result when it is done in multiple independent ways. To do good regression tests we need to do calculations in several ways. So I would like to see more overlapping structures in FriCAS, not less. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 same after being 'De Morgan' inverted. Patch is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent4.patch File is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent.spad Here are corresponding regression tests where I have made the name changes and added additional tests for the new simplifications. Patch is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresentRegression4.patch File is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent.input Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 the structures mathematicians are using. 2) To implement Haskel-like structures. This is aimed at separating the 'pure' from the 'impure' in particular chaining together sequences of potentially impure functions. I think this distinction is important because it determines what type of structure is used. In the first case we might use this: class Monad m where unit :: a -> m a mult :: m (m a) -> m a But in the second case we might use this: class Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a So in the case of Maybe, in the second case we could chain together a whole sequence of functions with a signature like this: Something -> Maybe Something into a combined function, this would mean that we would not have to test for "fail" in-between each function call. In the first case we would have a structure like this: Maybe (Maybe Something) which, presumably would return "fail" if either the inner or outer Maybe failed. I suspect this is all a bit academic because I get the impression that the FriCAS compiler is too unpredictable to make the changes to the type system that would be required for a more general category theoretic structures. Please tell me I'm wrong as it would be really wonderful if FriCAS could support this in its most general form. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 src/algebra/dirichlet.spad src/algebra/graph.spad src/algebra/hashstate.spad src/algebra/html.spad src/algebra/mantepse.spad src/algebra/matcat.spad src/algebra/rinterp.spad I have put these all in the one patch file. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 in going the other direction (PermutationGroup to GroupPresentation where possible). I cant quite work out wordInGenerators and wordsForStrongGenerators functions. I know I have seen some documentation about this but I cant remember where I saw it. Martin B (2) -> permgp := dihedralGroup(3) (2) <(1 2 3),(1 3)> Type: PermutationGroup(Integer) (3) -> g := generators(permgp) (3) [(1 2 3),(1 3)] Type: List(Permutation(Integer)) (4) -> sg := strongGenerators(permgp) (4) [(2 3),(1 3)] Type: List(Permutation(Integer)) (5) -> w := wordsForStrongGenerators(permgp) (5) [] Type: List(List(NonNegativeInteger)) (6) -> wordInGenerators(first g,permgp) (6) [2,1,1,2] Type: List(NonNegativeInteger) (7) -> wordInGenerators(second g,permgp) (7) [2] Type: List(NonNegativeInteger) (8) -> [wordInGenerators(x,permgp) for x in g] (8) [[2,1,1,2],[2]] Type: List(List(NonNegativeInteger)) -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 contents of the book, like "-- remove rows from xxx to xxx, except for row xxx". Opinions? I don't know much about the subject but, in general terms, I think it is better if anyone can contribute to FriCAS without having access to a technical library. Perhaps it is not the purpose of comments to teach the underlying mathematics, only how it is implemented, I would think its generally better if that could be done without requiring a specific book which may go out of print. Widening out the scope beyond your question. When I am browsing code the aspect where I would generally like improvement to comments and documentation is: a fuller specification of the expected parameters and outputs of a function and a higher level overview of what it does as opposed to its internal workings which might be deduced from the code. Also an explanation of the type parameters. Is it obvious what types are required here? BezoutMatrix(R, UP, M, Row, Col) : Exports == Implementation where R: Ring UP : UnivariatePolynomialCategory R Row : FiniteLinearAggregate R Col : FiniteLinearAggregate R M: MatrixCategory(R, Row, Col) Perhaps I am thinking about this from the point of view of a potential user who is not an expert in the subject and perhaps your question is more about what is required by an expert in the subject who is modifying the code? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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. But it requires nontrivial computation to find presentation of the kernel. In general, to get a subgroup you specify new generators which are words in terms of generators of larger group. Another way is to specify a predicate so that the subgroup consists of elements satisfying the predicate. Again, it may be tricky to find presentation of such subgroup. And one needs to use appropriate predicate, otherwise elements satisfying the predicate do not form a subgroup. BTW: You can get arbitrary quotient by adding relations (possibly infintely many relations). Well my thinking went like this: 1) I want conversions between PermutationGroup and GroupPresentation. 2) To do this I want to implement Todd–Coxeter algorithm. 3) To do that I need to enumerate the cosets. 4) To implement cosets I need a subgroup. But I have not had time to study Todd–Coxeter algorithm. Until I investigate it I don't really know what I want. Would it be possible to commit the patch without the suspect words? Then I can take longer to investigate. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 regression tests, in gpresent.input file. Patch is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent2.patch File is here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent.spad Regression tests are here: https://github.com/martinbaker/fricasAlgTop/blob/master/gpresent.input Notes: Concerning item 1, inverse generators in relations were not being shown as inverse. I have used used the following conventions. * If index is positive it represents a generator shown as an alphabetic digit followed by number if required. * If index is zero it represents identity shown as 'e'. * If index is negative it represents an inverse generator. The notation uses '-' to indicate an inverse generator (I know this is an abuse of notation, because the group is not necessarily Abelian). This convention is not ambiguous and I don't like the alternatives, '-1' exponent uses too much space and upper case alpha for inverses may not be clear to people who don’t read documentation. Concerning item 5, I do like the idea of the regression tests being in a separate file with a meaningful name. Ideally I would like the name to be the same as the SPAD file name. I may have additional regression tests for this file and improvements to these tests. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 restrictions when writing code (and your help improving it), not so much so when trying to understand other peoples code. But it was _much_ easier to add tests to 'bugs2016.input'. OK, the next tests I write I will use an .input file. Then I can make more informed comments on compiler vs. interpreter for tests. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 including many which human would not generate. Your 'randomSimplicialComplex' looses advantage of random testing because it just uses already prepared examples. Well I was planning to expand these tests. In addition to the basic examples from the factory functions I was planning to have random sums and products of these complexes. I am a bit concerned that the code has only really been tested with simple examples. I would like greater confidence that some structures will not break the code and that the structures scale up without error. Concerning organization of tests, I do not buy argument that "it must be in the same file" OK, how about having an additional directory like src/algebra where there is a test file corresponding to every (eventually) spad file in src/algebra. I think it would really help if the test code and source code were 1:1. What is in which file matters mostlty for Makefiles and grep searches. Putting things different than source code means a lot of false hits from grep, which is a significant distraction. Also Makefile may get unnecessarly complicated. When doing "quick and dirty" fixes people will go directly to relevant function -- if you add something 20 lines below it may be as easily missed as something in completely different file. I think it is important to design these things from the point of view of someone new to FriCAS. Imagine, if you can, that I was new to FriCAS, that I wanted to contribute to the code, that I was not familiar with the test framework and that I believed in test driven development. Would I know where to put the test code? Would I have to resort to searching the source to find existing tests? What is important is that test should be easy to write and easy to run. Agreed and I think it is important to be able to run only tests relevant to my code. So I can run tests frequently during development not just when submitting a potential commit. But if your tests require separate action to run, then they will be ignored. Why not call these tests from the test framework? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 compute fundamental group, but not enough for higher homotopy.And even fundamental group seem to give wrong results sometimes. So one way to go forward is to declare that DeltaComplex is only for homolgy (and by extension cohomology). Alternatively one may work out how to represent maps, say piecewise linear map and use this representation in DeltaComplex. At some moment we will like to represent maps anyway (they are needed for functorial properties and for higher homotopy), so IMO resonable way is to say that just now DeltaComplex is for homology (and maybe fundamental group) and implement similar but more topological domain later. To help analyse this, I think torus shows the issues most clearly. First the fundamental group when we start with SimplicialComplex: (1) -> tS := torusSurface()$SimplicialComplexFactory (1) (1,2,3) (2,3,5) (2,4,5) (2,4,7) (1,2,6) (2,6,7) (3,4,6) (3,5,6) (3,4,7) (1,3,7) (1,4,5) (1,4,6) (5,6,7) (1,5,7) Type: FiniteSimplicialComplex(VertexSetAbstract) (2) -> fundamentalGroup(tS) (2) Type: GroupPresentation I think this can be further simplified, I suspect that it will take a long time until the simplification gets to the level of the GAP program for example. We could re write the above as: Substituting for -o we have: w*t = t*w That is, two edges that commute. Moving everything to one side of the equation we have: t * w * -t * -w Now lets look at the situation for the compacted form (3) -> tD := torusSurface()$DeltaComplexFactory (3) 1D:[[1,- 1],[1,- 1]] 2D:[[1,2,- 1,- 2]] Type: DeltaComplex(VertexSetAbstract) (4) -> fundamentalGroup(tD) (4) Type: GroupPresentation This is not correct, we have lost the orientation information, so how does this happen? The fundamental group is all about loops and the algorithm works by finding loops, each loop will be an edge not in the spanning tree: (5) -> uG := UndirectedGraph(NNI) (5) UndirectedGraph(NonNegativeInteger) Type: Type (6) -> grapht : uG := oneSkeleton(tD) (6) Vertices: 1 Edges: 1-1,1-1,1-1,1-1 Type: UndirectedGraph(NonNegativeInteger) (7) -> spant : Tree(Integer) := spanningTreeNode(grapht, 1::NNI)$uG (7) 1 Type: Tree(Integer) But this is not necessary, because we only have one vertex, we already know the loops, every edge is a loop. So we don't need to do this spanning tree stuff. In fact the information we want is already in the DeltaComplex representation in its purest form: 2D:[[1,2,- 1,- 2]] Representing the edges by 'A' and 'B' we get: A * B * -A * -B So we can calculate the fundamental group: 1) In the case of a fully triangulated DeltaComplex from the mapping from 1D to 0D cells (the graph). 2) In the case where it has been reduced down to 1 vertex, we then use the mapping from 2D to 1D cells. But what about the situation inbetween these two extremes? Somehow I think we need to use both mappings. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 omited part dealing with "randomSimplicialComplex". This function is fishy, giving result which is far from beein random. And usefulness is far from clear, for testing testing all cases is more efficient and more convenient. This function is for regression testing. I think it is very important that regression tests are in the same source file as the code being tested. It may seem that it is just as good to have a separate script file like bugs2016 but I think human nature means things don’t get used and updated by anyone modifying the code if hidden away in a separate file. Of course you may have other regression tests but I think its also important to have tests written by the original author and anyone else working on the file. These tests have already caught a couple of bugs which might otherwise had got into the code. It would be good if there was some standardised way of doing this that does not pollute the namespace or use runtime resources. I do feel strongly that this code does need to be in the same file or they could be ignored. I would also like to write more regression tests for other code that I have written. If there were a standarised way to add it to the source files then I would do this. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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() : DeltaComplex(VertexSetAbstract) == dC := DeltaComplex(VertexSetAbstract) vs1 := vertexSeta(2)$VertexSetAbstract deltaComplex(vs1, [[[1, -2], [1, -2]], [[1, -2, 1, -2]]])$dC So, I've just patched the patch, still in the same place: https://github.com/martinbaker/fricasAlgTop/blob/master/alg_top2.patch and the file is here: https://github.com/martinbaker/fricasAlgTop/blob/master/alg_top.spad -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[fricas-devel] [PATCH] alg top - new factory functions.
Here is a proposed patch for alg_top, the patch is here: https://github.com/martinbaker/fricasAlgTop/blob/master/alg_top2.patch and the file is here: https://github.com/martinbaker/fricasAlgTop/blob/master/alg_top.spad This adds new factory functions, in SimplicialComplexFactory there is a triangulation of dunceHat from Kurt Pagani. I have added a new package 'DeltaComplexFactory' which has functions to construct common complexes which are smaller than DeltaComplexes constructed from SimplicialComplexes. Some of these are based on your bugs2016.input file. Apart from Homotopy (which I will look at next) the only anomaly is projective plane, see line 19 below. Martin B (1) -> DCF := DeltaComplexFactory() (1) DeltaComplexFactory Type: Type (2) -> cD := circle()$DCF (2) 1D:[[1,- 1]] Type: DeltaComplex(VertexSetAbstract) (3) -> dhD := dunceHat()$DCF (3) 1D:[[1,- 1]] 2D:[[1,1,- 1]] Type: DeltaComplex(VertexSetAbstract) (4) -> tD := torusSurface()$DCF (4) 1D:[[1,- 1],[1,- 1]] 2D:[[1,2,- 1,- 2]] Type: DeltaComplex(VertexSetAbstract) (5) -> ppD := projectivePlane()$DCF (5) 1D:[[1,- 1],[1,- 1]] 2D:[[1,- 2,1,- 2]] Type: DeltaComplex(VertexSetAbstract) (6) -> kbD := kleinBottle()$DCF (6) 1D:[[1,- 1],[1,- 1]] 2D:[[1,2,1,- 2]] Type: DeltaComplex(VertexSetAbstract) (7) -> SCF := SimplicialComplexFactory() (7) SimplicialComplexFactory Type: Type (8) -> cS := sphereSurface(2)$SCF (8) (1,2) -(1,3) (2,3) Type: FiniteSimplicialComplex(VertexSetAbstract) (9) -> dhS := dunceHat()$SCF (9) (1,2,8) (2,3,8) (3,7,8) (1,3,7) (1,2,7) (1,6,8) (1,2,6) (6,7,8) (2,4,6) (5,6,7) (2,5,7) (4,5,6) (2,3,4) (2,3,5) (1,3,4) (1,4,5) (1,3,5) Type: FiniteSimplicialComplex(VertexSetAbstract) (10) -> tS := torusSurface()$SCF (10) (1,2,3) (2,3,5) (2,4,5) (2,4,7) (1,2,6) (2,6,7) (3,4,6) (3,5,6) (3,4,7) (1,3,7) (1,4,5) (1,4,6) (5,6,7) (1,5,7) Type: FiniteSimplicialComplex(VertexSetAbstract) (11) -> ppS := projectivePlane()$SCF (11) (1,2,3) (1,3,4) (1,2,6) (1,5,6) (1,4,5) (2,3,5) (2,4,5) (2,4,6) (3,4,6) (3,5,6) Type: FiniteSimplicialComplex(VertexSetAbstract) (12) -> kbS := kleinBottle()$SCF (12) (3,4,8) (2,3,4) (2,4,6) (2,6,8) (2,5,8) (3,5,7) (2,3,7) (1,2,7) (1,2,5) (1,3,5) (4,5,8) (4,5,7) (4,6,7) (1,6,7) (1,3,6) (3,6,8) Type: FiniteSimplicialComplex(VertexSetAbstract) -- circle (13) -> homology(cD) (13) [Z,Z] Type: List(Homology) (14) -> homology(cS) (14) [Z,Z] Type: List(Homology) -- dunce hat (15) -> homology(dhD) (15) [Z,0,0] Type: List(Homology) (16) -> homology(dhS) (16) [Z,0,0] Type: List(Homology) -- torus (17) -> homology(tD) (17) [Z,Z*2,Z] Type: List(Homology) (18) -> homology(tS) (18) [Z,Z*2,Z] Type: List(Homology) -- projective plane (19) -> homology(ppD) (19) [Z,Z+C2,0] Type: List(Homology) (20) -> homology(ppS) (20) [Z,C2,0] Type: List(Homology) -- klein bottle (21) -> homology(kbD) (21) [Z,Z+C2,0] Type: List(Homology) (22) -> homology(kbS) (22) [Z,Z+C2,0] -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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, but if you have converted your objects to paths (included the fonts), then I see no reason why different browsers should show the SVG differently. It's even a w3 standard. https://www.w3.org/TR/SVG11/ Yes, fonts always seem to be a problem. I must admit that I have not tried this recently. Browser support for these standards seems to be constantly improving so I think I should test it out more frequently and convert objects to paths as you suggest. So much to do! I tend to find something that works and stick with it. Lines with arrow heads always used to be a problem (don't know if it still is?). Inkscape allows arrows to be added, but I guess that its not in the standard, Inkscape puts some sort of tag, like a macro, at the start of the file and this builds up each arrow head from smaller components. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 further external information wherever that information might be (wiki, translated Axiom book or other sites). Ideally those URLs would be picked up from ++ comments so that it would be available to other programs. Given the history of pan-axiom documentation issues I don't have a great expectation of massive improvements but any small incremental improvement would be something. Anyway, just a thought, I can get by with current situation if its not possible. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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: what is the sorce code of your diagrams? I use an open source program called Inkscape. It stores the diagrams in SVG (which is an XML format) so I suppose you could say that is the source but I don't edit it with a text editor. 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. Some of the diagrams can be quite big, too big for HyperDoc sized windows I think. Well, I prefer to be independent of network if possible. Network have unpredictable performance, may be not available at all. There are also securtity problems which vanish if tere is no network connection. So it good to have standalone documentation. Also we want documentation to be secure for the long term, that is, we don't want so documentation to disappear if an individual developer stops working on it or for a tool chain to become unmaintainable if an individual company goes bust. There must be some way that web documents could optionally be distributed with the code for use offline if required. Another aspect is conceptual and technical integrity. Online documentation fits well to distributed/decentralized model where various pieces are developed independently. This has advantages, allowing various approches and creating diverse points of view. But it also leads to replication and bloat. And it makes harder to find relevant correct documentation. From my point of view, its not very easy to find the correct documentation now, that’s why I would like a central hub which I think Fricas IO has the potential to become. So it makes sense to develop core documentation in more coordinated way, trying to use common style and common tools. Unfortunately, in the past it was hard to reach agreement what the common approach should be. Exactly, if there are n people reading this then there will be n different views about what the common approach should be. Your comments are a very good summary of the various sources of documentation and how they evolved. It is easy to see that each has its pros and cons. I think I'm reluctantly coming to the conclusion that there is not likely to be consensus on this any time soon. IMO ability to produce different renderings (versions) of documentation is important. Yes, and I expect different formats can be produced from hyperdoc at the syntax level. But once a document has been chopped up into small windows I think its usefulness and readability will be greatly diminished when concatinated back to HTML or other formats. When documenting precisely defined mathematical structures then it might be a good idea to force authors to be concise and fit everything into a small window. However with graphics related software there is a lot of explanation required and a limit to how much this can be compressed down. Even with mathematical structures like SimplicialComplex for example there are a lot of arbitrary decisions which need to be explained in a lot of detail which would be very hard to cram into small windows. By "arbitrary decisions" I mean choices about notation, representation, user interface, etc. that is not forced by the underlying mathematics. I will try to convert parts of your documentation to HyperDoc, we will see how it works. Please please don't. I sent the earlier post because I thought there might be a way to cut down on everyones work but that would just increase the workload. I would feel very guilty if I caused you extra work doing this. I think it would be better to stay with the current situation than to go down that path. I think there are situations where the small guys can beat the big guys but I think the battles have to be chosen carefully. I'm not sure competing with web tools is winnable especially since documentation tools are not the core business of FriCAS. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[fricas-devel] [PATCH] computation.spad Documentation Issues.
In order to complete the recent changes to computation.spad I have updated the documentation to match the code changes. Documentation changes only, no change to code. patch is here: https://github.com/martinbaker/multivector/blob/master/computation5.patch code is here: https://github.com/martinbaker/multivector/blob/master/computation.spad Issues: 1) Is it possible to suppress automatic insertion of spaces around colon and commas in literate parts of the file? 2) Am I wasting my time doing stuff on literate code? This is not a big deal for me. I will continue doing the literate version if you think it worthwhile but, if not, its better not to waste my (and your) time. 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. So why not just rely 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 ++ Basic Operations: ++ Related Constructors: ++ Also See: ++ AMS Classifications: ++ Keywords: ++ Reference: http://www.euclideanspace.com/prog/scratchpad/mycode/computation/ ++ Tutorial: http://www.euclideanspace.com/prog/scratchpad/mycode/computation/lambda/ ++ An implementation of untyped lambda-calculus Then Fricas IO might be able to pick up the URLs and generate links that users would see when they were browsing this domain. Just an idea. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 looks like they have found a way to code structures like fibrations, spectral sequences and relating chain complexes to structures like algebras, coalgebras, and much more. I think it would be good to include structures like these in FriCAS. I guess we need to get the basics right first but I also like to try to work out a long term path for where this is headed. Thank you for coding the dunceHat example. I will write a patch to include this in SimplicialComplexFactory. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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: I remember now, it is the same face but we allow it to be included multiple times in different orientations: (1) -> ASIMP := FiniteSimplicialComplex(VertexSetAbstract) (1) FiniteSimplicialComplex(VertexSetAbstract) Type: Type (2) -> v2a:List(List(NNI)) := [[1,3],[1,3],[3,1]] (2) [[1,3],[1,3],[3,1]] Type: List(List(NonNegativeInteger)) (3) -> sc1 := simplicialComplex(vertexSeta(3::NNI),v2a)$ASIMP (3) (1,3) (1,3) -(1,3) Type: FiniteSimplicialComplex(VertexSetAbstract) (4) -> addImpliedFaces(sc1) (4) [[-(1,3),(1,3),(1,3)]] Type: List(List(OrientedFacet)) (5) -> sc1::DeltaComplex(VertexSetAbstract) (5) 1D:[[1,- 2],[1,- 2],[- 1,2]] Type: DeltaComplex(VertexSetAbstract) Under a strict geometric interpretation of a definition of simplicialComplex I suspect that this should not be allowed? But, as we discussed earlier, it is useful not to prevent this to allow construction of interesting delta complexes. > - apparently you want chains here. Chains are not the same as > complexes. I take your point and I would like to pursue your earlier comments about having a separate chain domain (though I'm not sure exactly how). Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[fricas-devel] Github IO
Ralf, I notice that https://fricas.github.io/ has not been updated to 1.3.0. I guess that must mean its not automatically generated? Anyway I find the site useful and hope you get a chance to update it. Martin B. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 need to take orientation into account and orientation requires a consistent set of notation standards. Could it be that other programs are using different conventions? (1) -> triangle := sphereSolid(2)$SimplicialComplexFactory (1) (1,2,3) Type: FiniteSimplicialComplex(VertexSetAbstract) (2) -> delta(triangle) (2) (1,2) -(1,3) (2,3) Type: FiniteSimplicialComplex(VertexSetAbstract) So [(1,2),-(1,3), (2,3)] represents a circular chain (boundary of a triangle). Which can be notated [(1,2),(3,1), (2,3)] OTOH [(1,2), (1,3), (2,3)] represents two parallel chains, starting and ending at the same vertices. This will have different homology. These conventions make sense to me because all we need to do is order the facets (left entry is most significant) and then alternate the sign. This is what concerns me about your proposal, for changing the VertexSet structure, the user interface could then loose this ordering information. So is this Cyclic? [(a,b),-(a,c), (b,c)] I would say yes, but only if ab>c, but the user can't know this because they can't see the underlying index ordering. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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" -- deselect the checkbox), it means that you connect to the site in an encrytped way. So the connection to the target site is encrypted, the only thing that you don't know is that the site is the site it claims to be and that nobody has led you to a wrong site. With http, you neither have encryption nor can you be sure that someone led you to the wrong site. As I see it, this sites certificate simply has expired. So it would probably be a good thing to tell thit to the webmaster of www-fourier.ujf-grenoble.fr. As long as you trust that the .pdf does not have a virus, I think, it's not a problem if one trusts "self-signed certificates". Although nowadays people should probably switch to "Let's encrypt"-certificates. https://letsencrypt.org/ Ralf OK, thanks, I'll do that. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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). Thanks, very much, for checking this. BTW: why didn't you allow '0'? NNI=0,1,2,... ;) -- from https://www-fourier.ujf-grenoble.fr/~sergerar/Kenzo/Kenzo-doc.pdf Neither Firefox nor Chrome would allow me to connect to this site, I got: "Your connection is not secure The owner of www-fourier.ujf-grenoble.fr has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website." Even when I changed https to http it automatically changed it back and would not connect. ASIMP := FiniteSimplicialComplex(VertexSetAbstract) v0:List(List(NNI)) :=[[0],[1],[2],[3],[4],[5],[6],[7], _ [0,1],[0,2],[0,3], _ [0,4],[0,5],[0,6], _ [0,7],[1,2],[1,3], _ [1,4],[1,5],[1,6], _ [1,7],[2,3],[2,4], _ [2,6],[2,7],[3,4], _ [3,5],[4,5],[4,6], _ [5,6],[5,7],[6,7], _ [0,1,5],[0,1,6],[0,1,7], _ [0,2,3],[0,2,4],[0,2,6], _ [0,3,4],[0,5,7],[1,2,3], _ [1,2,4],[1,2,7],[1,3,5], _ [1,4,6],[2,6,7],[3,4,5], _ [4,5,6],[5,6,7]] Well since these values are potentially being used as indexes into VertexSet and since the usual FriCAS default is 1-based indexing I used that. However Waldek has suggested replacing VertexSet with any SetCategory which would allow indexes to be hidden from user interface. This would allow any values to be used here. I will therefore attempt to implement Waldeks suggestion. 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. On 19/09/16 04:59, Kurt Pagani wrote: -- Dunce hat -- https://en.wikipedia.org/wiki/Dunce_hat_(topology) v1:List(List(NNI)) :=[[1],[2],[3],[4],[5],[6],[7],[8], _ [1,2],[1,3],[1,4], _ [1,5],[1,6],[1,7], _ [1,8],[2,3],[2,4], _ [2,5],[2,6],[2,7], _ [2,8],[3,4],[3,5], _ [3,7],[3,8],[4,5], _ [4,6],[5,6],[5,7], _ [6,7],[6,8],[7,8], _ [1,2,6],[1,2,7],[1,2,8], _ [1,3,4],[1,3,5],[1,3,7], _ [1,4,5],[1,6,8],[2,3,4], _ [2,3,5],[2,3,8],[2,4,6], _ [2,5,7],[3,7,8],[4,5,6], _ [5,6,7],[6,7,8]] I don't think all these values are necessary because any set is assumed to contain all its subsets. However, explicitly including them should not cause a problem. I will try to investigate what is going on. Thanks again, Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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
is the same as
"string"@OutputForm
which gives the same result as
message("string")
that is without string quotes. OTOH
ss : String := "string"
ss::OutputForm
is the same as interpreter "string"::OutputForm and adds
string quote. I am thinking about removing the special
handling of '"string"@OutputForm' from Spad compiler.
There seem to be several uses of this in algebra, so there
is some work adjusting. But still I think that removing this
irregularity is better.
Waldek,
I think the main problem is much simpler than that, its not doing
anything with the result, it should assign it to variable 's'. So it
gives empty output like this:
(1) -> UNTYP := SKICombinators Untyped
(1) SKICombinators(Untyped)
Type: Type
(2) -> m1 := I()$UNTYP
(2)
Type:SKICombinators(Untyped)
but it should give output like this:
(2) -> m1 := I()$UNTYP
(2) I
Type:SKICombinators(Untyped)
I think the code should be like this:
-- output
coerce(n : %) : OutputForm ==
s : OutputForm := empty()$OutputForm
if n case lf then
-- leaf node so print I, K or S
s := (n.lf)::OutputForm -- **need to assign to s here **
if n case nd then
-- binary node which has two subnodes c1 and c2
if atom?(n.nd.c2) then
if variable?(n.nd.c2) then
s := hconcat([s,_
(n.nd.c1)::OutputForm,_
message(" "),_
(n.nd.c2)::OutputForm])$OutputForm
else
s := hconcat([s, (n.nd.c1)::OutputForm,
(n.nd.c2)::OutputForm])$OutputForm
else
s := hconcat([s,(n.nd.c1)::OutputForm,message("("),_
(n.nd.c2)::OutputForm,message(")")])$OutputForm
if n case vr then
-- variable node so print name
s := (n.vr)::OutputForm
s
Martin B
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] [PATCH] Minor code changes to computation.spad
Hi Waldek, 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: Updated file is here: https://github.com/martinbaker/multivector/blob/master/computation.spad and patch is here: https://github.com/martinbaker/multivector/blob/master/computation4.patch Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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:
https://groups.google.com/forum/?hl=en#!topic/fricas-devel/ouZg285DTcI
In this thread I think the long term solution is given by Waldek:
Waldek Hebisch wrote:
> I thought about easier debugging printouts
> from Spad and I see the following possibilities:
>
> - teach Spad compiler to allow "open types", that is types
> for which compiler can infer type of parameter. That
> would allow something like:
>
>print(x)
>
> with Spad compiler automatically choosing appropriate
> overloaded version of 'print' matching type of 'x',
> after a single import like:
>
>import from PrintPackage1(?)
>
> where '?' means that we allow all types of arguments.
>
> - Use infix operator plus overloading for printing, like:
>
> d_out << "abc" << 1
>
> with overloaded versions of '<<' it could print any type.
> Note: to avoid a lot of imports that requires either adding
> '<<' to all domains or "open types" like above.
>
> "open types" would require change to Spad compiler. Using '<<'
> with explicit import is just matter of writing appropriate
> package. In principle we could add '<<' to SetCategory or
> even to 'CoercibleTo(OutputForm)' (using conditional export
> in 'CoercibleTo').
I hope a solutions like these can be implemented, I don't have the
knowledge to do anything myself.
Martin B
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
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 to print string without quotes use 'message': message(str) gives you desired OutputForm. For nonconstant strings this is more efficient and in all cases is clearer than going via symbols. OK, I have done that. Updated file is here: https://github.com/martinbaker/multivector/blob/master/computation.spad and patch is here: https://github.com/martinbaker/multivector/blob/master/computation3.patch This compiles and works so, as far as I can tell, its ready to go. There is just one thing that I'm curious about. I now have lot of lines like this: print(message "warning I does not have a parameter to act on") This generates a compiler error like this: compiling exported coerce : SKICombinators UT -> ILogic ** comp fails at level 11 with expression: ** error in function coerce ** level 11 ** $x:= (message warning I does not have a parameter to act on) $m:= $EmptyMode $f:= #:G6598 # #) (#:G6601 # #) (|s| # #) (|lambdaOverSki| #)) ((|lambdaOverSki| #) (= #) (I #) (K #) ...) ((|Ski2Lambda| #) (= #) (|atom?| #) (|bind| #) ...))) >> Apparent user error: NoValueMode is an unknown mode I assume this is because there are 2 print functions with the same signature (although the error message gives no clue to this). So I changed the line to: print(message "warning I does not have a parameter to act on")$OutputForm and this makes the error go away. The interesting thing is, I only have to do this once (see line 2794 in code) and then all other similar functions compile without specifying domain. Its like I only have to tell the compiler which version of 'print' to use once and it then uses the same for all future 'print' calls. So, my questions are: 1) Are my suppositions correct? 2) If so, is it safe to rely on it? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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: https://github.com/martinbaker/multivector/blob/master/computation2.patch Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 Martin PS I do have some further changes to this file (comments and minor code changes) but I will send those separately as I think thats what you prefer. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 OutputFormat. No longer has arrows on edges - JG 2) New version of addArrow! and simplify unnecessarily complex code - JG + MB 3) New output to SVG: diagramSvg2 which does not clip lines - MB These changes were sent to me by Johannes Grabmeier who is using UndirectedGraph to output data, I also applied some of his changes to other graph types where appropriate. Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[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 outputting to SVG. Now uses transform tag rather than changing font-size which only has limited number of sizes. 2) Additional addSceneLine function which does not clip line. 3) Various small bug fixes 4) Update URLs and remove whitespace from URLs These changes are required for some updates to graph.spad that Johannes Grabmeier has sent me. I will wait to see if this patch is acceptable before I send the patch to graph code. Thanks, Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
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 the merit in this. When users are just using abstract (combinatorial) topology they can use: FiniteSimplicialComplex(NNI) or FiniteSimplicialComplex(Symbol) But if some 'geometry' is involved then VS will have to be something more complicated and some part of the software will have to 'see' inside this SetCategory. This geometry is not just for graphical interface (important to me as this is) but it is also genuine mathematical content, for example I would like to distinguish isotopy, that is embeddings in higher dimensions, where a trefoil knot is different from a circle for example also we need guarantee that facets do not intersect. Perhaps FiniteSimplicialComplex could implement mostly just the abstract stuff and the geometry could be done externally in other domains or packages? As you point out, constructors and output will have to be more complicated to do this. In order to keep the output to a manageable size I think I will need something like the following in coerce to OutputForm: if (VS is NNI) or (VS is PI) or (VS is Integer) or (VS is Symbol) then map_to_VS_in_output() else use_index_in_output() That is, if VS is something compact (like a number or a symbol) then use that in the output but if it is something more complicated (like a coordinate) then just display the index instead. Would this work? Is there a less messy way to see inside VS? Part of your confusion may come from fact that in textbooks chains play important role, but you have not direct representation of chains. You represent chains as list of cells, which means that 0 chain is represented as empty list. But you do not have operations on chains like addition or multiplication by scalar. In a sense adding chains is trivial, all you need is FreeModule(Integer, Facet), but you do not have Facet, you only have OrientedFacet. Instead of Facet one could use say Set(Integer), but then this becomes completely disconnected from your code. This looks like an interesting idea. I guess this would only work for DeltaComplex and not FiniteSimplicialComplex because the facets need to be graded. Do you think it would be a problem having both (since it involves some duplication). So we have: Facet for DeltaComplex OrientedFacet for FiniteSimplicialComplex It seems to me that one of the big advantages of panaxiom is its type system and so that should be used to enforce the grading. That is, if we try to add Facets of different dimensions that will be detected at compile time rather than runtime. So can we define a facet type like this: Facet(n:NNI) -- an 'n' dimensional facet. We can then define a chain like this: Chain(n:NNI) ... Rep := FreeModule(Integer, Facet(n)) Could we define a boundary map like this: BoundaryMap(n:NNI) ... Rep := Chain(n) -> Chain(n-1) Not sure how practical this is? In practice, for finite dimensions, we would just hide a lookup table inside a lambda so perhaps we might as well put the lookup table directly in the Rep: Rep := List(List(Integer))) We then need a way to define DeltaComplex, a bit like this: DeltaComplex(n:NNI,VS : VertexSet) ... Rep := Record(VERTSET : VS, MAPS : [BoundaryMap(m) for m in n..1]) but that does not work. Is there a way to have comprehensions for types? Or is there some other way to do this? Martin B -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
