RomRaider

Who else are you gonna ask?

Ghost busters? :-)

Thinking about the conversions situation. Given that the whole thing is in a single XML file, it should be possible to scan that file for all of them and intelligently convert them across. So maybe it is feasible to have a change in direction there. If I write something to scan across it and check for certain formatting of the expressions, and convert it into a discrete set of steps that can be reversed, would you be OK with accepting that change? If there are any oddballs such a scan will find them and we can then discuss what to do about that. From what I've seen, though, all of them fit the standard scale/offset pair. The example you gave fits that, but would be cleaner if we had a more extensible operations list.

Perhaps an ordered set like this:



Then toECU is implicit and just the reverse process.

Fred.

How do you define the order of operations?

As read in would be my choice if the XML lib being used allows it.

So an XML representation of RPN?
Why not just RPN then?

What's "RPN" ? The definitions are already a huge XML file, right? That's what I meant. You lost me. Care to explain?

http://en.wikipedia.org/wiki/Reverse_Polish_notation

Yes the files a huge and your notation will not help them become smaller.

No, it well help them become cleaner, clearer, more exact and precise and clean up the code that should never have existed to check two conversions when there should have only ever been one. Breaking them down into a dir structure (which could be done first) will make it/them smaller.

It's been years since I used "RPN" and I've never seen it written as an acronym :-p I don't see the relevance or humour, but I'm hoping it was the latter :-)

If I'm being dry, forgive me, but:


reads like normal math to me! :-p

Fred.

Some people are shy and/or don't understand the value of a "+1" style post.

A)

"I am all for sensible notations, <snip>"
....
"I have nothing meaningful to add to it, but I support your opinion"

B)

"I like the scaling setup"
"I was thinking simple gradient/offset for each, but this accomplishes the same, with more options"

Me:

"i'd prefer the simple scale/offset, BUT, the subaru ecu guys clearly weren't thinking the same thing :-)"
"imagine my surprise when i got 2.8444444444 when i tried to "fix" the other number"
"it was obvious it had to be a fraction though"
"and 90 is no coincidence either, being a timing"

--------------------

How many of them are three way calculations? like your 256, 90, 20 one? Are there any sine() sqrt() ^2, etc? or all simple mult/div/add/sub?

Simpler is better, but I feel as though the Subaru engineer logic should be exposed with all three numbers, not just 2.84444444 and 20.

Time to go and buy a transformer :-)

Fred.

That is completely unclear when you defined this:

Your definition has no groupings

Why not leave the current conversion alone and just write out the discrete values to use?
x * (90 / 256 ) - 20
Much shorter and simpler to understand than your proposal. What am I missing?

Here are a few other ECU conversions to consider:
"x*.00229800533137237"
"(x*.591715976)-75.29411712"
"(x*.0001220703125)*14.7"
"x*.004577637"
"(x-32768)*.001333224"
"x*(-.001333224)"
"(x*1.8)+32"
"x*.004"
"96560.6/x"
Look at this link, at the scalings for reference.

In addition, the Logger uses the same library to define conversion formulas but some are much more complex.
Recent example:
(P12/(([P7:kPa]*1000)/(287.05*([P11:C]+273.15))*1000))/(149.9*P8/3456*0.0283/60)*100
The P# items are other logged parameters in this case, think recursive.

I disagree, it's ordered.


AFAIK, you can only do one mathematical operation at a time.


Because it's not reversible and requires defining the same relationship twice, once forward, once backward. This is dirty.


That it's not reversible and thus prone to human error. It also means there is more code than necessary to handle the fact that some human screwed up.

Perhaps I'm missing something. Can the lib, in the process of processing an expression, provide an inverted copy back to you to store in memory? If so, just delete 50% of the entries and you meet my requirement :-)


All of them except this one are standard: "96560.6/x" what is this variable? It could still be handled easily, though.


I'll take a look later. Just got home and haven't had lunch, nearly 6pm.


Of course, having derivative expressions in a logger is pretty normal. PW vs RPM = duty, etc. It's not about ditching the lib, though I may have mistakenly said that earlier in the thread?

Fred.

Ah, right that's who we got started with this discussion.

That would be really nice if it did, but I don't know if it does.

I used SnakeYAML today for the first time. Very easy and natural. I look forward to using it much more in future :-)