On Fri, 4 Nov 2011 18:01:29 -0000, you wrote:
>> On Fri, 4 Nov 2011 12:01:48 -0000, Paul wrote:
>>
>> >This just shows how bad C is for this particular type of problem.
>>
>> But Paul, it is such a COMMON problem! Trees??? Come on.
>> Who doesn't have to do one, once in a while? With it being so hard
to
>> do in C, folks go to great lengths to avoid them even when that data
>> structure is the natural and correct fit for the problem at hand.
>>
>> I completely understand the early K&R elements as to why the concept
>> wasn't included -- it was being developed for an operating system
port
>> soon to come and this just wasn't on the radar scope then. But it
>> seems inexcusable to me that
>> C89 missed including the concept. It had already been implemented by
>> an existing compiler team, fielded as a product in some use by the
>> time, and it was a good team who knew their business and understood the
>> entire context well.
>
>Perhaps this would have been preferred over the wreck that is the imaginary
>floating point type of C99!
>
>If you're keen for this, the way to make it happen is to push the
national
>body, make an implementation, and try to gain acceptance. Just talking
>about it is not enough to persuade anybody to implement it on your behalf,
>or even adopt it, I'm afraid.
>
>> >In Lisp,
>> >possibly my most favoured language of all time (though Smalltalk comes
>> >close), there is no problem, it is highly elegant. :-) I would say
>> >that the languages I liked most, of the Lisp/Scheme class, are T and
>> Common Lisp.
>>
>> But I would _never_ consider using Lisp in many of my embedded
>> projects. And I'm sure you can do a better job listing out more good
>> reasons why than I could manage.
>
>Yes, but I wasn't commenting on using Lisp as an embedded programming
>language. I'd agree that Lisp in a small embedded system doesn't
work well.
>However, my first exposure to Lisp was on a Commodore PET with a humble 6502
>running the Lisp interpreter in RAM--not fast enough for anything serious,
>but fun to dabble with.
>
>> Thanks. I wasn't aware of it.
>>
>> >C++11 now has lambdas. As lambdas can access free variables (in
>> >Lisp/Church/lambda calculus speak), your count example actually comes
>> >out fairly well using a lambda.
>>
>> Would you care to provide a quality example? I am only vaguely
>> familiar with lambdas, as I haven't yet picked up c# for anything
>> serious yet (I do NOT enjoy being a Windows programmer, though I am
>> still forced to it at times, but I am developing .NET code right now
>> and probably will delve in soon.)
>
>There are loads of C++11 lambda examples which you can find using Google.
>You create a lambda with a capture list, a parameter list, and the body.
>You still need an iterator, but the lambda means that you don't need to
>create a stand-alone function, allocate a static, and so on. I use
>iterators, templates and the like a *lot* in our linker in order to optimize
>and rewrite code, and lambdas would help here. If I used coroutines, my
>code would not be portable. However, C++11 is new, so there's no point
>rewriting existing, working code!
>
>> >Everything in C++ with lambdas is ugly compared to Lisp. Currying is
>> >abysmal in C++.
>>
>> I think I spotted something like currying in f#, when skimming it some
>> months back.
>>
>> >Everybody should be able to speak at least three different classes of
>> >programming language to be rounded as a programmer. You don't need
to
>> >be proficient, but learning another class of programming language
>> >expands your capabilities and allows you to think differently in the
>> >language you practice most.
>>
>> While I don't disagree with the thrust you make, it's not
addressing
>> the point I'm making. I use assembly and C for most of my embedded
>> programming. You know why better than I do. I don't have the option
>> of using Lisp or C++11 or c# or f#. Sorry.
>
>Yes, you do. You can use them whenever you want to program for fun on a PC.
>I'm just comparing high-level features here, not the application to
embedded
>systems. There are so many things about that you can play with if you just
>had the time...
>
>> Those aren't possible, nor
>> will they be. But I do have to deal with the real kinds of problems
>> I've laid out and do so in C. I have in the past and I will in the
>> future.
>
>> The point is that the semantic I laid out is so useful and so simple to
>> maintain and explain and use and so powerful. It doesn't violate for
a
>> fraction of a second any of C's own motivations which are simple and
>> efficient compiler tools. It doesn't break any existing C code. And
it
>> solves very frequently encountered, REAL problems that everyday C
>> programmers encounter. And it does ALL OF THIS in a fashion that would
>> work with the smaller micros around just like C itself does. It breaks
>> nothing at all and isn't even that difficult to modify an existing
>> compiler (so said Pennello when I spoke with him about it -- that was
>> in 1986, or so, so we are NOT talking about the 25 years of later
>> improvements and refinements to linkers and compilers. It was easy
>> then.)
>>
>> You could differentiate your product, Paul, by including syntax for the
>> semantic. ;)
>
>Nobody would use it as it has no industry backing; there is no business
>motivation to do this. It doesn't matter how hard you argue, you're
pushing
>uphill. If you really need it, do what I do, get down and write your own
>tools!
Which is what I do.
But I'm sure you well understand that it is frustrating when
a need so frequently encountered in programming has so
complex an answer, expressed in standard C, and when such a
small change could so beautifully resolve so many of these
with clarity, simplicity, efficiency, and added abstraction.
To me, it is the single most important frontier for C.
I don't just ask, Paul. I do. I've been building this stuff
on my own, in pig-C/assembly, ever since I encountered it in
the mid 1980's with Metaware. But it does wear on me that
something so wonderful remains even today at arm's length for
embedded work. And you must understand that I have to admit
it is not often in my customers' best interests for me to
field my own incarnation. The balancing is that if I don't
do it, the customer pays in code complexity that junior C
programmers have trouble following (sadly, because their
training seems to be poorer these days) but they get standard
C out of it except where assembly is a must, anyway; or else
I do it, but the customer pays in a new paradigm that, while
simpler to read for a junior programmer, remains a fair
mystery to them. They will read it, but be hard pressed to
create more of it.
And talk about traversing SCCs? I despair of the idea in C.
It's a mess if you use standard C -- 100's of lines of code
in bare cases and probably only 1 in a 100 C programmers
could even hope to read it. Yet trivial with this mechanism.
Still, of course, I take your points. You run your business.
I run mine.
Jon
Digression on Iterators
Started by ●October 18, 2011
Reply by ●November 4, 20112011-11-04
Reply by ●June 14, 20122012-06-14
On Fri, 4 Nov 2011 12:01:48 -0000, Paul wrote:
>
>This just shows how bad C is for this particular type of problem. In Lisp,
>possibly my most favoured language of all time (though Smalltalk comes
>close), there is no problem, it is highly elegant. :-) I would say that
>the languages I liked most, of the Lisp/Scheme class, are T and Common Lisp.
>
>http://en.wikipedia.org/wiki/T_(programming_language)
>
>C++11 now has lambdas. As lambdas can access free variables (in
>Lisp/Church/lambda calculus speak), your count example actually comes out
>fairly well using a lambda.
>
>Everything in C++ with lambdas is ugly compared to Lisp.
>
Hi, Paul. Just spend the last half year getting more fully
familiar with C++11 lambdas, and also as implemented in
Microsoft's C#, VB.NET, and F# (still learning F#.)
It had been years since I'd done a commercial quality Windows
package for a customer. But I accepted a project knowing
beforehand that lambdas would likely help a lot and would
drive my need to learn the semantics and syntax. I completed
the project about a month back and delivered it and it has
been working flawlessly (so I am told) through the extensive
testing they've done. In another couple of weeks they expect
to roll it out to their customers. So it's looking good. Not
a single error found from the very first delivery of code,
which still remains unchanged but much more tested now.
I am very much impressed at how well the lambdas worked to
make the project maintainable and easily explained and
documented. I did a complete and thorough code review with
their lead programmer (who had NO experience with them, at
all) and he feels very excited by what he saw and learned.
The difference made was not minor. As I was learning, I
implemented an early version without them and that early DLL
source was nearly three times the size of what I delivered
recently. The use of a few very simple lambdas chopped the
code down and eliminated many classes I'd used earlier.
All this just tells me more why I keep implementing a watered
down version when the language I use lacks them. They are
simply that useful.
I have to say that I do NOT like the C++11 syntax. From what
I read in N1968 (not the accepted approach), I might have
preferred that one. But there is no question in my mind that
the C++11 style is ugly as sin. And why does the programmer
have to do ALL THE INFERENCE WORK for the C++ compiler?
Anyway, I now expect lambdas in embedded compilers "real soon
now." (Other than gcc, which already has them.)
I definitely had a lot of fun, lately, and have grown
re-acquainted with Lisp and Haskell, too. I have to add that
VB.NET's syntax is gnarly. I can't use a "dim x as
action(...) = sub(...) end sub" thing where a parameter is
passed 'byref' without first creating a "typedef" using a
delegate declaration, since "as action" doesn't have the
syntax to express the byref parameter semantic, directly.
That took me a few hours to track down. Pain in the ....
Okay. So where are my lambdas? ;)
Jon
http://faculty.cse.tamu.edu/jarvi/papers/n1968.pdf
>
>This just shows how bad C is for this particular type of problem. In Lisp,
>possibly my most favoured language of all time (though Smalltalk comes
>close), there is no problem, it is highly elegant. :-) I would say that
>the languages I liked most, of the Lisp/Scheme class, are T and Common Lisp.
>
>http://en.wikipedia.org/wiki/T_(programming_language)
>
>C++11 now has lambdas. As lambdas can access free variables (in
>Lisp/Church/lambda calculus speak), your count example actually comes out
>fairly well using a lambda.
>
>Everything in C++ with lambdas is ugly compared to Lisp.
>
Hi, Paul. Just spend the last half year getting more fully
familiar with C++11 lambdas, and also as implemented in
Microsoft's C#, VB.NET, and F# (still learning F#.)
It had been years since I'd done a commercial quality Windows
package for a customer. But I accepted a project knowing
beforehand that lambdas would likely help a lot and would
drive my need to learn the semantics and syntax. I completed
the project about a month back and delivered it and it has
been working flawlessly (so I am told) through the extensive
testing they've done. In another couple of weeks they expect
to roll it out to their customers. So it's looking good. Not
a single error found from the very first delivery of code,
which still remains unchanged but much more tested now.
I am very much impressed at how well the lambdas worked to
make the project maintainable and easily explained and
documented. I did a complete and thorough code review with
their lead programmer (who had NO experience with them, at
all) and he feels very excited by what he saw and learned.
The difference made was not minor. As I was learning, I
implemented an early version without them and that early DLL
source was nearly three times the size of what I delivered
recently. The use of a few very simple lambdas chopped the
code down and eliminated many classes I'd used earlier.
All this just tells me more why I keep implementing a watered
down version when the language I use lacks them. They are
simply that useful.
I have to say that I do NOT like the C++11 syntax. From what
I read in N1968 (not the accepted approach), I might have
preferred that one. But there is no question in my mind that
the C++11 style is ugly as sin. And why does the programmer
have to do ALL THE INFERENCE WORK for the C++ compiler?
Anyway, I now expect lambdas in embedded compilers "real soon
now." (Other than gcc, which already has them.)
I definitely had a lot of fun, lately, and have grown
re-acquainted with Lisp and Haskell, too. I have to add that
VB.NET's syntax is gnarly. I can't use a "dim x as
action(...) = sub(...) end sub" thing where a parameter is
passed 'byref' without first creating a "typedef" using a
delegate declaration, since "as action" doesn't have the
syntax to express the byref parameter semantic, directly.
That took me a few hours to track down. Pain in the ....
Okay. So where are my lambdas? ;)
Jon
http://faculty.cse.tamu.edu/jarvi/papers/n1968.pdf
Reply by ●June 14, 20122012-06-14
Hi Jon,
> I am very much impressed at how well the lambdas worked to make the
> project maintainable and easily explained and documented. I did a complete
> and thorough code review with their lead programmer (who had NO experience
> with them, at all) and he feels very excited by what he saw and learned.
Every programmer should know more than just a single algorithmic programming
language if they care about their craft.
> The difference made was not minor. As I was learning, I implemented an
> early version without them and that early DLL source was nearly three
> times the size of what I delivered recently. The use of a few very simple
> lambdas chopped the code down and eliminated many classes I'd used
> earlier.
I'm sure the classes, and perhaps template functions, were all single-liners
that did some adaptation or ordering for sorting or inserting into a map.
> All this just tells me more why I keep implementing a watered down version
> when the language I use lacks them. They are simply that useful.
Is this record stuck? ;-)
> I have to say that I do NOT like the C++11 syntax. From what I read in
> N1968 (not the accepted approach), I might have preferred that one. But
> there is no question in my mind that the C++11 style is ugly as sin. And
> why does the programmer have to do ALL THE INFERENCE WORK for the C++
> compiler?
...simply because the type matching in C++ is complex. And because the
compiler then knows how to compile the function efficiently when using POD
types. As C is does not offer true dynamic types, you're always going to
have to give up something. With Lisp, which has dynamic types, you gain in
expressiveness but you lose because types need to be checked at runtime and
you don't get type errors at compile or load time. Wings and roundabouts,
having implemented Lisp in the past, along with Prolog and Modula-2 and C
and... Well, you get the picture.
> Anyway, I now expect lambdas in embedded compilers "real soon now." (Other
> than gcc, which already has them.)
Really? :-(
> I definitely had a lot of fun, lately, and have grown re-acquainted with
> Lisp and Haskell, too. I have to add that VB.NET's syntax is gnarly. I
> can't use a "dim x as
> action(...) = sub(...) end sub" thing where a parameter is passed 'byref'
> without first creating a "typedef" using a delegate declaration, since "as
> action" doesn't have the syntax to express the byref parameter semantic,
> directly.
> That took me a few hours to track down. Pain in the ....
>
> Okay. So where are my lambdas? ;)
Stuck in a hyperspace bypass, I hope...
-- Paul.
> I am very much impressed at how well the lambdas worked to make the
> project maintainable and easily explained and documented. I did a complete
> and thorough code review with their lead programmer (who had NO experience
> with them, at all) and he feels very excited by what he saw and learned.
Every programmer should know more than just a single algorithmic programming
language if they care about their craft.
> The difference made was not minor. As I was learning, I implemented an
> early version without them and that early DLL source was nearly three
> times the size of what I delivered recently. The use of a few very simple
> lambdas chopped the code down and eliminated many classes I'd used
> earlier.
I'm sure the classes, and perhaps template functions, were all single-liners
that did some adaptation or ordering for sorting or inserting into a map.
> All this just tells me more why I keep implementing a watered down version
> when the language I use lacks them. They are simply that useful.
Is this record stuck? ;-)
> I have to say that I do NOT like the C++11 syntax. From what I read in
> N1968 (not the accepted approach), I might have preferred that one. But
> there is no question in my mind that the C++11 style is ugly as sin. And
> why does the programmer have to do ALL THE INFERENCE WORK for the C++
> compiler?
...simply because the type matching in C++ is complex. And because the
compiler then knows how to compile the function efficiently when using POD
types. As C is does not offer true dynamic types, you're always going to
have to give up something. With Lisp, which has dynamic types, you gain in
expressiveness but you lose because types need to be checked at runtime and
you don't get type errors at compile or load time. Wings and roundabouts,
having implemented Lisp in the past, along with Prolog and Modula-2 and C
and... Well, you get the picture.
> Anyway, I now expect lambdas in embedded compilers "real soon now." (Other
> than gcc, which already has them.)
Really? :-(
> I definitely had a lot of fun, lately, and have grown re-acquainted with
> Lisp and Haskell, too. I have to add that VB.NET's syntax is gnarly. I
> can't use a "dim x as
> action(...) = sub(...) end sub" thing where a parameter is passed 'byref'
> without first creating a "typedef" using a delegate declaration, since "as
> action" doesn't have the syntax to express the byref parameter semantic,
> directly.
> That took me a few hours to track down. Pain in the ....
>
> Okay. So where are my lambdas? ;)
Stuck in a hyperspace bypass, I hope...
-- Paul.
Reply by ●June 14, 20122012-06-14
On Thu, 14 Jun 2012 09:31:22 +0100, you wrote:
>Hi Jon,
>
>> I am very much impressed at how well the lambdas worked to make the
>> project maintainable and easily explained and documented. I did a complete
>> and thorough code review with their lead programmer (who had NO experience
>> with them, at all) and he feels very excited by what he saw and learned.
>
>Every programmer should know more than just a single algorithmic programming
>language if they care about their craft.
Most aren't exposed. I was exposed 20 years ago and fell in
love with the concept.
>> The difference made was not minor. As I was learning, I implemented an
>> early version without them and that early DLL source was nearly three
>> times the size of what I delivered recently. The use of a few very simple
>> lambdas chopped the code down and eliminated many classes I'd used
>> earlier.
>
>I'm sure the classes, and perhaps template functions, were all single-liners
>that did some adaptation or ordering for sorting or inserting into a map.
A lot of "helper" classes. Basically, wrapping up elevated
data that needed persistence and a member function or two.
All that just dissolved away with unnamed lambdas and a
compiler that can identify the variables needing persistance
across calls.
>> All this just tells me more why I keep implementing a watered down version
>> when the language I use lacks them. They are simply that useful.
>
>Is this record stuck? ;-)
Yes. It will HAUNT YOU until you die! Or give in. ;)
>> I have to say that I do NOT like the C++11 syntax. From what I read in
>> N1968 (not the accepted approach), I might have preferred that one. But
>> there is no question in my mind that the C++11 style is ugly as sin. And
>> why does the programmer have to do ALL THE INFERENCE WORK for the C++
>> compiler?
>
>...simply because the type matching in C++ is complex. And because the
>compiler then knows how to compile the function efficiently when using POD
>types. As C is does not offer true dynamic types, you're always going to
>have to give up something. With Lisp, which has dynamic types, you gain in
>expressiveness but you lose because types need to be checked at runtime and
>you don't get type errors at compile or load time. Wings and roundabouts,
>having implemented Lisp in the past, along with Prolog and Modula-2 and C
>and... Well, you get the picture.
>
>> Anyway, I now expect lambdas in embedded compilers "real soon now." (Other
>> than gcc, which already has them.)
>
>Really? :-(
Well, it seems to be from a "google search" I did before
writing that. Maybe you are telling me I need to go back to
that drawing board, so I will. I thought I saw it in 4.7 or
something. Oh, well. You know more than I do here.
>> I definitely had a lot of fun, lately, and have grown re-acquainted with
>> Lisp and Haskell, too. I have to add that VB.NET's syntax is gnarly. I
>> can't use a "dim x as
>> action(...) = sub(...) end sub" thing where a parameter is passed 'byref'
>> without first creating a "typedef" using a delegate declaration, since "as
>> action" doesn't have the syntax to express the byref parameter semantic,
>> directly.
>> That took me a few hours to track down. Pain in the ....
>>
>> Okay. So where are my lambdas? ;)
>
>Stuck in a hyperspace bypass, I hope...
hehe.
I want my lambdas. Right now. Go make them for me, Paul. :)
What else could possibly be more important in your life than
giving me a life of comfort and bliss(-32)? ;)
Jon
>Hi Jon,
>
>> I am very much impressed at how well the lambdas worked to make the
>> project maintainable and easily explained and documented. I did a complete
>> and thorough code review with their lead programmer (who had NO experience
>> with them, at all) and he feels very excited by what he saw and learned.
>
>Every programmer should know more than just a single algorithmic programming
>language if they care about their craft.
Most aren't exposed. I was exposed 20 years ago and fell in
love with the concept.
>> The difference made was not minor. As I was learning, I implemented an
>> early version without them and that early DLL source was nearly three
>> times the size of what I delivered recently. The use of a few very simple
>> lambdas chopped the code down and eliminated many classes I'd used
>> earlier.
>
>I'm sure the classes, and perhaps template functions, were all single-liners
>that did some adaptation or ordering for sorting or inserting into a map.
A lot of "helper" classes. Basically, wrapping up elevated
data that needed persistence and a member function or two.
All that just dissolved away with unnamed lambdas and a
compiler that can identify the variables needing persistance
across calls.
>> All this just tells me more why I keep implementing a watered down version
>> when the language I use lacks them. They are simply that useful.
>
>Is this record stuck? ;-)
Yes. It will HAUNT YOU until you die! Or give in. ;)
>> I have to say that I do NOT like the C++11 syntax. From what I read in
>> N1968 (not the accepted approach), I might have preferred that one. But
>> there is no question in my mind that the C++11 style is ugly as sin. And
>> why does the programmer have to do ALL THE INFERENCE WORK for the C++
>> compiler?
>
>...simply because the type matching in C++ is complex. And because the
>compiler then knows how to compile the function efficiently when using POD
>types. As C is does not offer true dynamic types, you're always going to
>have to give up something. With Lisp, which has dynamic types, you gain in
>expressiveness but you lose because types need to be checked at runtime and
>you don't get type errors at compile or load time. Wings and roundabouts,
>having implemented Lisp in the past, along with Prolog and Modula-2 and C
>and... Well, you get the picture.
>
>> Anyway, I now expect lambdas in embedded compilers "real soon now." (Other
>> than gcc, which already has them.)
>
>Really? :-(
Well, it seems to be from a "google search" I did before
writing that. Maybe you are telling me I need to go back to
that drawing board, so I will. I thought I saw it in 4.7 or
something. Oh, well. You know more than I do here.
>> I definitely had a lot of fun, lately, and have grown re-acquainted with
>> Lisp and Haskell, too. I have to add that VB.NET's syntax is gnarly. I
>> can't use a "dim x as
>> action(...) = sub(...) end sub" thing where a parameter is passed 'byref'
>> without first creating a "typedef" using a delegate declaration, since "as
>> action" doesn't have the syntax to express the byref parameter semantic,
>> directly.
>> That took me a few hours to track down. Pain in the ....
>>
>> Okay. So where are my lambdas? ;)
>
>Stuck in a hyperspace bypass, I hope...
hehe.
I want my lambdas. Right now. Go make them for me, Paul. :)
What else could possibly be more important in your life than
giving me a life of comfort and bliss(-32)? ;)
Jon
Reply by ●June 14, 20122012-06-14
> I want my lambdas. Right now. Go make them for me, Paul. :) What else
> could possibly be more important in your life than giving me a life of
> comfort and bliss(-32)? ;)
This is more important for me at the moment:
10 ' Graphical demonstration of calibrating a magnetometer.
20 '
30 ' Written by Paul Curtis, Rowley Associates Limited.
40 ' Do with this what you will, just don't claim you wrote it.
50 '
60 ' Use either a SolderCore LCD Shield or a SolderCore
70 ' Arcade Shield.
80 INSTALL "SOLDERCORE-GRAPHICS-SHIELD" AS G
90 '
100 ' Crank SPI speed to 40MHz. If you have more than a
110 ' simple setup, 40MHz might be too fast, so stick with
120 ' the default 20MHz.
130 G.SPEED = 40000000
140 '
150 ' Determine if we've installed an LCD or Arcade.
160 LCD = G.MODEL = "LCD-SHIELD-V1"
170 '
180 ' Use a CoreMPU which has a magnetometer that we wish
190 ' to calibrate.
200 INSTALL "CORE-MPU" AS MPU
210 '
220 ' Use the AHRS to fuse the CoreMPU's 9DOF gyro,
230 ' accelerometer, and magnetometer so we can rotate
240 ' the model once constructed and calibrated.
250 INSTALL "AHRS" USING MPU AS AHRS
260 '
270 ' And a Wii Nunchuk to pan about.
280 INSTALL "NUNCHUK" AS CHUK
290 '
300 ' Nice clean display.
310 CLG
320 '
330 ' Position camera. We use the vector part of the
340 ' quaternion to hold the camera position so it
350 ' integrates nicely with the projection phase.
360 C = QUAT(0, [0, 0, 2.5])
370 '
380 ' Set up initial unrotated view quaternion.
390 Q = QUAT(1, 0, 0, 0)
400 '
410 ' No uncalibrated magnetometer values yet.
420 UNCALIBRATED = []
430 M0 = [0, 0, 0]
440 '
450 ' Display collected values in white.
460 COLOR IFF(LCD, %WHITE, 7)
470 '
480 ' Collect data and display for 10s.
490 WHILE TIMER < 10000
500 '
510 ' Read magnetometer vector; adjust for view.
520 M = MPU.M / 30
530 '
540 ' Only process this reading if magnetometer vector
550 ' differs from the previous reading.
560 IF SUM(M <> M0) <> 0 THEN
570 ' Pause a little between samples.
580 PAUSE 0.05
590 '
600 ' Display acquired position.
610 CALL PROJECT(M(0), M(1), M(2))
620 PLOT PX, PY
630 M0 = M
640 '
650 ' Record uncalibrated point.
660 UNCALIBRATED = UNCALIBRATED & [M]
670 ENDIF
680 WEND
690 '
700 ' Compute hard iron offset into V.
710 CALL HARD_IRON_CALIBRATION(UNCALIBRATED)
720 '
730 ' Apply calibration.
740 CALIBRATED = CLONE UNCALIBRATED
750 FOR I = 0 TO LEN CALIBRATED - 1
760 CALIBRATED(I) = CALIBRATED(I) - V
770 NEXT I
780 '
790 ' Now use AHRS quaternion output to rotate and view.
800 N = 1
810 WHILE CHUK.Z = 0
820 '
830 ' Adjust data on press.
840 IF CHUK.C THEN L = 1 - L : N = 1 : WAIT CHUK.C = 0
850 '
860 ' Use AHRS to deliver new view rotation.
870 Q = AHRS.Q
880 '
890 ' Display either uncalibrated values in red or
900 ' calibrated values in green.
910 CLG
920 CASE L
930 WHEN 0
940 COLOR IFF(LCD, %RED, 1)
950 CALL SHOW(UNCALIBRATED)
960 WHEN 1
970 COLOR IFF(LCD, %GREEN, 2)
980 CALL SHOW(CALIBRATED)
990 ENDCASE
1000 N = 0
1010 ENDIF
1020 WEND
1030 '
1040 END
1050 '
1060 DEFPROC SHOW(U)
1070 ' Project each coordinate in the array onto view.
1090 FOR EACH R IN U
1100 CALL PROJECT(R(0), R(1), R(2))
1110 PLOT PX, PY
1120 NEXT T
1130 ENDPROC
1140 '
1150 DEFPROC PROJECT(AX, AY, AZ)
1160 ' Project 3D point onto view using quaternion rotation.
1170 D = C - Q * QUAT(0, AX, AY, AZ) * CNJ Q
1180 PX = GFX.WIDTH / 2 + (GFX.WIDTH / 2) * D.I / D.K
1190 PY = GFX.HEIGHT / 2 + (GFX.HEIGHT / 2) * D.J / D.K
1200 ENDPROC
1210 '
1220 DEFPROC HARD_IRON_CALIBRATION(BP) USING X, Y, BETA
1230 ' Hard iron calibration, as per discussion in the
1240 ' CoreBASIC manual, just solve a linear system.
1250 Y = SUM TRN(BP ^ 2)
1260 X = TRN(TRN(BP) & [CON(LEN BP)])
1270 MAT BETA = INV(TRN X * X) * TRN X * TRN [Y]
1280 V = BETA(0 TO 2) / 2
1290 V = COL(V, 0)
1300 ENDPROC
Regards,
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Reply by ●June 14, 20122012-06-14
On Thu, 14 Jun 2012 18:23:47 +0100, you wrote:
>> I want my lambdas. Right now. Go make them for me, Paul. :) What else
>> could possibly be more important in your life than giving me a life of
>> comfort and bliss(-32)? ;)
>
>This is more important for me at the moment:
Hehe. I suspect EVERYTHING is more important to you.
Including trimming your nails. ;)
But if I seem to benefit from lambdas so much, I can only
imagine how much YOU would benefit from them. If you can't do
it for me, Paul, do it for your own sanity's sake. I know
it's been taking such a toll on you not having them. Just
think -- you could regain your sanity, again. ;)
Jon
>> I want my lambdas. Right now. Go make them for me, Paul. :) What else
>> could possibly be more important in your life than giving me a life of
>> comfort and bliss(-32)? ;)
>
>This is more important for me at the moment:
Hehe. I suspect EVERYTHING is more important to you.
Including trimming your nails. ;)
But if I seem to benefit from lambdas so much, I can only
imagine how much YOU would benefit from them. If you can't do
it for me, Paul, do it for your own sanity's sake. I know
it's been taking such a toll on you not having them. Just
think -- you could regain your sanity, again. ;)
Jon
Reply by ●June 15, 20122012-06-15
On 14/06/12 18:46, Jon Kirwan wrote:
>
>>> Anyway, I now expect lambdas in embedded compilers "real soon now."
> (Other
>>> than gcc, which already has them.)
>>
>>Really? :-(
>
> Well, it seems to be from a "google search" I did before
> writing that. Maybe you are telling me I need to go back to
> that drawing board, so I will. I thought I saw it in 4.7 or
> something. Oh, well. You know more than I do here.
>
gcc supported C++ lambdas from version 4.5:
For more complete C++11 status:
Of course, just because gcc supports it, does not mean that any specific
port of gcc supports it - sometimes language features are not
implemented for all targets, and if they need library support then that
sometimes needs to be written specifically for the target. So I have no
idea if the msp430 port of gcc supports lambdas. Peter Bigot has been
doing lots of work on getting full 20-bit support in place - I doubt
testing C++11 lambdas is on his things-to-do list. But if you are
interested in using them, then download the latest build, test them out,
and report back to the msp430 gcc mailing list - maybe they'll work, and
I'm sure people would like to know one way or the other.
>
>>> Anyway, I now expect lambdas in embedded compilers "real soon now."
> (Other
>>> than gcc, which already has them.)
>>
>>Really? :-(
>
> Well, it seems to be from a "google search" I did before
> writing that. Maybe you are telling me I need to go back to
> that drawing board, so I will. I thought I saw it in 4.7 or
> something. Oh, well. You know more than I do here.
>
gcc supported C++ lambdas from version 4.5:
For more complete C++11 status:
Of course, just because gcc supports it, does not mean that any specific
port of gcc supports it - sometimes language features are not
implemented for all targets, and if they need library support then that
sometimes needs to be written specifically for the target. So I have no
idea if the msp430 port of gcc supports lambdas. Peter Bigot has been
doing lots of work on getting full 20-bit support in place - I doubt
testing C++11 lambdas is on his things-to-do list. But if you are
interested in using them, then download the latest build, test them out,
and report back to the msp430 gcc mailing list - maybe they'll work, and
I'm sure people would like to know one way or the other.
Reply by ●June 15, 20122012-06-15
On Fri, 15 Jun 2012 09:06:08 +0200, David wrote:
>On 14/06/12 18:46, Jon Kirwan wrote:
>>
>
>>>> Anyway, I now expect lambdas in embedded compilers "real soon now."
>> (Other
>>>> than gcc, which already has them.)
>>>
>>>Really? :-(
>>
>> Well, it seems to be from a "google search" I did before
>> writing that. Maybe you are telling me I need to go back to
>> that drawing board, so I will. I thought I saw it in 4.7 or
>> something. Oh, well. You know more than I do here.
>>gcc supported C++ lambdas from version 4.5:
>
>For more complete C++11 status:
>
>Of course, just because gcc supports it, does not mean that any specific
>port of gcc supports it - sometimes language features are not
>implemented for all targets, and if they need library support then that
>sometimes needs to be written specifically for the target. So I have no
>idea if the msp430 port of gcc supports lambdas. Peter Bigot has been
>doing lots of work on getting full 20-bit support in place - I doubt
>testing C++11 lambdas is on his things-to-do list. But if you are
>interested in using them, then download the latest build, test them out,
>and report back to the msp430 gcc mailing list - maybe they'll work, and
>I'm sure people would like to know one way or the other.
Thanks, David. I thought I'd read that 4.7 had it, as I
mentioned.
Per your web link on the status, I see that delegating
constructors are present, too. But in 4.7. That was a no
brainer. Glad to see that there. It's not entirely clear to
me from the list, but is "noexcept" (as used to prevent
exception propagation) present? Including the use of noexcept
if and only if the operations it uses on template arguments
are noexcept, too?
template
void do_f(vector& v) noexcept(noexcept(f(v.at(0))))
{
for(int i; i v.at(i) = f(v.at(i));
}
(Or something like that. I haven't used the new syntax, so I
may have screwed something up. Hopefully, it gets the
question right, though.)
Jon
>On 14/06/12 18:46, Jon Kirwan wrote:
>>
>
>>>> Anyway, I now expect lambdas in embedded compilers "real soon now."
>> (Other
>>>> than gcc, which already has them.)
>>>
>>>Really? :-(
>>
>> Well, it seems to be from a "google search" I did before
>> writing that. Maybe you are telling me I need to go back to
>> that drawing board, so I will. I thought I saw it in 4.7 or
>> something. Oh, well. You know more than I do here.
>>gcc supported C++ lambdas from version 4.5:
>
>For more complete C++11 status:
>
>Of course, just because gcc supports it, does not mean that any specific
>port of gcc supports it - sometimes language features are not
>implemented for all targets, and if they need library support then that
>sometimes needs to be written specifically for the target. So I have no
>idea if the msp430 port of gcc supports lambdas. Peter Bigot has been
>doing lots of work on getting full 20-bit support in place - I doubt
>testing C++11 lambdas is on his things-to-do list. But if you are
>interested in using them, then download the latest build, test them out,
>and report back to the msp430 gcc mailing list - maybe they'll work, and
>I'm sure people would like to know one way or the other.
Thanks, David. I thought I'd read that 4.7 had it, as I
mentioned.
Per your web link on the status, I see that delegating
constructors are present, too. But in 4.7. That was a no
brainer. Glad to see that there. It's not entirely clear to
me from the list, but is "noexcept" (as used to prevent
exception propagation) present? Including the use of noexcept
if and only if the operations it uses on template arguments
are noexcept, too?
template
void do_f(vector& v) noexcept(noexcept(f(v.at(0))))
{
for(int i; i v.at(i) = f(v.at(i));
}
(Or something like that. I haven't used the new syntax, so I
may have screwed something up. Hopefully, it gets the
question right, though.)
Jon
Reply by ●June 16, 20122012-06-16
On 15/06/12 18:36, Jon Kirwan wrote:
> On Fri, 15 Jun 2012 09:06:08 +0200, David wrote:
>
>> On 14/06/12 18:46, Jon Kirwan wrote:
>>>>>> Anyway, I now expect lambdas in embedded compilers "real soon
>>>>> now."
>>> (Other
>>>>> than gcc, which already has them.)
>>>>
>>>> Really? :-(
>>>
>>> Well, it seems to be from a "google search" I did before writing
>>> that. Maybe you are telling me I need to go back to that drawing
>>> board, so I will. I thought I saw it in 4.7 or something. Oh,
>>> well. You know more than I do here.
>>> gcc supported C++ lambdas from version 4.5:
>>
>>
>>
>> For more complete C++11 status:
>>
>>
>>
>> Of course, just because gcc supports it, does not mean that any
>> specific port of gcc supports it - sometimes language features are
>> not implemented for all targets, and if they need library support
>> then that sometimes needs to be written specifically for the
>> target. So I have no idea if the msp430 port of gcc supports
>> lambdas. Peter Bigot has been doing lots of work on getting full
>> 20-bit support in place - I doubt testing C++11 lambdas is on his
>> things-to-do list. But if you are interested in using them, then
>> download the latest build, test them out, and report back to the
>> msp430 gcc mailing list - maybe they'll work, and I'm sure people
>> would like to know one way or the other.
>
> Thanks, David. I thought I'd read that 4.7 had it, as I mentioned.
>
> Per your web link on the status, I see that delegating constructors
> are present, too. But in 4.7. That was a no brainer. Glad to see that
> there. It's not entirely clear to me from the list, but is "noexcept"
> (as used to prevent exception propagation) present? Including the use
> of noexcept if and only if the operations it uses on template
> arguments are noexcept, too?
>
> template
> void do_f(vector& v) noexcept(noexcept(f(v.at(0))))
> {
> for(int i; i > v.at(i) = f(v.at(i));
> }
>
> (Or something like that. I haven't used the new syntax, so I may have
> screwed something up. Hopefully, it gets the question right,
> though.)
>
> Jon
>
I don't know, I'm afraid. I haven't used C++ very much as yet, and it
has always been with exceptions fully disabled ("-fno-exceptions in
gcc). Exceptions can be useful in some sorts of programming, but I
don't see them as a useful thing in embedded programming - and they can
be /very/ costly, in several different senses.
> On Fri, 15 Jun 2012 09:06:08 +0200, David wrote:
>
>> On 14/06/12 18:46, Jon Kirwan wrote:
>>>>>> Anyway, I now expect lambdas in embedded compilers "real soon
>>>>> now."
>>> (Other
>>>>> than gcc, which already has them.)
>>>>
>>>> Really? :-(
>>>
>>> Well, it seems to be from a "google search" I did before writing
>>> that. Maybe you are telling me I need to go back to that drawing
>>> board, so I will. I thought I saw it in 4.7 or something. Oh,
>>> well. You know more than I do here.
>>> gcc supported C++ lambdas from version 4.5:
>>
>>
>>
>> For more complete C++11 status:
>>
>>
>>
>> Of course, just because gcc supports it, does not mean that any
>> specific port of gcc supports it - sometimes language features are
>> not implemented for all targets, and if they need library support
>> then that sometimes needs to be written specifically for the
>> target. So I have no idea if the msp430 port of gcc supports
>> lambdas. Peter Bigot has been doing lots of work on getting full
>> 20-bit support in place - I doubt testing C++11 lambdas is on his
>> things-to-do list. But if you are interested in using them, then
>> download the latest build, test them out, and report back to the
>> msp430 gcc mailing list - maybe they'll work, and I'm sure people
>> would like to know one way or the other.
>
> Thanks, David. I thought I'd read that 4.7 had it, as I mentioned.
>
> Per your web link on the status, I see that delegating constructors
> are present, too. But in 4.7. That was a no brainer. Glad to see that
> there. It's not entirely clear to me from the list, but is "noexcept"
> (as used to prevent exception propagation) present? Including the use
> of noexcept if and only if the operations it uses on template
> arguments are noexcept, too?
>
> template
> void do_f(vector& v) noexcept(noexcept(f(v.at(0))))
> {
> for(int i; i > v.at(i) = f(v.at(i));
> }
>
> (Or something like that. I haven't used the new syntax, so I may have
> screwed something up. Hopefully, it gets the question right,
> though.)
>
> Jon
>
I don't know, I'm afraid. I haven't used C++ very much as yet, and it
has always been with exceptions fully disabled ("-fno-exceptions in
gcc). Exceptions can be useful in some sorts of programming, but I
don't see them as a useful thing in embedded programming - and they can
be /very/ costly, in several different senses.
Reply by ●June 16, 20122012-06-16
On Sat, 16 Jun 2012 16:07:26 +0200, you wrote:
>
>I don't know, I'm afraid. I haven't used C++ very much as yet, and it
>has always been with exceptions fully disabled ("-fno-exceptions in
>gcc). Exceptions can be useful in some sorts of programming, but I
>don't see them as a useful thing in embedded programming - and they can
>be /very/ costly, in several different senses.
I agree about the disabling of exceptions and exception
handling -- except in some cases. I actually had to add a per
thread, exception handler system (tethered into my operating
system data structures) in one case, as it was the best way
to support the customer's needs for maintainable code in a
rather complex system. It helped a lot. This was in C but it
supported all the usual nested TRY blocks and features most
are used to and it kept completely separated systems for each
thread.
So there is no absolute, bright line in life. Just rules of
thumb. The ability to use noexcept in C++ may actually be a
bit of a boon for embedded use. Though I wouldn't know until
I tested it out and looked at the resulting code.
Jon
>
>I don't know, I'm afraid. I haven't used C++ very much as yet, and it
>has always been with exceptions fully disabled ("-fno-exceptions in
>gcc). Exceptions can be useful in some sorts of programming, but I
>don't see them as a useful thing in embedded programming - and they can
>be /very/ costly, in several different senses.
I agree about the disabling of exceptions and exception
handling -- except in some cases. I actually had to add a per
thread, exception handler system (tethered into my operating
system data structures) in one case, as it was the best way
to support the customer's needs for maintainable code in a
rather complex system. It helped a lot. This was in C but it
supported all the usual nested TRY blocks and features most
are used to and it kept completely separated systems for each
thread.
So there is no absolute, bright line in life. Just rules of
thumb. The ability to use noexcept in C++ may actually be a
bit of a boon for embedded use. Though I wouldn't know until
I tested it out and looked at the resulting code.
Jon
