Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

On 2 April 2017 at 22:40, oldk1331 wrote: > It's building at: > > https://travis-ci.org/oldk1331/fricas/builds/217926813 > > (BTW, travis is really easy to use.) > > I would estimate the build + test takes over 20 minutes. > I see about 25 minutes. Not too bad. Looks good.

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

It's building at: https://travis-ci.org/oldk1331/fricas/builds/217926813 (BTW, travis is really easy to use.) I would estimate the build + test takes over 20 minutes. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

> How long does it take on Travis-CI? Still trying. Currently the problem is that the log is too big, causes travis to abort early. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

How long does it take on Travis-CI? On 2 April 2017 at 20:38, oldk1331 wrote: >> What is the >> quickest and easiest way to setup a FriCAS build environment on >> Travis-CI? Is FriCAS build time too long to make this practical? Is >> there a way to do incremental builds,

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

> What is the > quickest and easiest way to setup a FriCAS build environment on > Travis-CI? Is FriCAS build time too long to make this practical? Is > there a way to do incremental builds, i.e. starting from a previously > compiled and saved version of the development environment? I think

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

On 1 April 2017 at 22:02, oldk1331 wrote: >> I would be happy to participate in >> adding FriCAS as a "community supported language" in Travis if anyone >> else is interested. > > Bill, I think the "community supported language" means that it'll be easier > for other Spad

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

> I would be happy to participate in > adding FriCAS as a "community supported language" in Travis if anyone > else is interested. Bill, I think the "community supported language" means that it'll be easier for other Spad project, while there's not much Spad project, I think that is unnecessary.

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

On 1 April 2017 at 10:46, Martin Baker wrote: > 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

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

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

On 31 March 2017 at 14:00, Waldek Hebisch wrote: > > Concerning coverage, it is hard to say how good it is. If > you mean coverage as percentage of lines of code that > are actually executed during tests I think it is much > higher than 10%, but lower than 100% even if

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

oldk1331 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. > > There are virtues of FriCAS's "conservatism." At least the commit history > is clean. I agree that test

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

> Yes. Do you have a plan? I think the difficulty is quite deep. The > resistance to these abstractions seems to be based on a difference of > principle rather than technical difficulty. Challenging these > principles is much harder than just providing a patch and showing that > it works. A

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

On 31 March 2017 at 08:02, oldk1331 wrote: >> Do you consider this an argument for inclusion of this domain in >> FriCAS?. I am also very much in favor of including Pair in FriCAS but >> OpenAxiom also includes rep, per, Maybe, forall, introspection and >> other language

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

On 30 March 2017 at 07:57, oldk1331 wrote: > Hmm, looks like OpenAxiom has already implemented Pair in 2008: > > https://github.com/GabrielDosReis/open-axiom/blob/master/src/algebra/mkrecord.spad.pamphlet > Do you consider this an argument for inclusion of this domain in

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

I will temporarily give up my efforts to remove TBAGG from ALAGG. Now about Pair, I have 2 reasons for it: 1. It's easier to construct ALIST. Instead of [1,"1"]::Record(key:INT, entry:STRING) we can use pair(1,"1"). 2. It allows proper '=' defined in ALAGG. Record is a hack, it claims to have

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

> As first approximation to handling scope you would have stack of > hashtables. > Key is irrelevant to the problem, but typically it is String. String is not much information. Identifier would be better. I guess the scope stores (idenifier, value) pairs where the value type contains all the

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

Ralf Hemmecke wrote: > > On 03/28/2017 06:45 AM, Waldek Hebisch wrote: > > To be more explicit about usefulness: suppose that you need > > a lot of very similar tables. More precisely, imagine a > > compiler with scopes. For each scope you want to find > > closest definition. I mean, I want a

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

oldk1331 wrote: > > > I understand desire to have "fool proof" data structures. > > However, attemps to make very safe data structures typically > > either reduce functionality or efficiency. > > I'm doing so not for "safe", but for "correctness". > > > With current implementation scenarios

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

On 03/28/2017 06:45 AM, Waldek Hebisch wrote: > To be more explicit about usefulness: suppose that you need > a lot of very similar tables. More precisely, imagine a > compiler with scopes. For each scope you want to find > closest definition. I mean, I want a table for each scope. > Using

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

> I understand desire to have "fool proof" data structures. > However, attemps to make very safe data structures typically > either reduce functionality or efficiency. I'm doing so not for "safe", but for "correctness". > With current implementation scenarios like above works OK. > And other

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

oldk1331 wrote: > > One more argument: > > Like there are SetAgg/MultisetAgg, Dictionary/MultiDictionary, > if you insist that AlistAgg is "table like", fine, but AlistAgg is > not TableAgg, maybe "MultiTableAgg". That would be different thing, you would have change implementation and

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

oldk1331 wrote: > > TBAGG is KeyedDictionary is Dictionary: > ++ A dictionary is an aggregate in which entries can be inserted, > ++ searched for and removed. Duplicates are thrown away on insertion. > > So ALAGG doens't satisfies requirement of this structure. Note "on insertion". So

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

> This patch for me looks as step back. First, proposed Pair > is largely redundant. In practice Record serves well the > same purpose. In fact, unlike proposed Pair records have > user setable fields names instead of meaningless 'first' and > 'second' so Record from user point of view is

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

oldk1331 wrote: > > > (This an early version patch, many things are still lacking.) > > I want to do some big changes, this patch is a proof of concept: > > 1. Introduce a new domain Pair, as an abstraction over Record > with 2 fields. > > 2. Introduce Pair to AlistAgg. (and TableAgg, not

Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

On 03/27/2017 01:03 PM, oldk1331 wrote: > +pair(x, y) == [x, y] If I were a compiler, I would not see a specification for x and y, so I take the freedom to create a local function pair(x: Integer, y: Integer): List Integer == [x, y] and leave the signature pair: (A, B) -> %

[fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

(This an early version patch, many things are still lacking.) I want to do some big changes, this patch is a proof of concept: 1. Introduce a new domain Pair, as an abstraction over Record with 2 fields. 2. Introduce Pair to AlistAgg. (and TableAgg, not done in this patch.) 3. Remove TableAgg