JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

IRP Specification
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
Blade_Runner_2015



Joined: 05 Feb 2010
Posts: 6

PostPosted: Mon Feb 15, 2010 4:47 pm    Post subject: minor typos ? Reply with quote

This is a wonderful document! Thanks for putting it together.

A few typos to be corrected in the next version:

- automated process ro parse
- bit of the unshifed value
- all tbe bits
- bits beyond a cartain point


technical:

These are the only binary forms whose value can be negative

should this not be: These can only be binary forms whose values are negative.

(in the usual 1's complement form)
I believe this should be: (in the usual 2's complement form)

negative integers are expressed in 1's complement notation
I believe this should be: negative integers are expressed in 2's complement notation

negative values being expressed in the usual 1's complement form
I believe this should be: negative values being expressed in the usual 2's complement form

a negative integer in 1's complement form
I believe this should be: a negative integer in 2's complement form

negative integer is its usual 1's complement
negative integer in its usual 2's complement[/i]
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3175
Location: Cambridge, UK

PostPosted: Mon Feb 15, 2010 5:18 pm    Post subject: Reply with quote

Many thanks, Blade Runner. Especially on 1's Complement versus 2's Complement. You are absolutely right but for some reason the terms were fixed in my mind the wrong way round. They have been for a long time. I wonder how many times I have made that mistake. Sad As for
Quote:
These are the only binary forms whose value can be negative

should this not be: These can only be binary forms whose values are negative.

I take your point but think I will rephrase the sentence rather than just change to your wording. And thanks too for spotting all the typos - you really have read it carefully.
__________________
Graham
Back to top
View user's profile Send private message
Blade_Runner_2015



Joined: 05 Feb 2010
Posts: 6

PostPosted: Mon Feb 15, 2010 8:23 pm    Post subject: Reply with quote

Yes, I know I didn't get the phrasing or meaning just right - I'm sure you will be able to do much better than my suggestion.

Also, at the risk of splitting hairs I would point out that the document states "The number in a frequency item can include a decimal point. This is the only situation in IRP notation in which numbers can be other than integers" however in the document at http://www.hifi-remote.com/johnsfine/DecodeIr.html the G.I. Cable and G.I. Cable{1} UEI protocol: 00C4 shows a parameter value of 4.5 in the bitspec and the IRstream.
IRP notation: {38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*) C= -(D + F:4 + F:4:4)

I only mention this as a trivial comment for your extremely thorough and well written document. Thanks again for making it all so clear. Blade_Runner_2015. Belleville Ontario Canada
Back to top
View user's profile Send private message
Blade_Runner_2015



Joined: 05 Feb 2010
Posts: 6

PostPosted: Mon Feb 15, 2010 10:59 pm    Post subject: Reply with quote

A few more questions Graham;

For the statement:
"For a bitspec that translates bits in groups of n, the number of possible combinations is 2 to the power n. The corresponding sequences of bare IRstreams are listed in the order of the bit sequences given by the bitfields"

Should the immediately following expression:

0:n, 1:n, 2:n, 3:n, ... (n-1):n"

not be:

0:n, 1:n, 2:n, 3:n, ... (2**n -1):n

Similarly, for the statement:

"If the number of bare irstreams in the bitspec is 2 to the power n then these correspond, in their order of occurrence in the bitspec, to the bit sequences given by the bitfields

Should the immediately following expression:

0:n, 1:n, 2:n, 3:n, ... (n-1):n."

not be:

0:n, 1:n, 2:n, 3:n, ... (2**n-1):n."

Many thanks; Blade_Runner_2015
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3175
Location: Cambridge, UK

PostPosted: Tue Feb 16, 2010 7:11 am    Post subject: Reply with quote

Blade Runner, you are of course right on all your new points, too. But on the issue of non-integers in durations, I deliberately chose to regard the few examples of that as abuses of notation. There is no valid reason to use decimal points in durations, since in UEI protocols all durations are integer-valued (expressed in units of 2 microseconds). Frequencies are a different matter, since it is not the frequency that is stored in a protocol executor, it is the carrier on-time and off-time and these have to be calculated from the frequency and the duty cycle. Your example can be written equally well as

{38.7k,245}<2,-9|2,-18>(36,-18,F:8,D:4,C:4,2,-168,(36,-9,2,-356)*) C= -(D + F:4 + F:4:4)

just by halving the unit size.

It would cause a lot of difficulty in formalizing the notation if non-integers were allowed in durations. Suppose that X is a calculated value. Then a duration of X would need to allow X to be a non-integer but a bitfield F:X would require it to be an integer. I didn't want to face that when it didn't seem necessary.

I'm still hoping that John Fine will comment on this second draft. After all, he invented the notation and knows what he had in mind. He may have a view on the decimal point question, too.

Again, many thanks for the comments. In your thorough study, did you delve into the logic of the execution processes? It would be very nice to have an independent view of whether they stand up to scrutiny.
_________________
Graham
Back to top
View user's profile Send private message
Blade_Runner_2015



Joined: 05 Feb 2010
Posts: 6

PostPosted: Tue Feb 16, 2010 9:21 am    Post subject: Reply with quote

Yes, I agree with you completely Graham: non-integer durations expressed with decimal points would appear to introduce a needless complication into the protocol and your example illustrates very well how they may be avoided (except perhaps for cases where no common denominator may be found such as in the Akai protocol example below: some slight numerical approximation would appear to be necessary for such cases). I only wonder why the IRP notation definition for G.I. cable and others were specified using large unit numbers and fractional durations when a fully integer specification could have been used instead.
Another case involving unnecessary decimal points would be fractional absolute time durations in units of mS as shown in several protocol examples below from the same document at http://www.hifi-remote.com/johnsfine/DecodeIr.html . Of course these could instead be expressed in integer form if uS units were used instead of mS.

Akai
UEI protocol: 000D
IRP notation: {38k,289}<1,-2.6|1,-6.3>(D:3,F:7,1,^25.3m)+

Archer
IRP notation: {0k,12}<1,-3.3m|1,-4.7m>(F:5,1,-9.7m)+

Jerrold
UEI protocol: 0006
IRP notation: {0k,44}<1,-7.5m|1,-11.5m>(F:5,1,-23.5m)+
This is not a robust protocol, so spurious decodes are likely.

Matsui
IRP notation: {38K,525}<1,-1|1,-3>(D:3,F:7,1,^30.5m)+

~~~~~~~~~~~~~~~~~~~~~~~~~~~

I have gone through the execution process descriptions in section 1 and examples of section 7 and these all seem very logical and correct. I still have to study the execution model logic of chapter 14 and I expect this will take some time for me to absorb thoroughly but I will get back to you on this.

To split another hair, "If the number of bits in the bit sequence is not a multiple of n then it is a semantic error." Would this not rather be a syntactical error? (... you say semantics, and I say syntactics ...)

John McGinn (Blade_Runner_2015)
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3175
Location: Cambridge, UK

PostPosted: Tue Feb 16, 2010 9:51 am    Post subject: Reply with quote

If I understand you correctly, you don't think lead-outs such as -23.5m should be allowed. That should be -23500u. I agree, I consider that another abuse of notation and the syntax in the spec doesn't allow it. I doubt very much if a lead-out need be given to three significant figures in any case.
Quote:
I only wonder why the IRP notation definition for G.I. cable and others were specified using large unit numbers and fractional durations when a fully integer specification could have been used instead.

Exactly! Perhaps John Fine will comment on this in due course.
Quote:
I still have to study the execution model logic of chapter 14 and I expect this will take some time for me to absorb thoroughly but I will get back to you on this.

I really look forward to that. It makes it all worth while if even one person considers it worth taking the trouble to do this.
Quote:
To split another hair, "If the number of bits in the bit sequence is not a multiple of n then it is a semantic error." Would this not rather be a syntactical error? (... you say semantics, and I say syntactics ...)

Ah, at last something to disagree on! Each bitfield may be syntactically correct but may, overall, generate a bit sequence with an invalid number of bits. The number of bits in the bit sequence may even depend on the data, e.g. F:N. There is an example in the Zenith protocol where N=D. In such a case the error cannot be found until run time. I think this makes such errors be ones of semantics, not syntax. Smile

BTW Did you know that the latest version of DecodeIR.html is included in the package for DecodeIR.dll? I am currently maintaining DecodeIR.dll and I update DecodeIR.html whenever I add a new protocol to it.
________________
Graham
Back to top
View user's profile Send private message
Blade_Runner_2015



Joined: 05 Feb 2010
Posts: 6

PostPosted: Tue Feb 16, 2010 7:36 pm    Post subject: Reply with quote

Hello again Graham - some more trivial typo feedback:

o "possibly proceded by other bitspecs" - preceded?
o perfomed

other suggestions:

"beyond the pointer position" (two occurrences) - suggest using "above" instead of "beyond" for clarity

for DELETE FROM, an <item>"is deleted" from the stack which might be construed as inconsistent with the PULL operation. Suggest changing to REMOVE FROM or WITHDRAW FROM and "is removed" or "is withdrawn" from the stack.

question:
I don't see how upon return from EVALUATE name a reliable and/or persistent return value will be available to the calling routine in the case that name is unbound. Wouldn't the calling routine will just PULL a value from the stack for the return parameter? I can see that if EVALUATE name had its own private parameter stack then each successive or even recursive call of unbound EVALUATE name would result in the calling routine PULLing a successively lower pre-existing stack value however would the calling routine not just use a position on the parameter data stack to retrieve a result for "value" whose position could be anywhere and contain anything as a result of prior execution of other function calls which use the same parameter stack? I think I'm missing something here.

I need to understand this before I continue on to 14.4

- John M.
Back to top
View user's profile Send private message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

PostPosted: Tue Feb 16, 2010 9:08 pm    Post subject: Reply with quote

I don't really understand why a lead out of 9.7m or even a gap of 4.5 (times the defined unit) should be a problem.

But I don't feel strongly about it. You seem to feel strongly that they shouldn't be allowed.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3175
Location: Cambridge, UK

PostPosted: Wed Feb 17, 2010 7:23 am    Post subject: Reply with quote

For John F: It isn't the simple forms like a lead-out of 9.7m or a gap of 4.5 that worries me, it is making a consistent specification when expressions are used. In a lead-out of -Lm, L can be fractional. In a bitfield of F:4 or F:N neither F nor N can be fractional.

Perhaps the answer is to allow all values (numeric and results of expressions) to be fractional and to convert them to integers when they occur in bitfields. But I would want the conversion to be "floor" rather than "round" to preserve the meaning of integer division, e.g. since 39/10 = 3 in integer division, the two-step process of real-number division (to give 3.9) followed by conversion to integer must still give 3, so 3.9 converts to 3 rather than 4. It also means that F:4.5 is valid, and means the same as F:4.

Would you be happy with that way of working? And have you had (or will you have) time to read and comment on the second draft?

For John M: If I understand your problem, what you are missing is that conceptually all names are always bound. Of course, in a real implementation that cannot be the case, but it should be handled as follows. If a name unbound in the implementation is referenced then it is first bound to an arbitrary value (could always be 0, could be a random number, that's not relevant) and then processed with this binding. That's why, when a definition is cleared, I've made the name become re-bound to a value (0, but it would be better to allow it to be implementation-dependent so that with the above way of handling unbound names, it could remain unbound). In an implementation, once a name is bound to a value then it remains so throughout the current session - that implements the persistence of the environment in the execution model.

If I've misunderstood your difficulty, please do say so. Many thanks, too, for the new comments. And what do you think of my suggestion above to John F?
_______________
Graham
Back to top
View user's profile Send private message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

PostPosted: Wed Feb 17, 2010 11:08 am    Post subject: Reply with quote

My first thought was to consider a non integer in A:B:C or A<<B etc. to be an error. But I can see now I wasn't thinking clearly.

Your comments do make me realize that integer division is a little strange in a syntax that allows non integers.

mathdon wrote:
Perhaps the answer is to allow all values (numeric and results of expressions) to be fractional and to convert them to integers when they occur in bitfields.


I haven't thought through all the consequences. But at first look, I like that idea.

Quote:
But I would want the conversion to be "floor" rather than "round"


Definitely.

Quote:
have you had (or will you have) time to read and comment on the second draft?


Barely more than a glance and I don't expect to have real study time any time soon and I wouldn't have looked carefully enough anyway to spot all the details John M. spotted. So I'll have to trust you two.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Blade_Runner_2015



Joined: 05 Feb 2010
Posts: 6

PostPosted: Thu Feb 18, 2010 10:54 am    Post subject: Reply with quote

I still have some difficulty understanding the key binding and persistence concepts as well as the implementation but wonder what you think of the following:
  • First, a new structure consisting of two elements: one item to hold a data value and another item for a pointer.
  • Construct a uni-directional circular linked list of variable length out of static memory comprised of elements of this structure type by initializing the pointer variable of each structured element to point to the next structured element in the chain.
  • Create another pointer variable for the entire circular list which initially points to any one (random) structured element of the circular list.
On a conceptual key press, value would be retrieved from the data field of the currently pointed-to element of the chain. The pointer value of the structure would also be retrieved and used to update the circular list pointer. In this way, the next time the circular list was referenced, the next item in the chain would be accessed.

If there were just two elements in the chain (each pointer points to the other), this would emulate toggle behaviour.

If there was just one element in the chain (pointer points to itself), this would emulate a bound key assignment.

Three or more elements would emulate a circular list of selections.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3175
Location: Cambridge, UK

PostPosted: Fri Feb 19, 2010 4:25 am    Post subject: Reply with quote

Here's a bit more explanation, as your proposal seems unnecessarily complicated to me. In the URC-7781, the remote I know most about, there is a 5-bit counter that is never accessed or set directly by the user. It is initialized to 0 when the remote is reset and incremented whenever a protocol sends a signal. It survives the remote going to sleep, it is only ever reset when there is a full reset of the remote. That value is available to protocols if they wish to use it. A bit that toggles between successive signals is implemented simply by taking the lowest of these 5 bits, but there are protocols that reference more bits of this value.

It is that counter that I was trying to emulate. Perhaps saying that every name is always bound is overkill when all I really want is one such name, but the concept of persistence doesn't seem difficult to me since it is exactly what happens in the real remote.

Does this help?
_______________
Graham
Back to top
View user's profile Send private message
hengin



Joined: 22 Mar 2012
Posts: 3

PostPosted: Mon Mar 26, 2012 2:13 am    Post subject: Reply with quote

I've just spent a day looking at the IRP specification and have a few questions.

1. Is there a license attached to the IRP specification? May I use IRP in a commercial product?

2. From the specification I can not find when to multiply with the time unit item of the GeneralSpec to get the duration.
RC6: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,0:3,<-2,2|2,-2>(T:1),D:8,F:8,^107m)+

1,-1,2 and -2 is of cource multiplied with 444.

but in XMP: {38k,136,msb}<210,-760>(<0:1|0:1,-1|0:1,-2|0:1,-3|0:.....

210 and -760 is NOT multiplied with 136. How come? Is it because 210 and 760 is already greater than the unit item, 136? Can't find this in the specification.

3. I can not find a IRP notation for B&O. Is it possible to make one with the current specification? I'm missing expressions to expand a binary value to include "same as last bit" information. b01110101-> b0001101000010001 ("111" -> "122", where meaning of "2" is "same as last bit").

4. The natural language formulation is great in chapter 14. But is there any source code available , in c or whatever to start with?
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 930

PostPosted: Mon Mar 26, 2012 1:44 pm    Post subject: Reply with quote

Hi hengin,

1. I am probably not the person entitled to give an authoritative answer, but I'l try: A notation, like a mathematical statement, does not hold a copyright, unlike a literary work or a piece of software.

2. A "Duration" either carries a suffix (u, m, or p), otherwise these are multiples of the base time. This is clearly described in the specification. You must have either misunderstood something, or got an erroneous example -- there are very many errors in DecodeIR.html as well as in the comments in the source code of DecodeIR.

3b. I cannot make sense of the last sentence. "The last bit" of a number x (assuming MSB) is x%2, which is expressable within IRP.

4. My appreciation of Chapter 14 is ... different from yours. I implemented a (for all practical definitions complete) IRP rendering library in Java, described in this thread, see also this more computer-illiterate-friendly version. Licensed under GPL3.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4  Next
Page 2 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central