This paper describes how the screen size of 3D displays affect the subjective impressions of 3D-visualized content. The key requirement for 3D displays is the presentation of depth cues comprising binocular disparities and/or motion parallax; however, the development of displays and production of content that include these cues leads to an increase in costs. Given the variety of screen sizes, it is expected that 3D characteristics are experienced differently by viewers depending on the screen size. We asked 48 participants to evaluate the 3D experience when using three different-sized stereoscopic displays (11.5, 55, and 200 inches) with head trackers. The participants were asked to score presented stimuli on 20 opposite-term pairs based on the semantic differential method after viewing each of six stimuli. Using factor analysis, we extracted three principal factors: power , related to strong three-dimensionality, real, etc.; visibility , related to stable, natural, etc.; and space , related to agile, open, etc., which had proportions of variances of 0.317, 0.277, and 0.251, respectively; their cumulation was 0.844. We confirmed that the three different-sized displays did not produce the same subjective impressions of the 3D characteristics. In particular, on the small-sized display, we found larger effects on power and space impressions from motion parallax (η 2 = 0.133 and 0.161, respectively) than for the other two sizes. We found degradation of the visibility impressions from binocular disparities, which might be caused by artifacts from stereoscopy. The effects of 3D viewing on subjective impression depends on the display size, and small-sized displays offer the largest benefits by adding 3D characteristics to 2D visualization.

Mailing lists are used for information exchange in specific groups. However, in the recent times, the number of spam mails received has increased, and considerable amount of time is wasted in filtering spam mails. Spam filtering techniques are widely used tool, however, they produce false positive and false negative results. We propose a system to block spam mails in a mailing list. In our system, we assign different posting addresses to different mailing list members. A mailing list member sends a mail to the mail address assigned to him for sending a mail to the mailing list. When a spam mail is received, the address that is the cause of the spam mail is identified and invalidated, and a new address is assigned to the member. Thus, we can block spam mails from the invalidated address. Furthermore, our system is highly compatible with current mail systems because our system does not require any particular software to be installed in the client machines.

ccJava, a new kind of class-based AOP language, provides the weaving-interface mechanism in which the weaving can be realized by the component-and-connector architecture. The interface description constructs in ccJava can be considered a kind of architecture description language that takes into account the weaving. This paper provides a lightweight verification approach using Alloy, a structural modeling language based on relational logic. Using Alloy, we can verify whether the weaving based on the component-and-connector architecture satisfies some kinds of properties--whether advice-types are specified correctly,whether a pointcut selects join points correctly, and so on. By enforcing the architecture verified by Alloy to the class implementation, we can construct a reliable system.

Aspect-oriented programming (AOP) separates crosscutting concerns from primary concerns. These concerns are woven together by a weaver. Although AOP provides an effective module mechanism, it is not necessarily easy for a programmer to understand the overall behavior of a woven program. To deal with this problem, we propose a new kind of information hiding mechanism called a weaving-interface that encapsulates weaving in class-based AOP in which all kinds of concerns are described according to classes. Weaving-interfaces are completely separated from concerns described in terms of classes. A programmer who designs how to compose concerns does not have to know the details of class definitions, but has only to be aware of weaving-interfaces. A programmer who designs each concern does not have to know how the concern is composed, but has only to be aware of weaving-interfaces. Adopting the weaving-interface mechanism, AO weaving can be realized by the component-and-connector software architecture. This weaving-interface mechanism is effective for software modularity, evolution, and reuse