Re: [fricas-devel] Maybe preview 2

FYI, Julia language is considering "representing missing data as Union{T, Null}" (which is like our Union("failed", ...)), so they want to rename "Nullable" (like our Maybe) to avoid confusion. https://github.com/JuliaLang/julia/issues/22682 A pull request is here to rename "Nullable":

Re: [fricas-devel] Maybe preview

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

Re: [fricas-devel] Maybe preview

On Sat, Oct 14, 2017 at 2:44 AM, Bill Page wrote: > I do not understand 'Boolean' as a category. The 'Boolean' domain > satisfies the following categories: 'OrderedSet', 'Finite', 'Logic'. > Thinking of Boolean as a category in the mathematical sense seems >

Re: [fricas-devel] Maybe preview

On 12 October 2017 at 22:02, oldk1331 wrote: >> Since the 'Rep' is 'List' and true in Lisp (and >> in SPAD) is anything that is not 'nil' > > No. Boolean in SPAD should be a 2-object category, > aka 'false' and 'true', represented by NIL and T. > I do not understand 'Boolean'

Re: [fricas-devel] Maybe preview 2

On Wed, Oct 11, 2017 at 4:08 AM, Ralf Hemmecke wrote: > So my wish would be > > Maybe(X): with > none: () -> % > none?: % -> Boolean > coerce: X -> % > value?: % -> X (not really sure) > retract: % -> X My argument is, can you use 'coerce' to generate Maybe in

Re: [fricas-devel] Maybe preview

On Tue, Oct 10, 2017 at 8:05 PM, Bill Page wrote: >>> I think probably that (NULL (NULL x)) is optimized by Lisp >>> (at least by SBCL). >> >> Yes, but at Spad level, (CONSP X) is inlined, while >> (NULL (NULL x)) is not inlined, which involves a ELT lookup >> and a

Re: [fricas-devel] Maybe preview 2

Sorry for being late... > none : () -> % > none? : % -> Boolean > just : R -> % > just? : % -> Boolean > adjust : % -> R In fact, I don't quite understand Qian's argument. Although I previously opted for "coerce" and "retract", I never said that I would like Maybe(X) to be of category

Re: [fricas-devel] Maybe preview 2

I suggest that you make a final decision and that we agree to stick with it. I would like to update and properly test my patches for 'recip' which currently use coerce/retract. Overloading does make editing function names in source code a little more work. We might already be at a greatest lower

Re: [fricas-devel] Maybe preview

