reduce() anomaly?

[Robin Becker]

Re: reduce()--what is it good for? (was: Re: reduce() anomaly?)

In article <vr057vjp1j7f06 @corp.supernews .com>, Francis Avila
<francisgavila@ yahoo.com> writes[color=blue]
>"Alex Martelli" <aleax@aleax.it > wrote in message
>news:BsJrb.445 840$R32.1486536 2@news2.tin.it. ..[color=green]
>> Francis Avila wrote:[color=darkred]
>>> [a reduce() clone][/color]
>> [a long and thorough critique][/color]
>
>*Sigh* My only objective was to combine functional/recursive/iterative
>programming styles into an olive branch to extend to both parties of this
>silly war.
>
>But oh well. Like I said, I never found a use for reduce, but alas, I am a
>ham-fisted programmer entirely lacking in subtlety and art....
>--
>Francis Avila
>[/color]
This whole thread is reminiscent of vi vs emacs or an os war or similar.
It's a pity that people with a preferred style should be so dogmatic
that they want to remove language features to prevent others using them.

The whole 'only one way to do it' concept is almost certainly wrong.
There should be maximal freedom to express algorithms. As others have
stated min, max,... sum et al are useful specialisations , but because
they cover 99% of the space doesn't mean that reduce is redundant.
-Eliminate reducespeak and control the future-ly yrs-
Robin Becker

[Alex Martelli]

Python's simplicity philosophy (was Re: reduce()--what is it good for?)

Robin Becker wrote:
...[color=blue]
> This whole thread is reminiscent of vi vs emacs or an os war or similar.
> It's a pity that people with a preferred style should be so dogmatic
> that they want to remove language features to prevent others using them.[/color]

Python's essence is simplicity and uniformity. Having extra features
in the language and built-ins runs directly counter to that.

[color=blue]
> The whole 'only one way to do it' concept is almost certainly wrong.[/color]

Bingo! You disagree with the keystone of Python's philosophy. Every
other disagreement, quite consequently, follows from this one.

The world is *chock full* of languages designed with the philosophy
of "the more, the merrier". Why can't you let us have just _*ONE*_
higher-level language designed with full appreciation for "the spirit
of C" (as per the C standard's Rationale) in its key principles:

"""
(c) Keep the language small and simple.
(d) Provide only one way to do an operation.
"""

Maybe "the spirit of C" is as wrong as you claim it is. Personally,
I _cherish_ it, and in Python I found a language that cherishes it
just as much, while working at a much higher semantic level and thus
affording me vastly higher productivity. I will not stand idly by,
and let you or anybody else attack its foundations and thus try to
destroy its key strengths, without a fight.

[color=blue]
> There should be maximal freedom to express algorithms. As others have[/color]

Want "maximal freedom to express algorithms"? You can choose among
a BAZILLION languages designed according to your philosophy -- even
sticking just to higher-level languages with dynamic typing and
generally infix/algoloid syntax, Perl is the obvious example, and if
you just can't stand its core syntax, in full respect of this
"maximal freedom" principle, you can of course change it, too -- see
http://www.csse.monash.edu.au/~damia...Perligata.html and
revel in that _truly_ maximal freedom. Or, for a language that's
somewhat in-between, but still philosophically accepts the "maximal
freedom" tenet for which you crave, try Ruby -- if I _did_ want such
freedom, then Ruby is what I'd most likely use.

But can't you let us have *ONE* language that's designed according
to the concept you consider "almost certainly wrong"?! Why do YOU
use this language, even while you condemn its foundation and try to
undermine them, rather than using any one of the myriad that already
DO follow your philosophy?!

Trying to make Python into (e.g.) a Ruby with slightly different
cosmetics and "fine points" is truly absurd: if you want Ruby, you
know where to find it. Let Python stay Python, and leave those of
us who find ourselves best served by its design principles in peace!


Alex

[Robin Becker]

Re: Python's simplicity philosophy (was Re: reduce()--what is it good for?)

