STL multimap

[castironpi]

Is multimap just a syntax-checked dictionary of mutable sequences?

Is def( a ): a[:]= [x] a trick or part of the language? It looks
pretty sharp in variable-width.

 

[Aaron Watters]

Hi there. Maybe a little more context would
help us figure out what you want here...

Is multimap just a syntax-checked dictionary of mutable sequences?

I think the equivalent of a multimap can be
implemented several different ways, depending on
what you need:

for
1 maps to 2,3
5 maps to 7
- dictionary mapping to lists
{ 1:[2,3], 5:[7] } # supports unhashable values
- dictionary mapping to dictionary
{ 1:{2:None,3:None}, 4:{7:None} } # faster for certain lookups
and dense data
- dictionary with tuple/pairs as keys
{ (1,2):None, (1,3):None, (4,7):None } # streamlined for
existence testing

If you search usenet (google groups) for multimap
you will find some nice discussions by Alex Martelli and others.

Is def( a ): a[:]= [x] a trick or part of the language? It looks
pretty sharp in variable-width.

You lost me here.

python 2.6:

def (a): a[:]=[x]

File "<stdin>", line 1
def (a): a[:]=[x]
^
SyntaxError: invalid syntax

All the best. -- Aaron Watters

===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=gaping+security+hole

 

[castironpi]

Hi there.  Maybe a little more context would
help us figure out what you want here...

Is multimap just a syntax-checked dictionary of mutable sequences?

I think the equivalent of a multimap can be
implemented several different ways, depending on
what you need:

  for
       1 maps to 2,3
       5 maps to 7
  - dictionary mapping to lists
       { 1:[2,3], 5:[7] } # supports unhashable values
  - dictionary mapping to dictionary
       { 1:{2:None,3:None}, 4:{7:None} } # faster for certain lookups
and dense data
  - dictionary with tuple/pairs as keys
       { (1,2):None, (1,3):None, (4,7):None } # streamlined for
existence testing

It's possible there are four different kinds of multimaps.

objects map to set
objects map to frozenset
objects map to sequence
frozenset maps to object

What does the STL use? I am interested in a serialization that
changes certain bits and appends more. Prior discussion brought me to
multimap, but that quotient stifled it.

If you search usenet (google groups) for multimap
you will find some nice discussions by Alex Martelli and others.

Is def( a ): a[:]= [x] a trick or part of the language?  It looks
pretty sharp in variable-width.

You lost me here.

