Writing a module declaration like, e.g. 'module graphics.3d.mesh;' crashes dmd 0.51 after displaying this error message:

position.d(5): ';' expected
position.d(5): no identifier for declarator

with this crash info (FWIW):

DMD caused an invalid page fault in
module DMD.EXE at 0177:004040c5.
Registers:
EAX=0070b038 CS=0177 EIP=004040c5 EFLGS=00010216
EBX=ccccd000 SS=017f ESP=006efd04 EBP=00000472
ECX=00850604 DS=017f ESI=0070b044 FS=3f8f
EDX=00000000 ES=017f EDI=0070b038 GS=3f7e
Bytes at CS:EIP:
8b 13 56 89 d9 ff 52 14 50 e8 fd d4 07 00 83 c4
Stack dump:
0070aa8c 00850604 00850604 00423388 0070b038 00704ef4 0070b038 00000000
00000000 00704f1c bff713e2 00000177 bff712c5 00003e83 c1758400 bff765d5

Rob

Though crashing is undesired behaviour, "3d" is not a valid identifier.

I quote from D manual, "Lexical":

"Identifiers start with a letter or _, and are followed by any number of letters, _ or digits. Identifiers can be arbitrarilly long, and are case sensitive. Identifiers starting with __ are reserved."

Which is consistent with C behaviour.  Not only C. You wouldn't name a variable "3d", would you? :> And lexing engine is simply the same.

Not a reason enough for a pagefault, nontheless.

-i.

Robert Medeiros wrote:
> Writing a module declaration like, e.g. 'module graphics.3d.mesh;' crashes
> dmd 0.51 after displaying this error message:
> 
> position.d(5): ';' expected
> position.d(5): no identifier for declarator
> 
> with this crash info (FWIW):
> 
> DMD caused an invalid page fault in
> module DMD.EXE at 0177:004040c5.
> Registers:
> EAX=0070b038 CS=0177 EIP=004040c5 EFLGS=00010216
> EBX=ccccd000 SS=017f ESP=006efd04 EBP=00000472
> ECX=00850604 DS=017f ESI=0070b044 FS=3f8f
> EDX=00000000 ES=017f EDI=0070b038 GS=3f7e
> Bytes at CS:EIP:
> 8b 13 56 89 d9 ff 52 14 50 e8 fd d4 07 00 83 c4
> Stack dump:
> 0070aa8c 00850604 00850604 00423388 0070b038 00704ef4 0070b038 00000000
> 00000000 00704f1c bff713e2 00000177 bff712c5 00003e83 c1758400 bff765d5
> 
> Rob
> 
> 

> Though crashing is undesired behaviour, "3d" is not a valid identifier.

Thanks - I wasn't sure at first if this was a bug or a feature (excluding
the crash).

> I quote from D manual, "Lexical":
[snip]
> Which is consistent with C behaviour.  Not only C. You wouldn't name a variable "3d", would you? :> And lexing engine is simply the same.

Somehow package "threed" just doesn't have the same ring... :)

Rob

In the math lexicon, it's called R3.  You could use that.  Except they usually use that funny olde-english style R.  ;)

There's nothing particularly special about 3 dimensions anyway.  And 3D or 2D math and transformations certainly aren't limited in use to just graphics.  So I question the structure of your library.  Do you have a 2D mesh, or a 4D mesh?

Sean

"Robert Medeiros" <robert.medeiros@utoronto.ca> wrote in message news:b17cr4$2qg1$1@digitaldaemon.com...
> > Which is consistent with C behaviour.  Not only C. You wouldn't name a variable "3d", would you? :> And lexing engine is simply the same.
>
> Somehow package "threed" just doesn't have the same ring... :)
>
> Rob

Hi Sean,

> There's nothing particularly special about 3 dimensions anyway.  And 3D or 2D math and transformations certainly aren't limited in use to just graphics.  So I question the structure of your library.  Do you have a 2D mesh, or a 4D mesh?

Actually, I invented that module name for illustration, but it was prompted by an example from the library I'm working on. That's an implementation of the conformal model of geometric algebra, for a research project related to computer vision. Some of the code is generic, i.e. applicable to blades and multivectors of arbitrary dimension (for which I'm trying to apply D templates), but more often that not for my purposes I can get away with hand-crafted code for algebraic entities of fixed dimension (1 -> 5) which can be tweaked for efficiency, hence the 1d, 2d, etc. Your suggestion for using 'rN' notation is a good one that I think I'll adopt. Thanks!

As for the gothic 'R' notation: maybe if we get to the point where we can use UTF-?? for our source files... :)

Rob

