[ANN] GSL Shell new beta release with anti-gran graphics module

classic Classic list List threaded Threaded
126 messages Options
12345 ... 7
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Pavol Severa
the gsl-shell is really great

I have a little complaint however :)
complex numbers are not quite precise, e.g.

> =(1+1i)^2
1.2246063538224e-016+2i

The complex module from numlua doesn't have these problems; would it
be somehow possible to merge it with gsl-shell? (the module is very
small and independent of any libraries)

Best regards,
Pavol
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Francesco Abbate-2
In reply to this post by David Given
2009/12/3 David Given <[hidden email]>:
> Which version are you using? Do you have Lua bindings for the more
> exotic bits, such as the AGG widget set?

I'm using the GPL version of AGG since GSL Shell itselt is GSL.
Talking about the bindings, for the moment I've something very limited
but functional for doing most standard simple drawing of lines and
polygons. No binding for widgets or even to draw font glyphs.

For the other side I'm planning to extend the binding to cover more
functionalities but my objective is not to have a complete set of
bindings to AGG. The reason is that the library is very well designed
in C++ with templates and to convert everything in Lua is not
interesting. I think is more interesting to use AGG directly from
C/C++ library code and writing a slightly more higher level interface
depending on your application. This is what I've done and I'm planning
to extend.

Thank you for your remarks.

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

steve donovan
On Thu, Dec 3, 2009 at 3:24 PM, Francesco Abbate <[hidden email]> wrote:
> I'm using the GPL version of AGG since GSL Shell itselt is GSL.
> Talking about the bindings, for the moment I've something very limited
> but functional for doing most standard simple drawing of lines and
> polygons. No binding for widgets or even to draw font glyphs.

Well, let's think what a scientific plotting package needs, at least
as 'primitives' (in the sense of available through a Lua binding):
  - Axis and plot labels
  - ability to draw boxes with text in them (can then make legends)

Things like error bars can obviously be done with graphics primitives,
as can marks.

So text is important...

> bindings to AGG. The reason is that the library is very well designed
> in C++ with templates and to convert everything in Lua is not
> interesting.

But perhaps useful?

Not everything, of course! Once the basic primitives are available,
everything else can be done in Lua ;)

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Francesco Abbate-2
In reply to this post by Pavol Severa
2009/12/3 Pavol Severa <[hidden email]>:
> the gsl-shell is really great

thank you :-)

> I have a little complaint however :)
> complex numbers are not quite precise, e.g.
>
>> =(1+1i)^2
> 1.2246063538224e-016+2i
>
> The complex module from numlua doesn't have these problems; would it
> be somehow possible to merge it with gsl-shell? (the module is very
> small and independent of any libraries)

Asko's LNUM patch contains some known bugs that we should fix, any
help is welcome. Doug Rogers already sent me a patch to fix an error
with integer power of complex number but for the moment I didn't
commit it. I don't know if this is related to your problem, I will
need to look more closely.

I'm potentially interested in the numlua complex stuff but I would
like to understand how numlua manage complex numbers ? Are they
considered as native types ?

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Pavol Severa
>
> I'm potentially interested in the numlua complex stuff but I would
> like to understand how numlua manage complex numbers ? Are they
> considered as native types ?
>

they are userdata, in this sense it's no as pretty as Asko's patch
(numlua is an ordinary lua library)
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Francesco Abbate-2
In reply to this post by David Kastrup
2009/12/3 David Kastrup <[hidden email]>:

> And it can't even sensibly deal with multiple return values.
>
> local x=3
> fun2(|x| x*x,x)
>
> Is this
> fun2(function(x) return x*x end, x)
> or
> fun2(function(x) return x*x, x end)
> ?

I think you didn't understood the point. The notation

|<args>| <expr>

in meant to replace

function(<args>) return <expr> end

only in the case we have an expression and returned value. As you
should know, in Lua, a comma separated list of expression is *not* an
expression so there is no ambiguity whatsoever.

I repeat it:
- the comma ',' is *not* an operator in Lua
- a comma separated list of expression is *not* an expression

so there is no ambiguity. If you want to return multiple values you
should use the ordinary notation.

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

David Kastrup
Francesco Abbate <[hidden email]> writes:

