Dimensions in Croquet space

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Dimensions in Croquet space

Holz, Marc
Dimensions in Croquet space

Hello,

When creating an object in a croquet space e.g. a floor like this here:

 floor := self makeFloor: space fileName: 'lawn.bmp'.
 floor extentX: 300 y: 0 z: 300.

what are the dimensions in the above example ? Meter or feet ?

Best regards,

Marc Holz

Siemens AG
A&D ATS4
D-90475 Nürnberg
Gleiwitzerstrasse 555
Tel ++49 911 895-3578
Fax ++49 911 895-4903
Email: [hidden email]

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Heinrich v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender; Johannes Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus Wucherer
Sitz der Gesellschaft: Berlin und München
Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684
WEEE-Reg.-Nr. DE 23691322


Reply | Threaded
Open this post in threaded view
|

Re: Dimensions in Croquet space

Bert Freudenberg
Croquet doesn't really use units ... but the default eye height is  
1.6 if I remember correctly so meters is what everybody assumes.

- Bert -

On May 14, 2007, at 16:52 , Holz, Marc wrote:

> Hello,
>
> When creating an object in a croquet space e.g. a floor like this  
> here:
>
>  floor := self makeFloor: space fileName: 'lawn.bmp'.
>  floor extentX: 300 y: 0 z: 300.
>
> what are the dimensions in the above example ? Meter or feet ?
>
> Best regards,
>
> Marc Holz
>
> Siemens AG
> A&D ATS4
> D-90475 Nürnberg
> Gleiwitzerstrasse 555
> Tel ++49 911 895-3578
> Fax ++49 911 895-4903
> Email: [hidden email]
>
> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats:  
> Heinrich v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender;  
> Johannes Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes,  
> Jürgen Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J.  
> Sharef, Klaus Wucherer
> Sitz der Gesellschaft: Berlin und München
> Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684
> WEEE-Reg.-Nr. DE 23691322
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Dimensions in Croquet space

David A Smith
In reply to this post by Holz, Marc
Let's assume meters, but note that this makes the avatars quite tall. I
did not choose a size, per se. I wanted the TWindows to be 3x4 units,
and this stuck, so an avatar is just a little over 4 units tall - just a
bit taller than a TWindow. I think meters is the right thing to use,
though - so if someone wants to take the time to fix up the default size
values, that would be nice.

David



Holz, Marc wrote:

>
> Hello,
>
> When creating an object in a croquet space e.g. a floor like this here:
>
>  floor := self makeFloor: space fileName: 'lawn.bmp'.
>  floor extentX: 300 y: 0 z: 300.
>
> what are the dimensions in the above example ? Meter or feet ?
>
> Best regards,
>
> Marc Holz
>
> Siemens AG
> A&D ATS4
> D-90475 Nürnberg
> Gleiwitzerstrasse 555
> Tel ++49 911 895-3578
> Fax ++49 911 895-4903
> Email: [hidden email]
>
> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Heinrich
> v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender; Johannes
> Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen
> Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus
> Wucherer
> Sitz der Gesellschaft: Berlin und München
> Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684
> WEEE-Reg.-Nr. DE 23691322
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [croquet-dev] Re: Dimensions in Croquet space

David P. Reed
You know, I think of the windows as being about 3 cm x 4 cm.   The
avatars are just over 4 cm tall, in my mind.   Why do you think that
avatars are as big as humans?   It never occurred to me that they would
be, since they are so much less capable physically or intellectually.

I "peek into" the Croquet world - I don't live there.

David A Smith wrote:

> Let's assume meters, but note that this makes the avatars quite tall.
> I did not choose a size, per se. I wanted the TWindows to be 3x4
> units, and this stuck, so an avatar is just a little over 4 units tall
> - just a bit taller than a TWindow. I think meters is the right thing
> to use, though - so if someone wants to take the time to fix up the
> default size values, that would be nice.
>
> David
>
>
>
> Holz, Marc wrote:
>>
>> Hello,
>>
>> When creating an object in a croquet space e.g. a floor like this here:
>>
>>  floor := self makeFloor: space fileName: 'lawn.bmp'.
>>  floor extentX: 300 y: 0 z: 300.
>>
>> what are the dimensions in the above example ? Meter or feet ?
>>
>> Best regards,
>>
>> Marc Holz
>>
>> Siemens AG
>> A&D ATS4
>> D-90475 Nürnberg
>> Gleiwitzerstrasse 555
>> Tel ++49 911 895-3578
>> Fax ++49 911 895-4903
>> Email: [hidden email]
>>
>> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Heinrich
>> v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender; Johannes
>> Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen
>> Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef,
>> Klaus Wucherer
>> Sitz der Gesellschaft: Berlin und München
>> Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684
>> WEEE-Reg.-Nr. DE 23691322
>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [croquet-dev] Re: Dimensions in Croquet space