In article <Os3sb.4625$9_. 212870@news1.ti n.it>, Alex Martelli
<aleax@aleax.it > writes[color=blue]
>Robin Becker wrote:
> ...[color=green]
>> This whole thread is reminiscent of vi vs emacs or an os war or similar.
>> It's a pity that people with a preferred style should be so dogmatic
>> that they want to remove language features to prevent others using them.[/color]
>
>Python's essence is simplicity and uniformity. Having extra features
>in the language and built-ins runs directly counter to that.[/color]

no disagreement, reduce is in line with that philosophy sum is a
shortcut and as others have said is less general.
[color=blue]
>[color=green]
>> The whole 'only one way to do it' concept is almost certainly wrong.[/color]
>
>Bingo! You disagree with the keystone of Python's philosophy. Every
>other disagreement, quite consequently, follows from this one.
>[/color]

not so, I agree that there ought to be at least one way to do it.
[color=blue]
>Want "maximal freedom to express algorithms"? You can choose among[/color]

.... you may be right, but I object to attempts to restrict my existing
freedoms at the expense of stability of Python as a whole.
[color=blue]
>But can't you let us have *ONE* language that's designed according[/color]

I am not attempting to restrict anyone or change anyone's programming
style. I just prefer to have a stable language.
--
Robin Becker

[G.A.]

Re: Python's simplicity philosophy (was Re: reduce()--what is it good for?)

On Tue, 11 Nov 2003 11:39:20 +0000, Robin Becker
<robin@jessikat .fsnet.co.uk> wrote:
[color=blue]
>... you may be right, but I object to attempts to restrict my existing
>freedoms at the expense of stability of Python as a whole.[/color]

To paraphrase a famous saying (at least in the context of US law), your
freedom ends where another person's maintenance headache begins.

Gary

[Douglas Alan]

Re: Python's simplicity philosophy

Alex Martelli <aleax@aleax.it > writes:
[color=blue]
> Robin Becker wrote:[/color]
[color=blue][color=green]
>> The whole 'only one way to do it' concept is almost certainly wrong.[/color][/color]
[color=blue]
> Bingo! You disagree with the keystone of Python's philosophy. Every
> other disagreement, quite consequently, follows from this one.[/color]

The "only one way to do it" mantra is asinine. It's like saying that
because laissez faire capitalism (Perl) is obviously wrong that
communism (FP) is obviously right. The truth lies somewhere in the
middle.

The mantra should be "small, clean, simple, powerful, general,
elegant". This, however, does not imply "only one way to do it",
because power and generality often provide for multiple "right" ways
to flourish. In fact, trying to enforce that there be only "one way
to do it", will make your language bigger, messier, more complicated,
less powerful, less general, and uglier, as misguided souls rush to
remove powerful and general tools like reduce() from the language, and
fill it up with special-purpose tools like sum() and max().

People have written entire articles on how to do functional
programming in Python:

http://www-106.ibm.com/developerworks/linux/library/l-prog.html

You would castrate Python so that this is not possible? Then you
would diminish Python, by making it a less general, less elegant
language, that has become unsuitable as a language for teaching CS101,
and only suitable for teaching How Alex Martelli Says You Should
Program 101.

|>oug

[Alan Kennedy]

Re: Python's simplicity philosophy

[Robin Becker][color=blue][color=green][color=darkred]
>>> The whole 'only one way to do it' concept is almost certainly wrong.[/color][/color][/color]

[Alex Martelli][color=blue][color=green]
>> Bingo! You disagree with the keystone of Python's philosophy. Every
>> other disagreement, quite consequently, follows from this one.[/color][/color]

[Douglas Alan][color=blue]
> The "only one way to do it" mantra is asinine.[/color]

I hate to interrupt anybody's free flowing argument, but isn't it the
case that Guido never said "There should be only one way to do it"?

My understanding of the "Pythonic Philosophy" is that "there should be
only one *obvious* way to do it", which is quite a different thing
entirely.

This philosophy is aimed at making python easy for newbies: they
shouldn't get confused by a million and one different possible
approaches. There *should* (not "must"!) be a simple and obvious way
to solve the problem.

Once one is familiar with the language, and all of the subtle power it
encompasses, anything goes in relation to implementing an algorithm.

Just my €0,02.

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan

[Dave Brueck]

Re: Python's simplicity philosophy

