473,320 Members | 1,872 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Sets in Python

Hello,
I recently tried using the set function in Python and was surprised to
find that

a=[ 1, 2,3, [1,2] ]

doesn't work with 'set', throwing TyperError (unhashable exception). I
found out that this is because lists can't be hashed.

So,this implies 'a' cannot be a set in python which i think is quite
unfortunate, after all 'a' does look like a mathematical set.

My question is,
1) Why can't lists be hashed?
and
2) This is not related, but is there i neat way (without pop and list
comprehension) to convert a set into a list? I say neat because i'm
guessing using list comprehension might turn out be slow and there
might be other methods which are faster.

Thank you for your time
SM

Sep 19 '07 #1
22 2056
sapsi wrote:
2) This is not related, but is there i neat way (without pop and list
comprehension) to convert a set into a list? I say neat because i'm
guessing using list comprehension might turn out be slow and there
might be other methods which are faster.
a = set([1, 2, 3, 4])
b = list(a)
Sep 19 '07 #2
On Sep 18, 5:39 pm, sapsi <saptarshi.g...@gmail.comwrote:
I recently tried using the set function in Python and was surprised to
find that

a=[ 1, 2,3, [1,2] ]

doesn't work with 'set', throwing TyperError (unhashable exception). I
found out that this is because lists can't be hashed.
So,this implies 'a' cannot be a set in python which i think is quite
unfortunate, after all 'a' does look like a mathematical set.
This is written as:

a = set([1, 2, 3, frozenset([1, 2])])
This is not related, but is there i neat way (without pop and list
comprehension) to convert a set into a list?
list(a)
Raymond

Sep 19 '07 #3
On Sep 19, 10:39 am, sapsi <saptarshi.g...@gmail.comwrote:
My question is,
1) Why can't lists be hashed?
They are mutable.

Sep 19 '07 #4
On Sep 18, 7:39 pm, sapsi <saptarshi.g...@gmail.comwrote:
Hello,
I recently tried using the set function in Python and was surprised to
find that

a=[ 1, 2,3, [1,2] ]

doesn't work with 'set', throwing TyperError (unhashable exception). I
found out that this is because lists can't be hashed.

So,this implies 'a' cannot be a set in python which i think is quite
unfortunate, after all 'a' does look like a mathematical set.
It is not the variable *a* itself that's a problem when constructing a
set (ie. set(a)); it is the content. set() goes through each of the
items and adds that item to the set. 1, 2, and 3 are valid because
they can be hashed. The next item in the list, however, is [1,2], and
cannot be hashed because it is a mutable list.

The solution is as Raymond Hettinger said:

a = set([1, 2, 3, frozenset([1, 2])])
My question is,
1) Why can't lists be hashed?
They're mutable.
and
2) This is not related, but is there i neat way (without pop and list
comprehension) to convert a set into a list? I say neat because i'm
guessing using list comprehension might turn out be slow and there
might be other methods which are faster.
list(a_set)
Thank you for your time
You're welcome.

Sep 19 '07 #5
sapsi <sa************@gmail.comwrote:
Why can't lists be hashed?
Several people have answered "because they're mutable" without
explaining why mutability precludes hashing. So:

Consider a dict (dicts have been in Python a *lot* longer than
sets, and have the same restriction) which allowed lists as
keys:

d = {}
k = [1, 2]
d[k] = None

Now, if I were to do:

k.append(3)

what would you expect:

d.keys()

to return? Did d magically rehash k when it was modified? Did d[k]
take a copy of k, and if so, how deep was the copy (consider
d[[1, k]] = None followed by a modification to k)? Leaving the hash
unchanged and relying on collision detection to resolve won't work,
since you may go directly for d[[1, 2, 3]] and not spot that
there's already an entry for it since it's been hashed under [1, 2].

