gmane.comp.mathematics.open-axiom.devel

[open-axiom-devel] attribute shallowlyMutable

Gabriel Dos Reis — 2013-05-20T14:55:29

* Important aggregate hierarchy change:

The attribute shallowlyMutable was removed.
It was replaced with the unary category constructor
ShallowlyMutableAggregate.  This category extends
HomogeneousAggregate, and is distinguished by
the fact that components can be modified in place.
This is captured by the exports:

    map!: (S -> S, %)

[open-axiom-devel] Collection and find

Gabriel Dos Reis — 2013-05-20T14:52:19

* Library change:

The operation 'find' was moved from 'Collection' to 'FiniteAggregate'.
This was done without any breakage to the existing usage
in the library, confirming what could be suspected of its semantics
implications -- that it assumed the underlying aggregate satisfies
FiniteAggregate.

[open-axiom-devel] Change concerning finite aggregates

Gabriel Dos Reis — 2013-05-19T18:47:25

* Fundamental library change:

The attribute finiteAggregate has been removed.  It is replaced
with a more structured construct: the new category FiniteAggregate.

In the process of implementing this change, I ran into several issues,
some in the algebra hierarchy of aggregates, some in the compiler.
I've adapted both.  Removing the attribute let me to uncover several
curious logic/hacks in the library.

Since this is a fundamental change, I expect that there might be
some residual in forms of bugs.  Two wrongs don't make a right, but
in the field some software, sometimes they do.  So be on the look out
for these.

Please test and report any problem you may find.

Re: [open-axiom-devel] [open-axiom-help] "complete 0" is 0 ?

Gabriel Dos Reis — 2013-05-19T13:04:34


we are talking about the empty set, i.e. something for which *any*
statement (including its opposite) is vacuously true.  So, the above
is nonconclusive.

On the other hand, I can understand the desire to extend to the limiting
case.

[open-axiom-devel] parts from HomogeneousAggregate

Gabriel Dos Reis — 2013-05-18T08:26:49

The "parts" export is gone from HomogeneousAggregate.
It was almost always equivalent to members.  The redundancy
was confusing and unnecessary.

[open-axiom-devel] Multiset and members

Gabriel Dos Reis — 2013-05-18T04:14:44

The old operation "members" of Multiset was renamed to "unique"
to reflect its semantics, to avoid confusion with the export
"members" from HomogeneousAggregate.

This closes, I hope, a long standing issue with what to
do with members vs. parts.  The latter is going away.

[open-axiom-devel] Collection and find

Gabriel Dos Reis — 2013-05-17T23:16:05

As currently specified, the operation "find"
(from category Collection) appears to be
a terminating function: it either succeeds
with an element or fails.  This indicates that
it is more appropriate for FiniteAggregate than
for Collection.

The real defining property of Collection is that
it is an aggregate that can be constructed
from a specified list of elements.

Any contrary opinion to moving it to FiniteAggregate?

Re: [open-axiom-devel] IndexedAggregate is implicitly assumed to bea

Waldek Hebisch — 2013-05-17T03:08:21

You assume that 'entries' is succesful.  But given infinite
sequence I see:

(4) -> entries(si)
 
   >> Error detected within library code:
   infinite stream
(4) -> si

   (4)  [1,1,1,1,1,1,1,1,1,1,...]
                                                      Type: Sequence(Integer)

Re: [open-axiom-devel] IndexedAggregate is implicitly assumed to bea

Gabriel Dos Reis — 2013-05-17T03:16:57

| > 
| > While working through the semantics implications of category exports,
| > I've come to the conclusion that any domain D that satisfies the
| > category IndexedAggregate must also be morally finite.  For each
| > instance of such a domain would need to have a finite indices (because
| > the operations indices$D must return a list), and it would also need to
| > have a finite set of entries -- the operation entries$D must return a
| > list. 
| >
| 
| You assume that 'entries' is succesful. 

Indeed, for the specification doesn't say it can may fail.

In case when an operation is partial, we usually have a return type of
Union(D,"failed") -- or we have two variants with one being "IfCan".

| But given infinite  sequence I see:
| 
| (4) -> entries(si)
|  
|    >> Error detected within library code:
|    infinite stream

I believe this is evidence that this operation should not be provided
as exports for domains that are not finite, which goes to my original
observation.

[open-axiom-devel] IndexedAggregate is implicitly assumed to be afinite aggregate

Gabriel Dos Reis — 2013-05-17T01:10:00

Hi,

I have been working on getting rid of the attribute finiteAggreagte and
replacing it with the more structured category FiniteAggregate.  See

  http://sourceforge.net/p/open-axiom/code/2869/tree//trunk/src/algebra/aggcat.spad.pamphlet?diff=515862a75fcbc90e9951aa9f:2868

for its introduction.

While working through the semantics implications of category exports,
I've come to the conclusion that any domain D that satisfies the
category IndexedAggregate must also be morally finite.  For each
instance of such a domain would need to have a finite indices (because
the operations indices$D must return a list), and it would also need to
have a finite set of entries -- the operation entries$D must return a
list. 

