Bug #2353: bag info: Rate is sometimes printed as fraction - RSBag - Open Source Collaboration Platform

Bug #2353

bag info: Rate is sometimes printed as fraction

Added by J. Wienke over 8 years ago. Updated almost 8 years ago.

Status:

Resolved

Start date:

07/24/2015

Priority:

Normal

Due date:

Assignee:

J. Moringen

% Done:

100%

Category:

Commandline Tools

Target version:

Robotics Service Bus - rsb-0.15

Description

For some channels. the rate is printed as a fraction, not as a number, e.g.:

Rate    : 25/124

Related issues

Associated revisions

Revision 988fc7e0
Added by J. Moringen almost 8 years ago

Builder-based formatting style in src/commands/info.lisp

fixes #2353, fixes #2352, refs #2351

src/commands/info.lisp (header): updated copyright
(bag-style-tree): new class
(stream): new special variable; used by `format-event' method
(format-event bag bag-style-tree t): new method; format bag and
channel information in a textual tree using a provided builder
traversal and computed properties
(info::print-format): changed :no -> nil in type
(command-execute info): construct a `bag-style-tree' instance and use
it in `format-event'
bag-info/main.lisp (main): translate print-format value :no to nil for
:print-format initarg of `info' command
rsbag-tools-commands.asd (system rsbag-tools-commands): added system
dependency on rsbag-builder

History

#1 Updated by J. Moringen over 8 years ago

Related to Bug #2352: bag info: Durations contain 'd0' at the end added

#2 Updated by J. Moringen over 8 years ago

J. Wienke wrote:

For some channels. the rate is printed as a fraction, not as a number, e.g.:

Fractions (of integers) are (rational) numbers :)

This happens when the duration is an integer (the number of events is always an integer). Dividing the two integers results in a rational number. For rates, this is arguably the correct behavior since rates are often rationals that cannot be represented exactly as floating point numbers (hence the custom rational number type in GStreamer).

Would it be better for your use-case to force everything to e.g. double float and print with eNN suffix (to address #2352 as well)?

#3 Updated by J. Wienke over 8 years ago

This might be true from a theoretical point of view but:

It makes automatic parsing hard
Users probably never have seen these suffixes
So I really don't mind whether the rate represented as floating point is off by a tiny fraction, as long as I have a consistent output format.