Hi Waldek,
I can not reproduce the slowdown in the following example
after applying your patch. Did I miss something here?
On 8/24/21 8:48 PM, Waldek Hebisch wrote:
two times longer than current version. More visible
slowdown is on formal derivatives:
f := operator 'f
D(f(x), x, 655)
curren
On Thu, Aug 26, 2021 at 09:07:58AM -0400, Bill Page wrote:
> Waldek wrote:
>
> > It still uses order to find positions in kernel cache.
>
> Although order is at least to some extent arbitrary, it is still
> necessary for the ordering to be consistent during a session to
> satisfy category 'Compar
On Thu, Aug 26, 2021 at 05:21:56PM +0800, Qian Yun wrote:
> I did not give the patch a full test, but the logic in the patch
> looks very reasonable to me.
>
> About performance (50% slower?), do you think it is acceptable?
We need to do something. As I wrote, I noticed unsoundness of
kernel ord
Waldek wrote:
> It still uses order to find positions in kernel cache.
Although order is at least to some extent arbitrary, it is still
necessary for the ordering to be consistent during a session to
satisfy category 'Comparable'.
On Thu, Aug 26, 2021 at 5:22 AM Qian Yun wrote:
>
> Most time sp
I did not give the patch a full test, but the logic in the patch
looks very reasonable to me.
About performance (50% slower?), do you think it is acceptable?
Most time spent on Kernel should be in "linearSearch".
And since Kernel doesn't have order, I wonder if it is possible to
using some kind
It was already discussed that there is no consisent and reasonably
computable order on kernels. Example by Kurt Pagani from February
2 2017 shows that this may lead to user-visible troubles. Recently
Qian reported that this leads to bugs during integration.
Core of the problem is that due to fai
Bill Page
>
> On 20 March 2015 at 14:07, Waldek Hebisch wrote:
>
> Could you explain why the original data structure representation, i.e.
> a Record, could not be properly saved to/from files? Is this a
> general limitation for all SPAD data structures?
The point is that we need to run extra c
On 20 March 2015 at 14:07, Waldek Hebisch wrote:
> Bill Page wrote:
>>
>> On 19 March 2015 at 19:26, Waldek Hebisch wrote:
>> > Basically, kernels
>> > need special handling when saving/restoring them to/from files.
>> > Intput/output routines see only Lisp level representation of
>> > the data,
Bill Page wrote:
>
> On 19 March 2015 at 19:26, Waldek Hebisch wrote:
> > Bill Page wrote:
> >> ...
> >> Why not something more SPADish like:
> >>
> >> Rep == Record(position:NonNegativeInteger, op:OP, arg:List S)
> >
>
> Gee, my guess was almost what it used to be ...
>
> > That could be anw
On 19 March 2015 at 19:26, Waldek Hebisch wrote:
> Bill Page wrote:
>> ...
>> Why not something more SPADish like:
>>
>> Rep == Record(position:NonNegativeInteger, op:OP, arg:List S)
>
Gee, my guess was almost what it used to be ...
> That could be anwered looking at ChangeLog. Basically, ker
Bill Page wrote:
>
> Thanks for the detailed reply. I took a look at the code in kl.spad
> and I see here most of the details to which you refer. My first
> question after reading this is: Is there a good reason that the
> representation of the Kernel domain is so "lisp-ish"? E.g.
>
> ope
Waldek,
Thanks for the detailed reply. I took a look at the code in kl.spad
and I see here most of the details to which you refer. My first
question after reading this is: Is there a good reason that the
representation of the Kernel domain is so "lisp-ish"? E.g.
operator(k : %) : OP == SP
Bill Page wrote:
>
> Waldek,
>
> Since this apparently came up again in another situation (your reply
> to my recent email), I thought I would try again to more carefully
> understand the problem you describe. I've highlighted some of your
> original email by marking them a), b) etc. below.
>
>
Waldek,
Since this apparently came up again in another situation (your reply
to my recent email), I thought I would try again to more carefully
understand the problem you describe. I've highlighted some of your
original email by marking them a), b) etc. below.
On 10 May 2014 at 08:40, Waldek Heb
>> If tests give wrong result just because of )clear all vs. )clear
>> completely, then time is not an argument. Correctness is.
>
> Well, goal of tests is to find errors.
Well, yes, of course.
> If test fails because ')clear all' does not work correctly, then test
> did its job: it found error
Ralf Hemmecke wrote:
>
> On 05/10/2014 03:28 PM, Waldek Hebisch wrote:
> >> I always use )clear completely.
>
> Same for me.
>
> >> Is there a good reason to provide "weaker"
> >> alternatives such as )clear all ?
>
> )clear completely would probably also reset something like
>
> )set stream
On 05/10/2014 03:28 PM, Waldek Hebisch wrote:
>> I always use )clear completely.
Same for me.
>> Is there a good reason to provide "weaker"
>> alternatives such as )clear all ?
I inserted )clear completely after each section in the book, but ran
into problems because that also removes some )set'
Bill Page wrote:
>
> I always use )clear completely. Is there a good reason to provide "weaker"
> alternatives such as )clear all ?
>
1) Speed: ')clear completely' forces reinitialization all domains
and this takes some time. In interactive use it is probably
below human perception level
I always use )clear completely. Is there a good reason to provide "weaker"
alternatives such as )clear all ?
--
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, s
We can get wrong results after ')clear all'. One example
in Issue 119 in the wiki. AFAICS the problem is due to
implementation of kernels. Namely, we keep kernels in
a cache. We impose somewhat arbitrary order and use binary
search to find a kernel. More precisely, when we create
a kernel w lo
20 matches
Mail list logo
