Some more notes

S

Steve Holden

David said:
Nope. Actually, I don't think that was even applicable since the call
I'm recalling took a UNC machine name but not a full path, so the only
thing in the parameter was the machine portion. Although maybe it did
include the share level.




I suppose, but I certainly saw UNC as a logical extension of path
semantics to cross the network boundary (and imagine that the choice
of \\ was logically consistent with that approach). It was a way to
layer a level "above the root" of the filesystem into a path naming
convention.
As in UNIX United, circa 1983, for example? That was essentially (IIRC)
a federated filesystem with each machine's root identified byt he
machine's name. It worked rather well for its time.
Although of course it DOES worek unr Cygwin, a superior environment to
many on Windows (even though the Twisted guys appear to dislike it).
Well, we clearly expect different things, which is fine, and shows the
variety in the universe :)

At least for me, knowing that the API permitted me to use
"/path/to/file.ext" instead of "\path\to\file.ext" made it seem
logical it would permit "//machine/share/path/file.ext" for
"\\machine\share\path\file.ext". Or at least desirable.
No use expecting logic form Microsoft, matey ;-)
I'll see if I can find at least one again and forward it over. I seem
to recall it was while using some of the win32net wrapped APIs to
interrogate things on a remote server.

But I'm also willing to just agree that it only impacts the machine
spec and that you could consider that distinct from any path
operation. I was really just qualifying the general comment about
Win32 accepting forward slashes in all system calls.

-- David

if-there's-a-nit-to-be-picked-you're-in-the-right-place-ly y'rs - steve
 
B

bearophile

Thank you Josiah Carlson for all your comments.
so argument over it is a moot point. [...]
Please stop advocating the removal of useful features. [...]
Stop complaining about them.

Well, I haven't done something bad, so I think I still have the rights
to discuss, suggest and ask things here.

In my opinion, the syntax-less case statement described in the PEP is
pure. That is, no new syntax is needed, but if your if/elif/else
statements are of a certain format, you gain the speed of dictionary
dispatch. I believe that any case-statement-like behavior in Python
will likely be of this sort.

I'm still too much ignorant of Python to understand this :)

I could have sworn that either append or prepend was fast

On Mathematica (4.0 ore less) both append and prepends are O(n) and
quite slow, if you want to do a much faster "append" to Mathematica
lists, you have to create a nested list:
[a, [b, [c, [d]]]]
And then Flatten it. This can be hundred times faster for 10000
elements.
A group of functions to do it re-defining the heads of the structure:

Clear[h123456]
createL = h123456[];
apppendL[l_, x_] := h123456[l, x];
prepL[l_, x_] := h123456[x, l];
convertL[l_] := Flatten[l] /.
h123456 -> List;

The only problem is education. Once one becomes educated about the
side-effects of append/extend/etc., one rarely has problems of this
kind,<

Okay. I'll take my time to learn more and I'll see if you are right.

Honestly, I (and likely many others) don't care that Mathematica can
be faster. C can be faster, Java can be faster, Perl can be faster.
We use Python for varying reasons and for varying purposes.<

I didn't meant to offend Python... I appreciate many languages at the
same time :)
(Comparing the speed of C with python is probably of little use, but
comparisons between Mathematica and Python can be a bit more
interesting, because they are both interpreted, etc. And maybe
Mathematica can suggest things to improve Python.)

For general programming, there are other better languages (in my
opinion, which I imagine is shared), nearly all of which are free.<

I agree.

If you mean things like (I can't remember the exact syntax, perhaps this is it)...
fib[a_] := If[a<3, Return[1], b=fib[a-1]+fib[a-2];fib[a]=b;Return]


Something like this is probably nicer and/or more correct:
fib[1] = 1;
fib[2] = 1;
fib[x_] := fib[x] = fib[x - 1] + fib[x - 2]

Mathematica's global hash can contain the triads: (functions, params,
value)

With a 'memoization decorator', it gets easier in the general case<

Nice :)

If you are talking about something else, perhaps you should describe
it.

I was talking about something different. I have found a page about it:
http://www.verbeia.com/mathematica/tips/HTMLLinks/Tricks_Misc_7.html
But this page is still quite basic: with the automatic rewriting rules
and pattern matching you can do lot of things.

Funny, I found no mention of division operator breaking on the Python
3.0 wiki:

I'm sorry, I'm ignorant and I'm just confused about all this. I've
read the PEP238:
http://www.python.org/peps/pep-0238.html
And here:
http://python.fyxm.net/peps/pep-3000.html
I find:
True division becomes default behavior

It's just an idea, and it's similar to Delphi sintax... The PEP275
suggests something like:

switch EXPR:
case CONSTANT:
SUITE
case CONSTANT:
SUITE
...
else:
SUITE

And:
Another proposed extension would allow ranges of values (e.g. case
10..14: ...)

I've just used the Python range(a,b) to express the half-open
interval... But probably the Pascal a..b syntax is better.

Understand that 'obj.attr = val' implies that obj is mutable. Do you
also want to remove object oriented programming in Python? Likely not,
but understand the implications for what you say.

I see.

A bear hug and thank you again,
Bearophile
 
J

Josiah Carlson

Thank you Josiah Carlson for all your comments.
so argument over it is a moot point. [...]
Please stop advocating the removal of useful features. [...]
Stop complaining about them.