> >> The whole 'only one way to do it' concept is almost certainly wrong.[color=blue]
>[color=green]
> > Bingo! You disagree with the keystone of Python's philosophy. Every
> > other disagreement, quite consequently, follows from this one.[/color]
>
> The "only one way to do it" mantra is asinine. It's like saying that
> because laissez faire capitalism (Perl) is obviously wrong that
> communism (FP) is obviously right. The truth lies somewhere in the
> middle.[/color]

Part of the problem here is that just saying "only one way to do it" is a
horrible misquote, and one that unfortunately misses IMO some of the most
important parts of that "mantra":

c:\>python
Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on
Type "help", "copyright" , "credits" or "license" for more information.[color=blue][color=green][color=darkred]
>>> import this[/color][/color][/color]
The Zen of Python, by Tim Peters
[snip]
There should be one-- and preferably only one --obvious way to do it.

-Dave

[Alex Martelli]

Re: Python's simplicity philosophy (was Re: reduce()--what is it good for?)

Robin Becker wrote:
...[color=blue][color=green]
>>Python's essence is simplicity and uniformity. Having extra features
>>in the language and built-ins runs directly counter to that.[/color]
>
> no disagreement, reduce is in line with that philosophy sum is a
> shortcut and as others have said is less general.[/color]

'sum' is _way simpler_: _everybody_ understands what it means to sum a
bunch of numbers, _without_ necessarily having studied computer science.

The claim, made by somebody else, that _every_ CS 101 course teaches the
functionality of 'reduce' is not just false, but utterly absurd: 'reduce',
'foldl', and similar higher-order functions, were not taught to me back when
_I_ took my first university exam in CS [it used Fortran as te main
language], they were not taught to my son in _his_ equivalent course [it
used Pascal], and are not going to be taught to my daughter in _her_
equivalent course [it uses C]. Google for "CS 101" and convince yourself
of how utterly absurd that claim is, if needed -- how small is the
proportion of "CS 101" courses that teach these subjects.

