Re: maxima on html page

maxima-admin <at> math.utexas.edu wrote on 02/28/2006 02:32:11 AM:

> Dear users of Maxima
> 
> I would like to know whether there are some scripts to include the 
> output of maxima into html page.

Yes, this can be done. One way to do this (the only way I know of)
is to install the wxmaxima user interface. You can download
wxmaxima from http://wxmaxima.sourceforge.net/. 

Barton

Re: maxima on html page

Hello Robert,

> I would like to know whether there are some scripts to include the
> output of maxima into html page.

There are several projects to do something like that -- see
http://maxima.sourceforge.net/relatedprojects.shtml
Of those, I like
http://www.et.byu.edu/~koj/maxima.html
See also the PHP scripts listed at
http://maxima.sourceforge.net/wiki/index.php/Maxima%20and%20Programming%20Languages
(by the same author as the Mediawiki stuff, but maybe not Mediawiki-specific.)

Hope this helps,
Robert Dodier

Re: maxima on html page

My suggestion is to produce TeX, and then post the document as pdf.
This is for production of static pages that you can view from
an internet browswer that knows about pdf.

The wikimedia link you indicate below suggest that somehow
you (running a browser) should allow a remote page
to execute maxima on your own machine, using commands from
that remote page.  This would be exceedingly insecure,
since maxima commands can run arbitrary instructions.

An alternative might be for maxima to generate xml or mathml.
do a google search on  maxima mathml xml
for more info.

RJF

Robert Marik wrote:

> Dear users of Maxima
>
> I would like to know whether there are some scripts to include the 
> output of maxima into html page.
>
> Something like 
> http://meta.wikimedia.org/wiki/User:Mafs/Computer_algebra but this 
> seems to be restricted on mediawiki only. I would like to know whether 
> there is a similar ready to use solution for html pages. I'm not 
> strong enough to write this myself (at least now), but I would like to 
> write some pages based on this for my students.
>

Re: Archiving somewhat important docs?

Re: maxima on html page

> An alternative might be for maxima to generate xml or mathml.

Along this line, there are a couple of packages to generate mathml
in the maxima/share/contrib directory of the Maxima distribution.

hth
Robert Dodier

Re: maxima on html page

Robert,

I'd be careful about using this script, or scripts like it. In particular
the variable

$maxima_blacklist

does not appear to contain the Maxima "system" command.  It appears that
an arbitrary user would be able to execute a system command, which (at a
very quick first read through) represents a rather large security hole.

I've tried to do something like this myself as part of

http://www.stack.bham.ac.uk

and this code is open source - with a "permit" rather than just a
"blacklist" approach to security.  I'm sorry I'm in such a rush today, but
I'd be careful about using this particular script!

Chris Sangwin
---------------------------------------------------------------
Maths, Stats & OR Network, part of the Higher Education Academy
School of Mathematics 
University of Birmingham, Birmingham, B15 2TT
+44 121 414 6197
---------------------------------------------------------------

On Tue, 28 Feb 2006, Robert Marik wrote:

> Dear users of Maxima
> 
> I would like to know whether there are some scripts to include the 
> output of maxima into html page.
> 
> Something like http://meta.wikimedia.org/wiki/User:Mafs/Computer_algebra 
> but this seems to be restricted on mediawiki only. I would like to know 
> whether there is a similar ready to use solution for html pages. I'm not 
> strong enough to write this myself (at least now), but I would like to 
> write some pages based on this for my students.
> 
> I googled the Internet without any result. Can you give me a few 
> pointers, please? Thank you.
> 
> Sincerely Robert Marik
> 
> _______________________________________________
> Maxima mailing list
> Maxima <at> math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
> 

Re: branch cut fixup for atanh(bfloat(x))

Greetings!

Just a quick update on an older related manner.