Consequently, I am proposing to make IndexedAggregate(I,S) extends
FiniteAggregate(S) instead of HomogeneousAggregate(S).

Opinions?

[open-axiom-devel] CFP Synasc 2013, Timisoara, Romania [7 days left for abstract submission]

SYNASC 2013 — 2013-05-12T15:29:19

[Please post - apologies for multiple copies.]

Call for Papers
---------------

                       SYNASC 2013

              15th International Symposium on
   Symbolic and Numeric Algorithms for Scientific Computing
         September 23-26, 2013, Timisoara, Romania
                   http://www.synasc.ro/
                  

Aim
---

SYNASC aims to stimulate the interaction between the two 
scientific communities of symbolic and numeric computing 
and to exhibit interesting applications of the areas both 
in theory and in practice. The choice of the topic is motivated 
by the belief of the organizers that the dialogue between 
the two communities is very necessary for accelerating the 
progress in making the computer a truly intelligent aid for 
mathematicians and engineers.

Important Dates
---------------

19 May 2013            :  Abstract submission  
26 May 2013            :  Paper submission 
22 July 2013           :  Notification of acceptance
01 September 2013      :  Registration
08 Septembe

Re: [open-axiom-devel] Arrays and matrices.

Gabriel Dos Reis — 2013-05-11T20:55:48

| One point I could see is that with two constructions one could try
| to separate the mathematical algebraic structure "Matrix" and the
| computer-science data-structure "2D-Array".
| Maybe there are good reasons to do this?

I consider the current state of matrix code in OpenAxiom to be too much
of obfuscation, but I am still going to keep the distinction 2d arrays
vs. matrices.  I think of the latter as linear algebra related whereas
the former is for more general stuff that do not necessarily have much
structures.

