Re: [fricas-devel] difference between EXPR INT and EXPR Complex INT
ping? Am Montag, 4. November 2019 09:23:33 UTC+1 schrieb Martin R: > > Thank you! Unfortunately, I am still not clear on the difference. Is the > following correct: > > EXPR INT assumes real variables and functions, and EXPR Complex INT is a > hack? > > Martin > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/2d8fe0bf-f888-4fd7-8d2f-8db8b9645f49%40googlegroups.com.
Re: [fricas-devel] ARRAY2 enhanced
Am 11.11.19 um 22:53 schrieb Ralf Hemmecke: > On 11/4/19 11:24 PM, Prof. Dr. Johannes Grabmeier privat wrote: >> Hi all, >> I have enhanved TwoDimensionalArray to include arithmetic for block >> matrices and have an operation array2 (similar to matrix for Matrix) for >> easy creation of two-dimensional array and would suggest to include this >> into the next version: > I guess the background of this is relatively clear. FriCAS currently > forbids the creation of Matrix(Matrix Integer). > > (15) -> A := matrix([[A11, A12],[A21, A22]])$Matrix(Matrix Integer) > >Matrix(Matrix(Integer)) is not a valid type. > > You basically suggest to get around this problem, but extending > TwoDimensionalArray. > > What application do you have in mind? block matrices as in the example I gave. I am really using them, when I have to split a matrix in subblocks according to orbits of group operations. > > Why I would be against this extension is that TwoDimensionaArray is a > data structure domain, i.e., no algebraic operations. > > Your operations should live in an "algebraic" domain. But even then I > see problems, because + and * will be partial functions (much as in > Matrix(Matrix Integer) if it were possible). that is very subtle distinction, what should be an arithmetic domain, if it has a + and/or a *. Is /\ etc. also an arithmetic operation? Do you propagate a meta classification of domains, which - right now - only can be in the peoples mind, not in a valid FriCAS definition? Is the domain Matrix an algebraic domain with all its partial functions + and *? Your argument would had been valid against the creation of a domain Matrix as well. I do not care, if someone, rewrites/enhances Matrix to allow Matrix Matrix Integer e.g., I would be content, from the practical point, one simply should be able to use block matrices and sophisticated meta discussions should not hinder practical implementations. > > A good motivation for your extensions would help to consider them for > FriCAS. > > Ralf > -- Mit freundlichen Grüßen Johannes Grabmeier Fraktionsvorsitzender FREIE WÄHLER, Stadtrat Deggendorf Prof. Dr. Johannes Grabmeier Köckstraße 1, D-94469 Deggendorf Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756 Fax: +49-(0)-322-241-92688 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/2a2795ad-9251-93f5-d005-d93e040871aa%40grabmeier.net.
Re: [fricas-devel] Problem using record selectors
Paul Onions wrote: > > I have a problem with FriCAS 1.3.5 using records inside a function. > As an example consider the following code, where I define a record > type and simple constructor and accessor functions:- > > (1) -> R ==> Record(a:Integer, b:Integer) >Type: Void > (2) -> makeR(x:Integer, y:Integer):R == [x,y] >Function declaration makeR : (Integer, Integer) -> Record(a: Integer > ,b: Integer) has been added to workspace. >Type: Void > (3) -> getA(r:R):Integer == r.a >Function declaration getA : Record(a: Integer,b: Integer) -> Integer > has been added to workspace. >Type: Void > > I then create a record and call my accessor function on it to retrieve > one of its components. This works as expected. > > (4) -> r := makeR(2,3) >Compiling function makeR with type (Integer, Integer) -> Record(a: > Integer,b: Integer) > >(4) [a = 2, b = 3] > Type: Record(a: Integer,b: Integer) > (5) -> getA(r) >Compiling function getA with type Record(a: Integer,b: Integer) -> > Integer > >(5) 2 > Type: PositiveInteger > > Now I'll create a variable in the global workspace of the same name as > one of the selectors. This breaks things, but this is expected > because the selector name used in my accessor function is evaluated > (as described in the documentation). > > (6) -> a := 0 >Compiled code for getA has been cleared. > >(6) 0 > Type: NonNegativeInteger > (7) -> getA(r) >There are 29 exposed and 5 unexposed library operations named elt > having 2 argument(s) but none was determined to be applicable. > Use HyperDoc Browse, or issue >)display op elt > to learn more about the available operations. Perhaps > package-calling the operation or using coercions on the arguments > will allow you to apply the operation. >Cannot find a definition or applicable library operation named elt > with argument type(s) > Record(a: Integer,b: Integer) > NonNegativeInteger > <... snipped ...> > > So now I try to create a more robust accessor function to stop this > happening (following guidance in the documentation):- > So, is this a bug? And if so, is there a workaround? I do not think this is a bug. Rather a deliberate limitation. If you look deeper you will see consistent pattern: interpreter language misses features needed for "large scale" programming, instead tries to be somewhat forgiving for interactive use. On small scale it is not hard to avoid name clashes, and while interpreter makes some effort to limit clashes with library functions it misses features available in Spad. It would be nice to remove interpreter limitations, but given that iterpreter design is based on then, this is large task and prgress is slow. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/E1iUXes-00062b-42%40hera.math.uni.wroc.pl.
