MathGroup Archive 2004

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data

  • To: mathgroup at smc.vnet.net
  • Subject: [mg52348] Re: [mg52321] Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data
  • From: "David Park" <djmp at earthlink.net>
  • Date: Wed, 24 Nov 2004 02:32:19 -0500 (EST)
  • Sender: owner-wri-mathgroup at wolfram.com

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





  • Prev by Date: Re: limits
  • Next by Date: Re: Iterator problem.
  • Previous by thread: Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data
  • Next by thread: Re: Re: Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data