maul-esel / linear.algebra.matrix Goto Github PK

Add core::exp(z), core::log(z), stdlib::mod(a, b), core::re(z), core::im(z), stdlib::conjugate(z) etc. Also prefix existing builtin procs with core::.

When calling a (stdlib) function or assigning to a variable, the value, if not of the parameter's / variable's type, must be implicitly cast to the correct type.

This might also (partially) replace NumberHelper.

Currently, only int exponents are allowed. Even so, an integer exponentiated with a negative exponent is not an integer but a rational (FIX that!). Also, allow real, rational and complex exponents for numbers (not matrices) and type accordingly.

Concerning validation warnings, allow them to be turned off by placing a comment near the code causing the warning, with an annotation specifying that all or specific warnings should not be issued.

To retrieve comments, look at code here.

sth. like

x := {
    2 if i = j
    0 if i <= j
    3 else
}

equivalent to:

if (i = j) { x := (2); }
else if (i <= j) { x := (0); }
else { x := (3); }

Differentiate between entry types:

• for int: det(A) = +/- 1
• for rational, real, complex : det(A) != 0

Depends on

• #2

Add ability to return multiple values from a function. One possibility: output parameters. Or, better: introduce an n-tupel data type (with each entry strictly typed) that can be passed or returned or used otherwise.

Add syntax to access components of tupel by index. Also, add ability to assign tupel components to a number of variables, like:

var tupel := (true, false, false);
var a,b,c := tupel;