"Practicality beats purity" and the design decision was to simply
sidestep these issues by disallowing mutable dict keys. And as the
set implementation is based on the dict implementation, it applies
to sets to.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
"Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump
Sep 19 '07 #6
On Sep 19, 6:16 am, Sion Arrowsmith <si...@chiark.greenend.org.uk>
wrote:
sapsi <saptarshi.g...@gmail.comwrote:
Why can't lists be hashed?

Several people have answered "because they're mutable" without
explaining why mutability precludes hashing. So:

Consider a dict (dicts have been in Python a *lot* longer than
sets, and have the same restriction) which allowed lists as
keys:

d = {}
k = [1, 2]
d[k] = None

Now, if I were to do:

k.append(3)

what would you expect:

d.keys()

to return? Did d magically rehash k when it was modified? Did d[k]
take a copy of k, and if so, how deep was the copy (consider
d[[1, k]] = None followed by a modification to k)? Leaving the hash
unchanged and relying on collision detection to resolve won't work,
since you may go directly for d[[1, 2, 3]] and not spot that
there's already an entry for it since it's been hashed under [1, 2].

"Practicality beats purity" and the design decision was to simply
sidestep these issues by disallowing mutable dict keys. And as the
set implementation is based on the dict implementation, it applies
to sets to.
While it's easy to explain the behavior, I think the decision to dis-
allow mutable items as keys is a bit arbitrary. There is no need for
dict to recompute hash (first of all, a user doesn't even need to know
if underneath 'hashing' is used -- the service is just a mapping
between one item to another item).

Since we know hashing is used, all that is needed is, a well-defined
way to construct a hash out of a mutable. "Given a sequence, how to
get a hash" is the problem. If later the given sequence is different,
that's not the dict's problem.
>>d = {}
a = 10
>>d[a] = 'foo'
d[5+5] = 'bar'
d[10]
'bar'

aren't the '5+5' which is 10, is different from the previous line's
a?.. so
why not allow similar behavior with lists/other sequence/even other
collections. As long as two objects compare equal the hash-result must
be the same. I guess this takes us to defining the equality operation
for lists-- which I think has a very obvious definition (ie same
length and the ith element of each list compare equal).

So if the list changes, it will result in a different hash and we will
get a hash-miss. I doubt this is in anyway less intuitive than dis-
allowing mutable items as keys.

Karthik

>
--
\S -- si...@chiark.greenend.org.uk --http://www.chaos.org.uk/~sion/
"Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

Sep 19 '07 #7
On Sep 19, 9:58 pm, Karthik Gurusamy <kar1...@gmail.comwrote:
>
Since we know hashing is used, all that is needed is, a well-defined
way to construct a hash out of a mutable. "Given a sequence, how to
get a hash" is the problem. If later the given sequence is different,
that's not the dict's problem.
Oh it is possible to construct a hash from a mutable. What is
difficult is creating the same hash when the mutable mutates. Or
indeed working out what it means when a hash key mutates and you
access the dictionary.
Ignoring this gives the programmer a big problem hence the limitation.

I don't think you have a better solution.

- Paddy.

Sep 19 '07 #8
On Sep 19, 3:06 pm, Paddy <paddy3...@googlemail.comwrote:
On Sep 19, 9:58 pm, Karthik Gurusamy <kar1...@gmail.comwrote:
Since we know hashing is used, all that is needed is, a well-defined
way to construct a hash out of a mutable. "Given a sequence, how to
get a hash" is the problem. If later the given sequence is different,
that's not the dict's problem.

Oh it is possible to construct a hash from a mutable. What is
difficult is creating the same hash when the mutable mutates.
Why? There is no reason that the dict should maintain the same hash,
after all the user is calling with a different sequence as key (after
the mutation).

There seems to be an underlying assumption that the dictionary key-
>value mapping should somehow maintain the mapping even when the key
changes behind its back.

The contract could very well be, hey if you give me a different
sequence later (by mutating the one you added), don't expect me to
find it in the dictionary.

