Re: Re: [fricas-devel] unique Value of Void
On Sat, Jun 30, 2018 at 11:30 AM, Waldek Hebisch wrote: > Bill Page wrote: >> > >> > Well, advantage is consistency with rules. >> > >> >> Could you site specifically what rule is being violated? > > The one that Ricardo was asking about: that 'if' always works, > but for one armed 'if' you get Void as a type. > >> ... >> In fact the Spad compiler does not always do what I had hoped. For >> example compiling the following function using Spad: >> >> f(x:Integer):PositiveInteger == if x<1 then 1 >> >> -- >> >> (1) -> f(0) >> >>(1) 1 >> Type: PositiveInteger >> (2) -> f(1) >>Internal Error >>Interpreter code generation failed for expression(|f| 1) > > The message looks fishy. Do you really used _Spad_ function here? Yes, here is the exact code that I compiled: -- file: one-armed.spad )abbrev domain TEST Test Test(): with test1: ()->Integer test2: ()->Void f:Integer -> PositiveInteger g:Integer -> PositiveInteger h:Integer -> PositiveInteger == add z:Integer := 1 test1() == A := if z<2 then 1 return A test2() == B := if 2<1 then 1 return B f(x:Integer):PositiveInteger == if x<1 then 1 g(x:Integer):PositiveInteger == coerce((if x<1 then 1 else void()$Void)::Union(Void,PositiveInteger)) h(x:Integer):PositiveInteger == g(x)+1 -- This is the result: (1) -> )co one-armed Compiling FriCAS source code from file /home/wspage/one-armed.spad using old system compiler. TEST abbreviates domain Test ... Test is now explicitly exposed in frame frame1 Test will be automatically loaded when needed from /home/wspage/TEST.NRLIB/TEST (1) -> f(0) (1) 1 Type: PositiveInteger (2) -> f(1) Internal Error Interpreter code generation failed for expression(|f| 1) (2) -> g(0) (2) 1 Type: PositiveInteger (3) -> g(1) >> Error detected within library code: "()" of mode Union(Void,PositiveInteger) cannot be coerced to mode PositiveInteger (3) -> h(0) (3) 2 Type: PositiveInteger (4) -> h(1) >> Error detected within library code: "()" of mode Union(Void,PositiveInteger) cannot be coerced to mode PositiveInteger (4) -> > The message looks like coming from interpreter and given > Spad function of correct type interpreter should just blindly > call it. > Yes, I thought so too. -- 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 fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] New domains FiniteSet / OneToN
Just quick remark: in similar situations I used a helper package, like: )abbrev package OTNHELP OneToNHelper OneToNHelper : with mklist : PositiveInteger -> List(PositiveInteger) == add mklist(n) == [i :: PositiveInteger for i in 1..n]$List(PositiveInteger) Than in OneToN: private ==> FiniteSet(PositiveInteger, mklist(n)$OneToNHelper) add This seems to work around the problem. -- Waldek Hebisch -- 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 fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: [fricas-devel] unique Value of Void
Bill Page wrote: > > On Sat, Jun 30, 2018 at 9:40 AM, Waldek Hebisch > wrote: > >> > >> On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch > >> wrote: > >> > On command line interpreter evaluates things so can use actual > >> > values to guess what would be useful. > >> > > Bill Page wrote: > >> Yes, one should expect that the interpreter would try harder to > >> guess reasonable types in order to relieve the user of (some) > >> of this responsibility. > >> > > In command line expression interpreter can use values. > > Sometime you get message that compilation failed, and > > that function will be interpreted. In such case interpreter > > uses similar rules as on command line. However, for serious > > computation such cases should be avoided because assigning > > types takes quite a lot of time. In compiled functions this is > > done once per type, when interpreting type assignment is > > re-done on every execution of a statement. > > > > Yes. There is a system command: > > )set function compile off/on (on by default) > > which is described as > > compile compile, don't just define function bodies > > but when I set function compile off, I still got the following result: > > (1) -> )set function compile off > (1) -> f2(x : Integer) : Integer == if (x > 1) then 1 >Function declaration f2 : Integer -> Integer has been added to > workspace. >Type: Void > (2) -> f2(2) >Compiling function f2 with type Integer -> Integer >Conversion failed in the compiled user function f2 . > >Cannot convert the value from type Void to Integer . > > -- > > Does this option still work? Perhaps my expectation was wrong. "Compile" have many meanings. The option concerns _Lisp_ compilation. I wrote about higher level, where compilation assentially means type assignment. AFAIK intepreter always tries to compile that is perform types assignment. Only when it fails function is interpteted (and this is lot slower then executiong function compilered by interpteter to Lisp and intepreted by Lisp implementation). > >> ... > >> I cannot see any advantage in having this behavior in the > >> interpreter. > > > > Well, advantage is consistency with rules. > > > > Could you site specifically what rule is being violated? The one that Ricardo was asking about: that 'if' always works, but for one armed 'if' you get Void as a type. > > >> I think the interpreter should be changed to do the same > >> thing as the Spad compiler. The function should attempt to coerce > >> the result of the if-then expression > >> > >> if (x > 1) then 1 > >> > >> to Integer. Of course this might cause an error for certain values > >> of x but the user is not likely to be surprised by this. > > > > Well, there are folks that want static checking, that is no type > > errors at runtime. They prefer Void as a result type. And > > there are folks who want to bend the rules. IMO some sloppines > > on command line is OK. But already for "interpreter" functions > > stricter type rules may be beneficial. > > > > Of course, having more relaxed rule in Spad compiler and stricter > > rule in intepreter is counterintuitive. The only explanation I > > see is that original authors decided to change rules. Remember > > that Spad is "old compiler" and compiler included in intepreter > > is "new compiler". > > > > In fact the Spad compiler does not always do what I had hoped. For > example compiling the following function using Spad: > > f(x:Integer):PositiveInteger == if x<1 then 1 > > -- > > (1) -> f(0) > >(1) 1 > Type: PositiveInteger > (2) -> f(1) >Internal Error >Interpreter code generation failed for expression(|f| 1) The message looks fishy. Do you really used _Spad_ function here? The message looks like coming from interpreter and given Spad function of correct type interpreter should just blindly call it. > -- > > This is a rather unexpected and obscure errror message. -- Waldek Hebisch -- 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 fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[fricas-devel] New domains FiniteSet / OneToN
Hi all,
since long I have a domain which respresents the elements of a list as a
elements of the domain: FiniteSet(S, List S) and a special case OneToN =
{1,2,3,...,n}.
Two problems:
1. < of PartialOrder does not work properly. Note, that the order of the
elements in the finite set is the given order in the list.
2. OneToN: my attempts to make it as comfortable for the user by using
as underlying domain PositiveInteger gives an error message:
(14) -> enumerate()$Q10
>> System error:
The value
#:G2267
is not of type
LIST
Using Integer instead gives confusion for coercing from positive
integers to OneToN by missing retractIfCan, but could not be identified,
what the system means.
Is the list argument ln a problem?
If the problems can be fixed, the domains could go into the system.
-- Here is an example computation:
FS4 := FiniteSet(Integer, [2,1,3,4])
(1) FiniteSet(Integer,[2,1,3,4])
Type: Type
eFS4 := enumerate()$FS4
(2) [2, 1, 3, 4]
Type:
List(FiniteSet(Integer,[2,1,3,4]))
a : FS4 := first eFS4
(3) 2
Type:
FiniteSet(Integer,[2,1,3,4])
b : FS4 := second eFS4
(4) 1
Type:
FiniteSet(Integer,[2,1,3,4])
a <= b
(5) true
Type: Boolean
b <= a
(6) false
Type: Boolean
a < b
(7) false
Type: Boolean
"in the interpreter this is true, in accordance with the implementation
of <= in the domain!"
(8) "in the interpreter this is true, in accordance with the
implementation of <= in the domain!"
Type: String
(a <= b) and not(b <= a)
(9) true
Type: Boolean
Q10 := OneToN 10
(10) OneToN(10)
Type: Type
enumerate()$Q10
>> System error:
The value
#:G2456
is not of type
LIST
--
Mit freundlichen Grüßen
Johannes Grabmeier
Prof. Dr. Johannes Grabmeier
Köckstraße 1, D-94469 Deggendorf
Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756
Tel. +49-(0)-991-3615-141 (d), Fax: +49-(0)-32224-192688
--
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 fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
)co finiteSet
FS4 := FiniteSet(Integer, [2,1,3,4])
eFS4 := enumerate()$FS4
a : FS4 := first eFS4
b : FS4 := second eFS4
a <= b
b <= a
a < b
"in the interpreter this is true, in accordance with the implementation of <=
in the domain!"
(a <= b) and not(b <= a)
Q10 := OneToN 10
enumerate()$Q10
)abbrev domain FINSET FiniteSet
)abbrev domain OTN OneToN
++ Authors: Johannes Grabmeier
++ Date Created: 2010-08-29
++ Date Last Updated:
++ 2018-06-29 JG
++ 2014-01-03 JG
++ Basic Operations:
++ Related Constructors: Finite, SetCategory
++ Also See:
++ AMS Classifications:
++ Keywords:
++ Reference:
++ Description: FiniteSet(S: SetCategory, lS: List S) represents the domain of
++ the elements of the given list. The ordering in lS defines the total order
++ on %. Note, that multiple entries in lS are removed.
FiniteSet(S: SetCategory, lS: List S): public == private where
public ==> Join(SetCategory, Finite, StepThrough,
OrderedFinite, RetractableFrom S, CoercibleFrom S)--, RetractableTo S)
private ==> S add
-- representation of the object:
Rep := S
rep(s : %) : Rep == s @ Rep
per(rp : Rep) : % == rp @ %
-- import of domains and packages
import OutputForm
-- local variables
lS := removeDuplicates! lS
n : NonNegativeInteger := #lS
Re: Re: [fricas-devel] unique Value of Void
On Sat, Jun 30, 2018 at 9:40 AM, Waldek Hebisch wrote: >> >> On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch >> wrote: >> > On command line interpreter evaluates things so can use actual >> > values to guess what would be useful. >> > Bill Page wrote: >> Yes, one should expect that the interpreter would try harder to >> guess reasonable types in order to relieve the user of (some) >> of this responsibility. >> >> > In the process it breaks several normal rules. >> > >> > Try: >> > >> > f(x) == if (x > 1) then 1 >> >Type: >> > Void >> > Time: 0 >> > sec >> > (7) -> f(2) >> >Compiling function f with type PositiveInteger -> Void >> >Type: >> > Void >> >Time: 0.02 (OT) = 0.02 >> > sec >> > (8) -> f(0) >> >Compiling function f with type NonNegativeInteger -> Void >> >Type: >> > Void >> >Time: 0.01 (OT) = 0.01 >> > sec >> > >> > In both cases you now get Void. >> >> Clearly this is a very poor (though technically correct) guess as >> to what the user might have wanted. > > Maybe I should say more: compiling a function interpreter can > _not_ use value, the function has to work for any value of > argument, so in compiled function interpreter has to obey rules. OK. I understand the distinction. > In command line expression interpreter can use values. > Sometime you get message that compilation failed, and > that function will be interpreted. In such case interpreter > uses similar rules as on command line. However, for serious > computation such cases should be avoided because assigning > types takes quite a lot of time. In compiled functions this is > done once per type, when interpreting type assignment is > re-done on every execution of a statement. > Yes. There is a system command: )set function compile off/on (on by default) which is described as compile compile, don't just define function bodies but when I set function compile off, I still got the following result: (1) -> )set function compile off (1) -> f2(x : Integer) : Integer == if (x > 1) then 1 Function declaration f2 : Integer -> Integer has been added to workspace. Type: Void (2) -> f2(2) Compiling function f2 with type Integer -> Integer Conversion failed in the compiled user function f2 . Cannot convert the value from type Void to Integer . -- Does this option still work? Perhaps my expectation was wrong. >> ... >> I cannot see any advantage in having this behavior in the >> interpreter. > > Well, advantage is consistency with rules. > Could you site specifically what rule is being violated? >> I think the interpreter should be changed to do the same >> thing as the Spad compiler. The function should attempt to coerce >> the result of the if-then expression >> >> if (x > 1) then 1 >> >> to Integer. Of course this might cause an error for certain values >> of x but the user is not likely to be surprised by this. > > Well, there are folks that want static checking, that is no type > errors at runtime. They prefer Void as a result type. And > there are folks who want to bend the rules. IMO some sloppines > on command line is OK. But already for "interpreter" functions > stricter type rules may be beneficial. > > Of course, having more relaxed rule in Spad compiler and stricter > rule in intepreter is counterintuitive. The only explanation I > see is that original authors decided to change rules. Remember > that Spad is "old compiler" and compiler included in intepreter > is "new compiler". > In fact the Spad compiler does not always do what I had hoped. For example compiling the following function using Spad: f(x:Integer):PositiveInteger == if x<1 then 1 -- (1) -> f(0) (1) 1 Type: PositiveInteger (2) -> f(1) Internal Error Interpreter code generation failed for expression(|f| 1) -- This is a rather unexpected and obscure errror message. However it is possible to compile explicit code such as: g(x:Integer):PositiveInteger == coerce((if x<1 then 1 else void()$Void)::Union(Void,PositiveInteger)) -- 2) -> g(0) (2) 1 Type: PositiveInteger (3) -> g(1) >> Error detected within library code: "()" of mode Union(Void,PositiveInteger) cannot be coerced to mode PositiveInteger -- which does do what I had hoped, i.e. that the code generated for f would be essentially the same as g. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To
Re: Re: [fricas-devel] unique Value of Void
Bill Page wrote: > > On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch > wrote: > > Riccardo GUIDA wrote: > >> ... > >> 3) The user is puzzled because > > > > The command line is not representative of FriCAS language. > > In my opinion it should be (almost) representative of FriCAS language (SPAD). > > > On command line interpreter evaluates things so can use actual values > > to guess what would be useful. > > Yes, one should expect that the interpreter would try harder to guess > reasonable types in order to relieve the user of (some) of this > responsibility. > > > In the process it breaks several normal rules. > > > > Try: > > > > f(x) == if (x > 1) then 1 > >Type: > > Void > > Time: 0 > > sec > > (7) -> f(2) > >Compiling function f with type PositiveInteger -> Void > >Type: > > Void > >Time: 0.02 (OT) = 0.02 > > sec > > (8) -> f(0) > >Compiling function f with type NonNegativeInteger -> Void > >Type: > > Void > >Time: 0.01 (OT) = 0.01 > > sec > > > > In both cases you now get Void. > > Clearly this is a very poor (though technically correct) guess as to > what the user might have wanted. Maybe I should say more: compiling a function interpreter can _not_ use value, the function has to work for any value of argument, so in compiled function interpreter has to obey rules. In command line expression interpreter can use values. Sometime you get message that compilation failed, and that function will be interpreted. In such case interpreter uses similar rules as on command line. However, for serious computation such cases should be avoided because assigning types takes quite a lot of time. In compiled functions this is done once per type, when interpreting type assignment is re-done on every execution of a statement. > > Unlike Spad compiler trying to declare type does not change the result: > > > > (9) -> f2(x : Integer) : Integer == if (x > 1) then 1 > >Function declaration f2 : Integer -> Integer has been added to > > workspace. > >Type: > > Void > > Time: 0 > > sec > > (10) -> f2(2) > >Compiling function f2 with type Integer -> Integer > >Conversion failed in the compiled user function f2 . > > > >Cannot convert the value from type Void to Integer . > > > > (10) -> f2(0) > >Conversion failed in the compiled user function f2 . > > > >Cannot convert the value from type Void to Integer . > > > > I cannot see any advantage in having this behavior in the > interpreter. Well, advantage is consistency with rules. > I think the interpreter should be changed to do the same > thing as the Spad compiler. The function should attempt to coerce the > result of the if-then expression > > if (x > 1) then 1 > > to Integer. Of course this might cause an error for certain values of > x but the user is not likely to be surprised by this. Well, there are folks that want static checking, that is no type errors at runtime. They prefer Void as a result type. And there are folks who want to bend the rules. IMO some sloppines on command line is OK. But already for "interpreter" functions stricter type rules may be beneficial. Of course, having more relaxed rule in Spad compiler and stricter rule in intepreter is counterintuitive. The only explanation I see is that original authors decided to change rules. Remember that Spad is "old compiler" and compiler included in intepreter is "new compiler". -- Waldek Hebisch -- 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 fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
