axiom-developer
[Top][All Lists]

## Re: [Axiom-developer] RE: Mathaction edit/preview/save problem

 From: William Sit Subject: Re: [Axiom-developer] RE: Mathaction edit/preview/save problem Date: Fri, 14 Jan 2005 17:49:14 -0500


William Sit wrote:
>
> Sorry, it was the Firewall setting. I set the Internet Zone to High and it
> blocked sending data from my computer. Setting it to Medium works. (However,
> that is only for the Mathaction site. I have no trouble sending data,
> etc to other sites with setting on High. So it is probably some special java
> applet that was blocked.)
>
> I am using the EZ Firewall Lite from Computer Associates (it is like
> ZoneAlarm).
>
> Thanks for helping to diagnose the problem.

Well, not quite. it only worked on the Sandbox page, where I was able to submit
an edit for the MainPage (I entered "What is this?"). In fact that page worked
(Preview/Save) even with the security setting on High.

But when I tried to edit the DynamicFunctionDomains, it still says "This page
cannot be displayed".

This is not intermittent. Every time. It's not a DNS problem because I can click
on to any link on the page and it displays. I just added Hello to the Sandbox
MainPage. I went right to the DynamicFunctionDomains and change (4,7) to (4,8)
and click preview. Then it stalls and same problem.

It seems to be a write privilege denied type of problem to me.

William
---
Bill, here is new page to replace the current one.

On Wednesday, January 12, 2005 12:00 PM you wrote:
Ralf Hemmecke wrote:

Well, I haven't checked whether it should really work, but
shouldn't:

Foo: with {
g: (n: PositiveInteger, k: PositiveInteger) ->
(P: PrimeFieldCategory, x: P)
g(n: PositiveInteger, k: PositiveInteger ):
(P: PrimeFieldCategory, x:P) == {
(PrimeField(n), k::Integer::PrimeField(n)
}
}

be even better?

Later William Sit wrote:

In fact you just pointed out a way to solve the problem! Notice
that you are in effect constructing a domain! So first create
this domain (call this anything else you like)

\begin{axiom}
)abbrev domain PPF PointedPrimeField
--%PointedPrimeField
PointedPrimeField(n:PositiveInteger):Cat==Dog where
Cat == FiniteFieldCategory with
foo:PositiveInteger->PrimeField(n)
foo(k)==k::Integer::PrimeField(n)
\end{axiom}

After compiling, define in the interpreter

\begin{axiom}
g(n,k)==foo(k)$PPF(n) g(7,4) \end{axiom} and it works (in Axiom)! (Do not declare the types for g because n is not defined). Compiling g is still a problem in Axiom due to signature limitation. At least this way, inlining a complicated function is almost like a function call. The idea is: Since in creating domains (or any other types of constructors), we are in effect creating a function(the domain constructor PPF is a function of sort, or functor) and the compiler can take dependent types in its signature,structurally:: PPF(n:PositiveInteger)==PrimeField(n) with foo so it should be able to compile something like g by lifting it to the package level. So here is another way using package. \begin{axiom} )abbrev package FOO Foo --%Foo Foo(n:PositiveInteger, k:PositiveInteger):T==C where T == with point:()->PrimeField(n) C == add point()==k::Integer::PrimeField(n) \end{axiom} After compiling, we can use:: point()$Foo(n,k)

in any computation in compiler code (and in interpreter).
\begin{axiom}
)abbrev package BARTEST Bartest
Bartest: T==C where
T == with
barrun: () -> Void
import FOO
barrun() ==
for k in 4..5 repeat
for n in [1,2,4,6]::List PositiveInteger repeat
print(point()$Foo(n+1,k)::OutputForm)$PrintPackage
\end{axiom}

\begin{axiom}
barrun()
\end{axiom}

Still can't call this bar(n,k) even if you use a macro expansion:

\begin{axiom}
bar ==>point()$Foo bar(4,7) \end{axiom} In compiler version (as probably the same in the interpreter version), the macro is expanded and parsed before attaching (4,7). bar(n,k) would be parsed in lisp code as ((|elt| |Foo| |point|)) |n| |k| but should be ((|elt| (|Foo| |n| |k|) |point|)) for the macro to work. The package version does not sacrifice the mathematical type structure of the original example that Martin proposed: g(n:PositiveInteger, k:PositiveInteger):PrimeField(n) It reflects exactly the same structure with the exception that there is no signature used and g(n,k) is replaced by the longer name point()$Foo(n,k) as illustrated in the Bartest package. Aldor is
nicer because it allows that, so that such a wrapper is not necessary. But the
wrapper is straightforward and general and can even be automated.

Can someone give an example where the *signature* of bar::

bar: (n: PositiveInteger, k: PositiveInteger) -> PrimeField(n)

is actually needed?