[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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,
> uploading
> 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)
} == add {
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)
Dog == PrimeField(n) add
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
C == add
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?
- RE: [Axiom-developer] Re: [Aldor-l] RE: Axiom domains and Aldorreturntypes, Bill Page, 2005/01/13
- RE: [Axiom-developer] Re: [Aldor-l] RE: Axiom domains and Aldorreturntypes, Bill Page, 2005/01/13
- [Axiom-developer] Mathaction edit/preview/save problem, William Sit, 2005/01/14
- [Axiom-developer] RE: Mathaction edit/preview/save problem, Bill Page, 2005/01/14
- Re: [Axiom-developer] RE: Mathaction edit/preview/save problem, Bob McElrath, 2005/01/14
- Re: [Axiom-developer] RE: Mathaction edit/preview/save problem, William Sit, 2005/01/14
- Re: [Axiom-developer] RE: Mathaction edit/preview/save problem,
William Sit <=
- RE: [Axiom-developer] RE: Mathaction edit/preview/save problem, Bill Page, 2005/01/16
- Re: [Axiom-developer] RE: Mathaction edit/preview/save problem, William Sit, 2005/01/16
- RE: [Axiom-developer] RE: Mathaction edit/preview/save problem, Bill Page, 2005/01/16
- Re: [Axiom-developer] RE: Mathaction edit/preview/save problem, William Sit, 2005/01/17
- RE: [Axiom-developer] RE: Mathaction edit/preview/save problem, Bill Page, 2005/01/17
- Re: [Axiom-developer] RE: Mathaction edit/preview/save problem, William Sit, 2005/01/17
- Re: [Axiom-developer] RE: Mathaction edit/preview/save problem, William Sit, 2005/01/18
- Re: [Axiom-developer] RE: Mathaction edit/preview/save problem, Eugene Surowitz, 2005/01/17