Add types for (strictly typed) lists and sets. Such variables can be assigned to corresponding literals or iterator function calls (see #17) (with special keyword). Also, the for(each) loop mentioned in #17 should be able to traverse an array as well.

Add syntax for number of elements (e.g. |list| or #list). Also, add syntax to access list entries by index. For both lists and sets, provide "is element of / included in" and "add to" syntax. Also, ability to join / union lists/sets and intersect sets and to convert between sets and lists and between list/set of type A and list/set of type B (casts, #20).

See if T can be a valid variable name without affecting the transposition syntax. I.e., remove the TRANSPOS token (shadows ID), maybe use predicates to make exponentiation / transposition unambiguous (would probably need to default to transposition).

Validation: produce a warning on a transposition if a T variable exists.

Accept an IntLiteral of 0 to be added to etc. a matrix, where 0 is interpreted as a matrix of appropriate size, containing only 0 entries.

Related:

• #13

Implement a mechanism to indicate errors. This includes the ability to "throw" an exception, "catch" it (in sth. like a try-catch (-finally?) block). Also consider an ability to define a global "on uncaught error" proc or similar.

Also add ability/requirement to annotate a method that might throw an error (or infer from code itself). Validate and warn on possibly erroring function calls without a try-catch.

Implement extended diagonalization algorithm that also calculates unimodular matrices (i.e. matrices M, N such that D = MAN where D is the diagonal matrix equivalent to a given A).

Implement both step-by-step (#18) and direct. Requires tuples (#16) to return (M, D, N).

Natural numbers are a subtype of integers that is closed under addition, multiplication, exponentation (with a natural exponent). The absolute value of an integer is a natural number, the negative of a natrual number is an integer. Subtraction of natural numbers results in an integer, division in a fraction > 0.

Matrices of natrual numbers are closed under addtion, multiplication. They cannot be diagonalized (only as int matrices).

Requires #30, #20.

Instead of inferring the model from grammar, export it to XCore and manage it manually. This allows customized implementations of methods and removal of deprecated classes like MatrixTypeUtils.

Similar to C#, functions with generic type parameters should be able to specify relationships between them. For example:

def myfunc : (%typeA($n ° $n) A, %typeB($n ° $n) B) -> boolean [%typeA <: %typeB, %typeB <: complex, int <: %typeA] {
}

(syntax may differ)

Add syntax for inline matrix literals, e.g.

var m := {{1,2,3}, {3 4 5}}

A special syntax for matrices that are constructed from other matrices. E.g. sth. like

var A := {
    I, B
    C, I
};

When a function is called, infer generic type and number arguments where possible. If generic arguments used in the return type are not explicitly specified and an expectation about the return type can be made, use the expected values.

Cases in which expectations can be made:

the return value...

1. ... is assigned to something
2. ... is passed as argument to a function
3. ... is used in a matrix addition or multiplication
4. ...

Note that in case 2, 3 multiple parameters to the function and how they are typed can influence each other.
Possibly retain conclusions from expectations to one parameter even if typing it fails, try other parameter(s) and merge conclusions, try again.

Add syntax for dividing matrices from left / from right. Result may have symbolic variables (see #21).

Matrices can have variable entries, e.g. as general solution to a division or for other things.

• Must be able to associate instances (e.g. a variable a and another entry 2 * a + 1).
• Implement arithmetic between variables and with T values.
• Reflect existence of such entries in matrix type.
• Add syntax to specify such entries in matrix literals.
• also allow such symbolic variables outside matrices (?)
• ability to set value of such variables in a matrix to concrete values (or other variables?)

Including similar, rational_canonical, characteristic_polynomial, minimal_polynomial, ...

Also implement =~ comparison operator.

Depends on:

#10

Add type(s) for rational, real, complex polynomials. Add syntax for defining polynomials and for evaluating a polynomial, given a (rational, real, complex) number or matrix.

Implement polynomial matrices.

A syntax to cast an expression to another type. Add XSemantics rules to verify such a cast is possible, validate them.

Typing involving generic types is messed up. Not knowing if a type might be closed to negation (-a), division (1/a) and potentially other expressions (e.g. multiplication with an expression of another (generic?) type) must be taken into account! Also, many typing rules (like division, multiplication) just ignore the fact that a type might be generic!

With the help of #30 it should be possible to validate what operations are possible on a generic type, and if a operation on an expression of a generic type cannot be given a type, error and require more relationships to be specified.

For this purpose, any relationships have to be stored in the GenericRegister and the subtyping and common-type systems also have to be adjusted.

Title says it. Implementation could be similar to how functions are checked to always return a value.

First: modify scoping so only variables declared before usage are found by scopes.

Use Gauß-Jordan-algorithm. Use in stdlib::exp.

Depends on:

• #7
• #8

Consider allowing overloads for functions and procs. Maybe limit them to overloads with the same number of parameters and the same basic param types (matrix, number, boolean). No dispatch binding, bind by formal parameter type (a rational matrix full of integers is treated as a rational matrix, not an integer matrix).

This may superseede #2.

Syntax: A^P. Implement in stdlib.

Rework function / proc call parameter type matching. For example, with generic types, do not use the type of the first such argument, use the common super type. Also, maybe move it to a real XSemantics judgment system, not just an auxiliary (see XSemantics examples).

The diagonalization algorithm can be improved. Instead of subtracting 1 from 490735 exactly 490734-times, substract 490734 from 490735 one time.

Consider making generic variables and generic types XText references including linking, scoping.

Instead just use integer divisions (i.e. instead of <3/4> write 3 / 4).

Depends on

• #4

Allow functions to specify return types that cannot be inferred from the params (for example, but not limited to, functions without params). Introduce syntax to specify such types in function calls.

Once arrays, sets (#19), function expressions (#26) exist, it might be useful to allow generic types to be not only numbers, but also any other type (e.g. to declare parameters as a set of any type).

Combined with #30, one might simply change %t to allow anything (i.e. make GenericType inherit Type directly). Or a new syntax could be introduced to handle arbitrary generic types differently than the existing ones.

Relates to #45.

Add ability to specify a set of builtin variables, functions and procs along with (if not matrix code) means of interpretation. Consider using this mechanism for stdlib and other builtin stuff (like @print, #29).

Scoping

Must provide EObject instances of appropriate type for such variables and functions.

Rough draft:

interface BuiltinProvider {
    FuncDeclaration[] getFunctions();
    ProcDeclaration[] getProcs();
    VarDeclaration[] getVariables();

    Object interpretFunction(FuncDeclaration func, Object[] parameters);
    void interpretProc(ProcDeclaration proc, Object[] parameters);
    Object getVariable(VarDeclaration variable);
    void setVariable(VarDeclaration variable, Object value);
}

public abstract class AbstractDeclarativeBuiltinProvider implements BuiltinProvider {
    // uses polymorphic dispatch and predefined method names or similar to collect, analyze and call methods
    // this also allows for function overloads
    // e.g. var_MyVar(), var_MyVar(Integer value) -> VarDeclaration MyVar
    // var_MyOtherVar() -> VarDeclaration const MyOtherVar
    // func_myFunc(), proc_myProc(), ....

    protected VarDeclaration[] collectVariables() { ... }
    protected FuncDeclaration[] collectFunctions() { ... }
    protected ProcDeclaration[] collectProcs() { ... }
}

public class DefaultStdlibProvider {
    @Override
    protected FuncDeclaration[] collectFunctions() { return super.collectFunctions().concat(loadStdlibFunctions()); }

    private FuncDeclaration[] loadStdlibFunctions() { ... }
}

Inject (!) instances or singleton instance into interpreter and global scope.

A script can override any of these by specifying a variable / func / proc with the same name (local scoping).

There are several issues with the current interpretation. For instance, it fails on nested function calls with generic parameters, that is it does not provide the inner call with the actually passed type information. Also, make sure to cover:

• matrix types with generic dimensions
• matrix types with generic entry types (and fixed or generic dimensions)
• generic param types

Write a bunch of tests, ideally in the language itself. Test that they are parsed (correctly) and execute them to test expected behaviour.

Requires #7.

Don't constantly re-evaluate an expression / a function call when its value does not change.

• implement proper equals() in all expression classes
• add new keyword welldefined to function declarations to indicate, that for the same parameters they produce the same result, without side effects => those can be optimized if the params are the same
• cache expression values (at least optimizable function calls), but not unlimited (throw them out of the cache after some time)
  • modify caching logic: if a max number of cached entries is set, assign a priority to each entry that increases the more often they are requested - throw out those with the least priority
  • maybe allow a base priority / priority factor to be passed, so that e.g. complex expressions have higher priority despite being requested less often than a very simple expression

Support sth. like yield to save a functions state, return a value and resume once the function is called again.
Also, a keyword for ending such an iteration is needed, like end.

Based on this, add a for(each) ... in ... loop.

Support checking the type of a variable. This can be helpful in the following situations:

• in functions and procs with generic parameters (do different things depending on their actual type)
• when working with a super type, e.g. a rational, check whether the given value is actually of a subtype, e.g. int (i.e. int?(3 / 2) is false, but int?(3 / 1) is true).

Proposed Syntax

As seen above, the syntax could be sth. like rational?(obj), i.e. <type-name> '?' '(' <expression> ')'. For matrix types, the type name should be enclosed in parentheses as well.

Additional Semantics

If the entry type on a matrix type is unspecified, it should not default to int (like it does in declarations), but just match any entry type.

Should also work for generic typs. i.e. %mytype?(3).

Encountered several such issues. The values just seems to vanish - on the same instance, the property has a value at first, but at later typings the value is null.

Examples:

• matrix initialization Disabling the commented code seems to fix it somehow.
• Matrix parameters with generic entry types: the specified generic entryType is used at first, but later the reference is null
• matrix literals: the entryType property is null despite being specified, therefore it falls back to integer

Return each step of the diagonalization process.

Depends on:

#17

Functions to return the properly sized matrices. Use them in other stdlib functions as well.

Depends on:

#13

Instead of just literals allow any expression in a literal, in parentheses if needed.

Implement functions as expressions. I.e. add a type (syntax), anonymous functions / lambda expressions, ability to refer to "normal" functions as if they were variables, call functions stored in a variable.

There has to be some possibility to output calculated values. This could be a simple builtin (not stdlib) print instruction that takes matrices, numbers and booleans, or something more elaborate including string support.