Eugen Leitl
On Mon, May 14, 2007 at 03:14:48PM -0400, David P. Reed wrote:

> I "peek into" the Croquet world - I don't live there.

Most users identify strongly with their avatars, which means
they automatically assume they're ~human sized.

--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
Reply | Threaded
Open this post in threaded view
|

Re: [croquet-dev] Re: Dimensions in Croquet space

Peter Quirk-2
Agreed. On a practical level, people modeling avatars and non-player
characters need to have a spatial scale reference. It becomes really
important when we want model movement, whether the differences between a
tortoise and a hare in covering a distance in a give time, or the way
different creatures walk up a staircase. The scale of the staircase affects
the way they ascend.

Referring to my earlier post where I suggested the space container should
include methods for measuring distance, it seems it should also include a
method to determine its scale, and we might want to think about how to
represent really big (galactic) and really small (molecular) worlds.

-- Peter

----- Original Message -----
From: "Eugen Leitl" <[hidden email]>
To: <[hidden email]>
Sent: Monday, May 14, 2007 4:25 PM
Subject: Re: [croquet-dev] Re: [croquet-user] Dimensions in Croquet space

> On Mon, May 14, 2007 at 03:14:48PM -0400, David P. Reed wrote:
>
>> I "peek into" the Croquet world - I don't live there.
>
> Most users identify strongly with their avatars, which means
> they automatically assume they're ~human sized.
>
> --
> Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
> ______________________________________________________________
> ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
> 8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
>
Reply | Threaded
Open this post in threaded view
|

Re: [croquet-dev] Re: Dimensions in Croquet space

Erik Anderson-9
Making reference to another 3D space, I know that SecondLife has problems with avatars that go over a certain altitude, they become distorted and at some point find that they can no longer move at all, most likely due to their maximum flight velocity being below the roundoff error of the altitude that they are at.

This may not be an issue with absolute scaling unless you are trying to model the orbital path of an ant, but distance from the origin can also pose a problem when dealing with the relatively small scale of an avatar.

On 5/14/07, [hidden email] <[hidden email] > wrote:
Agreed. On a practical level, people modeling avatars and non-player
characters need to have a spatial scale reference. It becomes really
important when we want model movement, whether the differences between a
tortoise and a hare in covering a distance in a give time, or the way
different creatures walk up a staircase. The scale of the staircase affects
the way they ascend.

Referring to my earlier post where I suggested the space container should
include methods for measuring distance, it seems it should also include a
method to determine its scale, and we might want to think about how to
represent really big (galactic) and really small (molecular) worlds.

-- Peter

----- Original Message -----
From: "Eugen Leitl" <[hidden email]>
To: <[hidden email]>
Sent: Monday, May 14, 2007 4:25 PM
Subject: Re: [croquet-dev] Re: [croquet-user] Dimensions in Croquet space

> On Mon, May 14, 2007 at 03:14:48PM -0400, David P. Reed wrote:
>
>> I "peek into" the Croquet world - I don't live there.
>
> Most users identify strongly with their avatars, which means
> they automatically assume they're ~human sized.
>
> --
> Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
> ______________________________________________________________
> ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
> 8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
>

Reply | Threaded
Open this post in threaded view
|

Re: [croquet-dev] Re: Dimensions in Croquet space

Paul Sheldon-2
In reply to this post by Holz, Marc
Erik Anderson wrote something about roundoff error I personally experienced.

I have a little virtual reality on my newton message pad I built
to navigate with gps.

Note : lat lons are an abbreviation for latitude and longitude.

I made coordinate systems : mine associates with each map picture lat lons,
just like a mathematical coordinate system associates with points
coordinates.
I had a standard coordinate 0..1 on each axis and then I had calibration
associate
that with a formula mapping that range to the lat lons.

I have these lat lon lists that draw a route as a zig zag line even if I am
off a map
that has associated

Well, to travel the Unites States, I had to make sure that I had maps
near where I was because if I were too far off a map or scaled up too much
my zig zag lines would disappear as well as the dot where my car was.

I've seen this virtual world manifestation of "the math" and it was
exciting.

Reply | Threaded
Open this post in threaded view
|

Re: [croquet-dev] Re: Dimensions in Croquet space

Les Howell
On Tue, 2007-05-15 at 09:36 -0800, [hidden email] wrote:

