2009/1/21 Waldek Hebisch
>
> Liu Xiaojun wrote:
> > Hi,
> >
> >It makes compilation step forward significantly, thanks again :).
> > But still has an error. I use ecl 8.12.0 (compiled from source), latest
> > fricas fetched from svn, (498 or so, I'm not sure), since *features*
> > does not sh
I have now tried testintegrate on Schaum set. I needed the following
version:
res : Union(Expression Integer, List Expression Integer)
ri0 : Expression Integer := exp(17)
testIntegrate(f: String, x: String, issue: String): Void ==
free ri0
testcaseNoClear("integrate(" f ", " x ") (" iss
On Wed, Jan 21, 2009 at 7:51 PM, Waldek Hebisch wrote:
>
> I think this is very good change _if_ we want to use InputForm
> + unparse to get linear output for humans. But if we want
> to preserve semantics, then it is not good.
That is an important issue: What do we really want InputForm (and
un
Martin Rubey wrote:
>
> How about the patches to have drawing of badly behaved functions work on sbcl?
>
> (actually, I see that I have two slightly differing sets of patches on my
> computer now, I'm attaching the more plausible one)
>
A I wrote, I feel that this patch just hides errors. We
Bill Page wroteL
>
> Here is another somewhat simpler and more general way to simplify the
> generated InputForm which contain complex constants:
>
> wsp...@virtual-debian:~/fricas-src/trunk$ svn diff
> Index: src/algebra/mkfunc.spad.pamphlet
> ===
Martin Rubey wrote:
>
> I just remembered that POLYLIFT got its arguments backwards:
>
> PolynomialCategoryLifting(E,Vars,R,P,S): Exports == Implementation where
>
What you propose: PolynomialCategoryLifting(R, E, Vars, P, S)?
> apart from this one, we have two conventions:
>
> 1) Ring fir
Martin Rubey wrote:
>
> I noticed the following today:
>
> (1) -> f(c:DFLOAT):DFLOAT == (for i in 1..100 repeat c^(2::PI); c)
> (2) -> g(c:DFLOAT):DFLOAT == (for i in 1..100 repeat c^(2::INT); c)
> (3) -> h(c:DFLOAT):DFLOAT == (for i in 1..100 repeat c*c; c)
>
> This is with clisp:
Martin,
Are you sure of that, usually, computations involving SBCL are speeder
than CLISP. I can not reproduce them.
Greg
Le mercredi 21 janvier 2009 à 18:33 +0100, Martin Rubey a écrit :
>
> I noticed the following today:
>
> (1) -> f(c:DFLOAT):DFLOAT == (for i in 1..100 repeat c^(2::PI)
Martin Rubey wrote:
>
> I just noticed that the emacs mode doesn't seem to like clisp together with
> ssh
> and with or without X.
>
> It behaves "one step late", i.e.,
>
> 1 yield nothing
> "a" yields 1
> 2 yields "a"
>
> and so on.
>
> Anybody noticed this already? I have no id
Martin Rubey writes:
> I just noticed that the emacs mode doesn't seem to like clisp together with
> ssh
> and with or without X.
>
> It behaves "one step late", i.e.,
>
> 1 yield nothing
> "a" yields 1
> 2 yields "a"
>
> and so on.
>
> Anybody noticed this already? I have no id
I just noticed that the emacs mode doesn't seem to like clisp together with ssh
and with or without X.
It behaves "one step late", i.e.,
1 yield nothing
"a" yields 1
2 yields "a"
and so on.
Anybody noticed this already? I have no idea how to fix this so far.
Martin
--~--~--
I noticed the following today:
(1) -> f(c:DFLOAT):DFLOAT == (for i in 1..100 repeat c^(2::PI); c)
(2) -> g(c:DFLOAT):DFLOAT == (for i in 1..100 repeat c^(2::INT); c)
(3) -> h(c:DFLOAT):DFLOAT == (for i in 1..100 repeat c*c; c)
This is with clisp:
(the timings are on different machin
Liu Xiaojun wrote:
> Hi,
>
>It makes compilation step forward significantly, thanks again :).
> But still has an error. I use ecl 8.12.0 (compiled from source), latest
> fricas fetched from svn, (498 or so, I'm not sure), since *features*
> does not show :unix, I applied the patch, and confi
On Wed, Jan 21, 2009 at 2:51 AM, Martin Rubey wrote:
>
> Bill Page writes:
>
>> Here is another somewhat simpler and more general way to simplify
>> the generated InputForm which contain complex constants:
>
> *If* we want this, we should do it in COMPCAT, I think. But I'm not
> sure whether we wa
Martin Rubey writes:
> I guess it's to late before the release, isn't it? I think that it's slightly
> better to have the Ring last, but I'm not sure.
>
> Any votes?
Ups, I forgot about the power series. They have consistently the Ring first,
so I vote for that one. I.e.:
UnivariatePolynom
I just remembered that POLYLIFT got its arguments backwards:
PolynomialCategoryLifting(E,Vars,R,P,S): Exports == Implementation where
apart from this one, we have two conventions:
1) Ring first
PolynomialCategory(R:Ring, E:OrderedAbelianMonoidSup, VarSet:OrderedSet):
SparseMultivariatePolyno
16 matches
Mail list logo
