@asmeurer @certik @skirpichev Thank you for introducing me to the world of
open source. I just have one question in mind. Could you please provide
feedback on my GSOC proposal so that I can make sure that all the problems
are patched by next time?
Thanks,
Aditya Shah
--
You received this
@asmeurer @certik I have posted my final proposal on melange. Could you please
take a look at it and provide suggestions
Thanks,
Aditya
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it,
Am 10.03.2014 02:28, schrieb Aditya Shah:
@asmeurer, I respectfully disagree. Using a python file to represent the
grammar forces the user to understand and know the format of the file.
Yes, but with a Python file he knows the format already.
Also, should the current Parser generator
@Jo thanks for chiming in. I understand your sentiment but from your reply,
I gather that you have properly understood my proposal. Firstly, adding
EBNF adds 1 extra layer which can anyways be overridden by an experienced
programmer such has yourself. Secondly, I propose to keep the extra layer
@Jo while I think the last of your concerns is valid, I would say that EBNF
is very popular in the field of theory of computation and programming
language principles. According to me, you would find more people who are
well versed in EBNF rather than knowing or wanting to learn modgrammar API.
Am 10.03.2014 12:19, schrieb Aditya Shah:
@Jo while I think the last of your concerns is valid, I would say that EBNF
is very popular in the field of theory of computation and programming
language principles. According to me, you would find more people who are
well versed in EBNF rather than
@Jo thanks for the swift reply. I'll try to explain my position to you.
Since, I come from a bit theoretical background, I do prefer to use EBNF to
manipulate grammars. As you said, that is a selected group of people and I
believe that. Also, on the suggestion of @asmeurer, if you read 6th last
Am 10.03.2014 12:41, schrieb Aditya Shah:
@Jo thanks for the swift reply. I'll try to explain my position to you.
Since, I come from a bit theoretical background, I do prefer to use EBNF to
manipulate grammars. As you said, that is a selected group of people and I
believe that. Also, on the
@Jo I think your concern regarding maintenance overhead is true, but then
it is true for all the software systems. I still maintain that adding the
extra layer does add some serious benefit. And as for the maintenance, I
think that some serious problems would arise when there is an issue of
@Jo I would also add that my claim that the Extra layer adds some benefit
is in the fact (which I already explained to you several posts back) that
most of the languages tend to share large portions of their grammar. So we
can simply merge the generic rules with the language specific rules to
Am 10.03.2014 19:26, schrieb Aditya Shah:
@Jo I would also add that my claim that the Extra layer adds some benefit
is in the fact (which I already explained to you several posts back) that
most of the languages tend to share large portions of their grammar.
If modgrammar isn't entirely
@Jo Okay let us assume that modgrammar allows us to share grammar. In that
case I have no problem to remove the EBNF dependency, although I would say
that it is a good thing to have around. Plus i haven't had the time to read
the entire documentation of modgrammar (too much coursework!). I
Am 10.03.2014 20:10, schrieb Aditya Shah:
@Jo Okay let us assume that modgrammar allows us to share grammar.
Okay.
Yeah. That's the implicit assumption I've been making; sorry for not
making that clear.
If it doesn't, the game changes.
In that
case I have no problem to remove the EBNF
@Jo thank you for your valuable insight. I will keep those points in mind
and I will definitely try out modgrammar first.
Regards,
Aditya Shah
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails
@Sachin Thanks. I have deleted the identical page. I will soon update the
page to include the sections of Mock API and Timeline.
Regards,
Aditya
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails
@asmeurer @skirpichev @certik @jo @srjoglekar246 I have completed my GSoc
proposal. You can find it
at
https://github.com/sympy/sympy/wiki/GSoC-2014-Application-Aditya-Shah-SymPy-Parsing-Framework.
Please review it and leave your suggestions below.
Thanks,
Aditya Shah
--
You received this
I agree about using a Python file. I think it's just question of using
Python syntax to represent the grammar.
Aaron Meurer
On Sun, Mar 9, 2014 at 12:04 PM, Aditya Shah adityasha...@gmail.com wrote:
@asmeurer @skirpichev @certik @jo @srjoglekar246 I have completed my GSoc
proposal. You can
@asmeurer, I respectfully disagree. Using a python file to represent the
grammar forces the user to understand and know the format of the file.
Also, should the current Parser generator Framework needs be replaced in
future (discontinued or any similar reason), it would cause much
With what you are suggesting they also have to know the format of the file.
Probably we should allow EBNF, but should allow users to create their
own grammars directly using the Python objects that the EBNF would be
internally converted to.
Aaron Meurer
On Sun, Mar 9, 2014 at 8:28 PM, Aditya
Well I think that is not a problem at all. In case the user wants to
directly skip to the part of generating the grammar as a python code,
he/she can do so. Write the correct grammar file and and jump to step 3
i.e. use the PGF to generate the parser. The rest of the things remain
same. So I
@asmeurer @skirpichev @certik @jo I have drafted a proposal for my project.
You can find it
at
https://github.com/sympy/sympy/wiki/GSoC-2014-Application-Aditya-Shah-SymPy-Parsing-Framework.
Please review it and leave your suggestions below.
Thanks,
Aditya
PS- I have yet to add the timeline
Nice proposal. You may want to add a section showing a rough mock-prototype
(API) of your work. This will make it easier for others to understand what
you are aiming at. Also, you seem to have made two identical wiki pages for
your proposal. Delete one of them.
On Sunday, February 16, 2014
@Jo Thanks a lot! The last post cleared all things up. So basically, I can
enforce a standardized grammar and implement that used the likes of
modgrammar library which I think is quite convenient and suitable for the
task. I need to define the rules of the grammar and in such a way that any
Am 07.03.2014 12:47, schrieb Aditya Shah:
@Jo Thanks a lot! The last post cleared all things up. So basically, I can
enforce a standardized grammar and implement that used the likes of
modgrammar library which I think is quite convenient and suitable for the
task. I need to define the rules of
@Jo Thanks again for the clarifications. I did some research and I observed
that conversion from Math Spec Languages to Sympy equivalent can be done
via the use of RE themselves. So this will allow for a very efficient
grammar(RE are manifestations of FSAs and the their conversions to CFGs is
Am 07.03.2014 14:23, schrieb Aditya Shah:
@Jo Thanks again for the clarifications. I did some research and I observed
that conversion from Math Spec Languages to Sympy equivalent can be done
via the use of RE themselves.
I doubt that that's possible for all cases.
This is one of the typical
@Jo, My philosophy is as much automation as possible. Now just for the sake
of argument consider this. We have 2 Math Spec languages A and B. Since
both are means to the same end, they differ only in subtle places. While
that might not be the case always, let us assume that it is so. By using
Am 06.03.2014 08:55, schrieb Aditya Shah:
@Jo Parser generators sure exist. They take in grammar specs and generate
parsers for that grammar. But the idea here is that we create our own
custom generator framework which takes in a predefined type of
rules(grammar) and then takes advantage of the
@Jo Well I am still unconvinced of your opinion that such the strategy that
I intend to adopt will fail in the long run. I'll give you my reasons for
it. Firstly, we are just talking about Math Spec Languages not generalized
programming languages with complex rules. I have noticed that the
Am 06.03.2014 20:47, schrieb Aditya Shah:
@Jo Well I am still unconvinced of your opinion that such the strategy that
I intend to adopt will fail in the long run. I'll give you my reasons for
it. Firstly, we are just talking about Math Spec Languages not generalized
programming languages with
On Wed, Mar 5, 2014 at 12:09 AM, Aditya Shah adityasha...@gmail.com wrote:
I have developed a raw block diagram and an API to explain my concept. It
goes as follows:
Suppose, we want to write a parser for the MathML Language. We need to
create 2 things:
1. A Spec File (this contains the
@Certik Thanks for replying. I think that we might be able to make quite a
robust parser after all. Well I do agree that it may escape some very
peculiar use cases but still according to me such a parser (and quite fully
functional at that) is better than having no parser.
I am currently
On Wed, Mar 5, 2014 at 10:10 AM, Aditya Shah adityasha...@gmail.com wrote:
@Certik Thanks for replying. I think that we might be able to make quite a
robust parser after all. Well I do agree that it may escape some very
peculiar use cases but still according to me such a parser (and quite fully
@Certik. Sure thing, I'll draft a proposal on the wiki.
Thanks,
Aditya
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to
Am 05.03.2014 18:10, schrieb Aditya Shah:
@Certik Thanks for replying. I think that we might be able to make quite a
robust parser after all. Well I do agree that it may escape some very
peculiar use cases but still according to me such a parser (and quite fully
functional at that) is better
@Joachim Durchholz, thanks a lot for your warnings. I do understand your
concerns but I think that I will be able to create the desired thing. I do
admit that the final product may contain a few bugs but I will try to keep
it as bug free as possible
And BTW, for the parser structure I intend
Am 05.03.2014 20:06, schrieb Aditya Shah:
And BTW, for the parser structure I intend to use Compilers by Aho, Lam,
Sethi, Ullman as a reference book(popularly known as The Dragonbook).
Oh, that's *ancient*.
If
anyone can suggest a better reference material please comment below.
Well,
Am 05.03.2014 21:48, schrieb Joachim Durchholz:
Am 05.03.2014 20:06, schrieb Aditya Shah:
If
anyone can suggest a better reference material please comment below.
I forgot: GLR-style parsers exist in two varieties, early Earley style
and newer, Tomita style. Tomita is better than Earley
@Jo Thank you, that was quite enlightening. Now as to the parsers, they are
not exactly parsers. We do have rudimentary parsers for Mathematica and
Maxima in sympy right now. If you take a look at their code, you can see
that they are not CFGs but simple RE rules. They perform very good under
Am 06.03.2014 03:26, schrieb Aditya Shah:
So
the aim here right now is to generate a parser(or a converter as you may
call it) that converts that snippet to equivalent python/sympy code. After
that is successfully done, we can move onto a generic parser framework that
can convert entire programs
@Jo Parser generators sure exist. They take in grammar specs and generate
parsers for that grammar. But the idea here is that we create our own
custom generator framework which takes in a predefined type of
rules(grammar) and then takes advantage of the similarities between the
different
On Tue, Feb 25, 2014 at 7:51 PM, Aditya Shah adityasha...@gmail.com wrote:
As you have stated previously, the framework need not detect the language
that it is parsing from and the user provides input regarding that. Now,
since this is a Mathematica string, we directly specify it to be so. In
@Certik Thanks a lot for replying. Well, as to your first question, I
intend to develop a framework that can generate a parser. What we have in
mathematica.py is a parser. So I want to take that one step further and
devise a standard mechanism by which any developer can extend the enormous
I have developed a raw block diagram and an API to explain my concept. It
goes as follows:
Suppose, we want to write a parser for the MathML Language. We need to
create 2 things:
1. A Spec File (this contains the mappings between MathML features and
corresponding sympy features (although not
@asmeurer @skirpichev So how do you feel about the above mentioned idea? A
generic parsing framework for Sympy to facilitate extending Sympy to
similar Math Spec Languages?
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group
Can you elaborate on the idea a little more explicitly. How would it
parse ArcSin[Sqrt[x]] for example?
Aaron Meurer
On Mon, Feb 24, 2014 at 8:22 PM, Aditya Shah adityasha...@gmail.com wrote:
Can anyone please comment on the feasibility of my idea stated above?
Thanks,
Aditya Shah
--
You
On Monday, February 24, 2014 7:38:22 AM UTC+4, Aditya Shah wrote:
Then I have another idea in mind. A language specifier configuration file
can be given as input by the developer and sympy takes care of the rest.
It's quite like yacc. This would essentially reduce the workload of the
Not exact specification, but there is a proper syntax definition. Please
take a look here:
https://reference.wolfram.com/mathematica/tutorial/TheSyntaxOfTheMathematicaLanguage.html
So here what differs is that all the inbuilt functions start with a Capital
letter, Also inverse trignometric
Can anyone please comment on the feasibility of my idea stated above?
Thanks,
Aditya Shah
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Hello.
How will you evaluate thé probability of à language?
Christophe, a simple user.
Le 23 févr. 2014 04:19, Aditya Shah adityasha...@gmail.com a écrit :
I would like to discuss my plan of action to develop the general parsing
framework for Sympy. Right now the code is quite messy. The
I have concerns similar to Christophe's. I haven't done work on the parsing
module, so cannot comment on that part. However, a natural-language
processing toolkit (English, for now) for SymPy may need extensive NLP,
which I don't think belongs in SymPy. However, you _can_ think of building
Hi Christophe,
I would like to illustrate the process with an example. If the input string
is Sqrt[x], since such a format for square root function belongs only in
Mathematica spec, we can then proceed to convert the string to its sympy
equivalent. If the string is \sqrt[x], the leading \
Hi Sachin,
While I do agree that inclusion of NLP parser would be a big project in
itself. But if implemented even as an add-on, it can be used to augment the
capabilities of Sympy Live.
Btw just a quick question: Can such a project be considered for GSOC by
sympy?
Thanks,
Aditya Shah
--
Thanks for the explanations.
2014-02-23 14:46 GMT+01:00 Aditya Shah adityasha...@gmail.com:
Hi Sachin,
While I do agree that inclusion of NLP parser would be a big project in
itself. But if implemented even as an add-on, it can be used to augment the
capabilities of Sympy Live.
Btw just a
@asmeurer https://github.com/asmeurer,
@srjoglekar246https://github.com/srjoglekar246, @skirpichev.
Please review the idea and comment upon it so that a discussion can ensue.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this
Language heuristics seem like a waste of time to me. The user can just
input what language the expression is. If we need to guess (like in
SymPy Gamma), we can just try parsing with all the parsers and see
which ones worked.
The real issue is how to unify the disjoint code, as you pointed out,
so
Then I have another idea in mind. A language specifier configuration file can
be given as input by the developer and sympy takes care of the rest. It's quite
like yacc. But this would essentially reduce the workload of the developer
substantially regarding three development of a new parser.
Then I have another idea in mind. A language specifier configuration file
can be given as input by the developer and sympy takes care of the rest.
It's quite like yacc. This would essentially reduce the workload of the
developer substantially regarding the development of a new parser.
Aditya
Hey Aaron, I have solved the issue 1160 mentioned at
https://code.google.com/p/sympy/issues/detail?id=1160q=label%3AParsingcolspec=ID%20Type%20Status%20Priority%20Milestone%20Reporter%20Summary%20Stars
Please can you tell me the exact procedure to push the patch?
Thanks,
Aditya Shah
--
You
Btw i just submitted a PR at
https://github.com/sympy/sympy/pull/2947
Is that it or is anything missing?
Thanks,
Aditya Shah
On Friday, 21 February 2014 23:09:40 UTC+5:30, Aditya Shah wrote:
Hey Aaron, I have solved the issue 1160 mentioned at
Thanks for the reply Sachin. However I am quite unsure about the nature of
the PR. Is is supposed to be a patch or introduction of some new
functionality or something else altogether? Can you please clarify on that
matter?
Thanks,
Aditya Shah
--
You received this message because you are
Theres no restriction on that as such. Its basically just for the
organization people to see that you are okay with the basics and are
comfortable (atleast somewhat) with the SymPy codebase. Whether its a bug
fix or functionality addition is upto you - as long as you add/modify the
relevant
No, this is incorrect. You must have at least one PR *pushed into the
codebase*. See
https://github.com/sympy/sympy/wiki/gsoc-2014-application-template.
Perhaps you are confused by the deadline mismatch. The deadline for
opening the PR is the same as the student application deadline (March
21),
Thanks for the clarification Aaron. I'll keep the deadlines in mind.
On Wednesday, 19 February 2014 04:50:26 UTC+5:30, Aaron Meurer wrote:
No, this is incorrect. You must have at least one PR *pushed into the
codebase*. See
64 matches
Mail list logo
