Jason Grout wrote:
On 03/05/2010 07:04 PM, Dr. David Kirkby wrote:
I just got a doc test failure on Solaris.
File
"/export/home/drkirkby/32/sage-4.3.4.alpha0/devel/sage/sage/plot/colors.py",
line 660:
sage: gold / pi + yellow * e
Expected:
RGB color (0.51829585732141792, 0.49333037605210095, 0.0)
Got:
RGB color (0.51829585732141814, 0.49333037605210117, 0.0)
Looking at the doc test I see this:
--------------------------------------
EXAMPLES::
sage: from __future__ import division
sage: from sage.plot.colors import yellow, gold
sage: yellow / 4
RGB color (0.25, 0.25, 0.0)
sage: yellow.__truediv__(4)
RGB color (0.25, 0.25, 0.0)
sage: gold / pi + yellow * e
RGB color (0.51829585732141792, 0.49333037605210095, 0.0)
----------------------------------------------
The is absolutely no justification given in the doc test for this
result, so how do we know it's right?
Printing the values of 'yellow' and 'gold' I get:
sage: print yellow
RGB color (1.0, 1.0, 0.0)
sage: print gold
RGB color (1.0, 0.84313725490196079, 0.0)
sage:
I personally don't understand how one can divide one colour by another,
but I'm not disputing that there can be some logic in this. I tried in
Mathematica to just divide the these as lists
In[44]:= yellow={1,1,0}
Out[44]= {1, 1, 0}
In[45]:= gold={1.0,0.84313725490196079, 0.0}
In[46]:= gold/Pi + yellow E
Out[46]= {3.03659, 2.98666, 0.}
With no idea what this division is supposed to do, I tried.
In[47]:= Normalize[%]
Out[47]= {0.712944, 0.701221, 0.}
but that gives totally different numbers.
So I'm none the wiser. Of course, I could create a ticket to check the
expected value to be
0.51829585732141..., 0.49333037605210...,0.0
but I'd have no justification for this.
Perhaps someone can enlighten me how one divides /multiples colours, and
can show me a high precision value for the result.
This is just one of several examples I've seen in Sage where the numeric
result from a doc test is not obvious. The "Expected" value is probably
what someone got on their computer. I "Got" a different value on my
computer. But who knows what the result should be? Without some
justification, I find it hard to believe this doc test achieves very
much. I've just waisted an hour trying to work out how I might reproduce
this, but can't
I assume we are talking about the patches up at #5601?
Probably. I can't say for sure. There is so many large patches on there, that I
have not studied them in detail.
IMHO, it would be good if the trac number appropriate to the test was documented
in the test. Then one might at least have some idea where to look.
First, note that colors are multiplied by scalars, not by other colors.
Yes, my mistake.
The documentation for the multiplication and division methods talk
about what a multiplication or division means---scale the RGB values by
the scalar.
sage: colors.yellow
RGB color (1.0, 1.0, 0.0)
sage: colors.yellow/2
RGB color (0.5, 0.5, 0.0)
sage: colors.yellow*0.3
RGB color (0.29999999999999999, 0.29999999999999999, 0.0)
This makes some sort of sense, at least numerically. However, what does
not make sense is when a resulting component is more than one, the
fractional part is taken as the value. Therefore,
sage: colors.red*2
RGB color (0.0, 0.0, 0.0)
I think this is a problem (and missed this when I reviewed the colors
patch, so this getting in is partially my fault!) At least explains
what colors*scalar is. I think this ought to be changed to make more
sense when a resulting component is outside of [0,1] (maybe cap the
values, instead of just take the fractional part). The problem here is
in the rgbcolor() function when it creates a color from a tuple.
There's information here about how Mathematica handles such cases
http://reference.wolfram.com/mathematica/ref/RGBColor.html
If the method in Sage is not right, then I'd give some consideration at least to
following how some other software does it. I'm not suggesting copying everything
Mathematica does, or considering it a God, but at least give it's methods some
thought.
The addition of two colors is documented in the function for addition,
and says there that it uses the blend function. The documentation for
blend says
Return a color blended with the given ``color`` by a given
``fraction``. The algorithm interpolates linearly between the
colors' corresponding R, G, and B coordinates.
This is so that colors.red+colors.blue is approximately purple (though
not exactly colors.purple, since colors.purple is a specifically defined
value according to HTML standards). colors.yellow+colors.red is
approximately colors.orange, etc.
Thanks,
Jason
My main points are
* There is not much information about that test.
* An explanation of why the "Expected" value is expected would be useful.
* It should be possible to compute manually a high precision result and
document that number in many cases - this being one of them.
To me, if the result computed on your computer is only good to 12 digits, the
expected result should not consist of all 16. Test failures on other processors
are almost inevitable in that case. The most logical way around that is to me to
compute a high precision result where possible.
I picked on this test, as it was the first failure I got of its type.
But I generally think tests should justify the expected result.
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