> 2009/12/3 David Kastrup <[hidden email]>:
>> And it can't even sensibly deal with multiple return values.
>>
>> local x=3
>> fun2(|x| x*x,x)
>>
>> Is this
>> fun2(function(x) return x*x end, x)
>> or
>> fun2(function(x) return x*x, x end)
>> ?
>
> I think you didn't understood the point. The notation
>
> |<args>| <expr>
>
> in meant to replace
>
> function(<args>) return <expr> end
>
> only in the case we have an expression and returned value.

Tell that to Steve.  He proposed

    Also, for 'quoting' an expression so that it can be called in
    another context:

    timer(1000,|| print 'timer finished')

which does not really worry about expression and returned value.  That
may not have been _your_ intent, but you can bet that people will use it
like that because it is sooooo convenient.

The unsuspecting reader will think about some logical or here.  I just
don't think that Lua is the right language for people who find writing
in line noise elegant.

Anyway, functions in Lua can return more than one value.  So you are
trying to propose a syntax that can only be used for _some_ anonymous
Lua functions, not in general.  And that means that we have not just
syntactical sugar, but different semantics.

> As you should know, in Lua, a comma separated list of expression is
> *not* an expression so there is no ambiguity whatsoever.
>
> I repeat it:
> - the comma ',' is *not* an operator in Lua
> - a comma separated list of expression is *not* an expression
>
> so there is no ambiguity. If you want to return multiple values you
> should use the ordinary notation.

Making it different.  And there _still_ is the issue of needing to
introduce an operator precedence.

Is

|x| x or y

the same as

function(x) return x end or y

or

function(x) return x or y end

?

If you say the latter, then you need to extend the precedence hierarchy
of Lua by another level.  There are already 8 levels.

Is this syntax extension worth introducing another precedence level?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Luiz Henrique de Figueiredo
In reply to this post by Pavol Severa
> > =(1+1i)^2
> 1.2246063538224e-016+2i
>
> The complex module from numlua doesn't have these problems

I get the same results with my lcomplex. We're probably both using cpow.
Perhaps numlua converts z^2 to z*z (which does give 0+2i).
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Pavol Severa
2009/12/3 Luiz Henrique de Figueiredo <[hidden email]>:
>> > =(1+1i)^2
>> 1.2246063538224e-016+2i
>>
>> The complex module from numlua doesn't have these problems
>
> I get the same results with my lcomplex. We're probably both using cpow.
> Perhaps numlua converts z^2 to z*z (which does give 0+2i).
>

