SymbolicC++

[Alan Bromborsky]

Ondrej, in order not to reinvent the wheel on you C++ library have you
looked at -

http://issc.uj.ac.za/symbolic/symbolic.html

[Ondřej Čertík]

Thanks Alan. Yes, I did. I tried simple benchmarks and SymbolicC++ is even slower than Sympy.

Sent from my mobile phone.

On Apr 26, 2014 9:32 AM, "Alan Bromborsky" <abr...@verizon.net> wrote:

Ondrej, in order not to reinvent the wheel on you C++ library have you looked at -

http://issc.uj.ac.za/symbolic/symbolic.html

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/535BD186.1040005%40verizon.net.
For more options, visit https://groups.google.com/d/optout.

[Joachim Durchholz]

Am 26.04.2014 21:50, schrieb Ondřej Čertík:
> Thanks Alan. Yes, I did. I tried simple benchmarks and SymbolicC++ is even
> slower than Sympy.

Wow.
So much for the assumption "C++ is generally faster than Python".
At best, it's potentially faster :-)

[Ondřej Čertík]

It is generally (a lot) faster, but you need to use the same
algorithms. Why apparently
SymbolicC++ doesn't use.

Ondrej

[Richard Fateman]

I just looked briefly at the documentation.  My guess is that the data structures and the organization

(templates) are a major problem.  I have no idea if the algorithms are inefficient.  I think the system may also suffers from Greenspun's tenth rule.  Except having chosen C++ instead of C to re-implement

the Lisp-equivalent underpining, the inefficiency of the design affects almost everything.

My theory, anyway.

RJF

PS  So far as I know, sympy is slower than the equivalent (free) Lisp code.  So yes, it is re-inventing

the wheel.  Worse, it is reproducing the chain of errors in design that led to existing computer algebra

systems.  Or as we say, standing on the toes of giants.  Look it up in wikipedia, esp. regarding Newton and Hook.

[Joachim Durchholz]

Am 27.04.2014 23:00, schrieb Richard Fateman:
> PS So far as I know, sympy is slower than the equivalent (free) Lisp code.

Any pointers to that one?

> So yes, it is re-inventing the wheel.

So many wheels, so many ways to invent them...

> Worse, it is reproducing the chain of errors in design that led
> to existing computer algebra systems.

Which ones do you mean?

And in general, if you think this is all misguided - what are you doing
here?
Just curious what thinking is motivating you.

[Alan Bromborsky]

See link http://www.eecs.berkeley.edu/Faculty/Homepages/fateman.html

[Richard Fateman]

On Sunday, April 27, 2014 2:24:27 PM UTC-7, Joachim Durchholz wrote:

Am 27.04.2014 23:00, schrieb Richard Fateman:
> PS  So far as I know, sympy is slower than the equivalent (free) Lisp code.

Any pointers to that one?

> So yes, it is re-inventing the wheel.

So many wheels, so many ways to invent them...

 > Worse, it is reproducing the chain of errors in design that led
> to existing computer algebra systems.

Which ones do you mean?

managing assumptions.

treating algebraic roots.

fo 2 examples.

 

And in general, if you think this is all misguided - what are you doing
here?

trying to educate.

the world does not need more crappy duplicative software. even in python.

Just curious what thinking is motivating you.

what motivates you?

 

[Alan Bromborsky]

What would be the best language then for the core of a computer algebra system?
What would be a reference(s) for the best algorithms for a computer algebra system?

Note that my interests are in dealing with the algebra of non commutative symbols and
the  products of scalar functions and non commutative symbols since
that is what I use in representing the multivectors and multivector fields of geometric (Clifford) algebras.

--
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+un...@googlegroups.com.

To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/290da599-2570-4537-bb63-66aa3b91aa32%40googlegroups.com.

[Joachim Durchholz]

Am 27.04.2014 23:46, schrieb Alan Bromborsky:
> See link http://www.eecs.berkeley.edu/Faculty/Homepages/fateman.html

Been there, seen that - still I'm wondering.

[Joachim Durchholz]

>>> Worse, it is reproducing the chain of errors in design that led
>>> to existing computer algebra systems.
>>
>> Which ones do you mean?
>>
> managing assumptions. treating algebraic roots. fo 2 examples.

That's areas.
What are the design errors? What would be better designs?
For the assumptions - do you mean the existing system, or the new system
that's being implemented?

>> And in general, if you think this is all misguided - what are you
>> doing here?
>>
> trying to educate. the world does not need more crappy duplicative
> software. even in python.

We have a saying in Germany: If you wish to give advice, pick the people
up where they stand.

What I'm reading from you is theory, with no indication how to apply, or
where to start, or anything. You do not seem to even have looked into
the overall code structure, to identify the low-hanging fruit. You don't
even have a plan to identify which fruit are hanging at what altitude...
and I'm not seeing how telling us "you're doing it all wrong" is going
to help SymPy along if you stay silent on what's wrong, or in what ways
it is wrong, or (most importantly) how it could be done better.

