Comments (6)
Ha! You asked me this WHILE I was fixing it. That was an early assumption about everything being
numeric that I knew I'd need to deal with and I did just that apparently while you were putting this question in.
As it stands, this should be addressed with the latest commit. However, there is still an open issue here which
is detecting cases where scale and offset don't make sense. My recent changes make it so that scale and offset
are not mandatory. So then you can store strings, booleans, etc.
But what happens if you supply a scale and offset and then provide bool values?
For now, if you don't specify a constraint type then we assume you know what you are doing. If you do
provide a constraint value, we check to make sure it is numeric.
I tried forcing users to specify a constraint type if they wanted to use scale or offset. But the problem is that you can have numeric types besides the Python builtins (matrices, complex numbers, numpy.float64, etc) and we cannot check all of those. So not specifying a type is an "out" in that case. Of course, you lose type checking functionality too.
We'll have to see if this is a reasonable compromise. Perhaps we just shouldn't check at all. If they specify
a scale and/or an offset, perhaps we should just wait and get a runtime error somewhere.
But in any case, the most recent commits at least removed the need for scale and offset to be mandatory.
from recon.
What about inverse aliases of booleans?
from recon.
So you mean something like having scale have a value of True if the alias was exactly equal to another boolean variable and False if it was the inverse of the base signal?
from recon.
Is this complexity worth it? I mean boolean signals are not a huge amount of storage. Inverses are then a subset of those. I'm not sure we'd really get any potential savings out of this. For one thing, I suspect people may not even think to use this feature even if we implemented it.
The problem I see with features like this (or even scaling+offset in general) is that they layer additional semantics onto the coding a decoding. I seriously considered just throwing out scale and offset altogether and sticking them in metadata instead. That way, people who extract the signals can do whatever they want. But it doesn't increase the complexity of conforming to the spec (since the spec would only dictate that implementations simply propagate metadata, not interpret it). Do you see my point?
from recon.
I'm not really considering the data saving, just the pre-existing data structures I'd like to fit in. I can interpret it that way if the data is boolean.
from recon.
If you don't care about data savings, then don't store as an alias, store as a (base) signal that is boolean. Then you can avoid having to "interpret" it at all.
from recon.
Related Issues (20)
- Add discussion to the paper about handling optional kinds of data
- Add argparse to wall_info script
- Create scripts to convert wall to meld HOT 1
- Create a script to convert dsres to meld HOT 1
- LICENCE file missing HOT 1
- Native MATLAB/Octave implementation
- Javascript implementation
- Look at u-msgpack-python HOT 1
- TypeError on fullRobot.mld HOT 10
- IOError on dsres.mld HOT 10
- Add argument parsing support to scripts
- Should DyMat (and SciPy) be added to install_requires? HOT 3
- Reduce entry overhead
- Use msgpack for everything HOT 10
- Look at wall2meld performance
- Avoid invalid files by error-prone mode flags of open HOT 5
- Use msgpack for transformations
- Register recon formats as media types HOT 1
- Update pyrecon on PyPI
- Register Content Type HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from recon.