yes (it uses the usual algorithm for integer powers, cumputing z^2,
(z^2)^2, ((z^2)^2)^2 ... and multiplying the results; generally, all
it's algorithms seem to be optimal)
Reply | Threaded
Open this post in threaded view
|

Re[2]: [ANN] GSL Shell new beta release with anti-gran graphics module

Bulat Ziganshin
In reply to this post by Luiz Henrique de Figueiredo
Hello Luiz,

Thursday, December 3, 2009, 6:05:12 PM, you wrote:

you can try (1+1i)^4 with numlua

>> > =(1+1i)^2
>> 1.2246063538224e-016+2i
>>
>> The complex module from numlua doesn't have these problems

> I get the same results with my lcomplex. We're probably both using cpow.
> Perhaps numlua converts z^2 to z*z (which does give 0+2i).


--
Best regards,
 Bulat                            mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Luiz Henrique de Figueiredo
In reply to this post by Pavol Severa
> yes (it uses the usual algorithm for integer powers, cumputing z^2,
> (z^2)^2, ((z^2)^2)^2 ... and multiplying the results; generally, all
> it's algorithms seem to be optimal)

Exponentiation by squaring is a good and popular algorithm and it
is optimal in the asymptotic sense, but it's not stricly optimal:
http://en.wikipedia.org/wiki/Exponentiation_by_squaring#Alternatives_and_generalizations
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Francesco Abbate-2
In reply to this post by David Kastrup
2009/12/3 David Kastrup <[hidden email]>:
> If you say the latter, then you need to extend the precedence hierarchy
> of Lua by another level.  There are already 8 levels.
>
> Is this syntax extension worth introducing another precedence level?

Actually there is a shift/reduce conflict in the grammar since the expression
|x| x or y
can be parsed as:
(|x| x) or y
or
|x| (x or y)

But please note that for your example, there is no difference between
|x| x+y
and
|x| x or y
Since both '+' and 'or' are considered operators.

The answer is that once '|' args '|' is parsed Lua recursive descent
parser just look for an 'expr' and will eat (shift) everything that
looks as an expression. So something like
|x| x or y

will always be parsed as |x| (x or y) and no new precedence level has
been introduced.

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Francesco Abbate-2
In reply to this post by Luiz Henrique de Figueiredo
2009/12/3 Luiz Henrique de Figueiredo <[hidden email]>:
>> > =(1+1i)^2
>> 1.2246063538224e-016+2i
>>
>> The complex module from numlua doesn't have these problems
>
> I get the same results with my lcomplex. We're probably both using cpow.
> Perhaps numlua converts z^2 to z*z (which does give 0+2i).

We can discuss about the algorithm to calculate a power but for me
this is a printing problem. To have a not-exactly zero value can
happen because of how FP values works but in GSL shell I've designed a
smarter system to print a matrix, here an example:

> m = cnew(2,2,|k,j|(k+1i * j)^2) -- create a complex matrix
> =m -- print the matrix
[    2i -3+4i ]
[  3+4i    8i ]

As you can see there are no spurious 'almost zero' values.

For me the standard printing method of Lua for printing complex number
should be modified in order to take into account both the magnitude of
imaginary and real parts and to chop to zero the components if :

re_part < eps * z_norm or
im_part < eps * z_norm

where z_norm is sqrt(re_part^2+im_part^2) and eps is something like 10^-8.

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

David Kastrup
In reply to this post by Francesco Abbate-2
Francesco Abbate <[hidden email]> writes:

> 2009/12/3 David Kastrup <[hidden email]>:
>> If you say the latter, then you need to extend the precedence hierarchy
>> of Lua by another level.  There are already 8 levels.
>>
>> Is this syntax extension worth introducing another precedence level?
>
> Actually there is a shift/reduce conflict in the grammar

Which is bisonbabble for "we need another precedence level".

> since the expression
> |x| x or y
> can be parsed as:
> (|x| x) or y
> or
> |x| (x or y)
>
> But please note that for your example, there is no difference between
> |x| x+y
> and
> |x| x or y
> Since both '+' and 'or' are considered operators.

Depends on the precedence of the |...| operator.  If it is in between +
and or, there is a difference.

> The answer is that once '|' args '|' is parsed Lua recursive descent
> parser just look for an 'expr' and will eat (shift) everything that
> looks as an expression.

As long as you declare the expr reduce as higher precedence as the |
args | reduce.  Or just pray that the order of declaration will
implicitly do this for you.

> So something like
> |x| x or y
>
> will always be parsed as |x| (x or y) and no new precedence level has
> been introduced.

Just because you ignore shift/reduce conflicts and hope for the best, it
does not mean that they are not there.

Whether you explicitly state the precedence or cross fingers and pray
that bison does the right thing behind your back, the new precedence
level is there.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Norman Ramsey
In reply to this post by David Kastrup
 > steve donovan <[hidden email]> writes:
 >
 > > PS the more I play with things like |x| x*(x-1), I wish that this
 > > syntax was supported in vanilla Lua. A very convenient bit of
 > > syntactical sugar if you are fond of the functional style.
 >
 > function(x) return x*(x-1) end
 >
 > is terse enough not to pine for shortcuts looking like line noise.

No it's not.  I've written too much "\x -> x * (x-1)" to be satisfied
with standard Lua syntax.  This syntax, from Haskell, looks
like line noise only if you've never seen lambda calculus.

Look at the information design: in the standard Lua example you give,
there are 30 characters of which 8 are unique to this particular
function, and the rest are syntactic noise.  The Haskell version is 15
characters with 10 unique ones, or if you compress to "\x -> x*(x-1)"
(apples to apples), 13 characters of which 8 are unique to the
function.  The information density for the Haskell syntax is much higher.

Lua's standard syntax militates against anonymous functions, and it
often drives what would be one-line functions onto a second line.
For example this simple example does not fit in 80 columns:

  local sizes = table.map(function(s) return s:gsub('%A', ''):lower() end, names)

but

  local sizes = table.map(\s -> s:gsub('%A', ''):lower(), names)

fits easily and is (in my opinion) easier to read.

I recognize that Lua is not an expression-oriented language and that a
special syntax for functions does not meet Lua's goal of being easily
accessible to Pascal programmers.  But it frustrates me that Lua is a
functional language with full lexical closures and yet the syntactic
overhead for anonymous functions is a heavy burden.  (I'm also
frustrated that the library support for functional programming is
poor---table.map is a function I had to define myself.)


Norman Ramsey
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Pavol Severa
In reply to this post by Francesco Abbate-2
> We can discuss about the algorithm to calculate a power but for me
> this is a printing problem. To have a not-exactly zero value can
> happen because of how FP values works but in GSL shell I've designed a
> smarter system to print a matrix, here an example:
>
>> m = cnew(2,2,|k,j|(k+1i * j)^2) -- create a complex matrix
>> =m -- print the matrix
> [    2i -3+4i ]
> [  3+4i    8i ]
>
> As you can see there are no spurious 'almost zero' values.
>

sometimes it's nice to have arithmetic with (small) integers exact.
It's perhaps less useful for "complex integers", but still
(1+1i)^2==2i might be true

(but as I said - gsl-shell is great :)

-p
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

David Kastrup
In reply to this post by Norman Ramsey
Norman Ramsey <[hidden email]> writes:

>  > steve donovan <[hidden email]> writes:
>  >
>  > > PS the more I play with things like |x| x*(x-1), I wish that this
>  > > syntax was supported in vanilla Lua. A very convenient bit of
>  > > syntactical sugar if you are fond of the functional style.
>  >
>  > function(x) return x*(x-1) end
>  >
>  > is terse enough not to pine for shortcuts looking like line noise.
>
> No it's not.  I've written too much "\x -> x * (x-1)" to be satisfied
> with standard Lua syntax.  This syntax, from Haskell, looks
> like line noise only if you've never seen lambda calculus.

And other line noise looks like line noise only if you've never seen C.
Or BNF.  Or Python.  Or Perl.  Or awk.  Or ada.  Or APL.  Or Scheme.

> Look at the information design: in the standard Lua example you give,
> there are 30 characters of which 8 are unique to this particular
> function, and the rest are syntactic noise.  The Haskell version is 15
> characters with 10 unique ones, or if you compress to "\x -> x*(x-1)"
> (apples to apples), 13 characters of which 8 are unique to the
> function.  The information density for the Haskell syntax is much
> higher.

Information density is not a Lua design goal.  Use APL if you are
concerned about that.

> Lua's standard syntax militates against anonymous functions,

No, it doesn't.  It is one of the most concise _procedural_ languages in
existence for creating and accessing anonymous functions.

> and it often drives what would be one-line functions onto a second
> line.

Write APL.

> For example this simple example does not fit in 80 columns:
>
>   local sizes = table.map(function(s) return s:gsub('%A', ''):lower() end, names)
>
> but
>
>   local sizes = table.map(\s -> s:gsub('%A', ''):lower(), names)
>
> fits easily and is (in my opinion) easier to read.

For somebody not knowing the construct?  Hardly.

> I recognize that Lua is not an expression-oriented language and that a
> special syntax for functions does not meet Lua's goal of being easily
> accessible to Pascal programmers.  But it frustrates me that Lua is a
> functional language with full lexical closures and yet the syntactic
> overhead for anonymous functions is a heavy burden.

Lua is a _procedural_ language.  Which is why functions have a _return_
statement, all control structures _don't_ return values, and values are
_assigned_ to variables rather than bound.

> (I'm also frustrated that the library support for functional
> programming is poor---table.map is a function I had to define myself.)

So you are frustrated that Lua is not Haskell or Scheme.  Other people
are frustrated because it is not C++ or Ada.

I would be frustrated when Lua were not Lua.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Sam Roberts
On Thu, Dec 3, 2009 at 12:04 PM, David Kastrup <[hidden email]> wrote:
> Norman Ramsey <[hidden email]> writes:
>> (I'm also frustrated that the library support for functional
>> programming is poor---table.map is a function I had to define myself.)
>
> So you are frustrated that Lua is not Haskell or Scheme.  Other people
> are frustrated because it is not C++ or Ada.
>
> I would be frustrated when Lua were not Lua.


Francesco,

Obviously people feel stongly about syntax, eh! :-)

Personally, I am among those that wish that lua syntax for anonymous
functions was less verbose, too, so I understand why you would want to
extend the syntax for gslshell. One place where every keystroke
actually does count is interactive shells.

That aside, a practical thing you should consider is that you are
creating lua dialect, and code written in it is no longer portable.

I hope that the gsl module itself does not depend on your dialect, so
that it can be used in contexts outside of the "shell".

I tried to verify this by building the gsl module against the system
lua5.1 to see if I can use it independently of the shell, but I don't
have enough of its dependencies installed (or time), to do this now.

Do you expect the gsl module to be useable independently of your
shell? The graphing capability in particular caught my attention.

Cheers,
Sam
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Francesco Abbate-2
2009/12/3 Sam Roberts <[hidden email]>:
> Do you expect the gsl module to be useable independently of your
> shell? The graphing capability in particular caught my attention.

Hi Sam,

I'm glad that someone is willing to talk about GSL shell itself and
not about the syntax extension :-)