>Or
indeed working out what it means when a hash key mutates and you
access the dictionary.
Ignoring this gives the programmer a big problem hence the limitation.

I don't think you have a better solution.
But why would a programmer expect to find the match, when his/her code
has changed the sequence (or has somehow let the hash key mutate) from
the time of dictionary addition.

If I did, a = [10, 20] and I did d[a]= 'foo', then a.append(30).
If dict complains key error on d[a] now, I won't be surprised. If I do
d[[10, 20, 30]], I will be surprised if it doesn't find the item. Of
course, in today's behavior the above is syntax error.

Karthik

>
- Paddy.

Sep 19 '07 #9
On Sep 19, 7:26 pm, Karthik Gurusamy <kar1...@gmail.comwrote:
If I did, a = [10, 20] and I did d[a]= 'foo', then a.append(30).
If dict complains key error on d[a] now, I won't be surprised. If I do
d[[10, 20, 30]], I will be surprised if it doesn't find the item. Of
course, in today's behavior the above is syntax error.
It sounds as though you're proposing something like the following:
>>k = mylist([1, 2])
d = {k : 'test'}
d[k]
'test'
>>k.append(3)
d[k]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: [1, 2, 3]

So far, so good. But how do you explain the following to a confused
newcomer?
>>d.keys()
[[1, 2, 3]]
>>k in d.keys()
True
>>k in d
False
>>d[k]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: [1, 2, 3]

In other words, to repeat Sion Arrowsmith's question, what would you
expect d.keys() to return after a key of d has been modified?

Mark

Sep 20 '07 #10
On Wed, 19 Sep 2007 20:58:03 +0000, Karthik Gurusamy wrote:
While it's easy to explain the behavior, I think the decision to dis-
allow mutable items as keys is a bit arbitrary. There is no need for
dict to recompute hash
What???

Of course it does. How else can it look up the key? Because it (somehow)
just recognizes that it has seen the key before? How? By magic?
(first of all, a user doesn't even need to know
if underneath 'hashing' is used -- the service is just a mapping between
one item to another item).
The user doesn't need to know the mechanism, but the dict does. Dicts are
implemented as hash tables. I suppose they could be implemented as
something else (what? linear lists? some sort of tree?) but the same
considerations must be made: the dict must be able to find keys it has
seen before. How is the dict supposed to recognise the key if the key has
changed?
Since we know hashing is used, all that is needed is, a well-defined way
to construct a hash out of a mutable. "Given a sequence, how to get a
hash" is the problem.
Nonsense. That's not the problem. The problem is how to get exactly the
same hash when the sequence has changed.

In other words, if you have two mutable objects M1 and M2, then you
expect:

hash(M1) == hash(M2) if and only if M1 and M2 are equal
hash(M1) != hash(M2) if M1 and M2 are unequal

but also:

if M1 mutates to become equal to M2, hash(M1) must remain the same while
still being different from hash(M2).

That means that hash() now is a non-deterministic function. hash([1,2,3])
will vary according to how the list [1,2,3] was constructed!

Obviously something has to give, because not all of these things are
mutually compatible.
If later the given sequence is different, that's
not the dict's problem.
Data structures don't have problems. Programmers do. And language
designers with sense build languages that minimize the programmers
problems, not maximize them.

So if the list changes, it will result in a different hash and we will
get a hash-miss. I doubt this is in anyway less intuitive than dis-
allowing mutable items as keys.
The choices for the language designer are:

(1) Invent some sort of magical non-deterministic hash function which
always does the Right Thing.

(2) Allow the hash of mutable objects to change, which means you can use
mutable objects as keys in dicts but if you change them, you can no
longer find them in the dict. They'll still be there, using up memory,
but you can't get to them.

(3) Simply disallow mutable objects as keys.

Alternative 1 is impossible, as we've seen, because the requirements for
the Right Thing are not mutually compatible.

