Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Wouldn't having a fixed-point type in Simgear be a better choice than floats for these situations? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine writes: > > GoF book?? > > esoteric geek speak :-) > http://hillside.net/patterns/DPBook/DPBook.html > > If you can't dazzle em with Nah, it's just shorter than typing "DESIGN PATTERNS: ELEMENTS OF REUSABLE OBJECT-ORIENTED SOFTWARE" or "the Gamma/Helm/Johnson/Vlissades book" all the time. For C++ programmers, the GoF book is as familiar as K&R book is/was for C programmers -- I wouldn't expect anyone to be dazzled by the abbreviation. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine writes:
> Actually I was thinking about writing self documenting code
> ie something like
>
> // virtual base class
> class FGProperty : public SGPropertyNode {
> FGProperty () = 0 ;
> }
>
> // type specific derived classes for each property 'type'
> class FGInt : public FGProperty {
> }
>
> class FGBool public FGProperty;
> class FGDouble public FGProperty;
> class FGString public FGProperty;
> etc..
>
> then
> class SomeSystem : public FGSubsystem
> {
> .
> private:
> FGBool* _serviceable;
> FGDouble* _rpm;
> FGDouble* _pressure;
> FGDouble* _suction;
> };
Sure -- that sounds relatively harmless, and adds the advantage of a
bit of extra compile-time type checking.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Julian Foad writes: > For those of us with a two-button mouse it's a little awkward; I've > configured Xwindows to emulate a middle button when I press both together. It should be very easy to add action areas over the actual displayed digits -- that way, even one-button-mouse Mac types can be happy. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Michael Bonar writes: > > ...snip > > >To understand the Command design pattern better, you can look at page > >233 of the GoF book. There's not a precise pattern in there > >corresponding to the property tree, but it does share some > >characteristics with the Mediator pattern (page 273). > > GoF book?? esoteric geek speak :-) http://hillside.net/patterns/DPBook/DPBook.html If you can't dazzle em with Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson wrote:
Julian Foad writes:
> I attach a patch which does these, and an update to navcom-radio.xml
> which specifies "resolution" appropriately and sets "max" to 118 or 136
> instead of 117.95 or 135.975. Other files will need to be updated
> similarly; how is this for a start? It seems to work without skipping
> values.
Committed -- thanks.
OK -- thanks. I have now fixed up all the other XML files in the base
package accordingly.
But what have I got myself into? I have introduced special handling of
discrete values (by specifying the new tag "resolution"), but I haven't
resolved the inconsistencies between the four cases:
- Analogue Clamped: min <= x <= max (this makes sense)
- Analogue Wrapped: min <= x < max (this makes sense)
- Discrete Clamped: not available (why not?)
- Discrete Wrapped: min <= x < max (matches analogue case but is
unintuitive)
What we have is sensible behaviour for analogue values but not for
discrete values.
It is silly not to have Discrete Clamped behaviour available. The
sensible definition of it, from the meaning of the word "maximum", would
be "min <= x <= max". But it would also be sensible to be able to
switch between "wrapped" and "clamped" without changing the value of "max".
Discrete Wrapped behaviour is now stable in the presence of
floating-point error (when "resolution" is specified to mark it as being
a "discrete" value), and its definition (meaning of "max") matches the
analogue case which I thought was a good idea. However, the meaning of
"max" here is not the intuitive meaning of the word. I said before that
the "max" value specified should not depend on the (variable) step size,
but now we have a fixed "resolution" which it could depend on. We could
specify "min=108, max=117.95, resolution=0.05" unambiguously with an
intuitive meaning of "max". In this example the range finishes just
before a round number, and it would be nicer to be able to write
something like "118" instead of
"117.95". When the range finishes on a round number, such as
(say) engine number 1 to 4 inclusive, then we want to write "min=1,
max=4" and for this to mean 1 to 4 inclusive, regardless of whether it
is wrapped or clamped.
This leads to:
- Analogue Clamped: min <= x <= max
- Analogue Wrapped: min <= x < max (we could allow or require
"lessthan" instead of "max")
- Discrete Clamped: min <= x <= max or min <= x < lessthan
- Discrete Wrapped: min <= x <= max or min <= x < lessthan
This seems reasonable from a user's point of view, but at the cost of
another new tag ("lessthan"). Is there a simpler way to handle discrete
values?
We could store the discrete value (e.g. radio frequency) as an integer
(e.g. 108000 to 117950 kHz in steps of 50, or channel number 0 to 199).
How would we _like_ to specify these?
- frequency: min=108000, lessthan=118000, step=50 or 1000 (but doesn't
lend itself to an analogue adjuster unless we also specify resolution=50)
- channel: type=integer, min=0, lessthan=200 (wrapped or not)
- channel: type=integer, min=0, max=199 (wrapped or not)
- engine: type=integer, min=1, max=4 (wrapped or not)
By storing a channel number rather than an frequency, we can make use of
the existing property attribute type="int" to provide the
snap-to-valid-value behaviour, rather than the "resolution" tag. But
then we have to convert the cahannel number to a frequency for display
and for output. This also requires that the property manager handles
integers in an appropriate manner, such as rounding to the nearest
integer when converting from floating-point representation. So maybe
that wouldn't be easier after all.
What to do? Implement "lessthan"? Or don't implement any support for
discrete values in the property-adjust commands, but let the
radio-specific C++ code take care of it in the getter and setter
functions tied to its frequency properties?
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Radio frequency range: min/max/wrap
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Megginson Sent: January 4, 2003 4:09 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Radio frequency range: min/max/wrap ...snip >To understand the Command design pattern better, you can look at page >233 of the GoF book. There's not a precise pattern in there >corresponding to the property tree, but it does share some >characteristics with the Mediator pattern (page 273). GoF book?? Cheers, Mike ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson writes:
>
> Norman Vine writes:
>
> > I think that what we are really trying to say is
> >
> > class SomeSystem : public FGSubsystem
> > {
> > .
> > private:
> >
> > FGProperty* _serviceable;
> > FGProperty* _rpm;
> > FGProperty* _pressure;
> > FGProperty* _suction;
> > };
>
> Not if this means what I think it means. Right now we're using the
> very common Command design pattern to represent actions that can be
> initiated by the user; in contrast, I think that you're talking about
> a class something like
>
> class FGProperty
> {
> public:
> void adjust (...);
> void multiply (...);
> void assign (...);
> // etc.
> private:
> SGPropertyNode_ptr _node;
> }
Actually I was thinking about writing self documenting code
ie something like
// virtual base class
class FGProperty : public SGPropertyNode {
FGProperty () = 0 ;
}
// type specific derived classes for each property 'type'
class FGInt : public FGProperty {
}
class FGBool public FGProperty;
class FGDouble public FGProperty;
class FGString public FGProperty;
etc..
then
class SomeSystem : public FGSubsystem
{
.
private:
FGBool* _serviceable;
FGDouble* _rpm;
FGDouble* _pressure;
FGDouble* _suction;
};
SomeSystem::init ()
{
_serviceable = new FGBool("/systems/something[0]/serviceable", true);
_rpm= new FGDouble("/engines/engine[0]/rpm", true);
_pressure = new FGDouble("/environment/pressure-inhg", true);
_suction = new FGDouble("/systems/something[0]/suction-inhg", true);
}
This way we can have Dr Pangloss's best of both worlds
ie Abstract properties and a data structure where the
intent is discernable by casual inspection and standard
'C' programming tools can be used for documentation
creation
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Dave Perry wrote: I just updated SimGear, FlightGear source, and base package from cvs. Now when I try to change frequencies, the numbers to the right of the decimal change mod 1, but the 1's, 10's and 100's didgits don't change. Yes, David changed it so that it is more like the real radio; one control (mouse left button) adjusts the sub-MHz part, and another (mouse middle button) adjusts the whole MHz. The left-and-right on the mouse is the opposite way round from the radio display; the logic is that the left button does the small adjustment and the middle button does a big adjustment, as it did before (though you may not have noticed). For those of us with a two-button mouse it's a little awkward; I've configured Xwindows to emulate a middle button when I press both together. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Radio frequency range: min/max/wrap
I just updated SimGear, FlightGear source, and base package from cvs. Now when I try to change frequencies, the numbers to the right of the decimal change mod 1, but the 1's, 10's and 100's didgits don't change. I know there were changes made in this area. Did I miss updating something? Plib per chance? I tried c172p-3d, the default c172, c172-3d-yasim, and the dc3. The dc3 was as before (i.e. rolled over after 117.95). All others were as described above. - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson writes:
>
> Norman Vine writes:
>
> > I think that what we are really trying to say is
> >
> > class SomeSystem : public FGSubsystem
> > {
> > .
> > private:
> >
> > FGProperty* _serviceable;
> > FGProperty* _rpm;
> > FGProperty* _pressure;
> > FGProperty* _suction;
> > };
>
> Not if this means what I think it means.
This is just saying 'what it as it is' :-)
In phenomenological terms
"To the things themselves"
I suggest that you step back and relook at this
as a user and not as the 'involved' author
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine writes:
> I think that what we are really trying to say is
>
> class SomeSystem : public FGSubsystem
> {
> .
> private:
>
> FGProperty* _serviceable;
> FGProperty* _rpm;
> FGProperty* _pressure;
> FGProperty* _suction;
> };
Not if this means what I think it means. Right now we're using the
very common Command design pattern to represent actions that can be
initiated by the user; in contrast, I think that you're talking about
a class something like
class FGProperty
{
public:
void adjust (...);
void multiply (...);
void assign (...);
// etc.
private:
SGPropertyNode_ptr _node;
}
I'd argue that that has almost no value. In C++ code, you can do
those things easily already:
_serviceable->setBoolValue(true);
The Command instances are not for C code; they're separate entities
that can be bound to user input. The methods on FGProperty would not
work because (a) commands would still need to be separate objects, so
the FGProperty methods would duplicate rather than replace them, and
(b) not all commands operate on properties anyway.
To understand the Command design pattern better, you can look at page
233 of the GoF book. There's not a precise pattern in there
corresponding to the property tree, but it does share some
characteristics with the Mediator pattern (page 273).
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Curtis L. Olson writes:
>
> Norman Vine writes:
> > I know nothing of Java and less about Gnome, but in Windows land
> > *most* programs that manipulate the registry at times other then
> > program installation are called 'viruses'
>
> And therefore, since the windows operating system can manipulate the
> registry while it is running ... QED :-)
the the same goes for the current implementation of FGFS QED :-)
Seriously though, I am trying to be productive !
< EP Speak >
This customer's 'story' is that the current 'iteration' seems confusing,
< /EPSpeak >
i.e.
class SomeSystem : public FGSubsystem
{
.
private:
SGPropertyNode_ptr _serviceable_node;
SGPropertyNode_ptr _rpm_node;
SGPropertyNode_ptr _pressure_node;
SGPropertyNode_ptr _suction_node;
};
I think that what we are really trying to say is
class SomeSystem : public FGSubsystem
{
.
private:
FGProperty* _serviceable;
FGProperty* _rpm;
FGProperty* _pressure;
FGProperty* _suction;
};
Note the clarity gained by abstracting out the underlying
implementation with a simple placeholder class
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine writes: > I know nothing of Java and less about Gnome, but in Windows land > *most* programs that manipulate the registry at times other then > program installation are called 'viruses' In this case, the application is the Windows operating system. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine writes: > I know nothing of Java and less about Gnome, but in Windows land > *most* programs that manipulate the registry at times other then > program installation are called 'viruses' And therefore, since the windows operating system can manipulate the registry while it is running ... QED :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Curtis L. Olson writes: > I was always taught: 1) Make a requirements specification 2) Make a > perfect and complete design (implies documentation could or should be > written at this point), 3) Impliment, 4) Test. When you finish one of > these steps, you move forward and never go back (too costly and > time-consuming to back track and redo.) That, of course, is the classic waterfall approach. It's a good design methodology for buildings and bridges, but, as it turns out, not for software. There's nothing wrong with #1 and #2 in principle, except that #1 is usually more political than practical, and #2 is usually prolonged indefinitely as an excuse not to move on to #3. > If things went astray in this process, then obviously you didn't do 1) > or 2) correctly. Either you are a screw up or you need a better > design methology to follow. This is the classic Emperor's New Clothes scam. > Obviously no one wants to be a screw up so we need to think up > better methodologies to follow to help us do a perfect requirements > spec and design up front. I was taught several goofy methologies > that I have always ignored because they seemed exceedingly > lame. :-) Just so. > The underlying fear is that the later a bug or insufficiency is > discovered in the process, the more costly it is to fix. That is > still true, but ... > > It's really really hard to do a perfect design up front that > encompases every future whim of your customer. In fact, beyond > trivial class room examples and maybe a few rare cases when all the > planets line up, I'd argue that it is impossible to do a perfect > requirements spec and perfect design before any coding happens. Kent Beck analyses this issue fairly well in one of his XP books. He makes some good economic arguments that, although any one missing feature is more expensive to add later, guessing today what features might be needed tomorrow is even more expensive because of all the wrong guesses. Especially with the waterfall approach, people tend to err on the side of conservatism (since there's no going back) and request every feature they might possibly need, no matter how unlikely. As a result, in my experience, what should be a $75,000 project quickly becomes a $2,000,000 project once it's scoped out, just for the sake of saving another $75,000 in possible feature enhancements later. I've written myself out of, perhaps, half a dozen big XML contracts by handing in an initial consultant's analysis saying that the scope of the project was far too big for any benefits it could ever bring. The project manager politely pays my invoice, then quietly finds a more agreeable consultant to write a new report. For the record, none of those projects succeeded in the end. > My inside sources tell me that these days people in software > engineering classes are thinking about a "spiral" approach. You still > have the same basic steps of doing a requirements spec, design, > impliment, test. But you permit yourself to iterate through the steps > and refine them as many times as it takes ... spiraling slowly towards > the finished product. Right -- that's incremental development. > Of course, what I was taught isn't complete bunk; the better job you > do at each stage (even if you plan to return and refine later) the > more quickly you arrive at a correct and finished product. That's true -- the code should be clean, easy to read, well-structured, and at least minimally commented. Clarity is more important than optimization most of the time. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine wrote: > > > > > We really need a dictionary of the 'known' property 'nouns', > > > 'verbs', 'adjectives' and 'adverbs' and *require* that this list is > > > updated before a new 'word' is introduced into the XML.> > Here is what I gleaned from your listing of the commands towards this end > > a property has the following methods > >assign < this, < value or 'other' > > >toggle < this > 'will create non existing property if necessary < >constructor >' >swap< this, other > >adjust < this, step, offset, factor, min, max, mask, wrap > >multiply < this, factor, min, max, mask, wrap > >scale< this, setting, offset, factor > For documentation purposes following are now affected by the presence of a 'resolution' tag also adjust < this, step, offset, factor, min, max, mask, wrap > multiply < this, factor, min, max, mask, wrap > Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson writes: > > Norman Vine writes: > > > This requirement is especially true in that 'the FGFS properties' > > is a 'one-of-a-kind' system > > I wish it were -- I could accept some kind of fame as the inventor of > something new -- but in fact it's just a simple, in-memory > hierarchical database. Its structure is very similar to that of the > Windows registery, the Java property system, and the Gnome gconf > stuff. I know nothing of Java and less about Gnome, but in Windows land *most* programs that manipulate the registry at times other then program installation are called 'viruses' Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Julian Foad writes: > I attach a patch which does these, and an update to navcom-radio.xml > which specifies "resolution" appropriately and sets "max" to 118 or 136 > instead of 117.95 or 135.975. Other files will need to be updated > similarly; how is this for a start? It seems to work without skipping > values. Committed -- thanks. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson writes: > > I am willing to accept a little lag but one can of course take the > > 'exteme-programming' approach of writing the documentation > > first before you code :-) > > Actually, they write the unit tests before they code. Kent Beck, at > least, doesn't seem to be a big fan of detailed documentation. This could take us down the road towards a discussion of underlying philosophies of software engineering. I took my software engineering class back in the late 80's when everyone was young and idealistic and before open-source really took off. I was always taught: 1) Make a requirements specification 2) Make a perfect and complete design (implies documentation could or should be written at this point), 3) Impliment, 4) Test. When you finish one of these steps, you move forward and never go back (too costly and time-consuming to back track and redo.) If things went astray in this process, then obviously you didn't do 1) or 2) correctly. Either you are a screw up or you need a better design methology to follow. Obviously no one wants to be a screw up so we need to think up better methodologies to follow to help us do a perfect requirements spec and design up front. I was taught several goofy methologies that I have always ignored because they seemed exceedingly lame. :-) The underlying fear is that the later a bug or insufficiency is discovered in the process, the more costly it is to fix. That is still true, but ... It's really really hard to do a perfect design up front that encompases every future whim of your customer. In fact, beyond trivial class room examples and maybe a few rare cases when all the planets line up, I'd argue that it is impossible to do a perfect requirements spec and perfect design before any coding happens. My inside sources tell me that these days people in software engineering classes are thinking about a "spiral" approach. You still have the same basic steps of doing a requirements spec, design, impliment, test. But you permit yourself to iterate through the steps and refine them as many times as it takes ... spiraling slowly towards the finished product. The assumption here is that we probably have to give up on the idea of doing a perfect design up front ... that has similar difficulties and challenges to predicting the future. There are some things we can predict pretty reliably (ie. the sunrise) but usually the things we want/need to predict are a lot more complex than that. Instead you do the best you can at each stage understanding that you will undoubtedly return to rework or refine the requirements spec and design and implimentation ... probably many times. To me this sounds a lot like what people often fall into naturally with open-source software development projects. Of course, what I was taught isn't complete bunk; the better job you do at each stage (even if you plan to return and refine later) the more quickly you arrive at a correct and finished product. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine writes: > This requirement is especially true in that 'the FGFS properties' > is a 'one-of-a-kind' system I wish it were -- I could accept some kind of fame as the inventor of something new -- but in fact it's just a simple, in-memory hierarchical database. Its structure is very similar to that of the Windows registery, the Java property system, and the Gnome gconf stuff. > I am willing to accept a little lag but one can of course take the > 'exteme-programming' approach of writing the documentation > first before you code :-) Actually, they write the unit tests before they code. Kent Beck, at least, doesn't seem to be a big fan of detailed documentation. > Here is what I gleaned from your listing of the commands towards > this end > > a property has the following methods > >assign < this, < value or 'other' > > >toggle < this > 'will create non existing property if necessary < >constructor >' >swap< this, other > >adjust < this, step, offset, factor, min, max, mask, wrap > >multiply < this, factor, min, max, mask, wrap > >scale< this, setting, offset, factor > These are all external operations on properties, not intrinsic methods. While property nodes are C++ objects, within FlightGear bindings they're pure data more similar a C struct. Once we have scripting working within FlightGear, people will no doubt define many more operations that can be performed on properties. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Curtis L. Olson writes: > > Perhaps a master document describing every property used in the > application is unreasonable, just like asking someone to maintain a > list of every variable used in the application would be unreasonable > and impossible to maintain. go for it :-) http://lxr.linux.no/ident > Instead, it might be more reasonable to ask the author of every module > to document all the properties used by that module ... this would be > more decentralized so everything wouldn't be in the same place, but > we'd at least have a chance at keeping each modules's docs up to date, > and if they lag, we can probably figure out who to beat up ... +1 < on a scale of agreement from -1.0 <-> 1.0 > I think that if we formalize the form of this a bit we can machine colate Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Perhaps a master document describing every property used in the application is unreasonable, just like asking someone to maintain a list of every variable used in the application would be unreasonable and impossible to maintain. Instead, it might be more reasonable to ask the author of every module to document all the properties used by that module ... this would be more decentralized so everything wouldn't be in the same place, but we'd at least have a chance at keeping each modules's docs up to date, and if they lag, we can probably figure out who to beat up ... Regards, Curt. Norman Vine writes: > David Megginson writes: > > > > Norman Vine writes: > > > > > We really need a dictionary of the 'known' property 'nouns', > > > 'verbs', 'adjectives' and 'adverbs' and *require* that this list is > > > updated before a new 'word' is introduced into the XML. > > > > That would be nice, but it would require a committed project manager > > willing and able to enforce it; if that manager were not extremely > > energetic, program development would soon start to drag down and stop. > > Well we certainly have a 'comitted' 'energetic' 'visionary' 'programer' with > CVS commit privilige that has created the requirement :-) > > This requirement is especially true in that 'the FGFS properties' is a > 'one-of-a-kind' system > > > I agree that documentation is a good > > thing, but it's necessary to accept that it will always lag a little. > > I am willing to accept a little lag but one can of course take the > 'exteme-programming' approach of writing the documentation > first before you code :-) > > > Right now, I've documented all of the built-in commands inside > > src/Main/fg_commands.cxx, but that's not all that useful for > > non-programmers. Here's a quick list for the documentation people, if > > anyone wants to beautify it (some of these are obviously deadwood and > > should be purged as soon as possible): > > Documenting the commands is *great* and I hope the documentation folks > pick up on your list but I believe that what we need is a more abstract level > of documentation. > A 'property' is a *very* abstract concept and I want to try to 'formalize' a bit > > ie > 1) what is property, > 2) how to define one > 3) what the allowable operations on one are. > > Here is what I gleaned from your listing of the commands towards this end > > a property has the following methods > >assign < this, < value or 'other' > > >toggle < this > 'will create non existing property if necessary < >constructor >' >swap< this, other > >adjust < this, step, offset, factor, min, max, mask, wrap > >multiply < this, factor, min, max, mask, wrap > >scale< this, setting, offset, factor > > > < this > always == (sgPropertyNode *) > > Hmmm... > > seems like we want to introduce 'class fgProperty' > > Cheers > > Norman > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson writes: > > Norman Vine writes: > > > We really need a dictionary of the 'known' property 'nouns', > > 'verbs', 'adjectives' and 'adverbs' and *require* that this list is > > updated before a new 'word' is introduced into the XML. > > That would be nice, but it would require a committed project manager > willing and able to enforce it; if that manager were not extremely > energetic, program development would soon start to drag down and stop. Well we certainly have a 'comitted' 'energetic' 'visionary' 'programer' with CVS commit privilige that has created the requirement :-) This requirement is especially true in that 'the FGFS properties' is a 'one-of-a-kind' system > I agree that documentation is a good > thing, but it's necessary to accept that it will always lag a little. I am willing to accept a little lag but one can of course take the 'exteme-programming' approach of writing the documentation first before you code :-) > Right now, I've documented all of the built-in commands inside > src/Main/fg_commands.cxx, but that's not all that useful for > non-programmers. Here's a quick list for the documentation people, if > anyone wants to beautify it (some of these are obviously deadwood and > should be purged as soon as possible): Documenting the commands is *great* and I hope the documentation folks pick up on your list but I believe that what we need is a more abstract level of documentation. A 'property' is a *very* abstract concept and I want to try to 'formalize' a bit ie 1) what is property, 2) how to define one 3) what the allowable operations on one are. Here is what I gleaned from your listing of the commands towards this end a property has the following methods assign < this, < value or 'other' > > toggle < this > 'will create non existing property if necessary < constructor >' swap< this, other > adjust < this, step, offset, factor, min, max, mask, wrap > multiply < this, factor, min, max, mask, wrap > scale< this, setting, offset, factor > < this > always == (sgPropertyNode *) Hmmm... seems like we want to introduce 'class fgProperty' Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine writes: > We really need a dictionary of the 'known' property 'nouns', > 'verbs', 'adjectives' and 'adverbs' and *require* that this list is > updated before a new 'word' is introduced into the XML. That would be nice, but it would require a committed project manager willing and able to enforce it; if that manager were not extremely energetic, program development would soon start to drag down and stop. I know of no open-source project that is able to enforce this kind of discipline; in fact, I know of no commercial project that actually succeeded in doing so, though I suspect that some defense and aerospace projects manage. I agree that documentation is a good thing, but it's necessary to accept that it will always lag a little. Right now, I've documented all of the built-in commands inside src/Main/fg_commands.cxx, but that's not all that useful for non-programmers. Here's a quick list for the documentation people, if anyone wants to beautify it (some of these are obviously deadwood and should be purged as soon as possible): Command: null Description: do nothing Command: exit Description: exit FlightGear Command: load Description: load a saved flight Parameters: file (optional): the name of the file to load, relative to the current directory (defaults to "fgfs.sav"). Command: save Description: save a flight Parameters: file (optional): the name of the file to save, relative to the current directory (defaults to "fgfs.sav"). Command: panel-load Description: (re)load the 2D panel Parameters: path (optional): the file name to load the panel from, relative to FG_ROOT. Defaults to the value of /sim/panel/path, and if that's unspecified, then to the relative path "Panels/Default/default.xml". Command: panel-mouse-click Description: pass a mouse click to the 2D panel Parameters: button: the mouse button number, zero-based is-down: true if the button is down, false if it is up x-pos: the x position of the mouse click y-pos: the y position of the mouse click Command: preferences-load Description: (re)load preferences Parameters: path (optional): the file name to load the panel from, relative to FG_ROOT (defaults to "preferences.xml"). Command: view-cycle Description: cycle the view Command: screen-capture Description: capture a screenshot Command: tile-cache-reload Description: reload the scenery tile cache Command: lighting-update Description: force the lighting to be updated Command: property-toggle Description: toggle a boolean property value between true and false Parameters: property: the name of the property to toggle; it will be created if it does not exist. Command: property-assign Description: assign a value to a property Parameters: property[0]: the name of the property to assign; it will be created if it does not exist. value: the value to assign to the property; *or* property[1]: the existing property to copy the value from. Command: property-adjust Description: increment or decrement a property value Parameters: property: the name of the property to adjust; it will be created if it does not exist. step: the amount of the increment or decrement (defaults to 0); *or* offset: offset (used for mouse movement, multiplied by factor) factor: scaling amount for the offset (defaults to 1) min (optional): the minimum allowed value (default is no minimum) max (optional): the maximum allowed value (default is no maximum) mask (optional): 'integer' to apply only to the left of the decimal point, 'decimal' to apply only to the right of the decimal place, or 'all' to apply to the full number (default is 'all') wrap: true if the value should be wrapped when it passes min or max, false if it should be clamped Command: property-multiply Description: multiply a property value Parameters: property: the name of the property to multiply; it will be created if it does not exist. factor: amount by which to multiply (defaults to 1) min (optional): the minimum allowed value (default is no minimum) max (optional): the maximum allowed value (default is no maximum) mask (optional): 'integer' to apply only to the left of the decimal point, 'decimal' to apply only to the right of the decimal place, or 'all' to apply to the full number (default is 'all') wrap: true if the value should be wrapped when it passes min or max, false if it should be clamped Command: property-swap Description: swap the values of two properties Parameters: property[0]: the name of the first property in the swap; it will be created if it does not exist property[1]: the name of the second property in the swap; it will be created if it does not exist Command: property-scale Description: set a property based on an axis or other moving input Parameters: property: the name of the property to scale; it will be created if it does not exist. setting: the current input device setting, usually between -1
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Julian Foad writes: > > Take a look at the patch I just submitted and let me know if you think > it's OK. it looks llike it will work < rant not aimed at any one or thing in particular > but where are all these 'properties' documented ? 'min', 'max', 'resolution', and 'wrap' all make perfect sense when talking about a 'value' but is there a 'crib sheet' anywhere so one can program in a new variable or is this all 'deep voodoo' reserved for the high priests or is it just a 'free for all' < /rant > We really need a dictionary of the 'known' property 'nouns', 'verbs', 'adjectives' and 'adverbs' and *require* that this list is updated before a new 'word' is introduced into the XML. This is espescially true in that the property gurus have stated that such a document is 'impossible' to produce given our present toolset and introducing new 'names' will just make the task more difficult unless we at least start documenting the new names as they are introduced. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
I (Julian Foad) wrote: I attach a patch which does these, ... ... It seems to work without skipping values. Ooh, I hate it when people say "it seems to work". It sounds so sloppy. What I meant is I designed it and analysed it very carefully, and then did just a quick test to confirm that it behaves as expected and doesn't have any obvious silly bugs. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine wrote: Julian Foad writes: Norman Vine wrote: A proper version needs to be based on Interval Arithmetic we could just snag a subset of the scalar functions from an existing package http://www.ti3.tu-harburg.de/~knueppel/profil/docu/Profil.texinfo_19.html Er ... we are not trying to do arithmetic on intervals. We are just incrementing and decrementing a scaler value within an interval. Er... If you want to assign a 'stepsize' that is not an integral value then you are doing Interval Arirthmetic Do you mean in the sense of using a tiny interval like [0.099,0.101] to represent a value like 0.1 that cannot be represented exactly in binary? I don't see how this would be particularly useful. also note I said 'snag a subset' ie just the scalar add and subtract parts Like this one? INTERVAL AddBounds (REAL r, REAL s) Returns an interval containing an enclosure of the true sum of r and s. So when advancing past the last valid frequency we could have AddBounds(135.975, 0.025) and it returns an interval that encloses 136.0 (presumably the smallest such interval). Then what? Could you give an example of what you mean? I don't follow. Granted you can make a special arithmetic for the frequency adjuster but why not use a proven mathematically sound methodology that will just work for any stepsize for all adjusters with or without wrap around I am explicitly aiming for a general implementation, not just for the radio frequencies. Take a look at the patch I just submitted and let me know if you think it's OK. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine wrote:
Julian Foad writes:
Norman Vine wrote:
This is the poor man's version taken from sg_inlines.h
// normalize a value to lie between min and max
template
inline void SG_NORMALIZE_RANGE( T &val, const T min, const T max ) {
T step = max - min;
while( val >= max ) val -= step;
while( val < min ) val += step;
};
That's effectively what we have (or had).
Close but not quite
Do you mean the fact that it brings values into range even if they are
more than one "interval size" away from the valid interval? That is a
fair comment, not affecting anything at present but nice for stability
(robustness) in the face of unknown future applications.
Or do you mean something else?
> and may not solve all of your perceived problems
My main perceived problem was that as floating-point errors accumulated,
~135.0 + ~1.0 will eventually become less than (136 - epsilon) which
would give a wrong radio frequency of 135. instead of wrapping round
to 118.0 or 135.0 or whatever. (136 MHz is not a valid frequency for
the COMM radio.)
The use of (analogue) circular wrapping like SG_NORMALIZE_RANGE provides
does not help prevent accumulated error. But the snap-to-valid-value
logic that I also proposed does.
and you are right about the < had > :-(
I'm suggesting to put it back ... or actually to use SG_NORMALIZE_RANGE.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson wrote:
Julian Foad writes:
> I don't like to add more configuration and code, I like to pare things
> down to the simplest correct implementation. But I think this "snap to
> valid value" behaviour will be necessary.
>
> I might have a go at an implementation. How do you feel about
> specifying "max" using the "min <= x < max" rule in all cases?
That may work -- please let me know what you come up with.
OK. I think the best thing to do would be:
Firstly, change back to wrapping modulo the interval, with "min <= x <
max" semantics. I believe the previous implementation did that. The
inline function that Norman mentioned also does that.
Secondly, make it snap to the nearest value (min + N*resolution) when a
"resolution" tag is present, taking special care of floating-point
precision. Or perhaps specify "number of divisions in the interval" as
an integer, instead of "resolution" by which I meant a floating-point
"size of a division".
I attach a patch which does these, and an update to navcom-radio.xml
which specifies "resolution" appropriately and sets "max" to 118 or 136
instead of 117.95 or 135.975. Other files will need to be updated
similarly; how is this for a start? It seems to work without skipping
values.
While working on this file I noticed some potentially serious warnings:
fg_commands.cxx: In function `bool do_property_adjust(const
SGPropertyNode*)':
fg_commands.cxx:435: warning: control reaches end of non-void function
fg_commands.cxx: In function `bool do_property_multiply(const
SGPropertyNode*)':
fg_commands.cxx:465: warning: control reaches end of non-void function
/usr/local/include/simgear/misc/props.hxx: At top level:
fg_commands.cxx:600: warning: `bool do_presets_commit(const
SGPropertyNode*)' defined but not used
And also the functions do_view_next and do_view_prev should probably be
"static".
- Julian
Index: fg_commands.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_commands.cxx,v
retrieving revision 1.13
diff -u -3 -p -d -r1.13 fg_commands.cxx
--- fg_commands.cxx 31 Dec 2002 18:26:06 - 1.13
+++ fg_commands.cxx 3 Jan 2003 23:13:07 -
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -39,22 +40,6 @@ SG_USING_STD(ofstream);
-/**
- * Template function to wrap a value.
- */
-template
-static inline void
-do_wrap (T * value, T min, T max)
-{
-if (min >= max) { // basic sanity check
-*value = min;
-} else if (*value > max) {
-*value = min;
-} else if (*value < min) {
-*value = max;
-}
-}
-
static inline SGPropertyNode *
get_prop (const SGPropertyNode * arg)
{
@@ -105,12 +90,21 @@ limit_value (double * value, const SGPro
if (min_node == 0 || max_node == 0)
wrap = false;
-if (wrap) { // wrap
-if (*value < min_node->getDoubleValue())
-*value = max_node->getDoubleValue();
-else if (*value > max_node->getDoubleValue())
-*value = min_node->getDoubleValue();
-} else {// clamp
+if (wrap) { // wrap such that min <= x < max
+double min_val = min_node->getDoubleValue();
+double max_val = max_node->getDoubleValue();
+double resolution = arg->getDoubleValue("resolution");
+if (resolution > 0.0) {
+// snap to (min + N*resolution), taking special care to handle imprecision
+int n = (int)floor((*value - min_val) / resolution + 0.5);
+int steps = (int)floor((max_val - min_val) / resolution + 0.5);
+SG_NORMALIZE_RANGE(n, 0, steps);
+*value = min_val + resolution * n;
+} else {
+// plain circular wrapping
+SG_NORMALIZE_RANGE(*value, min_val, max_val);
+}
+} else {// clamp such that min <= x <= max
if ((min_node != 0) && (*value < min_node->getDoubleValue()))
*value = min_node->getDoubleValue();
else if ((max_node != 0) && (*value > max_node->getDoubleValue()))
Index: navcom-radio.xml
===
RCS file: /home/cvsroot/FlightGear/FlightGear/Aircraft/Instruments/navcom-radio.xml,v
retrieving revision 1.4
diff -u -3 -p -d -r1.4 navcom-radio.xml
--- navcom-radio.xml2002/12/30 19:48:04 1.4
+++ navcom-radio.xml2003/01/03 23:13:01
@@ -286,7 +286,8 @@ properties' values.
decimal
-0.05
0.00
-0.95
+1.00
+0.05
true
@@ -304,7 +305,8 @@ properties' values.
integer
-1
108
-117
+118
+1
true
@@ -322,7 +324,8 @@ properties' values.
decimal
0.05
0.00
-0.95
+1.00
+0.05
true
@@ -340,7 +343,8 @@ properties' values
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Julian Foad writes:
>
> Norman Vine wrote:
> >
> > This is the poor man's version taken from sg_inlines.h
> >
> > // normalize a value to lie between min and max
> > template
> > inline void SG_NORMALIZE_RANGE( T &val, const T min, const T max ) {
> > T step = max - min;
> > while( val >= max ) val -= step;
> > while( val < min ) val += step;
> > };
>
> That's effectively what we have (or had).
Close but not quite and may not solve all of your perceived problems
and you are right about the < had > :-(
> > A proper version needs to be based on Interval Arithmetic we could just
> > snag a subset of the scalar functions from an existing package
> > http://www.ti3.tu-harburg.de/~knueppel/profil/docu/Profil.texinfo_19.html
>
> Er ... we are not trying to do arithmetic on intervals. We are just
> incrementing and decrementing a scaler value within an interval.
Er... If you want to assign a 'stepsize' that is not an integral value
then you are doing Interval Arirthmetic
in fact you are doing interval arithmetic with an integral stepsize
except that with integer arithmetic there are no precison problems
like the ones you brought up
also note I said 'snag a subset' ie just the scalar add and subtract
parts
Granted you can make a special arithmetic for the frequency adjuster
but why not use a proven mathematically sound methodology that will
just work for any stepsize for all adjusters with or without wrap around
ie a 'proper' implementation in the rigourous sense
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine wrote:
This is the poor man's version taken from sg_inlines.h
// normalize a value to lie between min and max
template
inline void SG_NORMALIZE_RANGE( T &val, const T min, const T max ) {
T step = max - min;
while( val >= max ) val -= step;
while( val < min ) val += step;
};
That's effectively what we have (or had).
A proper version needs to be based on Interval Arithmetic we could just
snag a subset of the scalar functions from an existing package
http://www.ti3.tu-harburg.de/~knueppel/profil/docu/Profil.texinfo_19.html
Er ... we are not trying to do arithmetic on intervals. We are just
incrementing and decrementing a scaler value within an interval.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson writes:
> Julian Foad writes:
>
> > The (previously) smooth rotation of angular values is worth
> > restoring and, unless it is tackled, I'm pretty sure floating-point
> > imprecision will result in users sometimes being unable to set an
> > end-point value like 118.000 MHz.
> >
> > Both use cases (1) and (2) can be accommodated together by applying the
> > more stringent snap-to-valid-value rule if and only if a non-zero
> > "resolution" is specified. (The resolution could be a property of the
> > controlled value and/or a property of the adjustment command.)
> >
> > I don't like to add more configuration and code, I like to pare things
> > down to the simplest correct implementation. But I think this "snap to
> > valid value" behaviour will be necessary.
> >
> > I might have a go at an implementation. How do you feel about
> > specifying "max" using the "min <= x < max" rule in all cases?
>
> That may work -- please let me know what you come up with.
This is the poor man's version taken from sg_inlines.h
// normalize a value to lie between min and max
template
inline void SG_NORMALIZE_RANGE( T &val, const T min, const T max ) {
T step = max - min;
while( val >= max ) val -= step;
while( val < min ) val += step;
};
A proper version needs to be based on Interval Arithmetic we could just
snag a subset of the scalar functions from an existing package
http://www.ti3.tu-harburg.de/~knueppel/profil/docu/Profil.texinfo_19.html
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Julian Foad writes: > The (previously) smooth rotation of angular values is worth > restoring and, unless it is tackled, I'm pretty sure floating-point > imprecision will result in users sometimes being unable to set an > end-point value like 118.000 MHz. > > Both use cases (1) and (2) can be accommodated together by applying the > more stringent snap-to-valid-value rule if and only if a non-zero > "resolution" is specified. (The resolution could be a property of the > controlled value and/or a property of the adjustment command.) > > I don't like to add more configuration and code, I like to pare things > down to the simplest correct implementation. But I think this "snap to > valid value" behaviour will be necessary. > > I might have a go at an implementation. How do you feel about > specifying "max" using the "min <= x < max" rule in all cases? That may work -- please let me know what you come up with. Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Julian Foad writes: > > I don't like to add more configuration and code, I like to pare things > down to the simplest correct implementation. But I think this "snap to > valid value" behaviour will be necessary. Sounds like this could make a useful addition FWIW - I have tried to keep some common tools in Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
I (Julian Foad) wrote: and, unless it is tackled, I'm pretty sure floating-point imprecision will result in users sometimes being unable to set an end-point value like 118.000 MHz. Not actually unable to, because they can go back to 135.975 and then forward to 118.000. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson wrote: Julian Foad writes: > I noticed that the radios had nav. freq. range 108.00 to 117.95 but com. > freq. 0 to 140; this should be 118 to 140. But while playing with that > I noticed that the wrapping is a bit unpredictable. With (min=118, > max=140, step=1, wrap=true) adjusting it up and down, it sometimes skips > 118 and sometimes skips 140. For the nav. frequencies, my 1991 UK > Pooley's Flight Guide confirms that the range is 108.00 to 117.95 > inclusive. But the current implementation that specifies (min=108.00, > max=117.95, step=0.05, wrap=true) tends to cycle (117.85, 117.90, > 108.00, 108.05) skipping 117.95. Yes, it was a mess. I've done some refactoring of the built-in property-adjust and property-multiply commands, and things work better now. I added a 'mask' argument that can take a value "decimal" to modify only the decimal part or "integer" to modify only the integer part. That means that the radio tunes more like a real KX-155 (or similar), at least if your panel is using navcom-radio.xml -- the left button adjusts the decimal part and the right button adjusts the integer part. I've also fixed the COM radio frequency range in that file. That's good to hear. Wrapping should also be simpler and more predictable. Ah, well ... It's good to see it factored out into a single place (limit_value). But I don't think it's predictable because floating-point imprecision can still break it (118.025 - 0.025 is sometimes a bit less than 118.000 and therefore becomes 135.975). Also, different kinds of "wrap" are wanted in different situations: (1) A circular value (e.g. heading, 0 to 360 degrees). The "min" value is considered to have the same meaning as the max value (both mean "North"). In this case the old behaviour, addition modulo 360, was correct and appropriate (so that 358 degrees plus a step of 5 becomes 003 degrees), giving a smooth rotation. Floating-point imprecision is not a problem: it doesn't matter whether 359 + 1 becomes 359.9 or wraps to 000.1, because they mean the same thing. In case (1) it is appropriate for the controlled range to be "min <= x < max" (not "min <= x <= max"), so that the specified "min" and "max" values are independent of the adjustment step size. Otherwise you would have to specify max=359 when step=1 but max=355 when step=5, and what when the step isn't known until run time? (2) A range where the bottom and top values do not mean the same. E.g. radio frequency whole MHz, 118 <= x < 136, which could also be stated as 118 <= x <= 135 when the step size is 1. It is important that the boundary values are stable in the presence of floating-point imprecision: 117.99 must not wrap to 135.something. The precision limit must be taken into account. In case (2) I can imagine wanting (in different situations) several different wrapping sequences. E.g. on an arbitrary control range of 100 to 200, step size 10: - Circular:190-100-110 / 193-103-113 / 103-193-183 / 110-100-190 - Hit first limit: 190-200-110 / 193-200-110 / 103-100-190 / 110-100-190 - Hit both limits: 190-200-100 / 193-200-100 / 103-100-200 / 110-100-200 - etc. In the case of an analogue value these all have ambiguities or "flickering" behaviour at their limits and I can think of no realistic requirement for any of them. In the case of a discrete value, I consider that all such sequences could be desirable in some situations, but the "circular" mode with "min <= x < max" covers the present (radio tuning) requirement well and can cover other requirements and is semantically simple. Discrete Values and Precision These definitions work for analogue and discrete values. However, when dealing with a property that takes only discrete values (e.g. the comm. radio frequency, usually at a resolution of 0.025 MHz) one could wish that at every step the value would be rounded off. Indeed, that will probably be necessary to prevent cumulative error from becoming larger than the floating-point precision limit "epsilon" and thus messing up the wrapping behaviour. One could always round values in the range (min +/- epsilon) to exactly min, and (max +/- epsilon) to exactly max. But that is only effective when the user takes the value to its limits, which might be never, so I don't think that's worth implementing. To avoid accumulating error, and also to round off grossly-wrong values (like 118.02 up to 118.025) would require the resolution to be specified separately: you can't say the value must be a multiple of the step size, because a control is often adjusted in steps of 5 or 10 times its resolution. Do we need to handle grossly-wrong values? Not when adjusting by pre-programmed increments as we do at present, but if we were to drag an analogue adjuster we would probably want it to click into place. Therefore I think that this method (snapping to (min + N*resolution)) will be necessar
re: [Flightgear-devel] Radio frequency range: min/max/wrap
Julian Foad writes: > I noticed that the radios had nav. freq. range 108.00 to 117.95 but com. > freq. 0 to 140; this should be 118 to 140. But while playing with that > I noticed that the wrapping is a bit unpredictable. With (min=118, > max=140, step=1, wrap=true) adjusting it up and down, it sometimes skips > 118 and sometimes skips 140. For the nav. frequencies, my 1991 UK > Pooley's Flight Guide confirms that the range is 108.00 to 117.95 > inclusive. But the current implementation that specifies (min=108.00, > max=117.95, step=0.05, wrap=true) tends to cycle (117.85, 117.90, > 108.00, 108.05) skipping 117.95. Yes, it was a mess. I've done some refactoring of the built-in property-adjust and property-multiply commands, and things work better now. I added a 'mask' argument that can take a value "decimal" to modify only the decimal part or "integer" to modify only the integer part. That means that the radio tunes more like a real KX-155 (or similar), at least if your panel is using navcom-radio.xml -- the left button adjusts the decimal part and the right button adjusts the integer part. I've also fixed the COM radio frequency range in that file. Wrapping should also be simpler and more predictable. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Radio frequency range: min/max/wrap
I noticed that the radios had nav. freq. range 108.00 to 117.95 but com. freq. 0 to 140; this should be 118 to 140. But while playing with that I noticed that the wrapping is a bit unpredictable. With (min=118, max=140, step=1, wrap=true) adjusting it up and down, it sometimes skips 118 and sometimes skips 140. For the nav. frequencies, my 1991 UK Pooley's Flight Guide confirms that the range is 108.00 to 117.95 inclusive. But the current implementation that specifies (min=108.00, max=117.95, step=0.05, wrap=true) tends to cycle (117.85, 117.90, 108.00, 108.05) skipping 117.95. There is a problem with the way "min" and "max" work when "wrap" is on and discrete steps are being used. "Wrap" is designed for analogue values to go round in a circle where "min" and "max" are regarded as equivalent. On things like our radio frequency controls, it is down to luck (due to floating-point precision) whether (min=118, max=140, step=1) cycles through (139, 140, 119) or (139, 118, 119). Some of the directional instrument controls are specified as (min=0, max=359, wrap=true). These should, I think, all be specified as (min=0, max=360, wrap=true), so that it doesn't skip 359, because in this case the min/max are the end points of an analogue range (not a set of discrete valid values). It doesn't matter whether it reads "360" or "0" for North. So: - Can anyone confirm the min. and max. settable com. frequencies on radios of this general type? I'm fairly convinced now that it must be 118.00 to 139.975 inclusive (or 139.95 on old models with 50 kHz spacing). - Do they wrap from one end of the range to the other? If not, it is easy to model properly. If they do, we need to look more carefully at the way the wrapping handles discrete steps. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
