On Mon, Jun 11, 2018 at 8:17 AM, oldk1331 wrote:
>>> The grammar for 'reduce': "func"/[args]
>>> is not only very strange, but also not applicable in interpreter.
>>>
>>> I don't think it's worth the effort that compiler supports this grammar,
>>> because it should be easilly replaced by "reduce
On Sun, Jun 10, 2018 at 12:55 PM, Prof. Dr. Johannes Grabmeier privat
wrote:
> Hi all,
>
> have added sqrt for prime fields, perhaps for next release.
>
> (1) -> )r sqrtpf
> ..
+1 Thank you.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebr
l examine your code.
>
In the example I gave a different (symbolic) definition of the scalars F:
MP ==> MPOLY(PARAMETERS,Integer)
F ==> Fraction(MP)
but as far as NCPOLY is concerned this is just another Field.
>
> On 06/05/2018 12:15 PM, Bill Page wrote:
> > ...
> > Some
an just an algebra.
> Is there a large gap between nc_ini03.input and 1803.10627.pdf; did I
> misunderstand the relationship?
>
>
Keep in mind that "1803.10627.pdf" is describing something more
general. From offline discussions with Konrad I gather that the FriCAS
codin
t;linpen.spad"?
There is a perhaps related but strange looking definition in
"ncpoly.spad" that is actually commented out:
--_= : (%, %) -> %
-- ++ \spad{f = g} for testing only ...
(strange because the result type is %). I am not sure of the intention
or if this is ir
ks, produces some reasonable
> outputs, but I have a feeling that it's unnecessarily restrictive. I
> hope this is not an _extremely_ silly question.
>
> RayR
>
>
> On 06/01/2018 09:25 AM, Bill Page wrote:
> > Thank you. Please extend my compliments to the author of th
On Thu, May 31, 2018 at 9:55 AM, Erik Eidsvig wrote:
> Thanks!
>
> -But what about n-root of a number? As an example, the 5th-root of 32?
>
> (I have tried commands like root(32,5), nrot(32,5) etc.)
>
(1) -> )what op root
Operations whose names satisfy the above pattern(s):
alg_split_root0
On Thu, May 31, 2018 at 4:34 AM, Ralf Hemmecke wrote:
>> As far as I know only in input file with correct indentation.
+1
>
> I also thought that this would work, but I remember that I had problems.
What problems?
> So the usual way is, to put things in an .input file in the following way:
>
>
On Mon, May 28, 2018 at 9:55 AM, Franz Lehner wrote:
> On Mon, 28 May 2018, Bill Page wrote:
>>
>> That's a pity. Is the problem with the published algorithm or the source
>> code?
>
> Factorization of noncommutative polynomials seems to be a difficult proble
On Mon, May 28, 2018 at 6:14 AM, Marduk BP wrote:
> It turns out that code was never released because it was buggy, so we
> can forget about it.
>
That's a pity. Is the problem with the published algorithm or the source code?
> But IMHO what I want to do does not require factoring a polynomial.
algebra system.
--
There is reference to some code that apparently was contributed to
Axiom but after a quick look I was not able to find it. Perhaps you
could contact the author?
Bill Page.
On Sun, May 27, 2018 at 1:59 PM, Marduk wrote:
> Dear all,
>
> given a multivariate monomial def
You try using unparse, e.g.
(1) -> output unparse(integrate(1/x^3,x)::InputForm)
(-1)/(2*x^2)
--
On Fri, Mar 9, 2018 at 12:25 PM, Raymond Rogers
wrote:
> :) That's what I wanted for input, thanks!
> fricas does interpret simple ASCII strings in the manner expected.
> Now how do I format the
On Tue, Feb 20, 2018 at 6:13 AM, wrote:
> Wish: If you plan to release binaries, would it be possible to compile
> and release in some contrib directory also the binaries of Kurt
> Parentani's fricas_jupyter [1] ... if the code works and Kurt agrees,
> I mean.
>
++1
Also include an option in m
On Tue, Feb 6, 2018 at 12:04 PM, Waldek Hebisch
wrote:
> ...
> I would write:
>
> a * rightRecip(a) = 1
>
Noted.
>
> I should have written leftRecip and rightRecip _as functions_
> are different. In particular there are element where left
> inverse exists but right inverse does not exist (that
On Tue, Feb 6, 2018 at 8:28 AM, Waldek Hebisch wrote:
> Prof. Dr. Johannes Grabmeier wrote:
>>
>> So my remark shoud better read:
>>
>> All general functions as leftRecip and rightRecip and associator are
>> superfluous as
>> soon as we have an associative structure,
>
> That is more complicated,
er'. For some reason they
still show up in domains like 'Polynomial Integer' although
'Polynomial Integer has CommutativeStar' is evaluated as 'true' in the
interpreter so perhaps the conditional type inference is not quite as
strong as one might like in hyperdoc. A
On Fri, Feb 2, 2018 at 3:53 AM, Prof. Dr. Johannes Grabmeier privat
wrote:
>
> All general functions as leftRecip and rightRecip are superfluous as
> soon we have a recip, ...
I don't think so. For example 'MagmaWithUnit' is inherited by a very
large number of domains. It exports 'leftRecip' and
I am not sure of the exact cause but it seems the interpreter is doing
a particularly bad job of imputing the types. The follow alternatives
work:
(1) -> integrand:Expression Complex
Integer:=1/2*2^(1/2)*1/(1+x)^2/(-%i+x^2)^(1/2)+1/2/(1+x)^2*2^(1/2)/(%i+x^2)^(1/2)
+---+
Perhaps this work by Kurt Pagani will be of some interest:
https://groups.google.com/d/msg/fricas-devel/FRDGVFsoAKw/IbJT3b6PAQAJ
https://github.com/nilqed/fricas_input/tree/master/deploy
This code includes innner product and Hodge dual on differential forms.
On 8 January 2018 at 09:18, Raymo
'x in the compiler is not the same as 'x in the interpreter. Try this
-- testpkg2.spad
)abbrev package TESTPKG TestPkg
TestPkg(x:Symbol,F: Field) : Interface == Implementation where
FPOLY ==> UnivariatePolynomial(x,F)
Interface == with
testf : FPOLY -> F
Implementation == add
testf(
anch with updates to the interface I think I
can find some time to try using it again.
Bill Page.
On 20 October 2017 at 07:51, oldk1331 wrote:
> 1. Why did you comment out the following code in
> contrib/texmacs/fricas/progs/fricas-input.scm?
>
> ;; ("" "1,"
On 13 October 2017 at 20:53, oldk1331 wrote:
>
> You said Boolean has 'Finite', and size()$Boolean is 2.
> So Boolean should have Canonical.
Canonical is not about the number of values in a domain, it is about
how equality is defined. Although Boolean has only two possible values
it has many poss
On 13 October 2017 at 06:30, oldk1331 wrote:
>
>> Yes, in category theory this is called a "split monomorphism"
>
> I read a little category theory recently, and here is my thought:
>
What reference do you prefer for category theory?
> There are many 'coerce' exported by FriCAS, and many of them
In what sense?
> Maybe is a low level domain, and it's one of the few "inline domains",
> it's totally OK to have $Lisp calls.
>
Yes. I was just suggesting that calling Lisp functions is no different
than making the assumption that the data values should be interpret
ble? x == x pretend Boolean
Then
if not retractable? m then error("too bad")
generates inline code like:
(COND ((NULL |m|) (|error| "too bad")))
On 10 October 2017 at 19:38, oldk1331 wrote:
> On Tue, Oct 10, 2017 at 8:05 PM, Bill Page wrote:
>>>> I thin
On 11 October 2017 at 00:30, oldk1331 wrote:
> Well, is 'coerce/retract' mentioned in category theory?
> Is there a theory about that?
>
Yes, in category theory this is called a "split monomorphism"
https://ncatlab.org/nlab/show/split+monomorphism
By definition 'retract' is the left inverse of
t.
This is not meant to "hijack" Nic Doye's message to the Axiom list but
I think reposting is justified since there are so very few people
actively interested in this subject.
Bill Page.
-- Forwarded message --
From: Nicolas Doye
Date: 5 September 2017 at 09:33
Su
might make sense to replace both of these with a
two argument form of this category.
There may be other domains where the coerce/retract pair is defined
but 'RetractableTo/RetractableFrom' is not specified. It would make
sense to me to change these other domains so it is clear th
% -> R
Compared to Haskell, the last one is perhaps an abuse of a Latin
prefix but causes me less dissonance than "unjust".
On 9 October 2017 at 21:41, Bill Page wrote:
> Yes, I am OK with this choice.
>
> Thank you very much for listening to my complaints ...
>
> On 9 O
On 10 October 2017 at 03:03, oldk1331 wrote:
> On Tue, Oct 10, 2017 at 10:30 AM, Bill Page
> wrote:
>> The function 'first' in the List domain calls SPADfirst$Lisp which is
>> a rather clever Lisp macro
>>
>> (defmacro |SPADfirst| (l)
>> (let ((te
meone with more Lisp experience than me can explain it?
I think probably that (NULL (NULL x)) is optimized by Lisp (at least by SBCL).
On 9 October 2017 at 19:57, oldk1331 wrote:
> On Mon, Oct 9, 2017 at 9:22 PM, Bill Page wrote:
>> My benchmarking shows the Lisp macros QCAR and C
Yes, I am OK with this choice.
Thank you very much for listening to my complaints ...
On 9 October 2017 at 20:11, oldk1331 wrote:
> On Mon, Oct 9, 2017 at 10:07 PM, Bill Page wrote:
>> On 9 October 2017 at 06:28, oldk1331 wrote:
>>>
>>> And it seems that there&
ly the ability to use the 'case' infix operator syntax in other
types besides Union needs changes to the compiler. As I said, I am
open to the suggestion this could be replaced with a simple function
call in Union also but what is most important to me is the overall
consistency of the F
is issue was resolved in OpenAxiom so that the case
construct can be exported by domains other than Union. Failing that
we might have
XX? --> failed?
YY? --> value?
Of course someone might prefer to substitute other names for "value"
and "failed", for example "
semantics so it
does not cause me much mental anguish but if it is not really needed,
I would still resist adding it to FriCAS.
Bill Page.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this g
rhaps
this is due to some internal optimizations in SPAD and/or SBCL? I
think it is best to avoid explicit Lisp dependencies if possible. Is
your experience different?
Bill Page.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra syste
Haskell's "nothing" is also pretty good.
This brings up the issue of the output form for Maybe. Currently we
have "failed" and for non-failed values the same output form used by R
without any additional markup. I think it is desirable to be able to
visually distingui
od idea. I'd rather
> like to be independent of such implementation details.
>
It seems reasonable to me to assume that any target language is likely
to provide at least some form of List as a primitive type. But in any
case we can at least assume that there will be a way to implement L
On 8 October 2017 at 03:47, Ralf Hemmecke wrote:
> On 10/08/2017 05:55 AM, Bill Page wrote:
>> "Union(R,"failed")" on the other hand does seem to take about 80%
>> longer to unwrap a value.
>
> I'm not a compiler expert (and I don't actually like
x) then "failed" else first x
retract x == if empty?(x) then error errMsg else first x
qretract x == first x
maybe(x, default) == if empty?(x) then default else first x
maybe(f,x,default) == if empty?(x) then default else f(first x)
if R has CoercibleTo OutputFo
Time: 0 sec
(5) -> M:Maybe NNI := empty()
(5) []
Type: Maybe(NonNegativeInteger)
Time: 0 sec
(6) -> bind(M,minus1)
(6) []
AD compiler and even Lisp to do whatever
optimizations are possible at those levels. Some day there may even
will be a SPAD compiler that generates LLVM code instead of Lisp. But
in any case, the choice of representation can make a big difference
depending on just what optimizations are available.
using old system compiler
(1) -> )time on
(1) -> f4 1
(1) 1
Type: PositiveInteger
Time: 0.00 (EV) + 0.04 (OT) = 0.04 sec
(2) -> f4 200
(2) 200
using 'Rep:=List R' that I sent in an earlier email. In the
interpreter it seems to be intermediate between your Maybe and Union
but when compiled it seems faster than both. Of course using 'List R'
as a representation is not as space efficient as using the domain R
itself but it do
On 5 October 2017 at 01:09, Ralf Hemmecke wrote:
> On 10/05/2017 02:32 AM, Bill Page wrote:
>>> I think current situation is a good compromise. We can
>>> say in documentation that all instances of Maybe share
>>> a common value of failed(), and nested usage of Maybe
ith
'coerce/retract' without any ambiguity.
I am sorry that this took me some time but it turned out that 'recip'
is quite deeply buried in FriCAS and the changes affected a lot of
code. I am still reviewing the changes and there may be a few places
where they can be polished a lit
On 4 October 2017 at 20:44, oldk1331 wrote:
> On Thu, Oct 5, 2017 at 8:32 AM, Bill Page wrote:
>> On 4 October 2017 at 19:38, oldk1331 wrote:
>>> Waldek, Bill, yes, for correctness we need to distinguish
>>> the inner domain and outer domain, and it's easy to
&g
On 4 October 2017 at 19:38, oldk1331 wrote:
> Waldek, Bill, yes, for correctness we need to distinguish
> the inner domain and outer domain, and it's easy to
> have a GENSYM() for each Maybe domain.
>
> But that will hurt performance.
>
Why will this hurt performance?
> I think current situation
A good model for the semantics of Maybe is a box that can contain at most
one thing or otherwise is empty. A box that contains another box is not
empty even if that box itself is empty.
Therefore I agree with Waldek. It seems to me that each instantiation of
Maybe should generate its own "failed"
OK, I will try what you suggest and then present the result.
On 29 September 2017 at 09:40, oldk1331 wrote:
> Bill, since we can't persuade each other, I suggest you to convert
> some Union("failed"..) to Maybe using 'coerce/retract', for example
> rewrite function 'recip'.
>
> Then you will find
re ONLY for List
> (and every possible Monad):
>
> coerce : S -> List S
> retract : List S -> S
>
> For List, the signature 'S -> List S' is named 'list', and
> the signature 'List S -> S' is named 'first'.
>
On 27 September 2017 at 19:05, oldk1331 wrote:
> The point of 'wrap/unwrap' or something like that is to avoid to
> specify type. Like you can use
>
>x := wrap y
>
> instead of
>
>x : Maybe A_VERY_LONG_TYPE := coerce y
>
That is very much against the spirit of the SPAD language which was
This is great but I definitely do not like to read "wrap" ... "unwrap"
... in spad source code. Didn't you say that we were now "on the same
page" with "coerce" and "retract"?
Do you notice any differences in performance and space utilization?
On 27 September 2017 at 08:10, oldk1331 wrote:
> I h
:
> On Sun, Sep 24, 2017 at 9:50 AM, Bill Page wrote:
>> The meaning of 'empty' is more neutral than 'failed'. It is possible
>> to use Maybe in situations where an empty value does not imply
>> failure.
>
> As the docstring said (which I copied from Ha
7; operator?
maybe : (R -> R, %, R) -> R
++ maybe(f,x,default) returns f(unwrap x) or default if failed?(x)
then 'unwrapOr' could be just the two argument form of this function.
I attach a copy of my test version using a convenient but less
efficient representation.
Bil
On 18 September 2017 at 21:54, oldk1331 wrote:
> I would like to suggest again to use Maybe over Union("failed", ...):
> ...
+1
I strongly agree.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this gro
On 17 September 2017 at 16:34, Ralf Hemmecke wrote:
>
>> One might expect that 'subtract' never fails. I think we should choose
>> between 'subtractIf' or 'subtractCan'.
>
> Well, I still opt for "subtract" in connection with "canSubtract?" and
> "subtractIfCan".
>
+1
I might expect that 'x - y'
On 24 July 2017 at 01:12, oldk1331 wrote:
> Some random thoughts:
>
I suppose that you are comparing FriCAS to SageMath? My comments below
should not be taken as any sort of endorsement or advertisement but
rather points for comparison.
> 1. I can't find a changelog so I don't know what key
> fe
On Jul 21, 2017 8:25 PM, "oldk1331" wrote:
I have a different view for these "system commands", I want
to create a package where "normal functions" can act as
these "system commands" (through Lisp calls, I presume).
So that they can use variables, called by other functions,
and have comments.
On 14 July 2017 at 05:52, oldk1331 wrote:
> ...
> About license, I wish you could change your mind and move FriCAS
> forward... BTW, I doubt there are companies clever enough to fork
> FriCAS and profit from it (other than doing technic suport, which is
> good :-)
>
+1
--
You received this mess
I would especially like to thank Waldek for his continuous committment to
improving FriCAS over the last ten years and more recently the extensive
work by oldk1331.
Thankyou!
On Jul 6, 2017 8:34 PM, "oldk1331" wrote:
I use gitstats to generate a statistics of FriCAS repo,
the development seems
+1
On Jul 7, 2017 4:26 AM, "oldk1331" wrote:
> It gives error for more than 2 arguments:
>
> (1) -> paren([sin x, cos x])
>
>>> Error detected within library code:
>Wrong number of arguments
>
>
> Also, the behavior mentioned in the documentation,
> "atan(paren [x, 2])", doesn't make sen
On 5 June 2017 at 20:02, oldk1331 wrote:
> On Tue, Jun 6, 2017 at 2:09 AM, Bill Page wrote:
>> On 5 June 2017 at 05:58, oldk1331 wrote:
>>> Also, it seems that current pattern-matcher is very different from
>>> (weaker?) the Jenks&Sutor book, why is that?
On 5 June 2017 at 05:58, oldk1331 wrote:
> Also, it seems that current pattern-matcher is very different from
> (weaker?) the Jenks&Sutor book, why is that?
>
Can you give an example?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system
On 4 June 2017 at 06:18, oldk1331 wrote:
> See the recent post in sci.math.symbolic, "[Axiom] define a rule",
> also see src/input/fixed.input.
>
> (1) -> r:=rule(j*j==1)
>
> 2
>(1) j == 1
>Type: RewriteRule(Integer,Integer,Expression(Integer))
> (2) -> r 0
>
On 24 May 2017 at 13:34, Waldek Hebisch wrote:
> Bill Page wrote:
>> I am only looking for some 'groebnerFactorize' result for any
>> convenient term ordering. Still, by the documentation I am left
>> wondering just which polynomial domain I should use to get
On 22 May 2017 at 13:01, Waldek Hebisch wrote:
> Bill Page wrote:
>>
>> Just to confirm in FriCAS the 'totalGroebner' routine which apparently
>> uses degree reverse lexical ordering takes much less time:
>>
>> Time: 1718.35 (EV) + 0.53 (OT) =
Fraction(S) the S is something like PrimeField 7?
>
The interpreter says:
"Fraction(PrimeField(7)) is not a valid type."
but perhaps this could be built in SPAD.
> Has anyone a good use case for such a fractionGcd function
> other than just convenience?
>
I would like
On 20 May 2017 at 03:12, oldk1331 wrote:
> From docstring of rootSimp:
>
> rootSimp : F -> F
> ++ rootSimp(f) transforms every radical of the form
> ++ \spad{(a * b^(q*n+r))^(1/n)} appearing in f into
> ++ \spad{b^q * (a * b^r)^(1/n)}.
>
> Since rootSimp onl
On 16 May 2017 at 16:13, Waldek Hebisch wrote:
> ...
> One trick is to substitute integers for some parameters.
> After
>
> oV := OrderedVariableList([mp,mq,mr,yqp,yrp,yrq])
> evl := enumerate()$oV
> ideq2a := [map(c +-> eval(c, evl, [3, 5, 7, 9, 11, 13]), p) for p in ideq2];
>
> I was able to com
ial
type rather than 'Polynomial'?
On 15 May 2017 at 18:21, Ralf Hemmecke wrote:
> On 05/15/2017 07:30 PM, Bill Page wrote:
>> I think the factor of 1000 in the difference in the time required to
>> compute the Groebner basis suggests that Singular is probably
>>
On 14 May 2017 at 13:02, Waldek Hebisch wrote:
>
> There were several bugs, I have now commited fixes for all that
> I have found. I still could not finish the calculation, it
> takes a lot of time. But it run for several hours without
> finding new errors.
>
Thank you very much Waldek. I great
On 14 May 2017 at 17:34, Ralf Hemmecke wrote:
> Look at the docstrings in GcdDomain. I think, we can do better.
>
> gcd : (%, %) -> %
> ++ gcd(x, y) returns the greatest common divisor of x and y.
>
> lcm : (%, %) -> %
> ++ lcm(x, y) returns the least common mul
On 14 May 2017 at 17:07, Ralf Hemmecke wrote:
> On 05/14/2017 07:22 PM, Bill Page wrote:
>> Algebraically some choices are better than others. In particular it
>> seems desirable that
>>
>> Q := Fraction R
>> gcd(n,m) = retract gcd(n::Q, m::Q)
>>
On 14 May 2017 at 09:25, Ralf Hemmecke wrote:
> On 05/13/2017 07:13 PM, Bill Page wrote:
>> By default Fraction always returns a gcd of 1.
>>
>> (1) -> gcd(1/3,1/4)
>>
>>(1) 1
>> Type: Fract
By default Fraction always returns a gcd of 1.
(1) -> gcd(1/3,1/4)
(1) 1
Type: Fraction(Integer)
But gcd is well defined provided that the underlying domain has GcdDomain.
diff --git a/src/algebra/fraction.spad b/src/algebra/fraction.spa
On 11 May 2017 at 08:16, Waldek Hebisch wrote:
> Bill Page wrote:
>>
>> http://axiom-wiki.newsynthesis.org/SandBoxBugGroebnerFactorize
>>
>> A simple example of Groebner factorization works:
>
>> But the following moderately complex problem fails:
>
>
http://axiom-wiki.newsynthesis.org/SandBoxBugGroebnerFactorize
A simple example of Groebner factorization works:
--
ideq1:LIST(POLY(FRAC(SMP(INT,OVAR([mp,mq,yqp]) := [ _
(yqp^2*mq^2*mp*%x3+yqp^2*mq*mp*%x1)*%x4+(yqp^2*mq*mp*%x1*%x3+(mp*%x1^2+(-1)*%x1)),
_
(yqp^2*mq*mp^2*%x3+yqp^2*mq*mp*
On 23 April 2017 at 23:25, oldk1331 wrote:
>
> Anyway, the function that transforms an OutputForm into
> printing should not transform '(* (- 1) (- 2))' into '2'.
>
+1
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsu
On 23 April 2017 at 19:35, oldk1331 wrote:
> On Sun, Apr 23, 2017 at 8:46 PM, Bill Page wrote:
>> Did you look at 'eval' operators in ExpressionSpace?
>
> Yes, my first post deals with 'eval' from ExpressionSpace,
> that there are symbol version and op
Did you look at 'eval' operators in ExpressionSpace?
On 22 April 2017 at 22:27, oldk1331 wrote:
> I saw an old thread that essentially has the same problem with
> this one:
>
> 12 Jan 2012, Bug: cos ~= cos?
>
> Ralf wrote:
>
> (1) -> s := operator 'sin
>
> (1) sin
>
Complete examples would make this a lot easier.
The following works for me:
https://cloud.sagemath.com/projects/87b42925-de3b-482c-99b2-edf1e1ba8bfb/files/test.as
It seems like 'mod' is a reserved word. I just changed it to 'modr'.
Bill.
On 22 April 2017 at 20:58, Doug Telford wrote:
>
> rega
On 22 April 2017 at 18:06, Doug Telford wrote:
> Using #include "axiom.as" instead of #include "aldor" cleared up a lot of
> the problems in my first post. However I have been unable to successfully
> substitute #include "axiom.as" for #include "aldor" in the following
> program , which runs ok
On 21 April 2017 at 19:58, Doug Telford wrote:
> #include "aldor"
Use
#include "axiom.as"
--
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
isprime: OneDimensionalArray Boolean
is an array of Boolean values.
isprime i := false
assigns the i'th element of this array to 'false'.
On 21 April 2017 at 19:12, Doug Telford wrote:
>
> also, the sieve function uses isprime, which is not a FriCAS function.
> Where does it find this f
The following might provide some useful information and examples
http://axiom-wiki.newsynthesis.org/Aldor
(: with the usual caveats concerning the quality of a
community-managed wiki: comments and updates appreciated :).
On 21 April 2017 at 15:04, Doug Telford wrote:
> I built fricas with sbc
On 19 April 2017 at 22:31, oldk1331 wrote:
> ... why not rename 'T' to 'top' and '_|_' to 'bottom'?
> (maybe add unicode 22A4/22A5 ⊤/⊥ as abbreviation)
>
+1 FriCAS should treat use of unicode more seriously.
--
You received this message because you are subscribed to the Google Groups
"FriCAS
t to do that in the face of the issues you mention is still very
much a research problem. As I said in my previous email it seems to me
that taking an "equational logic" point of view is most appropriate
where the underlying issues can be expressed algebraically.
Bill Page.
--
You receive
I think this is a good idea. We previously discussed:
https://groups.google.com/d/msg/fricas-devel/kQTJH9NY9WY/cUhhb4MLBAAJ
On 15 April 2017 at 06:54, oldk1331 wrote:
>> I think this interpreter signature resolution has defect:
>> it should prefer the signature that has the form '(%,%)->%'.
>
>
Maybe you intended
(12) -> sx_test:=series(x,x=0)*s_test
(12)
22 33 44 55 66 77 88 99 1010 11
x + a x + a x + a x + a x + a x + a x + a x + a x + a x + a x
+
12
O(x )
Type: UnivariatePuiseux
On 14 April 2017 at 09:28, Bill Page wrote:
> On 13 April 2017 at 22:19, oldk1331 wrote:
>> I think the setProperty/property from BasicOperator
>> can be useful in such situation, e.g. attach a 'positive'
>> property to a constant (nullary operator) 'x',
On 13 April 2017 at 22:19, oldk1331 wrote:
> Bill, just an early thought:
>
> I think the setProperty/property from BasicOperator
> can be useful in such situation, e.g. attach a 'positive'
> property to a constant (nullary operator) 'x', then
> for example 'x>0' can return ture (well, there's no
On 12 April 2017 at 13:12, Raymond wrote:
> For instance after
> n : PI
> we get.
>
> (9) -> if (n>-3) then true else false
>
>n is declared as being in PositiveInteger but has not been given a
> value.
>
> This was also mentioned in:
> http://axiom-wiki.newsynthesis.org/DefiniteIntegra
There are imperative-style alternatives to rule-based pattern
matching. Here is a nonsensical example illustrating some relevant
operations:
(1) -> isPlus(binomial(a,b)+binomial(b,c))
ba
(1) [( ), ( )]
cb
Type: Union(List(Expressi
, sman, and the FriCAS main image does not
seem to be very robust. The symbolic-expressions branch does add a
relatively large number of new domains and categories (about 20).
Perhaps that is enough to cause an overflow in hyperdoc not directly
related to view3d.
On 12 April 2017 at 08:17, Bill Page
Thanks. I definitely did not make any deliberate changes to graphics
or lib. If I understand correctly this is just C programming and the
problem apparently happens during the compilation of this code. Or
perhaps while linking this code with the Lisp image? But something is
strange or wrong about t
On 11 April 2017 at 08:42, oldk1331 wrote:
> Hmm, I can't access to the travis log right now (network is slow?),
It is working OK for me (Eastern Canada).
> and you know that the travis log is very simple due to log size
> limit.
>
Yes, I understand. I think the way you have filtered it is OK.
Thank you. I am using this script and your .travis.yml on my current
development branch.
I did notice one peculiarity. I can build the FriCAS main branch OK,
but my development branch failed:
https://travis-ci.org/billpage/fricas/builds/220150793
with an buffer overflow when building
/home/trav
This doesn't have much to do with macro expansions.
There is something very important about the application of rules to
expressions: This is a continuing rewriting process that continues
until the rule (or set of rules) can no longer be applied (fixed
point). So it is very easy to create infinite
same system. Most people are more
than willing to discuss their hard won knowledge even if they never
seem strongly motivated to just write it down in the form of useable
documentation. Questions and comments in a shared email list/group
such as your are critical to extracting that information
101 - 200 of 1443 matches
Mail list logo
