Dear GiNaCers, I have added the methods .real_part() and .imag_part() to the library for taking real and imaginary parts of expressions. Functions know how to take real and imaginary parts of themselves through two new function options. I did not add the required methods for this to all standard functions but the trigoniometric functions have been done. These new features are documented in the tutorial. Also, I noticed that the capitalization of words in section titles in the tutorial is inconsistent. I made this consistent by making all (except the first) words that are not names start with a lower case letter. Best, Chris
Dear Chris, Chris Dams wrote:
I have added the methods .real_part() and .imag_part() to the library for taking real and imaginary parts of expressions. Functions know how to take real and imaginary parts of themselves through two new function options. I did not add the required methods for this to all standard functions but the trigoniometric functions have been done. These new features are documented in the tutorial.
Did you chose that unconventional name because of numeric::real() and numeric::imag() returning a numeric object? Too bad... Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Dear Richy, On Sat, 22 Apr 2006, Richard B. Kreckel wrote:
I have added the methods .real_part() and .imag_part() to the library
Did you chose that unconventional name because of numeric::real() and numeric::imag() returning a numeric object? Too bad...
No, actually, just because I was thinking "what could be a nice name for a function that takes the real/imaginary part of something". Do you think that it should be changed? I am not sure whether numeric::real() and numeric::imag() would cause trouble in that case. Best, Chris
Dear Chris, Chris Dams wrote:
No, actually, just because I was thinking "what could be a nice name for a function that takes the real/imaginary part of something". Do you think that it should be changed? I am not sure whether numeric::real() and numeric::imag() would cause trouble in that case.
Sure the return type would cause trouble. The return type can only change if it's a reference or pointer and if it changes covariantly across the class hierarchy. In the case at hand, it's a numeric object, however, not a refernece. Even changing covariantly would not be a good idea in GiNaC for the very same reason basic::eval() and so many others return an ex object. No, the numeric::real() member function would have to be renamed to make place for a new signature ex numeric::real() (the free function real(const numeric&) could stay, in principle, I guess). This would break compatibility somewhat, however. Alternatively, ex::real() could dispatch to a differently named basic member function, like your real_part(). Not nice. Don't misunderstand me. I'm not advocating it, merely pondering aloud... Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (2)
-
Chris Dams
-
Richard B. Kreckel