> Erik Anderson wrote something about roundoff error I personally experienced.
>
> I have a little virtual reality on my newton message pad I built
> to navigate with gps.
>
> Note : lat lons are an abbreviation for latitude and longitude.
>
> I made coordinate systems : mine associates with each map picture lat lons,
> just like a mathematical coordinate system associates with points
> coordinates.
> I had a standard coordinate 0..1 on each axis and then I had calibration
> associate
> that with a formula mapping that range to the lat lons.
>
> I have these lat lon lists that draw a route as a zig zag line even if I am
> off a map
> that has associated
>
> Well, to travel the Unites States, I had to make sure that I had maps
> near where I was because if I were too far off a map or scaled up too much
> my zig zag lines would disappear as well as the dot where my car was.
>
> I've seen this virtual world manifestation of "the math" and it was
> exciting.
>
Hi, Paul,
    There are other effects as well.  In VR when you scale and rotate,
you multiply the values, occasionally multiple times.  With each pair of
multiplications you effectively lose one bit of accuracy.  Thus a float
which starts with 24 bits is reduced almost immediately to 23, then to
22 with a zoom, and finally to a 21 bit accuracy with a translation by
rotation in 3d space.  This may not seem like much error, but if you are
looking at a building, it has gone from being accurate at say
30.000meters to being off by one centimeter (approximately)  Walls no
longer meet, angles have openings, color fills leak, and joins don't.
Collisions can occur and things just are not pretty.  This gets worse
with distance, reducing shapes, losing texture, and actually changing
appearance.  I took some time a long time ago to create my own 3d
program in C using all doubles.  The difference in perception is
tremendous.  But even 64 bit can produce errors that are "funny".  The
future for 3d is beyond doubles, although I don't think that for general
graphics use to be good for most people, that more than a long double
would be necessary.

    However, people with good visual acuity will find that even long
doubles will require some "willful suspension of disbelief" for VR to be
"real".

    As I have seen these effects, and even run into them when playing
with simulations of things like the 3 object in space issue (gravity,
speed, inertia simulation to achieve orbits), it is apparent that
accuracy and precision are vital to many aspects of VR and simulation
calculation.  This is one reason I cringe when people talk about
simulations of earths environment far into the future.  Small round off
and truncation errors will propogate and like Baron Rothschild said “I
cannot, but I know that the eigth wonder of the world is compound
interest.”  The same can be said of compounding errors of round-oiff and
truncation.  Other problems exist between numeric representations, such
as binary floating point to hexadecimal floating point which yields an
odd error on multiples of something like 39 or 78 if I remember right.

    The limits of course must be determined by the technology and
whatever is chosen as the acceptable level of error.

Regards,
Les H.

Reply | Threaded
Open this post in threaded view
|

Re: [croquet-dev] Re: Dimensions in Croquet space

john_sellers@sellers.com
In reply to this post by David P. Reed
Actually dimensions are a great idea.  If any of you have see MathCad, it has a good implementation of dimensioning. It is really wonderful and enables conversion to be gracefully and effectively handled for just about any situation where dimensions are involved, no matter how complicated.

To explain such a system in its simplest and most crude form, all you have to do is define the unit conversions factors as values TO whatever global system of units you decide for the current standard.  This could be MKS, CGS, or whatever.  You would certainly need a set of length and time constants.  Then depending on how much you want to be able to simulate, the system could possibly also include mass, substance, charge, temperature, and luminosity, giving you a comprehensive method of scaling all kinds of dimensional values simulated in croquet or just used as pure data.

To extend it is simple.  If you decide you need a new measure like bigNose as 3.21 inches, where her hand is 2.3 bigNoses long then:

        bigNose := 3.21 * in.  "inches per bigNose times meters per inch is going to be meters per bigNose."
        herHand := 2.3 * bigNose.  "bigNoses times meters per bigNose is going to be meters"
        DisplayValueInCentimeters := herHand / cm.  "meters divided by meters per centimeter is going to be centimeters"

Another example: if you want to talk about 23 inches per second and convert this to miles per hour, it would look something like this:

     currentVelocity := 23 * inches / sec.
     displayValueInMilesPerHour := currentVelocity / (  mi / hr ). 

This gracefully generalizes to just about any measure.  For example if you want to convert from 111112 cubic feet per day to cubic yards per minute, you could say:

    volumeRate := 111112 * (ft raisedTo: 3) / day.
   displayValueInCubicYardsPerSecond := volumeRate /( (yd raisedTo: 3) / sec ).

Otherwise, as you do your calculations, you don't really have to worry about conversions, because once you incorporate the dimensions into your input quantities, any calculations you do will be internally correct to your MKS , CGS, or whatever system.  It is only upon displaying results you need to convert to apply the correct dimensions in whatever different units you wish to display.