Python's purpose is not, and has never been, to maximize the generality
of the constructs it offers. For example, Ruby's hashes (and, I believe,
Perl's) are more general than Python's dicts, because in those hashes
you can use arbitrary mutable keys -- e.g., arrays (Ruby's equivalent of
Python's lists), strings (which in Ruby are mutable -- more general than
Python's strings, innit?), etc. Python carefully balances generality,
simplicity, and performance considerations. Every design is a series of
compromise decisions, and Python's design is, in my opinion, the best
one around (for my purposes) because those compromises are struck with
an _excellent_ batting average (not perfectly, but better than any other
language I've ever studied, or designed myself). The underlying idea
that there should preferably be ONE obvious way to express a solution
is part of what has kept Python so great as it evolved during the years.

[color=blue][color=green][color=darkred]
>>> The whole 'only one way to do it' concept is almost certainly wrong.[/color]
>>
>>Bingo! You disagree with the keystone of Python's philosophy. Every
>>other disagreement, quite consequently, follows from this one.[/color]
>
> not so, I agree that there ought to be at least one way to do it.[/color]

But not with the parts that I quoted from the "spirit of C", and I
repeat them because they were SO crucial in the success of C as a
lower-level language AND are similarly crucial in the excellence of
Python as a higher-level one -- design principles that are *VERY*
rare among computer languages and systems, by the way:

Keep the language small and simple.

Provide only one way to do an operation.

"Only one way" is of course an _ideal_ goal (so I believe the way
it's phrased in Python, "preferably only one obvious way") -- but
it's a guiding light in the fog of languages constructed instead
according to YOUR completely oppposite goal, and I quote you:

There should be maximal freedom to express algorithms.

Choose just about every OTHER language on Earth, and you'll find
it TRIES (with better or worse results depending on how well or
badly it was designed, of course) to meet your expressed goal.

But NOT Python: you're using one of the _extremely few_ languages
that expressly do NOT try to provide such "maximal freedom", that
try instead to stay small and simple and provide (preferably)
only one (obvious) way to do an operation. Your choice of language
is extremely peculiar in that it _contradicts_ your stated goal!
[color=blue][color=green]
>>Want "maximal freedom to express algorithms"? You can choose among[/color]
>
> ... you may be right, but I object to attempts to restrict my existing
> freedoms at the expense of stability of Python as a whole.[/color]

Nobody restricts your existing freedom of using Python 2.3.2 (or
whatever other release you prefer) and all of its constructs and
built-ins; nobody ever proposed retroactively changing the license
to do that (and I doubt it could be done even if anyone wished!).

But we're talking about Python 3.0, "the point at which backwards
compatibility will be broken" -- the next _major_ release. To quote
Guido, in 3.0 "We're throwing away a lot of the cruft that Python has
accumulated." After a dozen years of backwards compatible growth,
Python has a surprisingly small amount of such cruft, but it definitely
does have some. Exactly _what_ qualifies as 'cruft' is not yet decided,
and it won't be for quite a while (Guido thinks he won't do 3.0 until
he can take PSF-financed time off to make sure he does it right). But
there is no doubt that "reduce feature duplication" and "change rules
every so slightly to benefit optimization" _are_ going to be the
themes of 3.0.

Python can't keep growing with great new ideas, _AND_ still be a
small and simple language, without shedding old ideas that do not
pull their weight any more, if they ever did. Check out, e.g.,
the "python regrets" talk of well over a year ago,

http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.ppt

to see that lambda, map, filter, and reduce are all among those
regrets -- things that Guido believe he never should have allowed
in the language in the first place. E.g., and I quote from him:

"""
reduce()
nobody uses it, few understand it
a for loop is clearer & (usually) faster
"""

and that was way BEFORE sum took away the vast majority of reduce's
use cases -- so, guess how he may feel about it now...?

One of Python's realities is that _Guido decides_. Not without lots
of pressure being put on him each and every time he does decide, of
course -- that's part of why he doesn't read c.l.py any more, because
the pressure from this venue had gotten way excessive. Of course,
he's going to be pressured on each and every one of the items he
mentions in detail in the "regrets" talk and more summarily in the
Python 3.0 "State of the Python Union" talk. But I'm surely not the
only one convinced that here, like in (by far) most difficult design
decisions in Python's past, he's on the right track. Python does
need to keep growing (languages that stop growing die), but it must
not become big, so it must at long last lose SOME of the accumulated
cruft, the "feature duplication".

I'll deeply regret, come Python 3.0, not being able to code
"if blah(): fleep()"
on one single like any more, personally. And I may try to put on
pressure for a last-minute reprieve for my own pet "duplicated
feature", of course. But in the end, if I use Python it's because
I believe Guido is a better language designer than I am (and that
most other language designers are), so I will accept and respect
his decisions (and maybe keep whining about it forevermore, as I
do for the "print>>bah,gor p" one:-).

[color=blue][color=green]
>>But can't you let us have *ONE* language that's designed according[/color]
>
> I am not attempting to restrict anyone or change anyone's programming
> style. I just prefer to have a stable language.[/color]

I think Python's stability is superb, but stability cannot mean that
there will never be a 3.0 release, or that the language will have to
carry around forever any mistaken decision that was once taken. I'm
not advocating a "high level of churn" or anything like that: we have
extremely "sedate" and stable processes to gradually deprecate old
features. But such deprecation _will_ happen -- of that, there is
most definitely no doubt.


Alex

[Douglas Alan]

Re: Python's simplicity philosophy

"Dave Brueck" <dave@pythonapo crypha.com> writes:
[color=blue]
> Part of the problem here is that just saying "only one way to do it" is a
> horrible misquote, and one that unfortunately misses IMO some of the most
> important parts of that "mantra":[/color]

Well, perhaps anything like "only one way to do it" should be removed
from the mantra altogether, since people keep misquoting it in order
to support their position of removing beautiful features like reduce()
from the language.

|>oug

[Dave Brueck]

Re: Python's simplicity philosophy

> > Part of the problem here is that just saying "only one way to do it" is
a[color=blue][color=green]
> > horrible misquote, and one that unfortunately misses IMO some of the[/color][/color]
most[color=blue][color=green]
> > important parts of that "mantra":[/color]
>
> Well, perhaps anything like "only one way to do it" should be removed
> from the mantra altogether, since people keep misquoting it in order
> to support their position of removing beautiful features like reduce()
> from the language.[/color]

You're joking, right? It is one of the key aspects of Python that makes the
language such a good fit for me. Changing the philosophy because a *few*
people don't "get it" or because they are apt to misquote it seems crazy.

-Dave

P.S. If reduce() were removed, none of my code would break. ;-)

[Douglas Alan]

Re: Python's simplicity philosophy

"Dave Brueck" <dave@pythonapo crypha.com> writes:
[color=blue][color=green][color=darkred]
>> > Part of the problem here is that just saying "only one way to do
>> > it" is a horrible misquote, and one that unfortunately misses IMO
>> > some of the most important parts of that "mantra":[/color][/color][/color]
[color=blue][color=green]
>> Well, perhaps anything like "only one way to do it" should be removed
>> from the mantra altogether, since people keep misquoting it in order
>> to support their position of removing beautiful features like reduce()
>> from the language.[/color][/color]
[color=blue]
> You're joking, right? It is one of the key aspects of Python that makes the
> language such a good fit for me. Changing the philosophy because a *few*
> people don't "get it" or because they are apt to misquote it seems crazy.[/color]

Of course I am not joking. I see no good coming from the mantra, when
the mantra should be instead what I said it should be: "small, clean,
simple, powerful, general, elegant" -- not anything like, "there
should be only one way" or "one right way" or "one obviously right
way". I have no idea what "one obviously right way" is supposed to
mean (and I don't want to have to become Dutch to understand it)
without the language being overly-restricted to the point of
uselessness like FP is. Even in FP, I doubt that there is always, or
even typically one obviously right way to accomplish a goal. To me,
there is never *one* obviously "right way" to do anything -- the world
(and the programming languages I chose to use) offer a myriad of
possible adventures, and I would never, ever want it to be otherwise.

|>oug

[David Eppstein]

Re: Python's simplicity philosophy

In article <lc4qxau8h7.fsf @gaffa.mit.edu> ,
Douglas Alan <nessus@mit.edu > wrote:
[color=blue]
> "Dave Brueck" <dave@pythonapo crypha.com> writes:
>[color=green]
> > Part of the problem here is that just saying "only one way to do it" is a
> > horrible misquote, and one that unfortunately misses IMO some of the most
> > important parts of that "mantra":[/color]
>
> Well, perhaps anything like "only one way to do it" should be removed
> from the mantra altogether, since people keep misquoting it in order
> to support their position of removing beautiful features like reduce()
> from the language.[/color]

I think the more relevant parts of the zen are:
Readability counts.
Although practicality beats purity.

The argument is that reduce is usually harder to read than the loops it
replaces, and that practical examples of it other than sum are sparse
enough that it is not worth keeping it just for the sake of
functional-language purity.

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Dave Brueck]

Re: Python's simplicity philosophy

> >> > Part of the problem here is that just saying "only one way to do[color=blue][color=green][color=darkred]
> >> > it" is a horrible misquote, and one that unfortunately misses IMO
> >> > some of the most important parts of that "mantra":[/color][/color]
>[color=green][color=darkred]
> >> Well, perhaps anything like "only one way to do it" should be removed
> >> from the mantra altogether, since people keep misquoting it in order
> >> to support their position of removing beautiful features like reduce()
> >> from the language.[/color][/color]
>[color=green]
> > You're joking, right? It is one of the key aspects of Python that makes[/color][/color]
the[color=blue][color=green]
> > language such a good fit for me. Changing the philosophy because a *few*
> > people don't "get it" or because they are apt to misquote it seems[/color][/color]
crazy.[color=blue]
>
> Of course I am not joking. I see no good coming from the mantra, when
> the mantra should be instead what I said it should be:[/color]

Nah, I don't really like your version. Also, the "only one way to do it"
misquote has been singled out when it really should be considered in the
context of the other items in that list - for whatever reason (maybe to
contrast with Perl, I don't know) it's been given a lot of weight in c.l.py
discussion threads.
[color=blue]
> "small, clean, simple, powerful, general, elegant"[/color]

It's really a matter of taste - both "versions" mean about the same to me
(and to me both mean "get rid of reduce()" ;-) ).
[color=blue]
> To me, there is never *one* obviously "right way" to do anything[/color]

Never? I doubt this very much. When you want to add two numbers in a
programming language, what's your first impulse? Most likely it is to write
"a + b". The same is true of a lot of other, even much more complex, things.
And IMO that's where this principle of an obvious way to do things comes
into play, and it's tightly coupled with the principle of least surprise. In
both cases they are of course just guiding principles or ideals to shoot
for, so there will always be exceptions (not to mention the fact that what
is obvious to one person isn't universal, in the same way that "common
sense" is rarely common).

Having said that though, part of the appeal of Python is that it hits the
nail on the head surprisingly often: if you don't know (from prior
experience) how to do something in Python, your first guess is very often
correct. Correspondingly , when you read someone else's Python code that uses
some feature you're not familiar with, odds are in your favor that you'll
correctly guess what that feature actually does.

And that is why I wouldn't be sad if reduce() were to disappear - I don't
use reduce() and _anytime_ I see reduce() in someone's code I have to slow
way down and sort of rehearse in my mind what it's supposed to do and see if
I can successfully interpret its meaning (and, when nobody's looking, I
might even replace it with a for-loop!). Of course that would be different
if I had a history of using functional programming languages, which I don't.
That's the line Guido walks: trying to find just the right combination of
different-but-better and intuitive-for-most-people, and the aforementioned
items from the Zen of Python are a way of expressing that.

-Dave

[John Roth]

Re: Python's simplicity philosophy


"David Eppstein" <eppstein@ics.u ci.edu> wrote in message
news:eppstein-1FB54D.10202111 112003@news.ser vice.uci.edu...[color=blue]
> In article <lc4qxau8h7.fsf @gaffa.mit.edu> ,
> Douglas Alan <nessus@mit.edu > wrote:
>[color=green]
> > "Dave Brueck" <dave@pythonapo crypha.com> writes:
> >[color=darkred]
> > > Part of the problem here is that just saying "only one way to do it"[/color][/color][/color]
is a[color=blue][color=green][color=darkred]
> > > horrible misquote, and one that unfortunately misses IMO some of the[/color][/color][/color]
most[color=blue][color=green][color=darkred]
> > > important parts of that "mantra":[/color]
> >
> > Well, perhaps anything like "only one way to do it" should be removed
> > from the mantra altogether, since people keep misquoting it in order
> > to support their position of removing beautiful features like reduce()
> > from the language.[/color]
>
> I think the more relevant parts of the zen are:
> Readability counts.
> Although practicality beats purity.
>
> The argument is that reduce is usually harder to read than the loops it
> replaces, and that practical examples of it other than sum are sparse
> enough that it is not worth keeping it just for the sake of
> functional-language purity.[/color]

IMO, this arguement is basically religious, that is, it is not based
on common sense. Apply, lambda, map, filter and reduce never constituted
a complete set of functional programming constructs, so trying to
make them so for the sake of the arguement is, basically, silly.

Apply was absorbed into the language core with a small change
in function call specifications. Good idea - it gets rid of a built-in
function.
Map and filter were (almost) obsoleted by list comprehensions and the zip
built-in function. Whether or not list comprehensions are clearer than map
and filter is debatable, but the only thing we lost in the transition was
map's
capability of processing lists of different lengths.

Sum is not an adequate replacement for reduce, regardless of the
performance benefits. Something similar to a list comprehension would
be. I don't, at this point, have a good syntax to suggest though.

A not so good example would be:

numbers = [1, 2, 3, 4]
result = [x: x + i for i in numbers]

The ":" signals that the result is a single object, not a list of
objects. The first list element is bound to that label, and then
the expression is evaluated for the rest of the elements of the list(s).

The problem with the syntax is the brackets, which suggest that the
result should be a list.

John Roth
[color=blue]
> --
> David Eppstein http://www.ics.uci.edu/~eppstein/
> Univ. of California, Irvine, School of Information & Computer Science[/color]

[Bob Gailer]

Re: reduce()--what is it good for? (was: Re: reduce() anomaly?)

I am glad to hear others rise to the "defense" of reduce(). I too am
reluctant to see it leave the language, as I'd have to rewrite some of my
code to accommodate the change.

The use of zip(seq[1:], [:-1]) to me is more obscure, and
memory/cpu-expensive in terms of creating 3 new lists.

Bob Gailer
bgailer@alum.rp i.edu
303 442 2625


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 11/10/2003