Services & ResourcesWolfram ForumsMathGroup Archive

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

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

• To: mathgroup at smc.vnet.net
• Subject: [mg52394] Re: [mg52348] Re: [mg52321] Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data
• From: DrBob <drbob at bigfoot.com>
• Date: Thu, 25 Nov 2004 05:50:49 -0500 (EST)
• References: <200411240732.CAA28826@smc.vnet.net>
• Reply-to: drbob at bigfoot.com
• Sender: owner-wri-mathgroup at wolfram.com

They were warned, they did it anyway, and it broke their own code.

The word "comeuppance" springs to mind.

Bobby

On Wed, 24 Nov 2004 02:32:19 -0500 (EST), David Park <djmp at earthlink.net> wrote:

> 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
>
>
>
>
>
>
>



-- 
DrBob at bigfoot.com
www.eclecticdreams.net

• References:
  • Re: Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data
    • From: "David Park" <djmp@earthlink.net>