Submitted by discordantus (Sat Jan 17 06:01:49 UTC 2004)
values = [ 1+1i, 2+2i, 3+3i, 4+4i ]
rather than this: values = [ Complex.new(1,1), Complex.new(2,2), Complex.new(3,3), Complex.new(4,4) ]
There is some precedent for this style of notation, in C and Java, the 'f' suffix is built into the language for specifying floats. In Python, the 'j' suffix specifies an imaginary number.
This change would not break any features, and it would make the language more attractive for people working with complex numbers.
def ieval(code) require 'complex' eval code.gsub(/[^\d]\d*\.?\d+i/){|m|"#{m[0..0]}Complex.new(0,#{m[1..-2]})"} end puts ieval("(2+3i)*(5-7i)")
Comments | Current voting | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
RCRchive copyright © David Alan Black, 2003-2005.
Powered by .
I realize now that I failed to mention treatment of variables (and methods, for that matter) in this RCR, and perhaps that made the proposal less clear
Dealing with both variables and methods, it would be unlikely that this notation could be implemented for them without breaking things. However, there would be many times that you would want to construct a complex number in this readable fashion, but using variables with values set at runtime. This could be implemented in both the aforementioned manner:
or, it could be done in this way, without implementing an additional method: Example one would require a new method (of class Numeric?) that converts a real number into an imaginary one, and example two is just built in.I'm not sure about whether it would be logical to call the method #to_c, since it's not simply converting it to a complex number, it's multiplying the value by 'i', that is, converting it to an imaginary number. Then again, I think #to_i (to imaginary) is already taken by something else... :) - marc
[quote]Example one would require a new method (of class Numeric?) that converts a real number into an imaginary one, and example two is just built in.[/quote]
example 1 is present already in ruby:
-- iepiep