Alternative (2) leads to hard-to-find, hard-to-diagnose bugs where you
store objects in a dict only for them to mysteriously disappear later.
Worse, it could lead to bugs like the following hypothetical:
>>M = [1, 2, 3]
D = {M: 'parrot'} # pretend this works
D
{[1, 2, 3]: 'parrot'}
>>M.append(4)
D
{[1, 2, 3, 4]: 'parrot'}
>>D[[1, 2, 3, 4]]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: [1, 2, 3, 4]

Try explaining that one to programmers: they can SEE the key in the dict
when they print it, but they can't get it or delete it because the hash
has changed.

Alternative 3 is easy to deal with: simply don't use mutable objects as
keys. That's what Python does. Sure, the programmer sometimes needs to
work around the lack (convert the list into a tuple, or a string, or
pickle it, whatever...) which on rare occasions is hard to do, but at
least there are no mysterious, hard to track down bugs.
--
Steven.
Sep 20 '07 #11
On Sep 19, 5:25 pm, Mark Dickinson <dicki...@gmail.comwrote:
On Sep 19, 7:26 pm, Karthik Gurusamy <kar1...@gmail.comwrote:
If I did, a = [10, 20] and I did d[a]= 'foo', then a.append(30).
If dict complains key error on d[a] now, I won't be surprised. If I do
d[[10, 20, 30]], I will be surprised if it doesn't find the item. Of
course, in today's behavior the above is syntax error.

It sounds as though you're proposing something like the following:
>k = mylist([1, 2])
d = {k : 'test'}
d[k]
'test'
>k.append(3)
d[k]

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: [1, 2, 3]

So far, so good. But how do you explain the following to a confused
newcomer?
>d.keys()
[[1, 2, 3]]
>k in d.keys()
True
>k in d
False
>d[k]

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: [1, 2, 3]