oldk1331 wrote: > > About the "Maybe Maybe X" problem: > > Since Waldek gives the idea of using GENSYM() to mark failure, > I want to hear his opinion. Well, I had hope that GENSYM() will be free from problems with tags. Alas, as it turned out the problem (incompatiblity of Spad and Lisp

Re: [fricas-devel] Maybe preview

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 Union(X,"failed") > so much, but we can have Monad in FriCAS without

Re: [fricas-devel] Maybe preview 2

On 9 October 2017 at 06:28, oldk1331 wrote: > Bill, the functions of Maybe deserve their uniq name other than > generic coerce/retract/empty/construct. > > And it seems that there's no common idiom on naming: > > https://en.wikipedia.org/wiki/Option_type > Thanks. That

Re: [fricas-devel] Maybe preview

On 8 October 2017 at 20:39, oldk1331 wrote: > On Mon, Oct 9, 2017 at 4:09 AM, Ralf Hemmecke wrote: >> >> Relying on lisp as the target language is not a good idea. I'd rather >> like to be independent of such implementation details. >> > > First,

Re: [fricas-devel] Maybe preview 2

On 10/09/2017 12:36 PM, oldk1331 wrote: >> List(X): NIL or a pointer to a record r >> where r holds a value of type X and a NIL pointer >> Record(x: X): NIL or a pointer to a value of type X >> >> So the List version stores an unnecessary NIL pointer together with a >> heap

Re: [fricas-devel] Maybe preview 2

On Mon, Oct 9, 2017 at 3:52 PM, Ralf Hemmecke wrote: > On 10/09/2017 02:39 AM, oldk1331 wrote: >> Let "Partial" stands for the global GENSYM() solution and "Maybe" >> stands for the "Rep := List R" solution. >> Then we still need to pick a default: what should 'subtractIfCan'

Re: [fricas-devel] Maybe preview 2

Bill, the functions of Maybe deserve their uniq name other than generic coerce/retract/empty/construct. And it seems that there's no common idiom on naming: https://en.wikipedia.org/wiki/Option_type -- You received this message because you are subscribed to the Google Groups "FriCAS -

Re: [fricas-devel] Maybe preview 2

On 10/09/2017 02:39 AM, oldk1331 wrote: > Let "Partial" stands for the global GENSYM() solution and "Maybe" > stands for the "Rep := List R" solution. > Then we still need to pick a default: what should 'subtractIfCan' return? In fact, I would choose the one that works faster and has minimal

Re: [fricas-devel] Maybe preview 2

On 8 October 2017 at 20:39, oldk1331 wrote: > I have updated Maybe to use "Rep := List R" for future compatibility with > Monad. > > https://github.com/oldk1332/fricas/commits/maybe > > (the branch is rebased) > >

Re: [fricas-devel] Maybe preview

On Mon, Oct 9, 2017 at 4:09 AM, Ralf Hemmecke wrote: >>> We can have Maybe with a global failed(). >> >> But then Maybe would not be a Monad (at least in the since used in Haskell). > > Exactly. And that is why for this case I would be rather against the > name "Maybe". I'd

[fricas-devel] Maybe preview 2

I have updated Maybe to use "Rep := List R" for future compatibility with Monad. https://github.com/oldk1332/fricas/commits/maybe (the branch is rebased) https://github.com/oldk1332/fricas/commit/aa341bffbddc1e42896862aacb116180158e79cb Still, the naming problem persists. We only need to

Re: [fricas-devel] Maybe preview

On 8 October 2017 at 16:09, Ralf Hemmecke wrote: > ... > Exactly. And that is why for this case I would be rather against the > name "Maybe". I'd rather opt for "Partial" as in Aldor even though > AldorLib implements Partial via Record and is thus more similar to >

Re: [fricas-devel] Maybe preview

On 10/08/2017 07:40 PM, Bill Page wrote: > 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

Re: [fricas-devel] Maybe preview

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 Union(X,"failed") > so much,

Re: [fricas-devel] Maybe preview

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 Union(X,"failed") so much, but we can have Monad in FriCAS without changing the language. We can have Maybe

Re: [fricas-devel] Maybe preview

On Sat, Oct 7, 2017 at 4:53 PM, Martin Baker wrote: > On 07/10/17 00:59, oldk1331 wrote: >> Monad is practical in FriCAS. But just like this time, we couldn't agree >> on a lot of things. So instead of introducing Monad first, Maybe later; >> I think introducing Maybe

Re: [fricas-devel] Maybe preview

On 6 October 2017 at 11:40, Martin Baker wrote: > On 01/10/17 04:49, oldk1331 wrote: >> >> Again, I think this is a small problem, because >> 1. there's no point of using Maybe(Maybe(XXX)). > > I have not followed this thread closely so apologies if my thoughts here are > off

Re: [fricas-devel] Maybe preview

On 01/10/17 04:49, oldk1331 wrote: Again, I think this is a small problem, because 1. there's no point of using Maybe(Maybe(XXX)). I have not followed this thread closely so apologies if my thoughts here are off track. I get the impression that you now agree that monads are not currently

Re: [fricas-devel] Maybe preview

On 5 October 2017 at 20:34, oldk1331 wrote: > To Bill: > > 1. Benchmarking in interpreter is meaningless, I'm sure > you noticed that you can do 10^6 calls in interpreter in 4s > while do 2*10^8 calls in 0.4s in compiler. > Of course, but not completely meaningless to someone

Re: [fricas-devel] Maybe preview

To Bill: 1. Benchmarking in interpreter is meaningless, I'm sure you noticed that you can do 10^6 calls in interpreter in 4s while do 2*10^8 calls in 0.4s in compiler. 2. The FriCAS you are using should be built from my branch, to have the inline patch, so that functions from Maybe can be

Re: [fricas-devel] Maybe preview

To Ralf: yes, the failed()$Maybe is like NULL from C, a unique global special value to indicate failure. We make that clear in documentation, then there's no problem. After all, there's currently no usage of Union("failed", Union("failed", X)) in the code, and there's only one Rep use

Re: [fricas-devel] Maybe preview

On 4 October 2017 at 23:41, oldk1331 wrote: >> How does this compare to the cost of testing case "failed" in the old >> Union(R,"failed") representation? > > I did a crude benchmark on failed?, 200 loops over a vector with > 10^6 elements of failed(): > > 1. Union(NNI,

Re: [fricas-devel] Maybe preview

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 >>> is not

Re: [fricas-devel] Maybe preview

BTW, if X1 := Union(X,"failed") and X2 := Union(X1,"failed"), where in current FriCAS is it specified that failed$X1 is different from failed$X2? It probably is, but only by the general rule that no two domain have elements in common. Even not NNI and Integer. We need coerce/retract (or some

Re: [fricas-devel] Maybe preview

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 >> is not recommended, Maybe should not be used as Rep >> itself but can be part of

Re: [fricas-devel] Maybe preview

> How does this compare to the cost of testing case "failed" in the old > Union(R,"failed") representation? I did a crude benchmark on failed?, 200 loops over a vector with 10^6 elements of failed(): 1. Union(NNI, "failed") 0.40s 2. Maybe NNI, 0.38s 3. "generic" Maybe NNI, can't be inlined,

Re: [fricas-devel] Maybe preview

Here is the first version of my rewrite of function 'recip' using my proposal to make 'Maybe(R)' satisfy 'RetractableTo(R)' and using 'coerce/retract' insteal of 'warp/unwrap': https://github.com/billpage/my-fricas/compare/maybe...billpage:maybe-retract Contrary to the claim below, I did not

Re: [fricas-devel] Maybe preview

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

Re: [fricas-devel] Maybe preview

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 >> have a GENSYM() for each Maybe

Re: [fricas-devel] Maybe preview

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

Re: [fricas-devel] Maybe preview

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. I think current situation is a good compromise. We can say in documentation that all instances of Maybe share a

Re: [fricas-devel] Maybe preview

oldk1331 wrote: > > A small problem to think about: > > Maybe Maybe Integer > > Should 't1 := wrap(failed()$Maybe Integer)' equal to > 't2 := failed()$Maybe Maybe Integer' > > Logically speaking, 'failed?(t1)' is false because t1 is > a Maybe(Integer) valued being wrapped. And 'failed?(t2)' >

Re: [fricas-devel] Maybe preview

A small problem to think about: Maybe Maybe Integer Should 't1 := wrap(failed()$Maybe Integer)' equal to 't2 := failed()$Maybe Maybe Integer' Logically speaking, 'failed?(t1)' is false because t1 is a Maybe(Integer) valued being wrapped. And 'failed?(t2)' is true so they are not equal. Current

Re: [fricas-devel] Maybe preview

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'. >

Re: [fricas-devel] Maybe preview

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 using 'coerce/retract' is verbose and unreadable. -- You received this message because you are subscribed to the

Re: [fricas-devel] Maybe preview

On 29 September 2017 at 07:36, oldk1331 wrote: > Benchmarks: > > Memory usage: > I measured it with ')lisp (sb-ext:get-bytes-consed)' > > When storing 100K "failed" values in List, > Union(Integer, "failed") takes 3.2MB memory > Maybe Integer takes 1.6MB memory > > I think the

Re: [fricas-devel] Maybe preview

Benchmarks: Memory usage: I measured it with ')lisp (sb-ext:get-bytes-consed)' When storing 100K "failed" values in List, Union(Integer, "failed") takes 3.2MB memory Maybe Integer takes 1.6MB memory I think the "failed" is alloced as String multiple times. Also see the generated lisp code for

Re: [fricas-devel] Maybe preview

After some debugging, seems this is the cause: diff --git a/src/interp/nruncomp.boot b/src/interp/nruncomp.boot index 323080a1..cd7dbea6 100644 --- a/src/interp/nruncomp.boot +++ b/src/interp/nruncomp.boot @@ -137,7 +137,7 @@ optDeltaEntry(op,sig,dc,eltOrConst) == sig := substitute(devaluate

Re: [fricas-devel] Maybe preview

On 09/28/2017 04:53 AM, oldk1331 wrote: >>> specify type. Like you can use >>> >>>x := wrap y >>> >>> instead of >>> >>>x : Maybe A_VERY_LONG_TYPE := coerce y one usually writes x := y :: SOME_TYPE so I wouldn't be against y :: Maybe(T) even if T is A_VERY_LONG_TYPE. As Bill said,

Re: [fricas-devel] Maybe preview

On 09/28/2017 11:43 AM, oldk1331 wrote: > Hmm, seems the inline optimization only works for Package, > not Domain. Any hints? Sorry, I've no idea about these internals, but it somewhat surprises me. Packages and domains are not really different, as I see it. It's only that in domains there are

Re: [fricas-devel] Maybe preview

Hmm, seems the inline optimization only works for Package, not Domain. Any hints? -- 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

Re: [fricas-devel] Maybe preview

On Thu, Sep 28, 2017 at 10:26 AM, Bill Page wrote: > 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 >> >>

Re: [fricas-devel] Maybe preview

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

Re: [fricas-devel] Maybe preview

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 And you can use 'coerce' this way, but I prefer 'wrap', because usually there are many 'coerce' for a type, but there's only one

Re: [fricas-devel] Maybe preview

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

[fricas-devel] Maybe preview

I have fixed Maybe so that it can be inline optimized. You can see it here: https://github.com/oldk1332/fricas/commits/maybe https://github.com/oldk1332/fricas/commit/bc2b445305da41a74f16dd8b982f31e5582ac274.patch