I was referring to a couple of threads from the Winter [cit. off'd.]
that never really gelled.

Modifying parameters is crucial to a number of control flow structures
(program divisions). Examples could come handy.

def a( x ): x[:]= [x[0]+ 1] ...
b= [2]
a(b)
b

[3]

I'm not sure if doing so is operating strictly by side-effect, or what
the term is. I forget from theory class if all the same terminology
holds post hoc* to introduction of Memory structures, either hard or
soft as modeled in formal functional-expressional language systems. I
noticed the idiom x[:]= [y]. Does it mean the right thing? At higher
levels of complexity, it scans as an unnamed struct. (Warning,
interacts with logical development.) What is the meaning of slice
assigment, if not?

*post/poster [...after]. This use originates in the Latin phrase,
'post hoc ergo propter hoc'.

python 2.6:>>> def (a): a[:]=[x]

  File "<stdin>", line 1
    def (a): a[:]=[x]
        ^
SyntaxError: invalid syntax

All the best.  -- Aaron Watters

===http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=gaping+securit...

 

[castironpi]

Hi there.  Maybe a little more context would
help us figure out what you want here...

On May 5, 1:28 pm, (e-mail address removed) wrote:

I think the equivalent of a multimap can be
implemented several different ways, depending on
what you need:

  for
       1 maps to 2,3
       5 maps to 7
  - dictionary mapping to lists
       { 1:[2,3], 5:[7] } # supports unhashable values
  - dictionary mapping to dictionary
       { 1:{2:None,3:None}, 4:{7:None} } # faster for certain lookups
and dense data
  - dictionary with tuple/pairs as keys
       { (1,2):None, (1,3):None, (4,7):None } # streamlined for
existence testing

It's possible there are four different kinds of multimaps.

objects map to set
objects map to frozenset
objects map to sequence
frozenset maps to object

What does the STL use?  I am interested in a serialization that
changes certain bits and appends more.  Prior discussion brought me to
multimap, but that quotient stifled it.

If you search usenet (google groups) for multimap
you will find some nice discussions by Alex Martelli and others.

Is def( a ): a[:]= [x] a trick or part of the language?  It looks
pretty sharp in variable-width.

You lost me here.

I was referring to a couple of threads from the Winter [cit. off'd.]
that never really gelled.

Modifying parameters is crucial to a number of control flow structures
(program divisions).  Examples could come handy.

I am questioning if value-succession is a sufficient protocol to side
effects.

Fibonacci numbers are formulaic. Month names are tabular. Factorials
are recursive. Hold there is no use for a factorial generator, i.e.
no factorials in business. Things the real world generates are
network requests of a station, successive graphics (though so far only
for games*), month names (and other units of time), produce, and
dollar values in the form of prices.

* Information display isn't the top of the market.

Simple matching that's hard to explain in a formal language can yield
scheduling, value, opinion. It is not clear that art or architecture
have tender/vital value. I.e., it's possible that the only value of
computers is automation in a system that is already pretty fine at
food, utilities, and walls.

If recursive generators are really useless (erect wall might not be),
there's no jobs in looking in to it. Which brings me to persistence
of generators juxtaposed to merely persistence of functions.
Sequences could map into a database pretty easily, in a line or less,
if deque/set/dict (i.e. non-sequential) don't modify easily on disk,
what's the function that allocates in a database?

def a( x ): x[:]= [x[0]+ 1] ...
b= [2]
a(b)
b

[3]

 

[Aaron Watters]

I'm having trouble following your discussion
and I suspect you might be a friend of Mark V Cheney.
But I will focus on this one point.

If recursive generators are really useless (erect wall might not be),

I would like to have recursive generators --
for example to be able to traverse a tree
and yield the value at every node. Right now
to do this you need to build a chain of generators
from each leaf to the root of the tree (or avoid
recursion by managing your own stack of nodes).
Every yield must "bubble up the tree".

With stackless Python you create the equivalent
of a "recursive generator" by using channels
-- and you can do a lot of other cool stuff with
channels too. The "yield" (which doesn't even
require a special keyword ) goes directly to
the other endpoint of the channel, with no bubbling.
It's too bad the Python that comes
installed on Macs doesn't support channels .

I know I didn't address your question or comments...
-- Aaron Watters

====
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=ifdef+stackless

 

[Arnaud Delobelle]

I'm having trouble following your discussion
and I suspect you might be a friend of Mark V Cheney.
But I will focus on this one point.



I would like to have recursive generators --
for example to be able to traverse a tree
and yield the value at every node. Right now
to do this you need to build a chain of generators
from each leaf to the root of the tree (or avoid
recursion by managing your own stack of nodes).
Every yield must "bubble up the tree".

There is a patch that allows them:

http://bugs.python.org/issue2292

But I don't know how it is implemented (i.e. does the 'bubbling up'
behaviour still happen behind the scene?).

Else you could use a trampoline, as I've done here:

http://www.marooned.org.uk/~arno/python/cogenerator.html

(Scroll down to 'Flattening nested cogenerators' and 'recursive
cogenerators' - I had fun doing it but it is terribly inefficient).

 

[castironpi]

I'm having trouble following your discussion
and I suspect you might be a friend of Mark V Cheney.
But I will focus on this one point.



I would like to have recursive generators --
for example to be able to traverse a tree
and yield the value at every node.  Right now
to do this you need to build a chain of generators
from each leaf to the root of the tree (or avoid
recursion by managing your own stack of nodes).
Every yield must "bubble up the tree".

With stackless Python you create the equivalent
of a "recursive generator" by using channels
-- and you can do a lot of other cool stuff with
channels too.  The "yield" (which doesn't even
require a special keyword ) goes directly to
the other endpoint of the channel, with no bubbling.
It's too bad the Python that comes
installed on Macs doesn't support channels .

I know I didn't address your question or comments...
  -- Aaron Watters

====http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=ifdef+stackless

Just talking is fine. (There's an intellectual moment of a group and
thread, which is fine and even fine to measure.)

You may be limiting your target audience to those who have engaged in
intellectual pursuits in computer science. I may too.

My favorites to generate are "carfulls" of people, which compose
pretty broadly. I can do roads, traffic, scheduling, etc., and I'd
like to install microrail. Genetic searches for useful structures
show promise. But my community has basic needs met: food and hot
running water. Going more places does not improve quality of life,
nor does going more often. Art is not very pretty, or for long, and
the art of motion has always been dance. What generators run, how
often or when, in a good process?

I think feedback is important: if a computer can tell you what you
just said, say with keyboard metrics or recognition, you may get more
choice, and higher quality.

FTR, I am mostly staying off paper and on flash. If you have a
computer, I'll probably try to set up a tron.py server-- bet it's a
screenful.