7
votes

Numéros de mise en œuvre

Je suis assez nouveau à Scala. Je veux écrire plusieurs objets mathématiques (complexe, polynôme, etc.) qui sont fermés sous certaines opérations (+, -, *) d'une manière qu'ils peuvent être utilisés en génériques et que des moules implicites peuvent être utilisées.

Je paraisse avoir résolu le premier bit. xxx

maintenant, comment puis-je écrire test () de sorte que xxx

retourne complexe (7, 1)?

scala generics

0 commentaires

3 Réponses :

2
votes

L'idée principale est que toutes les groupumberadditions ne sont pas compatibles, de sorte que vous semblez vouloir travailler avec une algèbre complexe, je suggérerais de construire une superclasse comprenant Goupunderaddition. Cependant, il n'est pas recommandé de faire une classe de cas (voir avertissements si vous avez un Classe de cas Code> Extension d'une classe de cas code>)

trait GroupUnderAddition[T] {
  def + (t : T) : T
}

class ComplexAlgebra(_re:Double, _im:Double) extends(GroupUnderAddition[ComplexAlgebra]) {
  val re = _re
  val im = _im     
  def + (c : ComplexAlgebra) = new ComplexAlgebra(re + c.re, im + c.im)  
}

case class Real(d : Double) extends ComplexAlgebra(d, 0)

case class Complex(real : Double, imaginary : Double) extends ComplexAlgebra(real,imaginary)

object Test {

  def test(a : ComplexAlgebra, b : ComplexAlgebra) = a + b

  def main(args : Array[String]) {
    println(test(Real(5), Real(2)))
  }
}

2 commentaires

Bien sûr, je pouvais faire cela, mais je veux garder des génériques. Le faire à votre façon, si je voulais appeler test avec deux polynômes, je devrais réécrire le tout.

Oui, mais vous avez 2 problèmes différents, le premier est que vous souhaitez créer le GRANDIC groupuméaddition qui implémenterait la méthode + . D'autre part, vous souhaitez avoir un spécifique (code> Mise en œuvre de 2 types de numéros différents: réel et complexe . Donc, vous avez à un autre tour, c'est pourquoi vous avez pensé à implicite def mais dans votre cas, je n'ai pas trouvé de solution avec cela.


                        
                                            
                            
                                
                                    1
 votes
                                
                            
                            
                                
                                     Le problème est que le  implicite def  code> n'est pas pris en compte pour la conversion des arguments, sauf si vous spécifiez la définition de la méthode à le faire. 
 Par conséquent, si vous avez quelque chose comme  réel (5 ) .foo  code> et  foo  code> est défini uniquement pour complexe, le  implicit  code> fonctionnera pour cela.  p> 
 Si vous avez une méthode comme si vous avez une méthode comme :  def fio (C: complexe) = ...  code> Vous ne pouvez pas l'appeler avec  foo (réel (5))  code> à la place.  P> 
 Si vous Voulez-vous appliquer une conversion implicite, vous devez spécifier votre méthode de sorte que ses arguments puissent être convertis. Pour la méthode ci-dessus  FOO  code>, vous pouvez le faire comme ceci:  p> 
println(test[Complex,Real,Complex](Real(5), Complex(2, 1)))
println(test[Complex,Complex,Real](Complex(2,1), Real(5)))

                                

                                                                    
                                    
                                    
                                        0 commentaires
                                        
                                                                                    
                                    
                                                            
                        
                        
                                            
                            
                                
                                    1
 votes
                                
                            
                            
                                
                                     Le vrai problème ici est que vous faites l'hypothèse (incorrecte) que  test (réel (5), complexe (2, 1))  code> est bien défini de quelque manière que ce soit, étant donné quoi vous avez écrit. Considérez ce qui suit: 
case class Word(s : String) extends GroupUnderAddition[Word] {
  def +(w : Word) = Word(s + w.s)
}

                                

                                                                    
                                    
                                    
                                        1 commentaires
                                        
                                                                                            
                                                    Test (réel (5), complexe (2, 1)) est bien défini, étant donné que j'ai une fonction de réalité implicite => complexe. Je n'essaie pas de faire ce travail pour deux enfants de groupumberaddition.