Re: Re: Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data
- To: mathgroup at smc.vnet.net
- Subject: [mg52449] Re: [mg52396] Re: Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data
- From: "Hobbs, Sylvia (DPH)" <Sylvia.Hobbs at state.ma.us>
- Date: Sat, 27 Nov 2004 01:41:15 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
Speaking of colors, are any of you aware of a standard color palette or utility that electronically automates conversion of a given color scheme legend to a palette viewable by students who have trichromatic or dichromatic colorblindness? For example, to such people the area below the light blue in this graph http://www.wolfram.com/products/mathematica/usersanduses/experience/images/s urna3dvolume.th.jpg might be viewed as brown instead of a continuous green-yellow-red gradient. While colors are used as teaching tools in math and geography, colorblindness (like nearsightedness) is not a learning disability if a correction for the distortion is made and the colorblind do see some gradient of the light curve shifted more towards red or green. Let me know if you have come across any palette standards (other black-grey-white) that are color blind accessible or colorblind simulation utilities that can be used. Sylvia Hobbs sylvia.hobbs at state.ma.us -----Original Message----- From: John Jowett [mailto:John.Jowett at cern.ch] To: mathgroup at smc.vnet.net Subject: [mg52449] [mg52396] Re: Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data David, I still don't have 5.1 but I agree with you that these seem to have be useless and arbitrary changes to Graphics`Colors`. Wolfram should fix it but, if they don't, I suppose it is always possible to keep a copy of the previous Colors.m inside a directory called Graphics in a location that comes earlier in $Path than that of the standard packages ({$UserBaseDirectory,"Applications"} or {$BaseDirectory,"Applications"} for example). From what you say, it seems that this version will have to Unprotect and modify those colours that are now in the kernel. This is what I have been doing with my modified version that avoids the name clashes with the chemical elements. It's annoying because anybody (such as you or me) distributing a package or application that depends on Graphics`Colors` will have to ensure that all users do something similar. I'm not sure that it is necessary to have a unit Degree as Kelvin is already there and is used, e.g., in the definition of BoltzmannConstant. The Miscellaneous`Units` has a special handling of temperature scales (ConvertTemperature) that are not proportional to each other like other units. It seems a bit clumsy but I don't have much occasion to use it myself. Otherwise Convert[5 Fahrenheit, Kelvin] returns something that might be considered reasonable, with a warning message. If anyone at Wolfram is listening, and agrees with all of us here that this mess should be tidied up, I would vote that the names {Gold, Cobalt, Titanium, Zinc} be reserved for chemical elements rather than colours. {Golden,CobaltBlue,TitaniumWhite,ZincWhite} might be reasonable alternatives (perhaps I'll put those in my version now). CobaltGreen is already in the package and the last two are very close to white. Otherwise, there are plenty of creative names for colours in automobile catalogues ... Gray is more difficult. It is a formally defined SI unit but is also common American usage for the colour. There is always the spelling "Grey" from British (and Australian, I think) English for the colour but I don't want to strain transatlantic relations here. Still, people not using the Units package would be free to define Gray=Grey for their convenience. It would also not hurt much to define GreyLevel=GrayLevel. John Jowett "David Park" <djmp at earthlink.net> wrote in message news:co1ejp$shb$1 at smc.vnet.net... > John, > > Your idea about non-conflicting color names seems good. Also there should be > a unit Degree and a different name for the numerical constant. > > The specific problem here though is different. > > Previously, the package Graphics`Colors` contained a set of named colors. > These colors were all uniformly represented in that they were all RGBColors. > That is, they all had the same Head. This uniformity of representation was > useful and I am certain that it plays a role in a lot of user code. > > In Version 5.1 the WRI developers have moved a few of the colors from the > Graphics`Colors` package to the kernel. (I think this is a mistake because I > am for similar things being treated uniformly. They should either move all > of the color names to the kernel or keep them together in the package. But > that is not the specific issue here. But suppose they move Gold to the > kernel, then your message isn't going to work.) In doing this, WRI also > changed the representation of certain neutral colors such as Black, White > and Gray from RGBColor to GrayLevel. I think this is a great mistake because > it will break every algorithm that depends on all named colors having the > same Head. I cannot think of a good reason for making this gratuitous > change. > > I found out about this problem from a beta tester who was using the > DrawGraphics package where it broke the ColorMix function. When he > complained to Wolfram Support (I never understand why beta testers must work > through Wolfram Support and don't have direct contacts to the developers!) > he just received a bureaucratic reply that said they took the possibility of > breaking old code into account (but do it anyway) and that I could just > change my code since my package was not Wolfram associated. (I did, but now > users of the package will have to stumble across the problem, wonder what is > going on, then check my site and download the new version.) > > I wrote (for the very first time and probably the very last time) to Steven > Wolfram about it. He never replied. I wrote to another top person and only > received a short reply that there was a good reason, although I never found > out what that reason was. So WRI received at least three messages about this > problem well before the release of 5.1. > > Now it turns out that this change not only affects user code "not associated > with Wolfram Research" but also breaks their own code. RasterArray requires > all the colors in the array to have the same Head. By fracturing the > representation of the named colors the user can no longer obtain expected > behavior for RasterArray, and I suppose also for DensityGraphics (maybe > someone could test that with a color function that uses named colors with > Black, White or Gray). > > It reminds me of that old vaudville doctor joke: "Doctor, my code breaks > when I use Gray." "Then don't use Gray!" Use RGBColor[0.752907, 0.752907, > 0.752907]. > > If this kind of thinking portends what we may expect for the user interface > for the 'graphics' Version, whenever it should appear, then I wouldn't be > too hopeful. > > David Park > djmp at earthlink.net > http://home.earthlink.net/~djmp/ > > > > > > > From: John Jowett [mailto:John.Jowett at cern.ch] To: mathgroup at smc.vnet.net > > "Yasvir Tesiram" <tesiramy at omrf.ouhsc.edu> wrote in message > news:cns1p1$e1j$1 at smc.vnet.net... > > G'day David, > > > > Very curious. I just checked and indeed all works fine with 5.0 but Gray > > isn't liked much in 5.1. Neither is Black, another color defined by > > GrayLevel. Other colors defined by RGB seems to work fine though. > > There probably is a good reason floating around somewhere. > > > > Hello, > Not having 5.1 yet, I don't know exactly what the problem is but one > good reason might be that some of the colours in Graphics`Colors` have names > that clash with other useful packages. Because of this, I have long had a > private version which loads with the following message: > > Graphics`Colors` - loading modified version of this standard package in > which \ > the colors > {Cobalt, Gold, Gray, Titanium, Zinc} > have been renamed: > {CobaltColor, GoldColor, GrayColor, TitaniumColor, ZincColor} > to eliminate clashes with the standard packages > Miscellaneous`ChemicalElements` and Miscellaneous`Units`. > > I'm not sure if this explains a problem with Black though. > > John Jowett > > > >