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: [mg52396] Re: Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data
  • From: "John Jowett" <John.Jowett at cern.ch>
  • Date: Thu, 25 Nov 2004 05:50:58 -0500 (EST)
  • Organization: CERN
  • References: <co1ejp$shb$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

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



  • Prev by Date: Re: Re: Re: Re: Newly Released Mathematica 5.1 Delivers Unmatched Performance for Handling Data
  • Next by Date: Projections
  • 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