Planning new release
Waldek Hebisch
at end of June, but there may be delay to beginning of July.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Alexandr Batalshikov
--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To post to this group, send email to fricas...@googlegroups.com.
To unsubscribe from this group, send email to fricas-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Martin Baker
> I plan new release (1.1.0) in the near future. Optimistically
> at end of June, but there may be delay to beginning of July.
>
Waldek,
Looking forward to it.
Can I persuade you to include the HTML formatter (html.spad.pamphlet) which is
here:
http://github.com/martinbaker/multivector/
into the new release? I have put the reasons why I think its useful here:
http://www.euclideanspace.com/maths/standards/program/mycode/output/
At the moment I have to use it by redirecting from MathMLFormat. It would
really help me use and develop it further, if it was available as a formatter
in its own right.
Also, would you be interested in including the code to write the contents of a
SubSpace domain to a Wavefront .OBJ file.
http://www.euclideanspace.com/maths/standards/program/mycode/graph/write/
If you were interested in this then I could put this into a pamphlet file.
However it is the HTML formatter that I am really keen for you to include
because the other code needs to be aware of it.
Martin Baker
Waldek Hebisch
> On Monday 14 Jun 2010 20:15:27 Waldek Hebisch wrote:
> > I plan new release (1.1.0) in the near future. Optimistically
> > at end of June, but there may be delay to beginning of July.
> >
>
> Waldek,
>
> Looking forward to it.
>
> Can I persuade you to include the HTML formatter (html.spad.pamphlet) which is
> here:
> http://github.com/martinbaker/multivector/
>
> into the new release? I have put the reasons why I think its useful here:
> http://www.euclideanspace.com/maths/standards/program/mycode/output/
>
> At the moment I have to use it by redirecting from MathMLFormat. It would
> really help me use and develop it further, if it was available as a formatter
> in its own right.
>
OK, I will add it.
> Also, would you be interested in including the code to write the contents of a
> SubSpace domain to a Wavefront .OBJ file.
>
> http://www.euclideanspace.com/maths/standards/program/mycode/graph/write/
>
> If you were interested in this then I could put this into a pamphlet file.
>
Ability to write 3-D data to files is interesting. But as I wrote
use of 'unparse' looks wrong -- I suspect that it can be replaced
by something simpler. In other words I feel that 'Export3D'
needs a cleanup before we include it.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
> Do you have a list of major changes?
>
The list is in making.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
Would it be possible to check the planned new release under SuSE
Linux
(because on SuSE the virtual memory limit is set low by default).
All that is necessary to check the problem is to run something that
uses a bit
of memory like draw.
and if required put:
ulimit -v unlimited
in the startup script. Or at lest put a warning about this on the
release
notes.
Even better would be to put into the SuSE build service like OpenAxiom
have
done. As you can see here:
http://software.opensuse.org/search?p=1&baseproject=ALL&q=open-axiom
this automatically generates rpms not only for SuSE but also for
Fedora, Mandriva, etc.
Unfortunately I don't have any skills or knowledge in doing this
otherwise I
would offer to help.
Martin Baker
Martin Baker
> Ability to write 3-D data to files is interesting. But as I wrote
> use of 'unparse' looks wrong -- I suspect that it can be replaced
> by something simpler. In other words I feel that 'Export3D'
> needs a cleanup before we include it.
and it does seem to be needed. Can any one help me work it out?
I would call it from the command line like this:
writeObj(subspace(makeObject(x*x-y*y,x=-1..1,y=-1..1)),"myfile.obj")
All the work is done by makeObject (in draw.spad) so that must be
where the parse, which must be unparsed, must get done.
There are two families of function calls in draw.spad with exactly the
same signatures:
makeObject - which builds a ThreeSpace structure
draw - (which I don't tend to use) which calls makeObject above and
then calls makeViewport3D (which opens the x-window and so on)
So makeObject only builds the ThreeSpace domain and I can see no
reason for it to call C or Lisp code.
It builds the points in this line:
fcn : L((SF,SF) -> Pt) :=
[(x, y) +-> makePt4(myTrap2(f, x, y), x, y, (first col2)(x,
y))]
where myTrap2 is defined as follows:
myTrap2(ff:(SF, SF) -> SF, u:SF, v:SF):SF ==
s := trapNumericErrors(ff(u, v))$Lisp :: Union(SF, "failed")
s case "failed" => 0
r:SF := s::SF
r >max()$SF => max()$SF
r < min()$SF => min()$SF
r
So does the Lisp function 'trapNumericErrors' parse the points?
Should I write a version of makeObject that does not call
'trapNumericErrors'?
Martin Baker
Waldek Hebisch
> > Ability to write 3-D data to files is interesting. ?But as I wrote
> > use of 'unparse' looks wrong -- I suspect that it can be replaced
> > needs a cleanup before we include it.
>
> I can't understand why 'unparse' is needed but I have tried it without
> and it does seem to be needed. Can any one help me work it out?
>
AFAICS instead of 'unparse(convert(v.1)@InputForm)' we should
use 'message((v.1)::OutputForm)'. ATM in iterpreter I get
wrong result trying 'message((1.2)::DoubleFloat::OutputForm)'
I do not know if this is interpteter weirdness or bug
in 'message', but if 'message' is buggy we should fix it
intead of woring around and using 'unparse'.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
So that I could give a comment Export3D.
Anyway, I get...
(1) -> message((1.2)::DoubleFloat::OutputForm)
(1) <mn>1.2</mn>
which looks a bit surprising to me. Why does this look like MathML? The
documentation says:
message: String -> %
++ message(s) creates an form with no string quotes
++ from string s.
But you obviously give something of OutputForm, not String, so there
must be an implicit coercion to String.
Interestingly, that is not defined in OutputForm. So where does it come
from???
Ralf
Waldek Hebisch
>
> Would it be possible to check the planned new release under SuSE
> Linux
> (because on SuSE the virtual memory limit is set low by default).
>
> All that is necessary to check the problem is to run something that
> uses a bit
> of memory like draw.
>
> and if required put:
>
> ulimit -v unlimited
>
> in the startup script. Or at lest put a warning about this on the
> release
> notes.
>
IMO setting limit is a policy decision made by owner (or system
administrator) and programs should not try to circumvent this.
In paticular owner or administrator has to decide what to do
with programs that want more virtual memory than the limit.
In case of sbcl-based FriCAS there are two possibilities:
- increase limit for FriCAS
- decrecres usage by FriCAS.
Only owner can decide which one is appropriate.
I conside setting of limit in SuSE as a SuSE bug. Of course we
could try to develop a workaround but while at first glace
such worarounds look easy I see no really good one. And
worarounds are not trivial in the sense that they (at least
potentially) may have undesirable effect on non-SuSE systems.
I will put warning in release notes, but in short term I do
not think we can do more. In a bit longer term I plan to
change way that FriCAS is run, so that the user will see
clearer error message.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
Oops. I misread description of 'message'. Of course I want
a function which produces a String from a number and
surprisingly I can not find one...
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
Little correction: it seems that ATM there is no direct way
to produce string representation of a DoubleFloat. So
I think that for release we should stick to the 'convert' +
'unparse' trick. But I would itroduce a new function:
toString(x : DoubleFloat) : String ==
unparse(convert(x)@InputForm)
and use it instead of inline code. Later we will add 'toString'
function to DoubleFloat (and maybe to other domains).
Remark: According to Axiom philosophy this function should be
called 'coerce' and DoubleFloat should have CoercibleTo(String).
But I do not want to try what crazy things interpreter will
do with such coercion...
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> unparse(convert(x)@InputForm)
> Remark: According to Axiom philosophy this function should be
> called 'coerce' and DoubleFloat should have CoercibleTo(String).
Yes.
> But I do not want to try what crazy things interpreter will
> do with such coercion...
Very much agreed. But what about "convert"? That should be the standard
name of such a function that the interpreter should not consider in
automatic coercions.
Also "string: DoubleFloat -> String" would be an option, but I'd rather
vote for "convert".
Ralf
Ralf Hemmecke
> use "convert". In 'i-coerce.boot' we have:
>
> coerceOrCroak(triple, t, mapName) ==
> -- this does the coercion and returns the value or dies
> t = $NoValueMode => triple
> t' := coerceOrConvertOrRetract(triple,t)
> t' => objValUnwrap(t')
> mapName = 'noMapName =>
> throwKeyedMsgCannotCoerceWithValue(objVal triple,objMode triple, t)
> sayKeyedMsg("S2IC0005",[mapName])
> throwKeyedMsgCannotCoerceWithValue(objVal triple,objMode triple, t)
>
> as you see the main function is called 'coerceOrConvertOrRetract'
> and it tries to use "convert".
> "convert" is not used by Spad compiler, but interpreter is different
> here.
Whatever the code says, it is not what I think how it should work. I
rather trust the intentions of the original developers and they say in
the Axiom Book
http://axiom-wiki.newsynthesis.org/uploads/chapter-2.xhtml#sec-2.7
A coercion is a special kind of conversion that Axiom is allowed
to do automatically when you enter an expression. Coercions are
usually somewhat safer than more general conversions. The Axiom
library contains operations called coerce and convert.
Only the coerce operations can be used by the interpreter to
change an object into an object of another type unless you explicitly
use a ::.
For me that means, that only "coerce" functions are allowed to be
inserted automagically. Never "convert". I am not so sure about
"retract" or rather "retractIfCan". The latter are probably necessary to
go back to the most specific domain that an object lives in.
When I started with Axiom, I got confused by the mere existance of
convert and coerce. They actually seem to be there for the same purpose.
But no, the difference is that the interpreter can use coerce but not
convert. If this distinction is blurred then it makes no sense to have
two different names.
So I am rather in favour of keeping that difference and working towards
a clear distinction.
As you see above there is a ::. While I worked with Axiom, I never
really thought about its explicit meaning. In Aldor the meaning is
clearly defined. a::X is syntactic sugar for coerce(a)@X. No retract, no
convert. But that is Aldor. In Axiom, it seems that :: can mean what
coerceOrConvertOrRetract says. Can you confirm that your above cited
function is the explicit translation of ::?
If it is part of the process of inserting coercions to make the types
match, then I'd argue that this should be fixed in favour of a clear
distinction between coerce and convert.
I know that we somewhat disagree on the "automatic insertion of
coercions in the compiler", but what I just said, all applied to the
interpreter. The compiler should in my opinion never silently insert a
coercion.
Ralf
Gabriel Dos Reis
[...]
| Whatever the code says, it is not what I think how it should work. I
| rather trust the intentions of the original developers and they say in
| the Axiom Book
>
| http://axiom-wiki.newsynthesis.org/uploads/chapter-2.xhtml#sec-2.7
>
| A coercion is a special kind of conversion that Axiom is allowed
| to do automatically when you enter an expression. Coercions are
| usually somewhat safer than more general conversions. The Axiom
| library contains operations called coerce and convert.
| Only the coerce operations can be used by the interpreter to
| change an object into an object of another type unless you explicitly
| use a ::.
>
| For me that means, that only "coerce" functions are allowed to be
| inserted automagically. Never "convert". I am not so sure about
| "retract" or rather "retractIfCan". The latter are probably necessary to
| go back to the most specific domain that an object lives in.
>
| When I started with Axiom, I got confused by the mere existance of
| convert and coerce. They actually seem to be there for the same purpose.
| But no, the difference is that the interpreter can use coerce but not
| convert. If this distinction is blurred then it makes no sense to have
| two different names.
A reasonably good mental model of 'coerce' is that it injects a value of
one domain into another domain, e.g. you can inject the integer value
1 into the ring of polynomial with integer coefficients without much of
computational information loss.
On the other hand, there are situations where we want a different
representation of a value, but we are willing to accept for a little bit
of occasional information loss: that is where 'convert' is most
appropriate. The string representation (in base 10) of a DoubleFloat
is not an injection as is well known.
>
| So I am rather in favour of keeping that difference and working towards
| a clear distinction.
>
| As you see above there is a ::. While I worked with Axiom, I never
| really thought about its explicit meaning. In Aldor the meaning is
| clearly defined. a::X is syntactic sugar for coerce(a)@X. No retract, no
| convert. But that is Aldor. In Axiom, it seems that :: can mean what
| coerceOrConvertOrRetract says. Can you confirm that your above cited
| function is the explicit translation of ::?
The Axiom interpreter actually does make the distinction.
Apparently, some people don't want that distinction so they have a flag
that you can set to tell the interpreter to use 'convert' when it should
be using only 'coerce'.
| If it is part of the process of inserting coercions to make the types
| match, then I'd argue that this should be fixed in favour of a clear
| distinction between coerce and convert.
>
| I know that we somewhat disagree on the "automatic insertion of
| coercions in the compiler", but what I just said, all applied to the
| interpreter. The compiler should in my opinion never silently insert a
| coercion.
The compiler is a different story from the interpreter.
Waldek Hebisch
> > OK, I will add it.
>
> Thanks, great news.
>
> > use of 'unparse' looks wrong -- I suspect that it can be replaced
> > needs a cleanup before we include it.
>
> I can't understand why 'unparse' is needed but I have tried it without
> and it does seem to be needed. Can any one help me work it out?
>
I have now included sligthly modified version in FriCAS (I moved
'unparse' to a separate 'toString' function).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Aleksej Saushev
Waldek Hebisch <heb...@math.uni.wroc.pl> writes:
> I plan new release (1.1.0) in the near future. Optimistically
> at end of June, but there may be delay to beginning of July.
For some time I cannot use FriCAS/SBCL:
$ fricas
viewman not present, disabling graphics
exec: /usr/pkg/lib/fricas/target/i486--netbsdelf/bin/hypertex: not found
RUNTIME WARNING: unable to raise process data size limit:
Invalid argument.
The system may fail to start.
This is SBCL 1.0.39.23, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
*
Alright, that viewman isn't present I know, I've built without X11 support,
though it would be nice to handle it somehow. But it doesn't start interpreter,
instead I get SBCL prompt (non-functioning anyway, I can get out only with SIGABRT).
--
HE CE3OH...
Ralf Hemmecke
> though it would be nice to handle it somehow. But it doesn't start interpreter,
> instead I get SBCL prompt (non-functioning anyway, I can get out only with SIGABRT).
That doesn't sound right. If you've build without X support then I'd
call this a bug in producing the right "fricas" shell script. It
shouldn't start any X related process then.
Anyway, what happens if you run
fricas -nosman
?
Ralf
Waldek Hebisch
What is the output of 'ulimit -v' on your system? Also, 'ulimit -d'
may be relevant. AFAIK by default sbcl wants to reserve 20 GB of
address space at startup, this may be the problem.
Also, have you tried to run the AXIOMsys binary directly:
/usr/pkg/lib/fricas/target/i486--netbsdelf/bin/AXIOMsys
(this not what normal user would want to do, but may give better
error messages).
--
Waldek Hebisch
heb...@math.uni.wroc.pl