reduce-algebra-developers — Discussion of development, administration and support for Reduce

You can subscribe to this list here.

 2009 2010 2011 2012 2013 2014 Jan (2) Feb (5) Mar Apr May (2) Jun (8) Jul (4) Aug Sep Oct (2) Nov (6) Dec Jan (1) Feb (1) Mar (3) Apr (2) May (2) Jun (2) Jul (18) Aug (13) Sep (7) Oct Nov Dec (2) Jan Feb (11) Mar Apr (4) May Jun (1) Jul (18) Aug (16) Sep (12) Oct (12) Nov (19) Dec (42) Jan (16) Feb (3) Mar (8) Apr (14) May (30) Jun (5) Jul (7) Aug (3) Sep (10) Oct (4) Nov (10) Dec (1) Jan (14) Feb (8) Mar (5) Apr (3) May (9) Jun (19) Jul Aug (27) Sep (5) Oct (18) Nov (12) Dec (8) Jan (5) Feb (8) Mar (20) Apr (22) May (28) Jun (9) Jul (6) Aug (35) Sep Oct Nov Dec
S M T W T F S

1

2

3

4

5

6

7

8

9

10

11
(1)
12
(3)
13

14

15
(2)
16
(2)
17

18

19
(3)
20

21
(2)
22
(2)
23

24

25

26
(1)
27
(2)
28

29

30

31

Showing 2 results of 2

 Re: [Reduce-algebra-developers] Turing off automatic simplification. From: Rainer Schöpf - 2011-07-16 19:54:48 ```On Fri, 15 Jul 2011 at 14:18 -0400, Ted Kosan wrote: > This past May I submitted the following question to the Reduce forum > which was about turning off automatic simplification: > > http://sourceforge.net/projects/reduce-algebra/forums/forum/899364/topic/4499010 > > The revalp code that Tony submitted provides a partial solution, but a > full solution would allow functions like NUM, DEN, and SUB to be used > on the expression so that it can be analysed and manipulated. At one > point I thought that I could add this feature myself, but I found that > I will have to study Rlisp further before I have the skills needed to > do it properly. Actually, you have to understand how the simplification process works (basically what the functions in packages/alg/reval.red do). The problem here is that things that look similar in function may be quite different. NUM/DEN are good examples: the argument of these operators is fully simplified before the actual numerator or denominator is taken. Which is to say right now that they will not work in "no-simp" (ie. OFF REVALP) mode. The same goes for SUB: substitution happens by simplifying and converting the expression into a standard quotient and descending into the constituents of this standard representation, performing the substitutions on the way. This is necessary to perform more complicated substitutions, like replacements for products of several terms. Consider a product like a*b*c in which you want to replace a*c by something else. Clearly this substitution must happen even if if there are many factors between a and c. On the other hand, PART and friends work on an expression "as it is", ie. without simplifying their arguments. So, accessing parts of an expression is possible even without simplification. I believe it would be possible to implement these "syntactical" access functions to work in no-simp mode. Variants of NUM/DEN could then be defined in terms of these functions: procedure NUM2 u; if ARGLENGTH u = -1 then u % number of symbol else if not (part(u,0)=quotient) then u % toplevel operator is not quotient else part(u,1); procedure DEN2 u; if ARGLENGTH u = -1 then u else if not (part(u,0)=quotient) then u else part(u,2); One could add definitions like these for many of the standard operators, to be used in no-simp mode, instead of the standard ones. This may be the easiest solution. > I am asking for this capability on behalf of the GeoGebra project > (http://GeoGebra.org) because they are in the process of adopting the > Java version of Reduce as the CAS computation engine for GeoGebra. By > the way, GeoGebra has millions of users worldwide and its level of > adoption continues to increase. They are very excited about the idea > of using the commercial-quality Reduce CAS as the computation engine > for GeoGebra and their plan is to ship Reduce with the new GeoGebra > 4.0 in August. > > I have asked Simon Weitzhofer, who is a GeoGebra developer, to join > this email list so that he can provide more information on the > no-simplification feature that they need for GeoGebra. That would be very helpful. > I am hoping > that this feature can be added to Reduce without too much difficulty. Well, first of all we need to understand what is actually needed. Thanks, Rainer ```
 Re: [Reduce-algebra-developers] Multiplying lists and a predicate function for lists From: Ted Kosan - 2011-07-16 16:10:31 ```Rainer wrote: > More generally, one should have various boolean operators for testing type, at > least for those types that can be declared, like matrix, vector, etc. Here is a list of most of MathPiper's boolean operators just for reference: IsAmicablePair, IsAtom, IsBoolean, IsBound, IsCarmichaelNumber, IsComposite, IsConstant, IsCoprime, IsDecimal, IsDiagonal, IsEquation, IsEven, IsEvenFunction, IsFreeOf, IsFunction, IsGaussianInteger, IsGaussianPrime, IsGaussianUnit, IsGreaterThan, IsHermitian, IsIdempotent, IsInfinity, IsInfix, IsInteger, IsIrregularPrime, IsLessThan, IsList, IsListOfLists, IsLowerTriangular, IsMatrix, IsMonomial, IsNegativeInteger, IsNegativeNumber, IsNegativeReal, IsNonObject, IsNonZeroInteger, IsNotZero, IsNumber, IsNumericList, IsOdd, IsOddFunction, IsOrthogonal, IsPositiveInteger, IsPositiveNumber, IsPositiveReal, IsPostfix, IsPrefix, IsPrime, IsPrimePower, IsQuadraticResidue, IsRational, IsScalar, IsSkewSymmetric, IsSmallPrime, IsSquareFree, IsSquareMatrix, IsString, IsSumOfTerms, IsSymmetric, IsTwinPrime, IsUnitary, IsUpperTriangular, IsVector, IsZero, IsZeroVector. Ted ```

Showing 2 results of 2