[fricas-devel] Re: XDistributedPolynomialFunctions1 - factor
Hello Konrad,
I did make a start on setting up a test harness for your algorithm;
all I need to add is the statistics recording; but got sidetracking with
Bill's algorithms. Just building my understanding.
Taking something out of context, you mention that a quiting
criterion for "T" is when it's impossible to factor T=U*V. This is what
the recursion algorithm does. I now understand what Cohn is doing;
although I couldn't pass a test on the real internal material.
I can't afford Mora's volumes; but I have found Cohn's "Free Rings
and Their Relations" and can afford that if you think it would help me.
I do have one (possibly more) of his papers as well. His caveat about
some expressions (in particular rectangular matrices) not being a UFD is
a little disturbing unless one's goal is /a factorization. /I am
presuming that he isn't talkin/g /about things like/
p=x+xyx=x(1+yx)=(1+xy)*x
/Which I got and didn't recognize./
/I am not saying your papers have anything wrong or too hard. I just
like to look into the history of mathematics (even current) to provide
context in my mind. One side of my brain loves the itty-bitty details
and the other wants to know how things came to be./
/ I haven't examined your algorithm in detail but it seems to me that
reducing to ALS, on a term by term bases might be easier that just
extending up matrices with the rules given. Unless the rules of
adding/multiplying to an ALS by a new term automatically produces a new
ALS. Of course, I am also assuming the commutation rules:
ALS(X+Y)=ALS(X+ALS(Y)), etc.. Is this true?
I don't understand your last paragraph. I think I managed to
extend the meaning of GCD to fractions in a manner to keep a large
number of properties (obviously not all :-)) at one time. I don't know
if it's relevant though.
I hope you forgive my ignorance of these matters. It's true, I am
ignorant.:'(
Enjoy
Ray
On 07/20/2018 05:10 AM, Konrad Schrempf wrote:
Dear Bill,
just recently I had a look into the two volumes of
Teo Mora on solving polynomial systems of equations.
There is quite some theory one could consider ;-).
Right now I just would like to add a comment about
more general base rings (rather domains because zero
devisors do not simplify things): The ansatz will
work if we add non-proper left and right subwords.
A simple example is p=6-2x (with integer coefficients),
which is REDUCIBLE because p = 2*(3-x); the only units
in Z are {+1,-1}.
In the case of a (base) field however, ALL elements
of zero degree are units so one can remove extra
dimensions in the solution variety a priori.
(About the latter --in a different context-- Franz
did some nice experiments in FriCAS. Keyword: Primary
Decomposition of ideals.)
Regards,
Konrad
--
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] interoperability with sage again
Martin R wrote: > > --=_Part_5621_1147149640.1532098688227 > Content-Type: multipart/alternative; > boundary="=_Part_5622_1923490781.1532098688228" > > --=_Part_5622_1923490781.1532098688228 > Content-Type: text/plain; charset="UTF-8" > > Dear Waldek, > > Am Freitag, 20. Juli 2018 16:16:15 UTC+2 schrieb Waldek Hebisch: > > > > Martin R wrote: > > > Curiously, the InputForm of products and sums gets rid > > > of subscripted symbols automagically... > > > > Well, you use dummy variables in input form. Scripted symbols > > only appear in names corresponding to dummies. So in effect > > you drop original names of variables, replacing them by > > dummies. > > > Yes. What I found curious is that the name is preserved in FriCAS: Names of variables do not matter for kernels equality, so you get names used in first kernel that you create. > Attached a new patch, treating symbols in OutputForm special. OK, please commit. -- Waldek Hebisch -- 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] interoperability with sage again
Dear Waldek, Am Freitag, 20. Juli 2018 16:16:15 UTC+2 schrieb Waldek Hebisch: > > Martin R wrote: > > Curiously, the InputForm of products and sums gets rid > > of subscripted symbols automagically... > > Well, you use dummy variables in input form. Scripted symbols > only appear in names corresponding to dummies. So in effect > you drop original names of variables, replacing them by > dummies. Yes. What I found curious is that the name is preserved in FriCAS: (10) -> p := product(1/k, k=1..n) n ++-++ 1 (10) | | - | | k k = 1 Type: Expression(Integer) (12) -> p::INFORM (12) (%defprod (/ 1 %B) %B k 1 n) Type: InputForm (16) -> product(1/%B, %B=1..n) n ++-++ 1 (16) | | - | | k k = 1 Type: Expression(Integer) At least for the sage interface it doesn't matter. Python is slightly crippled what concerns identifiers, so I would have to replace the scripted symbol with something else anyway... Attached a new patch, treating symbols in OutputForm special. Best wishes, 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. df Description: Binary data
Re: [fricas-devel] interoperability with sage again
Martin R wrote: > attached a patch. Curiously, the InputForm of products and sums gets rid > of subscripted symbols automagically... Well, you use dummy variables in input form. Scripted symbols only appear in names corresponding to dummies. So in effect you drop original names of variables, replacing them by dummies. ATM I am not sure if this matters. > > @@ -470,6 +470,19 @@ OutputForm() : SetCategory with > outputForm s == >sform concat(quote()$Character, concat(s, quote()$Character)) > > +convert(a: %): InputForm == > +b: SExpression := a pretend SExpression > +if atom?(b)$SExpression then > +if string?(b)$SExpression then > +c: String := string(b)$SExpression > +l: Integer := maxIndex(c) > +if l >= 2 and c.1 = c.l and c.1 = quote()$Character then > +d: String := c.(2..(maxIndex c)-1) > +b: SExpression := convert(d)$SExpression > +return convert(b)$InputForm ^^^ AFAICS this has undesirable effect on symbols. Namely, symbols are supposed to be evaluated: (1) -> if1 := (x::Symbol)::InputForm (1) x Type: InputForm (2) -> x := 5 (2) 5 Type: PositiveInteger (3) -> interpret(if1) (3) 5 Type: PositiveInteger However, it seem desirable to preserve names of symbols, and with the code above name (more precisely subscripts) can change: (31) -> z[y] (31) z y Type: Symbol (32) -> if2 := (z[y])::InputForm (32) (script z (construct (construct y) (construct) (construct) (construct) (construct))) Type: InputForm (33) -> y := 5 (33) 5 Type: PositiveInteger (34) -> interpret(if2) (34) z 5 Type: Symbol Also for consistency with other cases we should prevent 'y' from evaluation above. BTW: This ilustrates that InputForm (or rather 'convert') is not well defined. Namely, for expressions it is natural to expect that InputForm can be evaluated and value will depend on variables. For domains which represent values (most of FriCAS domains) it is natural that InputForm reconstructs the value. But there are borderline cases. In fact, it would make sense to have two different 'convert'-s: one which is intended to pick values from environment and the other which should reconstruct value exactly. But this is separate topic... -- Waldek Hebisch -- 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] interoperability with sage again
Dear all, attached a patch. Curiously, the InputForm of products and sums gets rid of subscripted symbols automagically... all the best, 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. df Description: Binary data