Re: [open-axiom-devel] open-axiom chokes on Legendre polynomial(Debian bug #706813)

Gabriel Dos Reis — 2013-05-09T13:14:16

| Hi, I have a bug report from Debian [1].
| 
| open-axiom seems to hangs in calcutaions of high-order Legendre
| polynomial coefficients.
| I have reproduced this on Gentoo too. Can't check lastest version, thought.

Fixed now on trunk in revision 2823.
The problem was in the interpreter.  As we moved to an intermediate
reprsentation (OIL), we failed to cover some cases where a Lisp code is
generated directly.  This prevented the function isRecurrenceRelation
from recognizing a recurrence definition, therefore OpenAxiom failed to
cache the last two computed values.  Which led to the extreme
performence hit.   

Things are back to normal, now.  Please verify.

Re: [open-axiom-devel] open-axiom chokes on Legendre polynomial(Debian bug #706813)

Gabriel Dos Reis — 2013-05-08T13:59:14

| Hi, I have a bug report from Debian [1].
| 
| open-axiom seems to hangs in calcutaions of high-order Legendre
| polynomial coefficients.
| I have reproduced this on Gentoo too. Can't check lastest version, thought.
| 
| Quoting:
| 
| ============  >8 ======================
| (1) -> p(0) == 1
|                                                                    Type: Void
| (2) -> p(1) == x
|                                                                    Type: Void
| (3) -> p(n) == ((2*n-1)*x*p(n-1) - (n-1) * p(n-2))/n
|                                                                    Type: Void
| (4) -> p(10)
|    Compiling function p with type Integer -> Polynomial Fraction
|       Integer
| 
|         46189  10   109395  8   45045  6   15015  4   3465  2    63
|    (4)  ----- x   - ------ x  + ----- x  - ----- x  + ---- x  - ---
|          256          256        128        128        256      256
|                                             Type: Polynomial Fraction Integer
| 
| So far so good, n

[open-axiom-devel] open-axiom chokes on Legendre polynomial (Debianbug #706813)

Игорь Пашев — 2013-05-05T10:02:36

Hi, I have a bug report from Debian [1].

open-axiom seems to hangs in calcutaions of high-order Legendre
polynomial coefficients.
I have reproduced this on Gentoo too. Can't check lastest version, thought.

Quoting:

============  >8 ======================
(1) -> p(0) == 1
                                                                   Type: Void
(2) -> p(1) == x
                                                                   Type: Void
(3) -> p(n) == ((2*n-1)*x*p(n-1) - (n-1) * p(n-2))/n
                                                                   Type: Void
(4) -> p(10)
   Compiling function p with type Integer -> Polynomial Fraction
      Integer

        46189  10   109395  8   45045  6   15015  4   3465  2    63
   (4)  ----- x   - ------ x  + ----- x  - ----- x  + ---- x  - ---
         256          256        128        128        256      256
                                            Type: Polynomial Fraction Integer

So far so good, now I typed

(5) -> coefficient(p(90),x,90)

and thi

Re: [open-axiom-devel] Bug 92 occurs on Windows XP / SP3

2013-04-25T21:30:22

Ok. Will set up an environment that builds. will report any pbs, build or run time.


Happy to read you again 😊


Keep up the good work I hope!



Envoyé depuis Courrier Windows



De : Gabriel Dos Reis
Envoyé : ‎jeudi‎ ‎25‎ ‎avril‎ ‎2013 ‎23‎:‎22
À : g.vanuxem< at >gmail.com
Cc : surow< at >attglobal.net; OpenAxiom

<g.vanuxem< at >gmail.com> writes:

| Hello,
|  
| I have not responded last time, sorry, very hard work.

Gregory, it is great to hear from you!

| Would be glad to test on a Windows 8 environment (32 bits)  and on a 7
| in network (did not work from memory).

We didn't finish the TCP/IP part on Windows for OpenAxiom-1.4.x so
anything that involved TCP/IP traffic did not work.  Non-TCP/IP stuff
works though, e.g. involing OpenAxiom with --no-server.

The plan is to use Windows' local pipe mechanism for interprocess
communication.

I am unlikely to work on that this week-end or next week (end of
semester, etc.), but I should resume the implementat

Re: [open-axiom-devel] Bug 92 occurs on Windows XP / SP3

Gabriel Dos Reis — 2013-04-25T21:22:13

| Hello,
|  
| I have not responded last time, sorry, very hard work.

Gregory, it is great to hear from you!

| Would be glad to test on a Windows 8 environment (32 bits)  and on a 7
| in network (did not work from memory).

We didn't finish the TCP/IP part on Windows for OpenAxiom-1.4.x so
anything that involved TCP/IP traffic did not work.  Non-TCP/IP stuff
works though, e.g. involing OpenAxiom with --no-server.

The plan is to use Windows' local pipe mechanism for interprocess
communication.

I am unlikely to work on that this week-end or next week (end of
semester, etc.), but I should resume the implementation once I'm done
with the administrative stuff that comes with daytime job.

We are also moving towards either SBCL or Clozure Lisp as default Lisp
on Windows -- both work relatively well (CLL better than SBCL).

Re: [open-axiom-devel] Bug 92 occurs on Windows XP / SP3

2013-04-25T21:05:29

Hello,


I have not responded last time, sorry, very hard work.


Would be glad to test on a Windows 8 environment (32 bits)  and on a 7 in network (did not work from memory).


Sorry again


(just re-subscribed)



De : Gabriel Dos Reis
Envoyé : ‎jeudi‎ ‎25‎ ‎avril‎ ‎2013 ‎16‎:‎36
À : surow< at >attglobal.net
Cc : OpenAxiom

Eugene Surowitz <surow< at >attglobal.net> writes:

| On my XP/SP3 system:
| 
| Before uninstalling OpenAxiom 1.4.1 poked
| various things and reproduced bug 92 in these ways:
| 
| Desktop icon: opens two windows: a terminal window and
|                a window with a "Main Frame" tab;
|                the terminal window has a blinking cursor
|                but does not accept input.
| 
| Start Menu > All Programs > OpenAxiom > OpenAxiom yields the same result.
| 
| Start Menu > All Programs > OpenAxiom > OpenAxiom(Interpreter)
|               opens what seems to be a properly functioning OpenAxiom window.
| 
| Cheers, Gene

Thank,

Re: [open-axiom-devel] Re: icons and exprint

Eugene Surowitz — 2013-04-25T21:10:04

Publishers have what is known as "Imprints";
these are, historically, other companies that
were absorbed but the customers don't care
about the merger and acquisitions.

Axiom, FriCAS, and OpenAxiom could possibly adopt a
common "exprint" while having their own unique icon/trademark.

Cheers, Gene

On 4/25/2013 4:45 PM, Bill Page wrote:


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: [open-axiom-devel] Re: icons

Bill Page — 2013-04-25T20:45:37

I think Gene has a good point also indirectly observed by Gaby: Most of the
proposals so far may not represent the actual intention of the web site -
even if FriCAS is the project which is hosting the site.

In the past when trying to refer to any of the original Axiom project,
FriCAS or OpenAxiom in a neutral way we have sometimes used the word

  PanAxiom

Perhaps some variant of this that might work. I just added #6 at

  http://axiom-wiki.newsynthesis.org/FriCASIcon

which incorporates all three names.

Bill.

On 25 April 2013 16:07, Eugene Surowitz <surow-gQP1dZ1XGl8JGwgDXS7ZQA< at >public.gmane.org> wrote:

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/ne

Re: [open-axiom-devel] Re: icons

Eugene Surowitz — 2013-04-25T20:07:53

I like the idea of icons/logos acknowledging the common history;
Things that might be used create sufficiently non-infringing are
style, color, shape, wording.

I'm not quite sure what I mean by 'style'.

As a 'wording' example, to distinguish to things on my product disk,
I label their top directories as:

AXIOM=AXIOM  AXIOM=FRICAS  AXIOM=OpenAxiom

( "=" just is the result of Windows naming limits )

Just ideas; Cheers , Gene

On 4/25/2013 10:16 AM, Bill Page wrote:


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr