[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.

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
 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)

)abbrev domain PPF PointedPrimeField
PointedPrimeField(n:PositiveInteger):Cat==Dog where
  Cat == FiniteFieldCategory with
  Dog == PrimeField(n) add

After compiling, define in the interpreter

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.

)abbrev package FOO Foo
Foo(n:PositiveInteger, k:PositiveInteger):T==C where
  T == with
  C == add

After compiling, we can use::


in any computation in compiler code (and in interpreter). 
)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


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

bar ==>point()$Foo

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?

reply via email to

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