axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

## Re: [Axiom-developer] Polynomials, abstract objects, provisos

 From: Ralf Hemmecke Subject: Re: [Axiom-developer] Polynomials, abstract objects, provisos Date: Sat, 29 Jul 2006 11:08:15 +0200 User-agent: Thunderbird 1.5.0.5 (X11/20060719)

```I have no idea what you are talking about, sorry. I was referring to Tim's (?)
idea that we could say something like:

p: Abstract POLY INT

i.e., not assign p a value,
```
```
Sorry, then I did not understand that.

```
```and still do interesting things with it. And I doubt that this is something
within reach, as it is, in my opinion, rather orthogonal to the philosophy of
the current Axiom Algebra.
```
```
```
```Something easier to grasp is probably:

z: Abstract Complex INT

```
and then be able to say
```w := conjugate z.

In other words: there would be no data representation as we are used to
currently.
```
```
```
I don't believe your last statement. Somewhere it must be stored that w and z are connected via "conjugate", so there must be some storage involved. Now the question is who is going to remember these relations?
```
```
Since I don't want the interpreter be too smart, I would like to encode such things in the library. And that could be done (theoretically at least).
```
```
Assume we have a domain A that exports foo: % -> % then you would need another domain DelayedA that basicly has the same exports as A and additionally two coerce functions A -> DelayedA and back.
```
```
In DelayedA function applications would be collected and only executed if you really provide an element of A. But there are more elements in DelayedA than in A, namely those that have no value in A.
```
```
In other words one would have a kind of ExpressionTrees where you carry the type information.
```
```
But don't quote me on that my ideas are completely underdeveloped. And there is certainly something missing that might look like provisos. For example, if you declare "a: Integer" and then say "5/a". It might be a bit easier to get the type of 5/a right. The value is a bit more problematic since at some point when you finally assign a value to "a" an exception might happen and your program has to deal with that. But an exception is an easy exercise. It is getting more complicated if the "unvalued but typed" expression might result in multible values.
```
Ralf

```

reply via email to

 [Prev in Thread] Current Thread [Next in Thread]