Waldek Hebisch <[EMAIL PROTECTED]> writes:
> I belive that conventions from HyperSpec are used in other languages,
> so I want to follow HyperSpec. However, note that actually one
> really should do a complex analysis exercise to theoretically determine
> how given combination behaves. Tests are useful too, but IMHO a
> reasonable test would take a bunch of curves which go trough some
> large area, but do not intersect cuts and compute few hundreds
> (or maybe thousends) of values and verify that result is
> continuous up to reasonable accuracy. Similarely for a few curves
> corssing/paralel to cuts (but checking for jumps when expected).
> Alterantively/additionaly one can test all poits form apropriate
> grid.
I like both possibilities. How would you test for coninuity of a curve? Would
you select a curve with small derivative, or rather compute the derivative
symbolically, and choose the distance of the points accordingly? It seems to
me that the second possibility would require that branch cuts of symbolic and
non-symbolic versions agree...
> I must admit that for me it would be easier to write such
> tests without using unittesting package (is it possible to tell
> the package name of test and result, but perform actual testing
> "outside"?).
Could you just write one short test and send it to the list, I'll see how to
integrate it into the unittesting framework. I do not see the difficulty
currently. See below for an example.
> So, it seems that we have to look deeper int code. One possibility
> is to have different version of routines for symbolic computation,
> and different numerical one. The numerical version can test
> the argument and (say for each quadrant) choose formula which
> for this argument gives correct cuts.
I believe it would be better to have tests first.
> Another problem is consistency of symbolic and numerical versions.
> Some users exect this, so it would be nice to avoid inconsistency
> if possible. But without conditional expressions this is
> unsolvable problem...
Yes. However, there should at least be a domain of values where the symbolic
and the numeric versions agree, and this should be documented.
In any case, we should do things we *can* do first, then worry about things we
cannot do...
Martin
)expose UnittestCount UnittestAux Unittest
epsilonAbsolute := 1.0e-10
epsilonrelative := 1.0e-20
testComplexFloat(a: String, b: String): Void ==
testTrue("norm(" a "-" b") < epsilonAbsolute")
testTrue("norm(" a "/" b "-1) < epsilonRelative")
testsuite "branch cuts"
testcaseNoClear "asin"
-- t = 0..tmax
-- x = -2..2
tmax := 10
X t == -2.0 + t/tmax * 4.0
y x == sqrt(-x^2 + 4.0)/2.0
tdiff := 1.0e-10
-- t = 0: arg1 is on the negative x-axis, arg2 in quadrant II
for t in 0..tmax-1 repeat
output(4*t+1)
arg1 := (X t + %i * y X t)::Complex Float
arg2 := (X(t+tdiff) + %i * y X(t+tdiff))::Complex Float
output(asin arg1)
output(asin arg2)
testComplexFloat("asin arg1", "asin arg2")
testComplexFloat("asin(arg1::Complex DFLOAT)",
"asin(arg2::Complex DFLOAT)")
X t == 2.0 - t/tmax * 4.0
y x == -sqrt(-x^2 + 4.0)/2.0
-- t = tmax: arg1 is on the positive x-axis, arg2 in quadrant IV
for t in 0..tmax-1 repeat
output(4*(t+tmax)+1)
arg1 := (X t + %i * y X t)::Complex Float
arg2 := (X(t+tdiff) + %i * y X(t+tdiff))::Complex Float
output(asin arg1)
output(asin arg2)
testComplexFloat("asin arg1", "asin arg2")
testComplexFloat("asin(arg1::Complex DFLOAT)",
"asin(arg2::Complex DFLOAT)")
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