David Gleason wrote:
RE: [croquet-dev] Re: [croquet-user] Dimensions in Croquet space

I'm new to Croquet, but I think the reason it's a great paradigm is that it's intuitive, because it mimics our 3d space-time reality.  Well, real numbers almost always have some kind of units associated with them (unless it's a dimensionless quantity such as a ratio).  e.g. if I order some carpet and say "I need 100 x 200 of tan carpet" they are going to ask "100 x 200 what?, feet? yards? meters?).

And from an API perspective, I think for the long term success of a system, it should be possible to just specify the units, instead of having to go and lookup whatever arbitrary units are being used by every thing you call, which would waste a lot of time, and facilitate bugs.  (e.g. the NASA Mars mission that crashed because the thing that calculated distance to the surface returned feet, and the thing that decided when to inflate the landing system interpreted the return value in meters.)

For things to be simple and intuitive we should be able to say simply "floor extentX: 300 meters y: 0 z: 300 feet." for example.  Is there some uniform support in Croquet for this to happen, i.e. can number objects store what units they are in?  I would be happy to contibute some time to look into this if there is interest.

-David Gleason


-----Original Message-----
From: David P. Reed [[hidden email]]
Sent: Mon 5/14/2007 12:14 PM
To: [hidden email]; David A Smith
Cc: [hidden email]; Holz, Marc
Subject: Re: [croquet-dev] Re: [croquet-user] Dimensions in Croquet space

You know, I think of the windows as being about 3 cm x 4 cm.   The
avatars are just over 4 cm tall, in my mind.   Why do you think that
avatars are as big as humans?   It never occurred to me that they would
be, since they are so much less capable physically or intellectually.

I "peek into" the Croquet world - I don't live there.

David A Smith wrote:
> Let's assume meters, but note that this makes the avatars quite tall.
> I did not choose a size, per se. I wanted the TWindows to be 3x4
> units, and this stuck, so an avatar is just a little over 4 units tall
> - just a bit taller than a TWindow. I think meters is the right thing
> to use, though - so if someone wants to take the time to fix up the
> default size values, that would be nice.
>
> David
>
>
>
> Holz, Marc wrote:
>>
>> Hello,
>>
>> When creating an object in a croquet space e.g. a floor like this here:
>>
>>  floor := self makeFloor: space fileName: 'lawn.bmp'.
>>  floor extentX: 300 y: 0 z: 300.
>>
>> what are the dimensions in the above example ? Meter or feet ?
>>
>> Best regards,
>>
>> Marc Holz
>>
>> Siemens AG
>> A&D ATS4
>> D-90475 Nürnberg
>> Gleiwitzerstrasse 555
>> Tel ++49 911 895-3578
>> Fax ++49 911 895-4903
>> Email: [hidden email]
>>
>> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Heinrich
>> v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender; Johannes
>> Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen
>> Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef,
>> Klaus Wucherer
>> Sitz der Gesellschaft: Berlin und München
>> Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684
>> WEEE-Reg.-Nr. DE 23691322
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Dimensions in Croquet space

Bert Freudenberg
You might want to check out the Units package:

        http://map.squeak.org/package/8664cb28-916b-4e8a-8cd6-b6db73f5024c

- Bert -


On May 30, 2007, at 6:58 , [hidden email] wrote:

> Actually dimensions are a great idea.  If any of you have see  
> MathCad, it has a good implementation of dimensioning. It is really  
> wonderful and enables conversion to be gracefully and effectively  
> handled for just about any situation where dimensions are involved,  
> no matter how complicated.
>
> To explain such a system in its simplest and most crude form, all  
> you have to do is define the unit conversions factors as values TO  
> whatever global system of units you decide for the current  
> standard.  This could be MKS, CGS, or whatever.  You would  
> certainly need a set of length and time constants.  Then depending  
> on how much you want to be able to simulate, the system could  
> possibly also include mass, substance, charge, temperature, and  
> luminosity, giving you a comprehensive method of scaling all kinds  
> of dimensional values simulated in croquet or just used as pure data.
>
> To extend it is simple.  If you decide you need a new measure like  
> bigNose as 3.21 inches, where her hand is 2.3 bigNoses long then:
>
>         bigNose := 3.21 * in.  "inches per bigNose times meters per  
> inch is going to be meters per bigNose."
>         herHand := 2.3 * bigNose.  "bigNoses times meters per  
> bigNose is going to be meters"
>         DisplayValueInCentimeters := herHand / cm.  "meters divided  
> by meters per centimeter is going to be centimeters"
>
> Another example: if you want to talk about 23 inches per second and  
> convert this to miles per hour, it would look something like this:
>
>      currentVelocity := 23 * inches / sec.
>      displayValueInMilesPerHour := currentVelocity / (  mi / hr ).
>
> This gracefully generalizes to just about any measure.  For example  
> if you want to convert from 111112 cubic feet per day to cubic  
> yards per minute, you could say:
>
>     volumeRate := 111112 * (ft raisedTo: 3) / day.
>    displayValueInCubicYardsPerSecond := volumeRate /( (yd raisedTo:  
> 3) / sec ).
>
> Otherwise, as you do your calculations, you don't really have to  
> worry about conversions, because once you incorporate the  
> dimensions into your input quantities, any calculations you do will  
> be internally correct to your MKS , CGS, or whatever system.  It is  
> only upon displaying results you need to convert to apply the  
> correct dimensions in whatever different units you wish to display.
>
> David Gleason wrote:
>> I'm new to Croquet, but I think the reason it's a great paradigm  
>> is that it's intuitive, because it mimics our 3d space-time  
>> reality.  Well, real numbers almost always have some kind of units  
>> associated with them (unless it's a dimensionless quantity such as  
>> a ratio).  e.g. if I order some carpet and say "I need 100 x 200  
>> of tan carpet" they are going to ask "100 x 200 what?, feet?  
>> yards? meters?).
>>
>> And from an API perspective, I think for the long term success of  
>> a system, it should be possible to just specify the units, instead  
>> of having to go and lookup whatever arbitrary units are being used  
>> by every thing you call, which would waste a lot of time, and  
>> facilitate bugs.  (e.g. the NASA Mars mission that crashed because  
>> the thing that calculated distance to the surface returned feet,  
>> and the thing that decided when to inflate the landing system  
>> interpreted the return value in meters.)
>>
>> For things to be simple and intuitive we should be able to say  
>> simply "floor extentX: 300 meters y: 0 z: 300 feet." for example.  
>> Is there some uniform support in Croquet for this to happen, i.e.  
>> can number objects store what units they are in?  I would be happy  
>> to contibute some time to look into this if there is interest.
>>
>> -David Gleason
>>
>>
>> -----Original Message-----
>> From: David P. Reed [mailto:[hidden email]]
>> Sent: Mon 5/14/2007 12:14 PM
>> To: [hidden email]; David A Smith
>> Cc: [hidden email]; Holz, Marc
>> Subject: Re: [croquet-dev] Re: [croquet-user] Dimensions in  
>> Croquet space
>>
>> You know, I think of the windows as being about 3 cm x 4 cm.   The
>> avatars are just over 4 cm tall, in my mind.   Why do you think that
>> avatars are as big as humans?   It never occurred to me that they  
>> would
>> be, since they are so much less capable physically or intellectually.
>>
>> I "peek into" the Croquet world - I don't live there.
>>
>> David A Smith wrote:
>> > Let's assume meters, but note that this makes the avatars quite  
>> tall.
>> > I did not choose a size, per se. I wanted the TWindows to be 3x4
>> > units, and this stuck, so an avatar is just a little over 4  
>> units tall
>> > - just a bit taller than a TWindow. I think meters is the right  
>> thing
>> > to use, though - so if someone wants to take the time to fix up the
>> > default size values, that would be nice.
>> >
>> > David
>> >
>> >
>> >
>> > Holz, Marc wrote:
>> >>
>> >> Hello,
>> >>
>> >> When creating an object in a croquet space e.g. a floor like  
>> this here:
>> >>
>> >>  floor := self makeFloor: space fileName: 'lawn.bmp'.
>> >>  floor extentX: 300 y: 0 z: 300.
>> >>
>> >> what are the dimensions in the above example ? Meter or feet ?
>> >>
>> >> Best regards,
>> >>
>> >> Marc Holz
>> >>
>> >> Siemens AG
>> >> A&D ATS4
>> >> D-90475 Nürnberg
>> >> Gleiwitzerstrasse 555
>> >> Tel ++49 911 895-3578
>> >> Fax ++49 911 895-4903
>> >> Email: [hidden email]
>> >>
>> >> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats:  
>> Heinrich
>> >> v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender; Johannes
>> >> Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen
>> >> Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef,
>> >> Klaus Wucherer
>> >> Sitz der Gesellschaft: Berlin und München
>> >> Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB  
>> 6684
>> >> WEEE-Reg.-Nr. DE 23691322
>> >>
>> >>
>> >
>> >
>>