Menu
▾
▴
cstk-devonly — A list for discussing CSTK's development issues
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
(5) |
Apr
(6) |
May
(3) |
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Stuart R. <st...@Cs...> - 2004-06-29 13:51:55
|
> Not sure whether it's this, but it doesn't look right:
> char *DataCell::get_string() {
> switch (type) {
> case CHAR_TYPE:
> return (char*)val.charval; //<- returns a byte as a ptr to a '\0'
> // terminated string
> }
> }
Whoops. That's my bad C knowledge coming out. Hehehe. Thanks. I'll change
it.
later,
Stuart
---
digimail: st...@tr...
electromagic-interweb: http://www.cs.nott.ac.uk/~str
This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
|
|
From: Kristof V. L. <kr...@co...> - 2004-06-29 13:47:10
|
Hi Stuart,
Stuart Reeves wrote:
> I want to be performing a vect[i].add_comp() but I notice that the method
> only accepts values between 0 and 255. The log files I'm testing my
> integration of LogFileParser and rtplot with have values that screw up the
> conversion to an unsigned 8bit value (such as -1). What was your thinking
> on the way in which scaling/accurate representation of these problematic
> values should be performed? I.e., should the vector object accept any
> values and scale them itself or should scaling be performed by the caller?
Ideally, I wanted to convert KVector to a template class (just like
BVector in the same file), but that would mean adjusting a lot of the
other files. I still plan to do it in the next months though..
I would argue for both approaches: sometimes you'd want to scale down
(when plotting hi-res sensordata on a handheld for instance) yourself,
sometimes you really need the vector to handle values that are floats or
more than 8 bits.. A template in that case would be our solution, I
think (without paying for it in performance).
> BTW, I have added (but not yet committed) a new field for <column> and
> <channel> entities called ``format.'' This can be set to ``float'' or
> ``integer'' to correspond with the DF_<type> defines.
Yep, that makes sense.
best,
Kristof.
http://www.comp.lancs.ac.uk/~kristof
|
|
From: Kristof V. L. <kr...@co...> - 2004-06-29 13:36:24
|
Stuart Reeves wrote:
> Cool. I've done very little work on CSTK recently. I was trying to hook up
> the log file parser into rtplot, but it's doing funny things. I'm sure
> I'll get to the bottom of it at some point.
Not sure whether it's this, but it doesn't look right:
char *DataCell::get_string() {
switch (type) {
case CHAR_TYPE:
return (char*)val.charval; //<- returns a byte as a ptr to a '\0'
// terminated string
}
}
> What data clustering/classification algorithms were you thinking of
> including in CSTK? I presume the k nearest neighbour class needs filling
> out...
Yup, Dikaios is now on the case since last week, in the meantime, I
added the SDM algorithm I used in my latest paper as well,
Best,
Kristof.
http://www.comp.lancs.ac.uk/~kristof
|
|
From: Stuart R. <st...@Cs...> - 2004-06-29 13:21:40
|
Hi, I want to be performing a vect[i].add_comp() but I notice that the method only accepts values between 0 and 255. The log files I'm testing my integration of LogFileParser and rtplot with have values that screw up the conversion to an unsigned 8bit value (such as -1). What was your thinking on the way in which scaling/accurate representation of these problematic values should be performed? I.e., should the vector object accept any values and scale them itself or should scaling be performed by the caller? BTW, I have added (but not yet committed) a new field for <column> and <channel> entities called ``format.'' This can be set to ``float'' or ``integer'' to correspond with the DF_<type> defines. later, Stuart --- digimail: st...@tr... electromagic-interweb: http://www.cs.nott.ac.uk/~str This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Stuart R. <st...@Cs...> - 2004-06-28 20:01:37
|
> So far, only the plot section works, the script is chaotic, and loads of > widgets need to be connected to the xml file, but it's easy work for > between paper writing and paper reviews :) Cool. I've done very little work on CSTK recently. I was trying to hook up the log file parser into rtplot, but it's doing funny things. I'm sure I'll get to the bottom of it at some point. What data clustering/classification algorithms were you thinking of including in CSTK? I presume the k nearest neighbour class needs filling out... later, Stuart --- digimail: st...@tr... electromagic-interweb: http://www.cs.nott.ac.uk/~str This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Kristof V. L. <kr...@co...> - 2004-06-28 18:54:50
|
I just started making a python script for the (long overdue) GUI layer.
It needs to be executed from the main directory:
'./cstk_devonly/gui/rtplotgui.p'
.. and expects the cstk_settings directory in that main directory as well.
So far, only the plot section works, the script is chaotic, and loads of
widgets need to be connected to the xml file, but it's easy work for
between paper writing and paper reviews :)
--
Kristof.
http://www.comp.lancs.ac.uk/~kristof
|
|
From: <ben...@id...> - 2004-05-25 08:21:15
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Kristof V. L. <kr...@co...> - 2004-05-17 10:32:42
|
Yup, I'm doing something very similar at this very moment, but with 40 accelerometers - my paper deadline is 23rd, so I'll be getting less and less responsive as I approach that date :) Best, Kristof. http://www.comp.lancs.ac.uk/~kristof |
|
From: Stuart R. <st...@Cs...> - 2004-05-13 14:01:35
|
Hi, The kind of neural net processing techniques used in this: http://www.cs.bris.ac.uk/Publications/Papers/1000617.pdf might be interesting and useful to CSTK... later, Stuart --- digimail: st...@tr... electromagic-interweb: http://www.cs.nott.ac.uk/~str This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Stuart R. <st...@Cs...> - 2004-04-08 11:32:28
|
> BTW: Is any actual parsing being done in LogFileParser? If not, should > we rename LogFileParser to LogFileReader (as you did in the example > code)? Just to make separation of concerns more clear between these > classes in the future.. Yeah, I just realised I called it LogFileReader (which was a mistake). LogFileParser does parsing inasmuch that it takes characters from a log file and then works out what values to put where in the channels... later, Stuart --- digimail: st...@tr... electromagic-interweb: http://www.cs.nott.ac.uk/~str |
|
From: Kristof V. L. <kr...@co...> - 2004-04-08 11:20:02
|
I did this already a week ago, so you probably have noticed already: two modules were added to the CVS repository: * cstk_datasets for example datasets (to assess & demo the code) * cstk_settings for the example XML settings documents (for a similar purpose) (they were in the cstk_devonly module before) Kristof. http://www.comp.lancs.ac.uk/~kristof |
|
From: Kristof V. L. <kr...@co...> - 2004-04-08 10:59:34
|
Whoops, my mistake - I thought the NMEA parser would do the reading and the parsing in one go, but this makes a lot more sense. BTW: Is any actual parsing being done in LogFileParser? If not, should we rename LogFileParser to LogFileReader (as you did in the example code)? Just to make separation of concerns more clear between these classes in the future.. Best, Kristof. http://www.comp.lancs.ac.uk/~kristof > -----Original Message----- > From: cst...@li... [mailto:cst...@li...] On > Behalf Of Stuart Reeves > Sent: 07 April 2004 13:17 > To: CSTK Development List > Subject: [Cstk-devonly] Re: NMEA Parser > > > In fact, this method fits definitely for the other parser classes as > > well.. You do need to add the channels and channel-length to the method I > > guess: > > virtual int read_line(char *line, DataCell* channels, uint numchannels)=0; > > so the method directly returns the channels in one go, right? > > Hmm... What I was thinking was that you might want to do something like > this: > > LogFileReader *l = new LogFileReader("datafile"); > NMEAParser *p = new NMEAParser(); > > while (blah) { > // Get the current line > char *line; > if (l->read_line(line); > // Parse it > p->parse_sentence(channels, numchannels, line); > ... > } > ... > } > > > Putting the channels and numchannels into read_line would be redundant > since all we're getting out of it is an unparsed string. No? |
|
From: Stuart R. <st...@Cs...> - 2004-04-07 12:24:48
|
> In fact, this method fits definitely for the other parser classes as
> well.. You do need to add the channels and channel-length to the method I
> guess:
> virtual int read_line(char *line, DataCell* channels, uint numchannels)=0;
> so the method directly returns the channels in one go, right?
Hmm... What I was thinking was that you might want to do something like
this:
LogFileReader *l = new LogFileReader("datafile");
NMEAParser *p = new NMEAParser();
while (blah) {
// Get the current line
char *line;
if (l->read_line(line);
// Parse it
p->parse_sentence(channels, numchannels, line);
...
}
...
}
Putting the channels and numchannels into read_line would be redundant
since all we're getting out of it is an unparsed string. No?
later,
Stuart
---
digimail: st...@tr...
electromagic-interweb: http://www.cs.nott.ac.uk/~str
|
|
From: Kristof V. L. <kr...@co...> - 2004-04-04 22:45:23
|
Hi Stuart, Sanity check = ok :) In fact, this method fits definitely for the other parser classes as well.. You do need to add the channels and channel-length to the method I guess: virtual int read_line(char *line, DataCell* channels, uint numchannels)=0; so the method directly returns the channels in one go, right? Best, Kristof. http://www.comp.lancs.ac.uk/~kristof/ On Sat, 3 Apr 2004, Stuart Reeves wrote: > I've implemented a basic NMEA parser with two basic methods: > > int parse_sentence(DataCell *channels, uint numchannels); > > int parse_sentence(DataCell *channels, > uint numchannels, > char *sentence); > > Essentially they get any NMEA string and parse the data into fields, > performing a checksum etc. (The top method reads from a file.) What now > needs to be done is to hook this up to SensorData implementors. This means > that I would want to be retreiving a data string from a log file or RS232. > For example, another method could be added to SensorData s.t.: > > virtual int read_line(char *line)=0; > > Implementors would make this method put a string version of the entire > line (e.g. scanned from a file or taken from the RS232 port) into char > *line so that the NMEA parser could be hooked up to it and put the > relevant NMEA data into channels... > > Make sense? Don't know if this is the best way to get around this problem > or not... |
|
From: Stuart R. <st...@Cs...> - 2004-04-03 16:07:36
|
I've implemented a basic NMEA parser with two basic methods: int parse_sentence(DataCell *channels, uint numchannels); int parse_sentence(DataCell *channels, uint numchannels, char *sentence); Essentially they get any NMEA string and parse the data into fields, performing a checksum etc. (The top method reads from a file.) What now needs to be done is to hook this up to SensorData implementors. This means that I would want to be retreiving a data string from a log file or RS232. For example, another method could be added to SensorData s.t.: virtual int read_line(char *line)=0; Implementors would make this method put a string version of the entire line (e.g. scanned from a file or taken from the RS232 port) into char *line so that the NMEA parser could be hooked up to it and put the relevant NMEA data into channels... Make sense? Don't know if this is the best way to get around this problem or not... later, Stuart --- digimail: st...@tr... electromagic-interweb: http://www.cs.nott.ac.uk/~str |
|
From: Stuart R. <st...@Cs...> - 2004-03-31 20:44:10
|
BTW, by ``strings'', I mean strings of maximum length 16 chars. Just to cover all bases. On Wed, 31 Mar 2004, Stuart Reeves wrote: > Hi, > > I'm going to add strings and char types to SensorData, because the NMEA > parser needs to put such data into DataCells. Just a warning, if you > wonder why it's there :) > > > later, > Stuart > --- > digimail: st...@tr... > electromagic-interweb: http://www.cs.nott.ac.uk/~str > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Cstk-devonly mailing list > Cst...@li... > https://lists.sourceforge.net/lists/listinfo/cstk-devonly > later, Stuart --- digimail: st...@tr... electromagic-interweb: http://www.cs.nott.ac.uk/~str |
|
From: Stuart R. <st...@Cs...> - 2004-03-31 20:14:06
|
Hi, I'm going to add strings and char types to SensorData, because the NMEA parser needs to put such data into DataCells. Just a warning, if you wonder why it's there :) later, Stuart --- digimail: st...@tr... electromagic-interweb: http://www.cs.nott.ac.uk/~str |
|
From: Kristof V. L. <kr...@co...> - 2004-03-31 15:51:47
|
Hi Stuart - sorry for the delay (due to me not being subscribed properly
to the mailing list. Duh.)
> 1) What's the difference between the columns and channels? Surely they
are
> one and the same thing?
Sometimes they are, sometimes they aren't: say you're only interested in
the data from two sensors, but the log file contains the data from
twenty sensors; in that case you can make the read() method more
efficient by discarding the other 18 values, so there are then 2
columns, and 20 channels. Hmm, I just noticed how these names are
confusing - I couldn't think of any better at the time..
> 2) I'm writing an NMEA parser at the moment, and I want to put it in a
new
> directory. Is this ok?
Of course - looking forward to it!
Best,
Kristof.
http://www.comp.lancs.ac.uk/~kristof/
|
|
From: Stuart R. <st...@Cs...> - 2004-03-27 16:36:13
|
Yo. I've finished + ci'ed the LogFileParser, but I now have two questions: 1) What's the difference between the columns and channels? Surely they are one and the same thing? 2) I'm writing an NMEA parser at the moment, and I want to put it in a new directory. Is this ok? Thanks. later, Stuart --- digimail: st...@tr... electromagic-interweb: http://www.cs.nott.ac.uk/~str |
|
From: Stuart R. <st...@Cs...> - 2004-03-26 21:01:54
|
> It seems that the only way to solve that read(DC,uint) problem is to > pass twice over the log file, with the first pass to get the minimum and > maximum limits for that specific channel. This is something you can do > with log files, but not with, say, streaming data (over serial line, > UDPs, ...). > > That's also what I meant in the comment for the empty read() method: it > first of all needs an object to store its data in, and it's impossible > to estimate number and type of channels for streaming data. > So I think we should just stick to the first two read(...) methods, and > make the logfile parser read(DC,uint) method a bit superior (over > rs232parser and the like) by not specifically requiring type definitions > for the channels - what do you think? Yes, I agree about the read(DC, uint) method for LogFileParser `superior'. It certainly makes more sense. After all, of course, the channels are specified by the associated XML file (AFAIK). This means that even for rs232 input, CSTK at least knows how many channels to expect. This does raise the issue of value scaling. For example, if I have a channel in a log file that starts off as a 8bit number, but eventually turns into a high 64bit number, the way that this is interpreted will the visualisation and any other receivers of this data that are sensitive to scale. later, Stuart --- digimail: st...@tr... electromagic-interweb: http://www.cs.nott.ac.uk/~str |