"Robert Medeiros" <robert.medeiros@utoronto.ca> wrote in message news:b184a6$srp$1@digitaldaemon.com...
> As for the gothic 'R' notation: maybe if we get to the point where we can use UTF-?? for our source files... :)

You can as of 0.51. But identifiers are still ascii.

> > As for the gothic 'R' notation: maybe if we get to the point where we
can
> > use UTF-?? for our source files... :)
>
> You can as of 0.51. But identifiers are still ascii.

Probably for the best. Otherwise, it would be entertaining for an hour or so to write all my identifiers in, say, Chinese ideographs -- after which it would just be confusing and a maintenance nightmare. But think of the obfuscated coding contests that one could win with a "feature" like that... one could write a veritable program of Babel... :)

Rob

"Robert Medeiros" <robert.medeiros@utoronto.ca> wrote in message news:b184a6$srp$1@digitaldaemon.com...
> Hi Sean,
>
> > There's nothing particularly special about 3 dimensions anyway.  And 3D
or
> > 2D math and transformations certainly aren't limited in use to just graphics.  So I question the structure of your library.  Do you have a
2D
> > mesh, or a 4D mesh?
>
> Actually, I invented that module name for illustration, but it was
prompted
> by an example from the library I'm working on. That's an implementation of the conformal model of geometric algebra, for a research project related
to
> computer vision. Some of the code is generic, i.e. applicable to blades
and
> multivectors of arbitrary dimension (for which I'm trying to apply D templates), but more often that not for my purposes I can get away with hand-crafted code for algebraic entities of fixed dimension (1 -> 5) which can be tweaked for efficiency, hence the 1d, 2d, etc. Your suggestion for using 'rN' notation is a good one that I think I'll adopt. Thanks!

Awesome!  I recently became very interested in geometric algebra and am getting to the point of familiarity with it that I can write a multivector class or write code that prints out all the individual adds and multiplies involved in any arbitrary grade vs. grade product.  I've already made some use of that stuff to optimize my quaternion transforming point function etc.

I think it's a great idea to make a geometric algebra template.  Have a look at Boost::clifford  ( supposed to be at http://jaap.flipcode.com/ga/  but seems down currently )   I would love to see what you come up with or even help out with ideas or implementation.

In my C++ math library I use a graded system like you say, where mixing different ranks together gives certain result types containing only the nonzero portion of the resulting multivector.  Keeping track of which grades are nonempty in a template would add complexity but would make it generate really efficient code and storage.  There would be no real reason to have special classes for points, vectors, and spinors, you could just use multivector for everything.  That sounds ideal, but may require some extensions to the existing template support to make it possible.

Once we have that, we would no longer need the complex type at all;  it would subsume the role of quaternion, complex, and in fact most 3D vector/plane/sphere/ray types wouldn't be necessary.

> As for the gothic 'R' notation: maybe if we get to the point where we can use UTF-?? for our source files... :)

Supposedly DMD 0.51 will read UTF-8 files as input but the lexer doesn't like any characters outside the ascii range and will complain about them. Being able to actually overload the cross product and dot product, paragraph, dagger, left contraction symbols as operators would be fantastic! The little superscript 2 could be Square, of course there's square root symbol, ALL KINDS of good stuff in Unicode for what we need.  And it wouldn't have to be hacks, provided the language supported those things being overloaded.  Even if the precedence defaulted to the highest possible it would still be light-years ahead of C++.

> Rob

What are the plans for extending identifiers to support Unicode?  How far are you willing to go?  ;)

At very least, accented latin characters should be accepted in identifiers. It might be nice if the language ignored the accents (but then again I think case should be ignored too).

I *really* want to be able to use the extra math symbols in Unicode as operators.  I could give you either a short list or a long list of the ones I would want.  Just allowing any Unicode character that is considered a symbol or mathematical operator would be fine too.

The ones that are most direly needed are

dot product (U+22C5 although there are several similar symbols)
cross product  (U+00D7)

The reason we need these is that they're ultra common operations that have higher precedence than multiply, meaning none of the available overloadable operators has the right precedence.

but it'd also be nice to have:

division operator (U+00F7)
set union and intersection
set membership
logical operators (and, or, xor, nor, nand, not)
comparison operators (single symbol support for <=, >=, !=, etc plus "almost
equal" for floats)
single symbol support for <<, >>

And I could go on and on.

Sean

----- Original Message -----
From: "Walter" <walter@digitalmars.com>
Newsgroups: D
Sent: Wednesday, January 29, 2003 10:40 AM
Subject: Re: Bug: Package names cannot start with digit.


>
> "Robert Medeiros" <robert.medeiros@utoronto.ca> wrote in message news:b184a6$srp$1@digitaldaemon.com...
> > As for the gothic 'R' notation: maybe if we get to the point where we
can
> > use UTF-?? for our source files... :)
>
> You can as of 0.51. But identifiers are still ascii.

