I've been hacking around with sympy for the past few weeks and I've
managed to put together a Boolean algebra module. The module in its
current state contains classes for the basic Boolean functions, along
with a simplifier which simplifies expressions based on the
Quine-McCluskey algori
Did anyone try the module ? I'm quite curious to hear from the group,
because this is my first real contribution to sympy.
On Mar 12, 8:40 pm, Akshay Srinivasan
wrote:
> I've been hacking around with sympy for the past few weeks and I've
> managed to put together a Boolea
.
>
>
> On Mar 12, 8:40 pm, Akshay Srinivasan
> wrote:
>> I've been hacking around with sympy for the past few weeks and I've
>> managed to put together a Boolean algebra module. The module in its
>> current state contains classes for the basic Boolean
r 12, 8:40 pm, Akshay Srinivasan
> > wrote:
> >> I've been hacking around with sympy for the past few weeks and I've
> >> managed to put together a Boolean algebra module. The module in its
> >> current state contains classes for the basic Boolean fu
gt; > On Mar 12, 8:40 pm, Akshay Srinivasan
>> > wrote:
>> >> I've been hacking around with sympy for the past few weeks and I've
>> >> managed to put together a Boolean algebra module. The module in its
>> >> current state contains clas
t;> because this is my first real contribution to sympy.
>>>>
>>>> On Mar 12, 8:40 pm, Akshay Srinivasan
>>>> wrote:
>>>>
>>>>> I've been hacking around with sympy for the past few weeks and I've
>>&g
> >>> On Fri, Mar 13, 2009 at 7:43 AM, Akshay Srinivasan
>
> >>> wrote:
>
> >>>> Did anyone try the module ? I'm quite curious to hear from the group,
> >>>> because this is my first real contribution to sympy.
>
> >>&
Hi Akshay!
On Sat, Mar 14, 2009 at 11:22 PM, Akshay Srinivasan
wrote:
> I got git to work, and am happy to send in my patch. This one solves
> the above mentioned problems, and simplifies expressions recursively.
>
> Note: boolalg/test.py is not a test! Its an example of usage.
First my apology
Yes , I agree that it'd better to merge this into sympy.core.logic ,
but I'm concerned about the usability. I'm not sure by how much
facts.py would have to be changed, if this is done. I'll try merging
it, over the week.
Is it alright to break backward compatibility with sympy.core.logic? I
guess
On Mon, Mar 16, 2009 at 9:58 PM, Akshay Srinivasan
wrote:
>
> Yes , I agree that it'd better to merge this into sympy.core.logic ,
> but I'm concerned about the usability. I'm not sure by how much
> facts.py would have to be changed, if this is done. I'll try merging
> it, over the week.
> Is it
Ondrej Certik wrote:
> On Mon, Mar 16, 2009 at 9:58 PM, Akshay Srinivasan
> wrote:
>
>> Yes , I agree that it'd better to merge this into sympy.core.logic ,
>> but I'm concerned about the usability. I'm not sure by how much
>> facts.py would have to be changed, if this is done. I'll try mergin
I had to make some changes to sympy.core.assumptions and
sympy.core.facts to make them work. And one thing I observed is that,
sympy.core.facts deviates from the normal coding fashion in sympy. For
instance,
.
if k[:1] == '!':
..
instead of
..
if isinstance(k,Not):
Any spe
On Thu, Mar 19, 2009 at 7:19 AM, Neptune wrote:
>
> I had to make some changes to sympy.core.assumptions and
> sympy.core.facts to make them work. And one thing I observed is that,
> sympy.core.facts deviates from the normal coding fashion in sympy. For
> instance,
> .
> if k[:1] == '!':
This is what I do to run tests.
##
[nept...@phoenix sympy] bin/test -v sympy/core/
= test process starts
==
executable: /usr/bin/python (2.6.1-final-0)
sympy/core/tests/test_arit.py[41]
test_bug1 ok
test_Symbol ok
test_ari
On Thu, Mar 19, 2009 at 8:51 AM, Neptune wrote:
>
> This is what I do to run tests.
> ##
> [nept...@phoenix sympy] bin/test -v sympy/core/
> = test process starts
> ==
> executable: /usr/bin/python (2.6.1-final-0)
>
> symp
Yes it worked! Thanks for the patch Ondrej, that did it.
I'm beginning to wonder if making sympy.core.facts to use the module I
wrote , is a good idea. From some initial tests, this seems to make
the import time noticeably more. Of course I can't be sure that this
is the reason- mainly because I
On Thu, Mar 19, 2009 at 10:41 AM, Akshay Srinivasan
wrote:
>
> Yes it worked! Thanks for the patch Ondrej, that did it.
Well, but still it's fishy. Could you please execute that test by
hand? E.g. undo the patch and do:
bin/test sympy/core/tests/test_arit.py -k test_pow2
if it hangs, then try
Its probably because of my crude merging. I have to tweak both
sympy.core.assumptions as well as sympy.core.facts to make use of my
module instead of sympy.core.logic . Turned out, taking the power of
(-x) put it into a infinite loop. I'm still working on it. This isn't
an issue with the current v
Assumptions are currently borked in sympy (thus Fabian's rewrite). But
I think by default x is not assumed to be real, so this should fail,
unless you defined x to be real.
Fabian is currently implementing a lot of logic for the new
assumptions system, maybe you can join forces? He needs help wit
On Mar 21, 3:52 pm, Vinzent Steinberg
wrote:
> Assumptions are currently borked in sympy (thus Fabian's rewrite). But
Indeed. The whole assumptions part looks very messy. I tried to each
of sympy.core.facts sympy.core.assumptions and sympy.core.basic to use
the module I've written, and failed mis
On Mar 21, 4:04 pm, Akshay Srinivasan
wrote:
> On Mar 21, 3:52 pm, Vinzent Steinberg wrote:
> > Assumptions are currently borked in sympy (thus Fabian's rewrite). But
>
> Indeed. The whole assumptions part looks very messy. I tried to each
> of sympy.core.facts sympy.core.assumptions and sympy.co
Shouldn't it be better to implement the assumptions system with
specialised classes instead of using strings and some make-shift
classes ? A sort of abstraction layer, so to speak. Keeping the layer
itself small will make it easier to implement it in Cython and should
be enough to more than offset
On Mar 22, 4:13 pm, Akshay Srinivasan
wrote:
> Shouldn't it be better to implement the assumptions system with
> specialised classes instead of using strings and some make-shift
> classes ? A sort of abstraction layer, so to speak. Keeping the layer
> itself small will make it easier to impleme
Akshay Srinivasan wrote:
> Shouldn't it be better to implement the assumptions system with
> specialised classes instead of using strings and some make-shift
> classes ? A sort of abstraction layer, so to speak. Keeping the layer
> itself small will make it easier to implement it in Cython and sho
On Mar 23, 7:45 pm, Akshay Srinivasan
wrote:
> On Mar 22, 4:13 pm, Akshay Srinivasan
> wrote:
>
> > Shouldn't it be better to implement the assumptions system with
> > specialised classes instead of using strings and some make-shift
> > classes ? A sort of abstraction layer, so to speak. Keepi
Vinzent Steinberg wrote:
>
> On Mar 23, 7:45 pm, Akshay Srinivasan
> wrote:
>
>> On Mar 22, 4:13 pm, Akshay Srinivasan
>> wrote:
>>
>>
>>> Shouldn't it be better to implement the assumptions system with
>>> specialised classes instead of using strings and some make-shift
>>> classes ? A
Thank you a lot for your work!
Reading your patch, there seem to rest some commented debug statements
(like '#raw_input(":")'). There are whitespaces at the end of some
lines, these can be removed, I think sympy has a script for this.
Sorry, I only had time for such a superficial review.
What's
Well, yes if the module was meant only to be used only for the
internals, it wouldn't make any difference at all. I intended the
module to be used directly by the user, so it has a better API, and a
much better simplification system. To be honest the only real
difference is the simplification func
Sorry for all the debugging code scattered all over the patch :)
On Mar 25, 9:00 pm, Akshay Srinivasan
wrote:
> Well, yes if the module was meant only to be used only for the
> internals, it wouldn't make any difference at all. I intended the
> module to be used directly by the user, so it has a
29 matches
Mail list logo