In other words, to repeat Sion Arrowsmith's question, what would you
expect d.keys() to return after a key of d has been modified?
In the new model, it should be the value at the time of addition.
That is [1,2] (not [1,2,3]). This does mean a copy of key in
maintained internally in the dict. I think today that's not needed
(just a reference to the key's object is sufficient).

Again, this may not be the most elegant solution; neither seems to be
the current requirement that keys must be immutable. Fundamentally
dict is a mapping; underneath it could even use other elaborate
algorithms (say for integer keys, an avl tree) -- there is no reason
to expose the the quirks of hashing to the programmer.

Karthik
>
Mark

Sep 20 '07 #12
On Sep 20, 5:02 am, Karthik Gurusamy <kar1...@gmail.comwrote:
In the new model, at the time of addition, you need to remember the
key at that time. If it's a list, you make a copy of the items.
In other words you ask the dict to freeze any mutable keys given to
it.
Try an implementation and you will find it is impractical. Checking
for mutability then doing deep copies of keys and would consume time
in something that greatly affects the speed of Python as a whole.
Pythons designers give *you* the option of doing this and leave the
underlying dict speedy. I can live with that.

- Paddy.
Sep 20 '07 #13
On Sep 20, 4:17 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
[...]
Data structures don't have problems. Programmers do.
That's QOTW material :-)
... And language
designers with sense build languages that minimize the programmers
problems, not maximize them.
....
>
The choices for the language designer are:

(1) Invent some sort of magical non-deterministic hash function which
always does the Right Thing.

(2) Allow the hash of mutable objects to change, which means you can use
mutable objects as keys in dicts but if you change them, you can no
longer find them in the dict. They'll still be there, using up memory,
but you can't get to them.

(3) Simply disallow mutable objects as keys.
(4) Allow mutable objects as keys, but have undefined (implementation
defined) behavior if keys are mutated.

This would seem a natural extension of the "we're all adults" paradigm
(if I name a variable _foo you should treat it as private).
Unfortunately there is no visual cue in this case, and tracking down
where you relied on undefined behavior is notoriously time-consuming
(just ask your nearest C++ multiplatform programmer).
Alternative 3 is easy to deal with: simply don't use mutable objects as
keys. That's what Python does. Sure, the programmer sometimes needs to
work around the lack (convert the list into a tuple, or a string, or
pickle it, whatever...) which on rare occasions is hard to do, but at
least there are no mysterious, hard to track down bugs.
Amen.

-- bjorn

Sep 20 '07 #14
On Thu, 20 Sep 2007 03:46:08 +0000, prikar20 wrote:
On Sep 19, 5:25 pm, Mark Dickinson <dicki...@gmail.comwrote:
>On Sep 19, 7:26 pm, Karthik Gurusamy <kar1...@gmail.comwrote:
If I did, a = [10, 20] and I did d[a]= 'foo', then a.append(30).
If dict complains key error on d[a] now, I won't be surprised. If I do
d[[10, 20, 30]], I will be surprised if it doesn't find the item. Of
course, in today's behavior the above is syntax error.

It sounds as though you're proposing something like the following:
>>k = mylist([1, 2])
d = {k : 'test'}
d[k]
'test'
>>k.append(3)
d[k]

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: [1, 2, 3]

So far, so good. But how do you explain the following to a confused
newcomer?
>>d.keys()
[[1, 2, 3]]
>>k in d.keys()
True
>>k in d
False
>>d[k]

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: [1, 2, 3]

In other words, to repeat Sion Arrowsmith's question, what would you
expect d.keys() to return after a key of d has been modified?

In the new model, it should be the value at the time of addition.
That is [1,2] (not [1,2,3]). This does mean a copy of key in
maintained internally in the dict.
A copy!? That has to be a deep copy. Which would make `dict`\s alot
slower and use more memory. Plus you can't store objects that can't be
copied anymore. That doesn't sound like a good trade off to me.

Ciao,
Marc 'BlackJack' Rintsch
Sep 20 '07 #15
On Sep 20, 9:50 am, thebjorn <BjornSteinarFjeldPetter...@gmail.com>
wrote:

it's bad form to reply to myself, I know, but
def __iter__(self):
for k in super(mdict,self).__iter__():
yield eval(k)
should probably be

def __iter__(self):
return (eval(k) for k in super(mdict,self).__iter__())

I'm still getting used to the power of generator expressions :-)

-- bjorn

Sep 20 '07 #16
On Sep 19, 10:58 pm, Bryan Olson <fakeaddr...@nowhere.orgwrote:
Bad news: Python 3000 has no immutable type for byte-strings.
The new bytes type cannot serve for dict keys or set members.
Many things one would want to hash are unhashable -- for
example, the results of the hash functions in hashlib.
Are you serious????

Sep 20 '07 #17
>>>>Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.au(SD) wrote:
>SDIn other words, if you have two mutable objects M1 and M2, then you
SDexpect:
>SDhash(M1) == hash(M2) if and only if M1 and M2 are equal
SDhash(M1) != hash(M2) if M1 and M2 are unequal
Huh? Unequal things may hash to the same value. That one of the essential
properties of a hash function.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org
Sep 20 '07 #18
On 2007-09-20, Marc 'BlackJack' Rintsch <bj****@gmx.netwrote:
>In the new model, it should be the value at the time of
addition. That is [1,2] (not [1,2,3]). This does mean a copy
of key in maintained internally in the dict.

A copy!? That has to be a deep copy. Which would make
`dict`\s alot slower and use more memory. Plus you can't store
objects that can't be copied anymore. That doesn't sound like
a good trade off to me.
Python's dict implementation is so deeply unorthoganal (is that a
word?) to Python's basic assignment semantics and clever type
hierarchy that it's hard to even sensibly promote anything other
than the current implementation without completely redesigning
Python.

--
Neil Cerutti
Sep 20 '07 #19
On 9/20/07, Dustan <Du**********@gmail.comwrote:
On Sep 19, 10:58 pm, Bryan Olson <fakeaddr...@nowhere.orgwrote:
Bad news: Python 3000 has no immutable type for byte-strings.
The new bytes type cannot serve for dict keys or set members.
Many things one would want to hash are unhashable -- for
example, the results of the hash functions in hashlib.