> Awesome!  I recently became very interested in geometric algebra and am getting to the point of familiarity with it that I can write a multivector class or write code that prints out all the individual adds and multiplies involved in any arbitrary grade vs. grade product.  I've already made some use of that stuff to optimize my quaternion transforming point function
etc.

I'm fairly recent to GA myself, only having discovered it this past summer. It's fascinating stuff, isn't it? If you're like me at all, you probably started reading, got mad that your grade school teachers didn't teach it like that, and then became a True Believer, and started evangelizing to friends, family, and strangers alike... :)

> I think it's a great idea to make a geometric algebra template.  Have a
look
> at Boost::clifford  ( supposed to be at http://jaap.flipcode.com/ga/  but seems down currently )   I would love to see what you come up with or even help out with ideas or implementation.

Thanks for the pointer -- I hadn't seen that page before; if you haven't already visited:

http://carol.wins.uva.nl/~leo/clifford/

you might want to. It's a nice list of GA related resources. I'll be glad to share the code once this project is a bit closer to completion. Actually, I'm porting from a C++ codebase already written, and so some cycles are getting spent just making things D-like, particularly rearranging code to accomodate the notion of modules, sticking once separate unit tests into the corresponding modules, etc. A fair amount of the design-work is done, but if you have any suggestions for a better way to do things, well, I've rewritten "finished" code a time or two before... :)

> In my C++ math library I use a graded system like you say, where mixing different ranks together gives certain result types containing only the nonzero portion of the resulting multivector.  Keeping track of which
grades
> are nonempty in a template would add complexity but would make it generate really efficient code and storage.  There would be no real reason to have special classes for points, vectors, and spinors, you could just use multivector for everything.  That sounds ideal, but may require some extensions to the existing template support to make it possible.

I was trying to avoid general multivector usage in favour of fixed-grade elements for reasons of efficiency (it seemed wasteful to store all those zero coefficients for a scalar, for instance), but I've recently started thinking that maybe that's the wrong way to go about things. Perhaps it's better to focus on making a high-quality, general multivector implementation as you say (particularly if the template tracked the non-zero components as you describe), getting more readable and maintainable code as a result, and letting Moore deal with speed and storage concerns. I need to think about this some more, but IIRC this is the way GABLE is implemented (a MATLAB tutorial package for GA). Perhaps the added complexity of tracking zero coefficients won't even be worth the storage gains, and where speed is a concern it might be interesting to try mapping multivector operations onto matrices to try getting a speed boost out of graphics hardware, at least for Euclidean multivectors we use in graphics, computer vision, etc.

> Once we have that, we would no longer need the complex type at all;  it would subsume the role of quaternion, complex, and in fact most 3D vector/plane/sphere/ray types wouldn't be necessary.

<nod> I think 'complex' is nearing obsolescence. Of course, it won't really go away until someone grows up having learned their maths without it, but we can start by avoiding it ourselves I suppose. The transition might be made easier by replacing complex with an equivalent bivector that behaves almost identically, and leaving the more general multivector mechanism you describe for those interested in the "new math". :) It would certainly be interesting to have it defined as part of D, as the 'complex' type currently is. It might be better though to leave it in Phobos/Deimos so different models of GA can be accomodated without mandating a single standard. It seems that GA software is still maturing; implementations still seem to be chasing a running target as the mathmatics itself is still evolving at a fair clip, relatively speaking.

> Supposedly DMD 0.51 will read UTF-8 files as input but the lexer doesn't like any characters outside the ascii range and will complain about them. Being able to actually overload the cross product and dot product, paragraph, dagger, left contraction symbols as operators would be
fantastic!
> The little superscript 2 could be Square, of course there's square root symbol, ALL KINDS of good stuff in Unicode for what we need.  And it wouldn't have to be hacks, provided the language supported those things being overloaded.  Even if the precedence defaulted to the highest
possible
> it would still be light-years ahead of C++.

I have to admit, I like the thought of being able to overload various mathematical operators, and other symbols. The only difficulty I see is in readability. As things stand, my preference for algebraic notation looks like this (with some personal modifications tacked on):

http://www.cs.toronto.edu/~hehner/UA.pdf

and others are likely to use those same symbols for very different purposes. 'Seems as though we'd need to adopt new symbols into the language with a canonical meaning, in the same way that '+' has a standard meaning, whose function in well-designed software should be deducible from the context.

Rob