Well, I haven't done something bad, so I think I still have the rights
to discuss, suggest and ask things here.

Oh, yes, feel free to complain about features that are being used by
literally thousands (perhaps hundreds of thousands) of people today.
Maybe tomorrow we'll start considering removing something so useful as
list mutation, dictionary mutation, object mutation, etc.

Or maybe not.

I'm still too much ignorant of Python to understand this :)

I'll quote the section of the PEP:

It should be possible for the compiler to detect an
if-elif-else construct which has the following signature:

if x == 'first':...
elif x == 'second':...
else:...

i.e. the left hand side always references the same variable,
the right hand side a hashable immutable builtin type. The
right hand sides need not be all of the same type, but they
should be comparable to the type of the left hand switch
variable.


Immutables are anything with type of: int, long, str, unicode, tuple;
though tuples must contain only other immutables to still be immutable.

I could have sworn that either append or prepend was fast

On Mathematica (4.0 ore less) both append and prepends are O(n) and
quite slow, if you want to do a much faster "append" to Mathematica
lists, you have to create a nested list:
[a, [b, [c, [d]]]]
And then Flatten it. This can be hundred times faster for 10000
elements.
A group of functions to do it re-defining the heads of the structure:

That was it. Well, in Python you no longer need to create recursive
structures. Just use list.append(), it is fast (you don't need to rely
on a Mathematica mis-feature *wink*). If you wanted to prepend instead,
just remember to list.reverse() it before you are done.

Okay. I'll take my time to learn more and I'll see if you are right.

Think of it like this. You had likely been reassigning lists to
themselves in order to repeatedly append or prepend to a Mathematica
list because standard appends and prepends were slow. Now you don't
have to. You were doing explicit mutation before, now you are doing
implicit mutation without need to flatten. Will the wonders never cease?

I didn't meant to offend Python... I appreciate many languages at the
same time :)

Ahh, but you said was, "hey, this super duper language does things like
this, wouldn't it be great if Python did this too?"

Understand that people have been building Python for only 2 years
younger than Mathematica. It gained some features and experience of C,
Modula and other languages which are far older than Mathematica, and
didn't limit the user to immutable types (thank god).

(Comparing the speed of C with python is probably of little use, but
comparisons between Mathematica and Python can be a bit more
interesting, because they are both interpreted, etc. And maybe
Mathematica can suggest things to improve Python.)

How would knowing about Mathematica help Python? Mathematica is
closed-source, commercial, and proprietary; you can't even look at the
guts for implementation details. We would be better off looking at
non-commercial implementations of Python, Perl, Lisp, Tcl, etc. for that.

And as for language features; it is of my opinion that the Mathematica
language leaves something to be desired, and I would prefer the
'features' of Mathematica language to be left there.

If you mean things like (I can't remember the exact syntax, perhaps this is it)...
fib[a_] := If[a<3, Return[1], b=fib[a-1]+fib[a-2];fib[a]=b;Return]


Something like this is probably nicer and/or more correct:
fib[1] = 1;
fib[2] = 1;
fib[x_] := fib[x] = fib[x - 1] + fib[x - 2]


If the code runs, it is correct. Is it in the Mathematica style? No.
I haven't written Mathematica code in around 3 years.

Mathematica's global hash can contain the triads: (functions, params,
value)

Hrm...lemme see...

global_hash = {}

def memoize(fcn):
def call(*args):
if (fcn, args) not in global_hash:
global_hash[(fcn, args)] = fcn(*args)
return global_hash[(fcn, args)]
return call

@memoize
def foo(arg1, arg2):
...

@memoize
def goo(arg1, arg2):
...


Goodness, so can Python. But it is not necessary, my original
declaration used individual dictionaries for each memoized function.

I was talking about something different. I have found a page about it:
http://www.verbeia.com/mathematica/tips/HTMLLinks/Tricks_Misc_7.html
But this page is still quite basic: with the automatic rewriting rules
and pattern matching you can do lot of things.

In the C/C++ world, that is called polymorphism. You can do
polymorphism with Python, and decorators may make it easier...


@accepts(int, str, int, unicode)
def foo(a, b, c, d):
pass

@accepts(str, int)
def foo(a, b):
pass


With a properly implemented accepts decorator (I believe one is floating
around there somewhere, I would give one, but it is getting late, and I
need to wash dishes and shave).

3.0 wiki:

I'm sorry, I'm ignorant and I'm just confused about all this. I've
read the PEP238:
http://www.python.org/peps/pep-0238.html
And here:
http://python.fyxm.net/peps/pep-3000.html
I find:

If you want floor division on integers, you can use the floor division
operator: // *gasp*

I believe that the standard division operator behavior on integers was
considered a misfeature in prior Python versions, a remnant of Python's
C roots, which is why it was slated for removal in 2.4, with documented
"it is going away" in the documentation for Python 2.3 .

It's just an idea, and it's similar to Delphi sintax... The PEP275
suggests something like:

Just because something fits with another language, doesn't mean that it
is even remotely Pythonic.

A bear hug and thank you again,

Gah, no more hugs. Please.
- Josiah
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,209
Messages
2,571,089
Members
47,687
Latest member
IngridXxj

Latest Threads

Top