Not that I can't sympathize with your points, or your position. Being
specific requires work, and I guess you don't have an unlimited time
budget. I can even sympathize with your Lisp preference (though I'd
prefer Haskell since it's 90% of Lisp's capabilities but ten times the
guarantees, plus performance aspects would be so different that it's an
experiment worth actually doing).
But... it's not going to lead anywhere at the level I'm seeing here.

>> Just curious what thinking is motivating you.
>
> what motivates you?

The realization that it was a repeated case of unhelpful feedback.
The wish to improve that situation.

[Richard Fateman]

On Monday, April 28, 2014 12:29:32 AM UTC-7, Joachim Durchholz wrote:

>>> Worse, it is reproducing the chain of errors in design that led
>>> to existing computer algebra systems.
>>
>> Which ones do you mean?
>>
> managing assumptions. treating algebraic roots. fo 2 examples.

That's areas.
What are the design errors? What would be better designs?
For the assumptions - do you mean the existing system, or the new system
that's being implemented?

The previous system apparently made the same mistakes as previous

computer algebra systems.  Perhaps because the programmers were

not sufficiently aware of what was done before.  I don't know what has

been done for the new system, but if the programmers are STILL ignorant

of the history of this problem, I wonder if it will be better.

 

>> And in general, if you think this is all misguided - what are you
>> doing here?
>>
> trying to educate. the world does not need more crappy duplicative
> software. even in python.

We have a saying in Germany: If you wish to give advice, pick the people
up where they stand.

We have a saying in this country that "three months in the programming lab can

save you half an hour in the library"

 

What I'm reading from you is theory, with no indication how to apply, or
where to start, or anything.

I'm sorry, but I'm not paid enough to direct you from day to day.  Reading a book or

some papers, maybe taking a course, would help.

 

You do not seem to even have looked into
the overall code structure, to identify the low-hanging fruit.

I'm not interested in picking low-hanging fruit and reprogramming stuff in python.

I'm interested in noticing the high-level bad design which will make the system

no better, and probably worse, than what has been done before

 

You don't
even have a plan to identify which fruit are hanging at what altitude...
and I'm not seeing how telling us "you're doing it all wrong" is going
to help SymPy along if you stay silent on what's wrong, or in what ways
it is wrong, or (most importantly) how it could be done better.

If you think you are doing it all right, and that the only changes needed

are incremental fixes to low hanging fruit, then feel free to continue

exactly the way you are going.  Maybe sympy II  will be better.  Or

maybe some other post-python language will become popular and

another group of people will write sympy (I)  in that language and re-invent

the same problematical designs.

 

Not that I can't sympathize with your points, or your position. Being
specific requires work, and I guess you don't have an unlimited time
budget.

It is not my job or interest to rewrite programs (some of which I have written)

in python for the sake of python

 

I can even sympathize with your Lisp preference (though I'd
prefer Haskell since it's 90% of Lisp's capabilities but ten times the
guarantees, plus performance aspects would be so different that it's an
experiment worth actually doing).

You are welcome to write in Haskell, but that doesn't improve the design,

ordinarily.

 

But... it's not going to lead anywhere at the level I'm seeing here.

>> Just curious what thinking is motivating you.
>
> what motivates you?

The realization that it was a repeated case of unhelpful feedback.

I'm not going to read the python code and tell you how to diddle it.

 

The wish to improve that situation.

I observed the behavior and from that deduced the design errors.

It is your job to study existing literature and systems if you want to do

something at least as good.  There are thousands of "commands" constituting

numerous computational subsystems and interacting data structures in

a system like Mathematica, Maple, Maxima.

Re-programming in python is one possibility. Studying and improving them while

programming in python is another, better idea.   Re-inventing them from scratch

is, with high probability, a worse idea.

If you find this unhelpful, it is probably because you are re-inventing, and don't want to

hear...

' 

[Matthew Rocklin]

This seems to be going down the same path as previous conversations.  I don't think that anyone will come away satisfied.

I recommend that both sides resist the urge to fight.  Alternatively Richard and Joachim, perhaps the two of you would enjoy continuing this conversation privately off list?

--

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+un...@googlegroups.com.

To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/c4d75d90-8bfd-4a90-adce-43e1e5998012%40googlegroups.com.

[Joachim Durchholz]

Am 28.04.2014 15:43, schrieb Matthew Rocklin:
> I recommend that both sides resist the urge to fight. Alternatively
> Richard and Joachim, perhaps the two of you would enjoy continuing this
> conversation privately off list?

I have shelved my answer already.

Did I miss useful feedback from Richard in the past?

Regards,
Jo