Actually, the Lua community demonstrated, till now, a very weak
interest on GSL shell but I've nevertheless made the effort to make
the GSL module fully usable from even with standard Lua binaries. If
you look at 'makeconfig' you will see the following lines:

ENABLE_COMPLEX = yes
BUILD_LUA_DLL = no

To have a 100% orthodox GSL module you should build it by disable the
complex number support and enable the build as a Lua DLL.
Unfortunately if you disable complex numbers you will miss important
submodules like FFT but other functions will be available. I recommend
anyway to enable at least support for complex numbers.

There is also the higher file 'igsl.lua' that gives access to some
basic facilities functions and it does depends on the |x| syntax. This
shouldn't be a problem because this module's purpose is to serve the
final user in the interactive shell and it is not needed to have
access to core GSL functionalities.

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Norman Ramsey
In reply to this post by David Kastrup
 > > No it's not.  I've written too much "\x -> x * (x-1)" to be satisfied
 > > with standard Lua syntax.  This syntax, from Haskell, looks
 > > like line noise only if you've never seen lambda calculus.
 >
 > And other line noise looks like line noise only if you've never seen C.
 > Or BNF.  Or Python.  Or Perl.  Or awk.  Or ada.  Or APL.  Or Scheme.

Come on, David---be fair.  Lambda calculus occupies a privileged
position.  Unlike Python, Perl, or APL, lambda calculus is 70 years
old, and it is the lingua franca of the functional-programming community.
People who are *interested* in programming with first-class functions
either are already familiar with lambda calculus or will soon learn
about it.

 > > Look at the information design: in the standard Lua example you give,
 > > there are 30 characters of which 8 are unique to this particular
 > > function, and the rest are syntactic noise.  The Haskell version is 15
 > > characters with 10 unique ones, or if you compress to "\x -> x*(x-1)"
 > > (apples to apples), 13 characters of which 8 are unique to the
 > > function.  The information density for the Haskell syntax is much
 > > higher.
 >
 > Information density is not a Lua design goal.  Use APL if you are
 > concerned about that.

I agree that Lua's goal is not to *maximize* information density.  
I believe Lua's goal is *appropriate* information density: there
should be enough keywords to guide beginners, but for experts, there
is not too much syntactic noise.  And I do think that in the case of
anonymous functions, Lua's design is out of balance: there is more
syntactic noise than is really tolerable, and what's going on is not
particularly helpful for beginners.

 > So you are frustrated that Lua is not Haskell or Scheme...

Kindly do not put words in my mouth.

 > I would be frustrated when Lua were not Lua.

But Lua is a moving target!  Over the course of its lifetime, Lua has
changed radically.  Do you want to return to upvalues with '%' syntax?
The introduction of lexically scoped closures was a serious change in
the language, and I think it unfortunate that this change was not
accompanied by a reconsideration of the syntax and the libraries in
light of this new feature.

I do not advocate for introducing Haskell syntax into Lua.
But I do advocate for more thought going into how Lua could be changed
the better to support functional programming---while remaining Lua.
Lua's design (and Roberto's book) show evidence of great effort put
into supporting object-oriented styles of programming in Lua.
I think it reasonable to ask that comparable effort be invested in
supporting functional styles of programming---while keeping Lua Lua.


Norman
12345 ... 7