In gcl 2.7.0 (unreleased), I've recently found it useful to support
constants (in the 'si package) for +inf, -inf and nan.  These are
actually used as proxies for unbounded real type probing of functions
and type propagation in the compiler to good effect.  In so doing, I
discovered si::*print-nans*, which when set to t makes these
printable.  I've also provided #'si::isfinite.  So far no reading, nor
signed zero, but some convention (as long as it doesn't break ansi)
seems straightforward and even backportable to 2.6 conceivably, as
2.7. is not ready yet.

Take care,

"Robert Dodier" <robert.dodier <at> gmail.com> writes:

> Hi Ray, you wrote:
> 
> > I think there needs to be more discussion about this.  Some Lisps
> > support signed zeroes (cmucl, sbcl), others do not.  Maxima's
> > bigfloats don't support signed-zeroes.
> 
> I don't see how we can have any results which depend on the
> presence of signed zero, be it float, bigfloat, or otherwise.
> 
> On a theoretical level: CLHS doesn't require that CL implementations
> support signed zero. So if we want Maxima to run on a CL implementation
> we can't require any results to depend on the presence of signed zero.
> 
> On a practical level: GCL and Clisp (and doubtless other implementations)
> don't support signed zero. GCL could probably be talked into it.
> Clisp explicitly denies the existence of IEEE 754 special values.
> In any event, for any other implementations signed zero would be
> a portability issue. IEEE 754 can't be considered a standard de facto
> for CL floating point arithmetic.
> 
> I'm not in favor of providing a signed zero for floating point implementations
> which lack it. I think that implies the bigfloat implementation shouldn't
> have one either.
> 
> This isn't the end of the story from my pov but I'll let that be enough for now.
> 
> best,
> Robert
> 
> _______________________________________________
> Maxima mailing list
> Maxima <at> math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
> 
> 
> 

--

-- 
Camm Maguire			     			camm <at> enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: branch cut fixup for atanh(bfloat(x))

I believe the continuity requirements given in the various CL standards 
for 
the inverse trig functions are too complicated for symbolic computing. For
floating point evaluation, I propose that we define the inverse trig 
functions by
their   logarc forms (using log(-1)  = i %pi).  As far as I know, this is 
what Maxima has 
always done. Presumably,  all simplifications in Maxima are consistent 
with this choice.

 Proposed:

(1) For double floating point evaluation, we write functions 
maxima-branch-atanh, and
etc .  For an input that is on a branch cut, these functions would return 
a value that is
consistent  with the logarc form of the function. They should, however, 
use a numerically 
friendly version of the logarc form.   For inputs off the branches, just 
use the cl functions. 
All lisps would use this scheme. A Lisp that gives bad values off a branch
cuts is just plain unworthy.  Maybe this is what Robert suggested the 
other day.

(2) I'm not so familiar with big floats, but I think basically the same 
scheme should be
used: maxima-branch-big-atanh and etc.  The CL compliant atanh Ray wrote 
should
be restored --- that way Ray's  atanh function  and the cl:atanh function 
would
agree everywhere for compliant. Lisps.  The functions maxima-branch-atanh 
and maxima-branch-big-atanh  would mostly be identical.

Barton

Re: branch cut fixup for atanh(bfloat(x))

Hi Barton,

> For floating point evaluation, I propose that we define the inverse trig
> functions by their   logarc forms (using log(-1)  = i %pi).  As far as I know, this is
> what Maxima has always done. Presumably,  all simplifications in Maxima are
> consistent with this choice.

To the best of my knowledge, the prescribed CL branch cuts
coincide with Maxima's symbolic branch cuts.
So, whether by design or coincidence, we don't have to make
further choices here. But documenting Maxima's convention
is a really good idea.

> (1) For double floating point evaluation, we write functions
> maxima-branch-atanh, and etc .  For an input that is on a branch cut,
> these functions would return a value that is consistent  with the logarc
> form of the function. They should, however, use a numerically
> friendly version of the logarc form.   For inputs off the branches, just
> use the cl functions. All lisps would use this scheme.

OK, I'll rename ATANH-HACK, etc to MAXIMA-BRANCH-ATANH, etc,
and cut the per-implementation conditional stuff #+(or sbcl clisp ...)
and then that's taken care of. (I revised ATANH-HACK, etc to punt
to CL:ATANH, etc whenever the input is not on a branch cut.)

> (2) I'm not so familiar with big floats, but I think basically the same
> scheme should be used: maxima-branch-big-atanh and etc.

No, I don't think that's necessary. There was only one problem
in the bigfloat stuff --- the derivation of a bigfloat formula for
atanh applied an identity which fails when Im z = 0. I put in
a special case for that and now it should be OK for all Lisp
versions. There's nobody to punt to (we own the sole bigfloat
trig implementation) so I don't see a need to split off the code
for branch cuts, since it already does the right
thing (i.e., it agrees with the symbolic code).

Hope this helps,
Robert

Re: branch cut fixup for atanh(bfloat(x))

Hi Barton,

> For floating point evaluation, I propose that we define the inverse trig
> functions by their   logarc forms (using log(-1)  = i %pi).  As far as I know, this is
> what Maxima has always done. Presumably,  all simplifications in Maxima are
> consistent with this choice.

To the best of my knowledge, the prescribed CL branch cuts
coincide with Maxima's symbolic branch cuts.
So, whether by design or coincidence, we don't have to make
further choices here. But documenting Maxima's convention
is a really good idea.

> (1) For double floating point evaluation, we write functions
> maxima-branch-atanh, and etc .  For an input that is on a branch cut,
> these functions would return a value that is consistent  with the logarc
> form of the function. They should, however, use a numerically
> friendly version of the logarc form.   For inputs off the branches, just
> use the cl functions. All lisps would use this scheme.

OK, I'll rename ATANH-HACK, etc to MAXIMA-BRANCH-ATANH, etc,
and cut the per-implementation conditional stuff #+(or sbcl clisp ...)
and then that's taken care of. (I revised ATANH-HACK, etc to punt
to CL:ATANH, etc whenever the input is not on a branch cut.)

> (2) I'm not so familiar with big floats, but I think basically the same
> scheme should be used: maxima-branch-big-atanh and etc.

No, I don't think that's necessary. There was only one problem
in the bigfloat stuff --- the derivation of a bigfloat formula for
atanh applied an identity which fails when Im z = 0. I put in
a special case for that and now it should be OK for all Lisp
versions. There's nobody to punt to (we own the sole bigfloat
trig implementation) so I don't see a need to split off the code
for branch cuts, since it already does the right
thing (i.e., it agrees with the symbolic code).

Hope this helps,
Robert