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
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
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 KR 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
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' togglethis 'will create non existing property if necessary constructor ' swap this, other adjustthis, step, offset, factor, min, max, mask, wrap multiplythis, 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
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' togglethis 'will create non existing property if necessary constructor ' swap this, other adjustthis, step, offset, factor, min, max, mask, wrap multiplythis, 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
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
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' togglethis 'will create non existing property if necessary constructor ' swap this, other adjustthis, step, offset, factor, min, max, mask, wrap multiplythis, 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
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
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: 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
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' togglethis 'will create non existing property if necessary constructor ' swap this, other adjustthis, step, offset, factor, min, max, mask, wrap multiplythis, 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 adjustthis, step, offset, factor, min, max, mask, wrap multiplythis, 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
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 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
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
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 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
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
[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
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
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
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 lessthan118/lessthan instead of max117.95/max. 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
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
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
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 class T
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
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 class T
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
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 class T
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
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 simgear/debug/logstream.hxx
#include simgear/misc/commands.hxx
#include simgear/misc/props.hxx
+#include simgear/sg_inlines.h
#include Cockpit/panel.hxx
#include Cockpit/panel_io.hxx
@@ -39,22 +40,6 @@ SG_USING_STD(ofstream);
-/**
- * Template function to wrap a value.
- */
-template class T
-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.
maskdecimal/mask
step-0.05/step
min0.00/min
-max0.95/max
+max1.00/max
+resolution0.05/resolution
wraptrue/wrap
/binding
/action
@@ -304,7 +305,8 @@ properties' values.
maskinteger/mask
step-1/step
min108/min
-max117/max
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 class T
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
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
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
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 necessary sooner or later. (The same semantic
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
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 simgear/sg_inlines.h 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 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
