Hi,
I am Bharath M R, a student of Electrical Engineering at IIT Madras.
I would like to apply for the building the gamma.sympy.org site. I would
like to
implement the following things as part of the project.
1)Basic parsing
Something like solve x**2==1, integrate x**2 will be parsed and
inter
This looks like a good start. Did you think about ways that some of
these ideas can be used in SymPy Live too?
On Thu, Mar 8, 2012 at 9:55 AM, Bharath M R wrote:
> Hi,
> I am Bharath M R, a student of Electrical Engineering at IIT Madras.
> I would like to apply for the building the gamma.sympy.
On 8 March 2012 18:25, Aaron Meurer wrote:
> This looks like a good start. Did you think about ways that some of
> these ideas can be used in SymPy Live too?
>
> On Thu, Mar 8, 2012 at 9:55 AM, Bharath M R wrote:
>> Hi,
>> I am Bharath M R, a student of Electrical Engineering at IIT Madras.
>> I
On Thu, Mar 8, 2012 at 10:33 AM, krastanov.ste...@gmail.com
wrote:
> On 8 March 2012 18:25, Aaron Meurer wrote:
>> This looks like a good start. Did you think about ways that some of
>> these ideas can be used in SymPy Live too?
>>
>> On Thu, Mar 8, 2012 at 9:55 AM, Bharath M R wrote:
>>> Hi,
>
On Thursday, March 8, 2012 10:55:34 PM UTC+5:30, Aaron Meurer wrote:
>
> This looks like a good start. Did you think about ways that some of
> these ideas can be used in SymPy Live too?
>
> On Thu, Mar 8, 2012 at 9:55 AM, Bharath M R
> wrote:
> > Hi,
> > I am Bharath M R, a student of Electric
On Fri, Mar 9, 2012 at 6:13 AM, Bharath M R wrote:
>
>
> On Thursday, March 8, 2012 10:55:34 PM UTC+5:30, Aaron Meurer wrote:
>>
>> This looks like a good start. Did you think about ways that some of
>> these ideas can be used in SymPy Live too?
>>
>> On Thu, Mar 8, 2012 at 9:55 AM, Bharath M R
> What we have now is very limited, and the way that it's done will not
> work. We have two kinds of parsers in SymPy right now. There's
> sympify(), which parses an expression in Python grammar and converts
> unknown variables into Symbols, literals into corresponding SymPy
> types (like 1 to
Hello,
On Sat, Mar 10, 2012 at 8:11 PM, Bharath M R wrote:
>
>> What is really needed is a parser, that goes through an expression,
>> and builds a syntax tree out of it. What you need to do is build
>> something that is modular enough that you can easily plug in new rules
>> to it (like "integr
On Sunday, March 11, 2012 12:00:52 AM UTC+5:30, scolobb wrote:
>
> Hello,
>
> On Sat, Mar 10, 2012 at 8:11 PM, Bharath M R
> wrote:
> >
> >> What is really needed is a parser, that goes through an expression,
> >> and builds a syntax tree out of it. What you need to do is build
> >> something
Am 11.03.2012 05:27, schrieb Bharath M R:
@Sergiu I was looking at top down operator precedence parsing for the task
That's the technique where the grammar requires the least contortions.
It also composes well: you can define sublanguages (such as arithmetic
and boolean logic), and as long as
On Sunday, March 11, 2012 7:00:15 PM UTC+5:30, Joachim Durchholz wrote:
>
> Am 11.03.2012 05:27, schrieb Bharath M R:
> > @Sergiu I was looking at top down operator precedence parsing for the
> task
>
> That's the technique where the grammar requires the least contortions.
> It also composes wel
Am 11.03.2012 17:58, schrieb Bharath M R:
Thanks for the reply. The parser is for building the web interface similar
to
Wolfram Alpha for SymPy. Basically I want to parse things like
integrate x**2 dx
roots x**2==1
Won't the operator precedence parsing be sufficient for this?
These two are ea
On Sun, Mar 11, 2012 at 6:58 PM, Bharath M R wrote:
>
> On Sunday, March 11, 2012 7:00:15 PM UTC+5:30, Joachim Durchholz wrote:
>>
>> Am 11.03.2012 05:27, schrieb Bharath M R:
>> > @Sergiu I was looking at top down operator precedence parsing for the
>> > task
>>
>> That's the technique where the
On Sun, Mar 11, 2012 at 6:27 AM, Bharath M R wrote:
>
> @Sergiu I was looking at top down operator precedence parsing for the task
> (http://javascript.crockford.com/tdop/tdop.html) . One of the important task
> is to
> come up with the grammar. Is it possible to meet you on IRC sometime to
> disc
> I've never had any serious experience with operator precedence
> parsing, but I have the intuition that this technique is going to be
> quite unwieldy if we would like to go beyond simple expressions like
> the ones you have shown.
>
> I'd advocate a more general approach to this problem, and n
Am 11.03.2012 21:40, schrieb Sergiu Ivanov:
I've never had any serious experience with operator precedence
parsing, but I have the intuition that this technique is going to be
quite unwieldy if we would like to go beyond simple expressions like
the ones you have shown.
It's a trade-off. The dec
Thanks for the helpful advice. So which method would you recommend
using for this? Expression size isn't an issue for SymPy Gamma, by
the way, as we are limited by what the App Engine can handle anyway
(You'll find that WolframAlpha can't handle very large or even
moderately expressions either).
On Tue, Mar 13, 2012 at 6:16 AM, Bharath M R wrote:
>
> Yeah I think I should use some parser generators. But doesn't it introduce
> a
> dependency on the parser generator. Is it ok to have this dependency?
Usually, you only use the parser generator to produce the code of the
parser. This result
On Tue, Mar 13, 2012 at 9:42 AM, Joachim Durchholz wrote:
> Am 11.03.2012 21:40, schrieb Sergiu Ivanov:
>
> Here's a run-down of available techniques:
>
> Operator-precedence:
> Somewhat limited (but not as badly as many people think).
> Extending the grammar requires the ability to grasp the conc
On Tue, Mar 13, 2012 at 10:22 AM, Aaron Meurer wrote:
>
> Thanks for the helpful advice. So which method would you recommend
> using for this? Expression size isn't an issue for SymPy Gamma, by
> the way, as we are limited by what the App Engine can handle anyway
> (You'll find that WolframAlpha
Am 13.03.2012 15:51, schrieb Sergiu Ivanov:
On Tue, Mar 13, 2012 at 6:16 AM, Bharath M R wrote:
Yeah I think I should use some parser generators. But doesn't it introduce
a
dependency on the parser generator. Is it ok to have this dependency?
Usually, you only use the parser generator to pro
Maybe this will be useful for the project: http://www.nltk.org/
On Tue, Mar 13, 2012 at 2:55 PM, Joachim Durchholz wrote:
> Am 13.03.2012 15:51, schrieb Sergiu Ivanov:
>
>> On Tue, Mar 13, 2012 at 6:16 AM, Bharath M R
>> wrote:
>>>
>>>
>>> Yeah I think I should use some parser generators. But do
Am 13.03.2012 17:24, schrieb Sergiu Ivanov:
Apparently, operator precedence parsing together with some additional
processing of the string may be enough. This may be a good start.
For the umteenth time, NO string processing. You'll be going straight to
ambiguity hell if you do that - you'll e
Am 13.03.2012 20:05, schrieb Jorge Cardona:
Maybe this will be useful for the project: http://www.nltk.org/
I have only passing knowledge of natural language processing.
I fear that it is going to devote a lot of effort to stemming and
similar activities that bear no fruit in a SymPy context.
Am 13.03.2012 09:22, schrieb Aaron Meurer:
Thanks for the helpful advice. So which method would you recommend
using for this?
Hard to tell right now. We need to see what grammars we want to support.
So the first step would probably be to draw up all the grammar rules for
features present (an
On Tue, Mar 13, 2012 at 9:16 PM, Joachim Durchholz wrote:
> Am 13.03.2012 17:24, schrieb Sergiu Ivanov:
>
>> Apparently, operator precedence parsing together with some additional
>> processing of the string may be enough. This may be a good start.
>
>
> For the umteenth time, NO string processing
On Tue, Mar 13, 2012 at 1:46 PM, Joachim Durchholz wrote:
> Am 13.03.2012 09:22, schrieb Aaron Meurer:
>
>> Thanks for the helpful advice. So which method would you recommend
>> using for this?
>
>
> Hard to tell right now. We need to see what grammars we want to support.
>
> So the first step wo
Am 13.03.2012 17:07, schrieb Sergiu Ivanov:
Thank you for the very good overview; I wish I had been given
something like this in my course on compilers.
You're welcome :-)
Some of that knowledge came with bruises.
A parser generator is required for LL and LR variants.
The problem with these
Am 13.03.2012 21:17, schrieb Aaron Meurer:
So would it help to start a wiki page where we list all the things we
want to support, in the order of importance?
> Here's a beginning of that list (in order):
- SymPy syntax: This is probably obvious, but correct SymPy/Python
syntax should always b
On Tue, Mar 13, 2012 at 2:58 PM, Joachim Durchholz wrote:
> Am 13.03.2012 21:17, schrieb Aaron Meurer:
>
>> So would it help to start a wiki page where we list all the things we
>> want to support, in the order of importance?
>
>> Here's a beginning of that list (in order):
>>
>>
>> - SymPy syntax
Am 13.03.2012 23:40, schrieb Aaron Meurer:
I see that http://en.wikipedia.org/wiki/Earley_parser lists four different
Python implementations, one of them just 150 lines.
Just about all of them are relatively short.
Ah, good to know, I checked only the last one because it was announced
as sho
On Wednesday, March 14, 2012 2:28:12 AM UTC+5:30, Joachim Durchholz wrote:
>
> Am 13.03.2012 21:17, schrieb Aaron Meurer:
> > So would it help to start a wiki page where we list all the things we
> > want to support, in the order of importance?
> > Here's a beginning of that list (in order):
> >
On Tue, Mar 13, 2012 at 10:18 PM, Joachim Durchholz wrote:
> Am 13.03.2012 17:07, schrieb Sergiu Ivanov:
>
>>> A parser generator is required for LL and LR variants.
>>> The problem with these is that they usually come with their own syntax,
>>> so
>>> using them requires learning new skills.
>>
>
On Wed, Mar 14, 2012 at 3:15 PM, Sergiu Ivanov
wrote:
>
>In this
> case the user thinks that all words are meaningless
Oops, I wanted to say "the user thinks all words are meaningful".
Sorry :-(
Sergiu
--
You received this message because you are subscribed to the Google Groups
"sympy" group
Am 14.03.2012 09:43, schrieb Bharath M R:
I am a complete noob here. But if we are trying to implement wide array of
syntaxes,
can't we write separate parsers for each of them and combine them with a
try exception statements
Say we have a latex input .
Then
try:
sympify(input)
except Interpr
Am 14.03.2012 14:15, schrieb Sergiu Ivanov:
On the other hand, you can switch the parsing techniques much easier
if you are using parser generators.
No, not at all.
All parser generators have a different input syntax, different mechanisms to
attach semantic actions, etc.
That's a decision that
I think writing the parser would be a GSOC project in itself. Also, I think
I don't have the expertise to write the parser.
Though it is possible that I can read up and try to implement, I think I
won't be able to do a good job of it.
I would like to take up the take up the task of implementing
Sure, it can be a separate project if you want, though in that case,
you might also look into ways that you could improve SymPy Live in
parallel.
Aaron Meurer
On Sat, Mar 17, 2012 at 12:35 AM, Bharath M R wrote:
> I think writing the parser would be a GSOC project in itself. Also, I think
> I do
On Fri, Mar 16, 2012 at 12:19 AM, Joachim Durchholz wrote:
>
> However, I would not stick with the first syntax that gives a match. It's
> entirely possible that two different syntaxes give a valid parse.
> So: try all syntaxes. Check if they give the same abstract syntax (logical
> structure, if
On Fri, Mar 16, 2012 at 12:58 AM, Joachim Durchholz wrote:
> Am 14.03.2012 14:15, schrieb Sergiu Ivanov:
>
>> I see. I thought the differences in syntax were not that influential.
>
>
> Well, it's not just syntax. The way you express semantic actions can have a
> deep impact.
> It's alike the sim
Am 17.03.2012 13:25, schrieb Sergiu Ivanov:
On Fri, Mar 16, 2012 at 12:58 AM, Joachim Durchholz wrote:
Am 14.03.2012 14:15, schrieb Sergiu Ivanov:
I see. I thought the differences in syntax were not that influential.
Well, it's not just syntax. The way you express semantic actions can hav
Am 17.03.2012 13:03, schrieb Sergiu Ivanov:
On Fri, Mar 16, 2012 at 12:19 AM, Joachim Durchholz wrote:
However, I would not stick with the first syntax that gives a match. It's
entirely possible that two different syntaxes give a valid parse.
So: try all syntaxes. Check if they give the same a
On Sat, Mar 17, 2012 at 11:57 PM, Joachim Durchholz wrote:
> Am 17.03.2012 13:25, schrieb Sergiu Ivanov:
>
>> Hm, the difference is actually much more fundamental than my
>> imagination would paint it to me :-(
>
>
> Oh, but the difference between C and Pascal is far from fundamental!
> If you wan
On Sat, Mar 17, 2012 at 11:57 PM, Joachim Durchholz wrote:
> Am 17.03.2012 13:03, schrieb Sergiu Ivanov:
>
>> In this case we might collect the statistics to
>>
>> see which of the grammars is usually chosen in ambiguous situations so
>> that we will be able to alter the defaults correspondingly.
Am 18.03.2012 12:02, schrieb Sergiu Ivanov:
I'm a bit sceptical about trying to get correlations out of user input.
Repeating myself: User input is multi-channel high-noise input, extracting
useful signals from that is hard.
Does your scepticism mean that you don't expect much useful
informatio
Hi, has anything more happened on this? In particular I'm interested in
any Latex parsing that can be done. I notice the github page
https://github.com/sympy/sympy/wiki/Parsing hasn't been updated in 2 years.
On Monday, 19 March 2012 09:52:14 UTC+13, Joachim Durchholz wrote:
>
> Am 18.03.2012
No projects on parsing were ever accepted for GSoC. It is still
something that we want to improve, but no major work has been done on
it.
Aaron Meurer
On Wed, Nov 26, 2014 at 7:15 PM, Arie Lakeman wrote:
> Hi, has anything more happened on this? In particular I'm interested in any
> Latex parsi
47 matches
Mail list logo