Are you serious????
It's a little Chicken Little. The current version of py3k has no
immutable bytes type, but there's work being done even as we speak to
implement it.
Sep 20 '07 #20

"Chris Mellon" <ar*****@gmail.comwrote in message
news:48******************************************@ mail.gmail.com...
| On 9/20/07, Dustan <Du**********@gmail.comwrote:
| On Sep 19, 10:58 pm, Bryan Olson <fakeaddr...@nowhere.orgwrote:
| Bad news: Python 3000 has no immutable type for byte-strings.
| The new bytes type cannot serve for dict keys or set members.
| Many things one would want to hash are unhashable -- for
| example, the results of the hash functions in hashlib.
| >
| Are you serious????
| >
|
| It's a little Chicken Little. The current version of py3k has no
| immutable bytes type, but there's work being done even as we speak to
| implement it.

To reinforce this comment: CPython3.0 will not be released for at least 9
months. The current 3.0.a1 is openly *experimental*. 3.0.a2 should be
released within a few weeks with an invitation for anyone concerned with
the final product to experiment with it.

GvR's development strategy has been to start small and add what is clearly
useful (rather than start large and trim). 3.0 is being trimmed bit.
Where too much is trimmed, something can get added back.

Sep 20 '07 #21
En Thu, 20 Sep 2007 08:46:29 -0300, Steven D'Aprano
<st***@REMOVE-THIS-cybersource.com.auescribi�:
Another way is to use this class:

class HashableList(list):
def __hash__(self):
return hash(tuple(self))
....and that will stop working as soon as the list is mutated (which is
exactly what you said before)

--
Gabriel Genellina

Sep 21 '07 #22
Thank you everyone for the assistance and for the very informative
discussion
Regards
SM

Sep 22 '07 #23

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

21
by: Raymond Hettinger | last post by:
I've gotten lots of feedback on the itertools module but have not heard a peep about the new sets module. * Are you overjoyed/outraged by the choice of | and & as set operators (instead of + and...
5
by: Raymond Hettinger | last post by:
For Py2.4, I'm working on a C implementation of Sets.py with the possibility of having a set() type as a builtin. There is a question as whether the current design for set of sets has been useful....
1
by: Gerrit Holl | last post by:
Brett C. wrote: > Sets now at blazing C speeds! > ----------------------------- > Raymond Hettinger implemented the sets API in C! The new built-ins are > set (which replaces sets.Set) and...
0
by: Dave Benjamin | last post by:
Hola, I made a backport of sets.py that will run on Jython 2.1. Here is a diff against the Python 2.3 version of sets.py. The changes were simple, but I may have made a mistake here or there,...
7
by: Steve | last post by:
This post has two parts. First is my feedback on sets. (Hello? Last summer called, they want their discussion thread back...) Second is some questions about my implementation of a partition...
6
by: Dan Stromberg | last post by:
Does anyone have a python implementation (or python C/C+ extension) that would allow me to perform set operations (union, intersection, difference, number of elements, &c) over very large...
11
by: Prateek | last post by:
I have 3 variable length lists of sets. I need to find the common elements in each list (across sets) really really quickly. Here is some sample code: # Doesn't make sense to union the sets -...
5
by: Alan Isaac | last post by:
This is an attempt to synthesize Bill and Carsten's proposals. (I'm changing the subject line to better match the topic.) http://docs.python.org/lib/typesmapping.html: for footnote (3) Keys...
7
by: Flavio | last post by:
Hi, I have been playing with set operations lately and came across a kind of surprising result given that it is not mentioned in the standard Python tutorial: with python sets, intersections ...
17
by: Larry Bates | last post by:
You can do the following: a = del a and a = {1:'1', 2: '2', 3: '3', 4:'4', 5:'5'} del a
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.