Yes, the number of digits that agree is not inherently related to the error. That's one things that has frustrated me so.
In practice, this
agree() procedure would only be called after two numbers are found to be different (say, by
verify(a,b) or
evalb(a-b=0)). I found the following bit of code to work for many examples, but it would often fail in odd situations:
a:= given answer;
b:= correct answer; # Calculated by evalf(something, #digits);
c:= how many digits in b;
d:= evalf(abs(a-b), c);
if ansdiff = 0.0 then
yes;
elif d<1 then
offby:= 1 - ( floor(log[10](SFloatMantissa(d))) + SFloatExponent(d) );
sprintf("It agrees to %a digits.",offby) );
else
no;
fi;
I'm trying to replace this code with code that works more properly.
Yes, the number of digits that agree is not inherently related to the error. That's one things that has frustrated me so.
In practice, this
agree() procedure would only be called after two numbers are found to be different (say, by
verify(a,b) or
evalb(a-b=0)). I found the following bit of code to work for many examples, but it would often fail in odd situations:
a:= given answer;
b:= correct answer; # Calculated by evalf(something, #digits);
c:= how many digits in b;
d:= evalf(abs(a-b), c);
if ansdiff = 0.0 then
yes;
elif d<1 then
offby:= 1 - ( floor(log[10](SFloatMantissa(d))) + SFloatExponent(d) );
sprintf("It agrees to %a digits.",offby) );
else
no;
fi;
I'm trying to replace this code with code that works more properly.
The first should return 4. The second should, as I've described the procedure, also return 4.
It has become increasingly clear to me that I need to step from this subject and write a new post describing exactly what I'm doing, exactly what I've tried, and exactly what I wish to accomplish. Though I say this, don't expect that post for the next few days; I'm setting Maple down and taking a short break. These past few days, I've been feeling handcuffed to my computer.
The first should return 4. The second should, as I've described the procedure, also return 4.
It has become increasingly clear to me that I need to step from this subject and write a new post describing exactly what I'm doing, exactly what I've tried, and exactly what I wish to accomplish. Though I say this, don't expect that post for the next few days; I'm setting Maple down and taking a short break. These past few days, I've been feeling handcuffed to my computer.
While it is a major problem that the other commands are not "acknowledged," I believe that Maple takes actual content of the worksheet from the other information in the <Equation> tag. Why Maple would so haphazardly store the commands in plain text is beyond me; but, what is even more frightening is that Maple is not consistent with the content it puts into its <Equation> tags! Just yesterday, I ran into a situation where Maple did not include a display attribute in the <Equation> tag! I have trimmed away the irrelevant data from the worksheet and posted the file here:
View 413_example_nodisplay.mw on MapleNet or
Download 413_example_nodisplay.mwView file details
This is something a student submitted, so I can't give rhyme or reason why Maple would encode the data in such a way. Every time I open and re-save the worksheet, it encodes the data properly. It is possible, though unlikely, that the student was using Maple 10.06, and not Maple 11.
I really should be more careful about side notes and comments I make in my posts, should I not?
I do take into consideration things like the location of the decimal and trailing zeros. I say that just before I give a snippet of code. To fully outline what my procedure does:
1) Checks if both numbers are floats.
2) Converts both numbers to strings.
3) Checks to see if the decimal is located in the same place for both numbers. Record that location.
4) Explodes the strings to lists.
5) Removes the decimal and any trailing zeroes.
6) Checks the length of the two new lists.
7) If the decimal was in the same place for both, checks entry by entry through the list.
8) Returns an answer based on how many digits to which the floats agreed.
Your example with the 1. and 10. was the same thing I pointed out in my previous comment. But yes, all in all, converting to strings might be useful, but they have serious drawbacks.
I really should be more careful about side notes and comments I make in my posts, should I not?
I do take into consideration things like the location of the decimal and trailing zeros. I say that just before I give a snippet of code. To fully outline what my procedure does:
1) Checks if both numbers are floats.
2) Converts both numbers to strings.
3) Checks to see if the decimal is located in the same place for both numbers. Record that location.
4) Explodes the strings to lists.
5) Removes the decimal and any trailing zeroes.
6) Checks the length of the two new lists.
7) If the decimal was in the same place for both, checks entry by entry through the list.
8) Returns an answer based on how many digits to which the floats agreed.
Your example with the 1. and 10. was the same thing I pointed out in my previous comment. But yes, all in all, converting to strings might be useful, but they have serious drawbacks.
It's great that Maple has functions like this built in for our convenience. The trick, it seems, is to actually find them.
Thank you for the suggestion! However, I see one major flaw with this method as presented:
[> a:= 1230.456789: b:= 123.4567890:
[> A:= convert(a,string): B:= convert(b,string):
[> StringTools:-CommonPrefix(A,B);
3
Which is incorrect. I could avoid most situations like this by checking on the location of the decimal with StringTools:-Search() first
[> StringTools:-Search(".",A); StringTools:-Search(".",B);
5
4
And then, I found another potential problem with this entire process of converting floats to strings for comparison:
[> c:= 123.456789e-10: C:= convert(c,string);
".123456789e-7"
That could lead to many other incorrect answers.
It's great that Maple has functions like this built in for our convenience. The trick, it seems, is to actually find them.
Thank you for the suggestion! However, I see one major flaw with this method as presented:
[> a:= 1230.456789: b:= 123.4567890:
[> A:= convert(a,string): B:= convert(b,string):
[> StringTools:-CommonPrefix(A,B);
3
Which is incorrect. I could avoid most situations like this by checking on the location of the decimal with StringTools:-Search() first
[> StringTools:-Search(".",A); StringTools:-Search(".",B);
5
4
And then, I found another potential problem with this entire process of converting floats to strings for comparison:
[> c:= 123.456789e-10: C:= convert(c,string);
".123456789e-7"
That could lead to many other incorrect answers.
I had wanted to put Maple down for the evening, but y'all just keep pulling me back in...
Okay. So, I looked at the help page again, and how to curry became quite clear.
evalindets(AAA, 'patfunc(string,anything)', curry(subs,listofsubs) );
evalindets(AAA, 'patfunc(string,anything)', rcurry(eval, listofsubs) );
I'll need to play with evalindets() to where and how it recurses with and without [flat]. I mean, I have an idea of how it works both ways, but not being a programmer or comp sci person by trade, I find actually watching it go to work a lot more informative.
I had wanted to put Maple down for the evening, but y'all just keep pulling me back in...
Okay. So, I looked at the help page again, and how to curry became quite clear.
evalindets(AAA, 'patfunc(string,anything)', curry(subs,listofsubs) );
evalindets(AAA, 'patfunc(string,anything)', rcurry(eval, listofsubs) );
I'll need to play with evalindets() to where and how it recurses with and without [flat]. I mean, I have an idea of how it works both ways, but not being a programmer or comp sci person by trade, I find actually watching it go to work a lot more informative.
Joel,
Thank you for the suggestion. If I really did need to convert the strings to lower case, StringTools:-LowerCase would be the tool to use. The substitutions I need to make are rather specific and numerous, and contained in that
listofsubs.
I had started playing around with
evalindets() after I learned about it from re-reading your post
here, but I didn't know about
patfunc. That sounds like it would make my life a lot less difficult.
And thank you for the
curry. Though I have seen and studied it before, I've never put it to use.
I haven't gotten back to tinkering yet, but using
evalindets() and
patfunc, I should be able to achieve the effect I want with something like:
evalindets(AAA, 'patfunc(string,anything)', a->subs(listofsubs,a) );
I don't know whether or not I'll need the
[flat] specification.
Joel,
Thank you for the suggestion. If I really did need to convert the strings to lower case, StringTools:-LowerCase would be the tool to use. The substitutions I need to make are rather specific and numerous, and contained in that
listofsubs.
I had started playing around with
evalindets() after I learned about it from re-reading your post
here, but I didn't know about
patfunc. That sounds like it would make my life a lot less difficult.
And thank you for the
curry. Though I have seen and studied it before, I've never put it to use.
I haven't gotten back to tinkering yet, but using
evalindets() and
patfunc, I should be able to achieve the effect I want with something like:
evalindets(AAA, 'patfunc(string,anything)', a->subs(listofsubs,a) );
I don't know whether or not I'll need the
[flat] specification.
We've run into the same problem recently. We don't know why, but < does not seem to want to compare numbers (integers, rational numbers, or floats) to what I'll call "numeric symbols" such as Pi, exp(nonzero integer), sin(Pi/7), etc.
What it comes down to is that evalb() has great weaknesses when dealing with inequalities. We've switched to using verify() for our inequalities.
[> verify( Pi, 3, 'less_than' );
false
However, we've noticed that verify() has surprising weaknesses when it comes to dealing with infinity!
[> verify( infinity, infinity );
true
[> verify( infinity, infinity, 'simplify' );
false
[> verify( -infinity..sqrt(35), -infinity..sqrt(5)*sqrt(7), 'range' );
false
[> verify( -infinity..sqrt(35), -infinity..sqrt(5)*sqrt(7), 'range'('simplify') );
false
--Schivnorr
We've run into the same problem recently. We don't know why, but < does not seem to want to compare numbers (integers, rational numbers, or floats) to what I'll call "numeric symbols" such as Pi, exp(nonzero integer), sin(Pi/7), etc.
What it comes down to is that evalb() has great weaknesses when dealing with inequalities. We've switched to using verify() for our inequalities.
[> verify( Pi, 3, 'less_than' );
false
However, we've noticed that verify() has surprising weaknesses when it comes to dealing with infinity!
[> verify( infinity, infinity );
true
[> verify( infinity, infinity, 'simplify' );
false
[> verify( -infinity..sqrt(35), -infinity..sqrt(5)*sqrt(7), 'range' );
false
[> verify( -infinity..sqrt(35), -infinity..sqrt(5)*sqrt(7), 'range'('simplify') );
false
--Schivnorr
