[GiNaC-devel] A smarter relational to Boolean conversion
Vladimir V. Kisil
V.Kisil at leeds.ac.uk
Sat Jun 5 23:55:53 CEST 2021
Dear Richard,
You are right, normal() shall be called by the user if needed. I
am attaching the amended patch.
Best wishes,
Vladimir
--
Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/
Book: Geometry of Mobius Maps https://doi.org/10.1142/p835
Soft: Geometry of cycles http://moebinv.sourceforge.net/
Jupyter notebooks: https://github.com/vvkisil/MoebInv-notebooks
>>>>> On Sat, 5 Jun 2021 22:14:33 +0200, "Richard B. Kreckel" <kreckel at in.terlu.de> said:
RK> Dear Vladimir,
RK> On 04.06.21 10:31, Vladimir V. Kisil wrote:
>> I am attaching a small patch. With it the following conversions
>> from relational to Boolean will become "true" from the current
>> "false":
>>
>> realsymbol x("x"); possymbol p("p"); cout << bool(p>0) << endl;
>> cout << bool(abs(x)>=0) << endl;
RK> Thank you for submitting this patch!
RK> What is the reason to call .normal() in the symbolic case?
RK> Generally, we never do automatic evaluation of expressions with
RK> complexity worse than O(n log n). See section 4.2 of the
RK> tutorial.
RK> The reason we don't do this is to not surprise the user with
RK> skyrocketing run-times, especially when expressions get longer
RK> or nested. It is a different story when the user calls a special
RK> transformation explicitly.
RK> Admittedly, this case here is not exactly automatic
RK> evaluation. But still, it is a normal() hidden deep inside a
RK> seemingly innocent coercion to Boolean. I think it would be more
RK> appropriate to let the user call .normal() explicitly, it that
RK> is desired.
RK> May I suggest to remove this one line?
RK> All my best, -richy. --
RK> Richard B. Kreckel
RK> <https://in.terlu.de/~kreckel/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Smarter-conversion-of-a-relational-to-Boolean.patch
Type: text/x-diff
Size: 2929 bytes
Desc: Conversion to bool patch.patch
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20210605/4fb0ee57/attachment.bin>
More information about the GiNaC-devel
mailing list