|
rjmccall posted:Most of what you're saying makes sense, but this specifically is really weird. You're being blasé about, basically, introducing an arbitrary and unnecessary source of data corruption to your clients, who may or may not care about the sensors having nice, small identifying numbers but definitely care a lot about reliably identifying a single stream of data. If the renumbering thing is really important for some reason you haven't explained, then yes, you almost certainly should just delay/suppress sending any data to the client for the first cycles until you've figured out how many sensors there are. You're right, I was thinking of interacting with on-screen objects where a 5 ms blip will be imperceptible (actually given that that the screen's refresh rate is a much slower 60 Hz I'm not sure what will happen), or doing timeseries analysis on movement data in which case you'd be discarding the first few seconds of data anyway. But those are assumptions I probably shouldn't be making, plus there may be other applications I'm not anticipating. (The renumbering thing is definitely important. My lab does human subjects research, if we were doing a development study with, say, a child interacting with an adult, we don't want to have to say "oh, looks like you're controlling the wrong avatars, can you switch sensors?" Instead we just give the lower-numbered sensor, of whatever two we happened to grab, to the adult)
|
#
?
Jan 17, 2014 08:10
|
|
|
|
| # ? May 23, 2024 20:33 |
|
|
Instead of trying to insert the sensor data into an input data map of some sort directly, I would suggest instead inserting them into a list of (sensor-id, data-value) tuples in the received order, and then after one cycle process that list at once. (Putting tuples into a list should also have slightly more predictable performance than updating a dict.)
|
|
#
?
Jan 17, 2014 11:19
|
|
|
seiken posted:vvv that's ridiculous, naming has nothing to do with it. Control flow exceptions are poo poo no matter what the language is or what they're called I love hearing this argument because I imagine a programmer going LA LA LA I CAN’T HEAR YOU when they discover that exception handling is a form of control flow.
|
|
#
?
Jan 17, 2014 14:58
|
|
|
I like the argument that exceptions should only be used in exceptional circumstances "because that's what the name says".
|
|
#
?
Jan 17, 2014 15:29
|
|
|
qntm posted:I like the argument that exceptions should only be used in exceptional circumstances "because that's what the name says". You should use goto instead of functions for your code. This makes your code more faster.
|
|
#
?
Jan 17, 2014 15:51
|
|
|
Which is why exceptions, a sort of non-local goto, are such an unalloyed good. We've come full circle.
|
|
#
?
Jan 17, 2014 15:56
|
|
|
qntm posted:I like the argument that exceptions should only be used in exceptional circumstances "because that's what the name says". This is exactly why they are called exceptions. You think they were named that because they're supposed to be used in non-exceptional circumstances?
|
|
#
?
Jan 17, 2014 16:19
|
|
|
How is StopIteration an exceptional circumstance?
|
|
#
?
Jan 17, 2014 16:34
|
|
|
I did mention I wasn't a python programmer. Nor did I design the language. I'm not going to defend their choice of exception implementation since it makes no sense to me 
|
|
#
?
Jan 17, 2014 16:37
|
|
|
Suspicious Dish posted:How is StopIteration an exceptional circumstance? It's an exceptionally poo poo design. 
|
|
#
?
Jan 17, 2014 16:37
|
|
|
Exception exception exception, that word has no meaning to me now... Whenever someone asks if they should learn Python, just say it's an exceptional language.
|
|
#
?
Jan 17, 2014 16:55
|
|
|
..btt posted:This is exactly why they are called exceptions. You think they were named that because they're supposed to be used in non-exceptional circumstances? Perhaps they mean such an exceptional circumstance as, not following the normal return path, or expected return path. c.f the semi-predicate problem Maybe exceptions just aren't goodenough
|
|
#
?
Jan 17, 2014 17:13
|
|
|
It's a nice idea, but not the reason. Have a read up on the history of exception handling (it starts with hardware). Of course this doesn't mean it's what the Python devs mean by "exception", but the concept predates Python by probably 50 years or so. E: oh, now I get it. Ignore me
..btt fucked around with this message at 17:36 on Jan 17, 2014 |
|
#
?
Jan 17, 2014 17:19
|
|
|
It turns out all the possible solutions to the semipredicate problem are bad in their own ways, especially when the error is recoverable or generally non-fatal 
|
|
#
?
Jan 17, 2014 17:20
|
|
|
..btt posted:It's a nice idea, but not the reason. Have a read up on the history of exception handling (it starts with hardware). (I have and no-one else gets my crummy jokes about it) quote:(a) to permit dealing with an operation's impending or actual failure. Two types of failure are of interest: range failure, and domain failure; from goodenough's paper in '75
|
|
#
?
Jan 17, 2014 17:34
|
|
|
Suspicious Dish posted:How is StopIteration an exceptional circumstance? If you have an iterable that's a million elements long, finding yourself at the end is a one-in-a-million event, which was agreed upthread to be pretty exceptional.
|
|
#
?
Jan 17, 2014 18:19
|
|
|
clearly, the classic C design pattern is better: Functions return whether or not they worked. Then if it didn't work, you check a global to see what was wrong. If your function actually needs to return data, you provide a pointer to where it should go as a parameter, and hope that you've understood the documentation and allocated enough memory for the results.
|
|
#
?
Jan 17, 2014 18:35
|
|
|
Guido van Rossum's coroutine library for AppEngine uses exceptions as the normal way to return values (due to limitations in Python 2's generators). He clearly does not feel that the name of a thing should dictate how it can be used.Python code:
|
|
#
?
Jan 17, 2014 18:42
|
|
|
SurgicalOntologist posted:(The renumbering thing is definitely important. My lab does human subjects research, if we were doing a development study with, say, a child interacting with an adult, we don't want to have to say "oh, looks like you're controlling the wrong avatars, can you switch sensors?" Instead we just give the lower-numbered sensor, of whatever two we happened to grab, to the adult) The bit I'm not following is how you can simultaneously know you're at the start of a session and NOT know that you might need to change sensor mappings. Seems like you should have a bit at the beginning that maps out the first sensors seen and doesn't need to be handled every time you're checking the mapping?
|
|
#
?
Jan 17, 2014 18:45
|
|
|
tef posted:I love hearing this argument because I imagine a programmer going LA LA LA I CAN’T HEAR YOU when they discover that exception handling is a form of control flow. Only if by control flow you mean the (╯° °）╯︵ ┻━┻ operator.
|
|
#
?
Jan 17, 2014 18:55
|
|
|
I just spent an hour trying to figure out why my fractal was coming out all wrong, and well...code: Look at the order of the indices.For bonus points, explain what went wrong in my brain there.
|
|
#
?
Jan 17, 2014 18:58
|
|
|
JawnV6 posted:The bit I'm not following is how you can simultaneously know you're at the start of a session and NOT know that you might need to change sensor mappings. Seems like you should have a bit at the beginning that maps out the first sensors seen and doesn't need to be handled every time you're checking the mapping? Yeah you're right. The issue I originally had with that is how to know when that initial mapping period is over. I don't trust the data coming in to be right on time, or to perfectly cycle between the sensors. But I just figured out a way to ask the device how many sensor's to expect (there's a function in the device's C API that was never mapped into the Python API) so this is now a moot point and I will explicitly wait until I get the expected number of sensors.
|
|
#
?
Jan 17, 2014 19:01
|
|
|
tef posted:I love hearing this argument because I imagine a programmer going LA LA LA I CAN’T HEAR YOU when they discover that exception handling is a form of control flow. what? Of course they're a form of control flow. They're a really bad form of control flow that you shouldn't use unless you run out of memory or can't open a file, that's the whole point
|
|
#
?
Jan 17, 2014 19:10
|
|
|
Suspicious Dish posted:How is StopIteration an exceptional circumstance? New iterator control mechanisms were developed because making users use an exception to control iteration is stupid. The use of StopIteration is exceptional because no one really uses it anymore
|
|
#
?
Jan 17, 2014 19:11
|
|
|
What newer control mechanisms were that?
|
|
#
?
Jan 17, 2014 19:15
|
|
|
tef posted:
But two and a half of these points relate to resumable exceptions, which hardly any languages have ever implemented (Smalltalk! and also amusingly supported by libUnwind), and which very few people would consider superior to just passing down a callback.
|
|
#
?
Jan 17, 2014 19:29
|
|
|
Suspicious Dish posted:What newer control mechanisms were that? Python code:
|
|
#
?
Jan 17, 2014 21:28
|
|
|
Python code:
|
|
#
?
Jan 17, 2014 21:34
|
|
|
QuarkJets posted:
 StopIteration is the newer iteration protocol, as defined in PEP 234 and implemented in Python 2.2. Before that, iterating over sequences with e.g. for item in seq was defined in terms of repeated calls to seq.__getitem__: seq[0], seq[1], and so on. This is obviously terrible if the sequence doesn't provide you efficient random access, so for instance it's O(n2) for a linked list like a collections.deque. The for loop predates StopIteration, not the other way around.
|
|
#
?
Jan 17, 2014 21:41
|
|
|
I mean if you just look at the built-in Exception hierarchy of Python it's clear that StopIteration is just weird and should have triggered some code smell alarms:pre:BaseException
+-- SystemExit
+-- KeyboardInterrupt
+-- GeneratorExit
+-- Exception
+-- StopIteration
+-- StandardError
| +-- BufferError
| +-- ArithmeticError
| | +-- FloatingPointError
| | +-- OverflowError
| | +-- ZeroDivisionError
| +-- AssertionError
| +-- ... others ...
.
.
.
|
+-- Warning
+-- DeprecationWarning
+-- PendingDeprecationWarning
+-- ... others ...
|
|
#
?
Jan 17, 2014 21:49
|
|
|
It's neat to see that ES6, which originally followed a model similar to Python, discovered a simple solution:JavaScript code:
|
|
#
?
Jan 17, 2014 22:04
|
|
|
The C++ in me is rolling it's eyes so hard it hurts right now.
|
|
#
?
Jan 17, 2014 22:30
|
|
|
Suspicious Dish: You can do the same basic idea pretty cleanly in a concatenative language by using a variable stack effect. Something like this will return a curried function (generator), and then every time you evaluate it you'll get either a "true" left on the stack with the value underneath or a "false" on the stack with no value.code:
|
|
#
?
Jan 17, 2014 23:53
|
|
|
Suspicious Dish posted:How is StopIteration an exceptional circumstance? I guess the principle is that in large arrays it's the most optimal way of iterating (i.e. keep going until something goes horribly wrong) and in smaller arrays the overhead is negligible compared to iterating over an array in the first place. Basically the idea that time = (x * y) + z where x is the length of the array, y is the time to access an element, and z is the exception handler evaluation time. For small values of x, z is massive, but the handling time is still small on modern processors. For larger values of x, z gets comparatively minute compared to checking the range of x versus the current position. I guess it's an optimisation of sorts?
|
|
#
?
Jan 18, 2014 00:42
|
|
|
It doesn't seem all that optimal - you're still checking every iteration whether the end has been reached yet, only now the library throws an exception once that happens which gets propagated up. I guess it's marginally better than checking twice whether you've reached the end (once inside the data structure and once outside), assuming that one of those checks can't be elided at any point. It seems like the "optimal" mechanism would be the functional-style "pass a callback which gets called on every element", where the end of the iteration implicitly happens when the function returns to the caller.
|
|
#
?
Jan 18, 2014 00:57
|
|
|
Exceptions are great, quit being afraid of them and quit pretending anyone gives half a poo poo that they're "expensive." This isn't 1995 and unless you're doing real-time work it literally does not matter at all.
|
|
#
?
Jan 18, 2014 03:18
|
|
|
HORATIO HORNBLOWER posted:Exceptions are great, quit being afraid of them and quit pretending anyone gives half a poo poo that they're "expensive." This isn't 1995 and unless you're doing real-time work it literally does not matter at all. Except they're also poo poo for debugging. Audio on iOS is done using C++ exceptions for flow control, which can severely hamper debugging legitimate or rare-firing C++ exceptions, since the debugger will halt on playing sound. Exceptions create basically an alternate stack unwinding system and if you aren't doing garbage collection can also gently caress up memory management unless you know what you're doing, which is certain to never *always* be the case. Exceptions as flow control is sufficiently wrong to warrant careful use, not wanton sprinkling around a codebase.
|
|
#
?
Jan 18, 2014 03:39
|
|
|
Suspicious Dish posted:How is StopIteration an exceptional circumstance? I really, really, really, hate this. I don't know why they use exceptions for this kind of stuff. Exceptions make sense for functions that can't reach their post-conditions and not much else. It's embarassing that so many languages and libraries use exceptions for basic control flow.
|
|
#
?
Jan 18, 2014 04:42
|
|
|
If the post-condition for iterable.next() is that the iterator is moved and the next item is returned, and then you call it when there is no next item, an exception seems kind of appropriate.
|
|
#
?
Jan 18, 2014 07:58
|
|
|
|
| # ? May 23, 2024 20:33 |
|
|
evensevenone posted:If the post-condition for iterable.next() is that the iterator is moved and the next item is returned, and then you call it when there is no next item, an exception seems kind of appropriate. So you're saying the item after the current item is nothing? So why not return None?
|
|
#
?
Jan 18, 2014 08:49
|
|
