is there a way to have NaN for Int, Long, Boolean ...?

What's your use-case?

On 14 July 2010 23:59, boris pezzatti <boris.pezzatti@wsl.ch> wrote:

I would like to have something similar to Double.NaN (not available number) also for Int, Long  and Boolean ... but as far as I know it doesn't exist (does somebody know why?).

Does anybody know a solution?

I think the use of Option could be a possibility. What I was asking myself about the use of Option is:

- is there a significant performance drop or bigger memory consumption when using a List[Option[Int]] instead of a List[Int]  (with many values)?
- is there already an implementation of the operators (+,-,*,/,<,>,=) which manage the Option[] inputs?

Boris




--
P Please consider the environment before deciding to print this e-mail.
_________________________________________________________
Boris Pezzatti
Swiss Federal Research Institute WSL
Research unit Ecosystem Boundaries
Team Insubric Ecosystems
via Belsoggiorno 22
CH-6500 Bellinzona
Switzerland

phone direct ++41 91 821 52 32
phone ++41 91 821 52 30
fax ++41 91 821 52 39
boris.pezzatti@wsl.ch
http://www.wsl.ch

--
Kevin Wright

mail/google talk: kev.lee.wright@gmail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Calculating indices from parameters of meteorological stations (like Temperature, rainfall, snowcover 0/1, ...), which can  be missing (measurement failures,...).
Those indices are often based on values of the previous day, so I need be consistent if the result does make sense (a value) or not (NaN). In case of NaN, the index can again be calculated only if the initialization conditions are met again ...

The most simple is probably to handle every input parameter as a Double (even if it is not) and use Double.NaN for missing values ... but I was wondering if a "purer" approach could be applied.

 

On 07/15/2010 01:02 AM, Kevin Wright wrote:

AANLkTiku6Rz33f1ApN1Rpq8-AzwWZN_nRM0AsFge3dcW [at] mail [dot] gmail [dot] com" type="cite">What's your use-case?

On 14 July 2010 23:59, boris pezzatti <boris [dot] pezzatti [at] wsl [dot] ch" rel="nofollow">boris.pezzatti@wsl.ch> wrote:

I would like to have something similar to Double.NaN (not available number) also for Int, Long  and Boolean ... but as far as I know it doesn't exist (does somebody know why?).

Does anybody know a solution?

I think the use of Option could be a possibility. What I was asking myself about the use of Option is:

- is there a significant performance drop or bigger memory consumption when using a List[Option[Int]] instead of a List[Int]  (with many values)?
- is there already an implementation of the operators (+,-,*,/,<,>,=) which manage the Option[] inputs?

Boris




--
P Please consider the environment before deciding to print this e-mail.
_________________________________________________________
Boris Pezzatti
Swiss Federal Research Institute WSL
Research unit Ecosystem Boundaries
Team Insubric Ecosystems
via Belsoggiorno 22
CH-6500 Bellinzona
Switzerland

phone direct ++41 91 821 52 32
phone ++41 91 821 52 30
fax ++41 91 821 52 39
boris [dot] pezzatti [at] wsl [dot] ch" target="_blank" rel="nofollow">boris.pezzatti@wsl.ch
http://www.wsl.ch

What are the valid indices? If they cannot be negative, then why not just use -1 to represent an invalid index. That approach is widely used. For example, if you ask for the index of a character in a String, but it is not found, you get -1. I believe that approach is called "in-band signaling," since -1 is a valid integer.

Yes, I realize that Option is the preferred Scala approach and is type safe. However, I was frustrated when I recently tried to use it. Maybe it was just my own ignorance. I was reading lines of text and converting each line into a  data record defined by a particular class. I figured I'd use Option. However, I found that if the text was invalid, I still needed to return an instance of the data record class at some point. So I eventually had to define a "null" version of each data record type to satisfy the type system -- and then I didn't need Option.

Russ P.


On Wed, Jul 14, 2010 at 4:21 PM, boris pezzatti <boris.pezzatti@wsl.ch> wrote:

Calculating indices from parameters of meteorological stations (like Temperature, rainfall, snowcover 0/1, ...), which can  be missing (measurement failures,...).
Those indices are often based on values of the previous day, so I need be consistent if the result does make sense (a value) or not (NaN). In case of NaN, the index can again be calculated only if the initialization conditions are met again ...

The most simple is probably to handle every input parameter as a Double (even if it is not) and use Double.NaN for missing values ... but I was wondering if a "purer" approach could be applied.

 

On 07/15/2010 01:02 AM, Kevin Wright wrote:

What's your use-case?

On 14 July 2010 23:59, boris pezzatti <boris.pezzatti@wsl.ch> wrote:

I would like to have something similar to Double.NaN (not available number) also for Int, Long  and Boolean ... but as far as I know it doesn't exist (does somebody know why?).

Does anybody know a solution?

I think the use of Option could be a possibility. What I was asking myself about the use of Option is:

- is there a significant performance drop or bigger memory consumption when using a List[Option[Int]] instead of a List[Int]  (with many values)?
- is there already an implementation of the operators (+,-,*,/,<,>,=) which manage the Option[] inputs?

Boris




--
P Please consider the environment before deciding to print this e-mail.
_________________________________________________________
Boris Pezzatti
Swiss Federal Research Institute WSL
Research unit Ecosystem Boundaries
Team Insubric Ecosystems
via Belsoggiorno 22
CH-6500 Bellinzona
Switzerland

phone direct ++41 91 821 52 32
phone ++41 91 821 52 30
fax ++41 91 821 52 39
boris.pezzatti@wsl.ch
http://www.wsl.ch

Russ Paielli wrote:
> What are the valid indices? If they cannot be negative, then why not
> just use -1 to represent an invalid index. That approach is widely
> used. For example, if you ask for the index of a character in a
> String, but it is not found, you get -1. I believe that approach is
> called "in-band signaling," since -1 is a valid integer.
Do not do this.

There's no Int.NaN or Long.NaN.  But let's keep in mind what Double.NaN really is:  just a pattern of bits that is given special meaning when used in the context of calculations involving doubles.  If you want to use Ints instead of Doubles, then choose some arbitrary value (like MIN_VALUE) and call that NaN for your purposes.
W


On Jul 14, 2010, at 9:05 PM, Russ Paielli wrote:

What are the valid indices? If they cannot be negative, then why not just use -1 to represent an invalid index. That approach is widely used. For example, if you ask for the index of a character in a String, but it is not found, you get -1. I believe that approach is called "in-band signaling," since -1 is a valid integer.

Yes, I realize that Option is the preferred Scala approach and is type safe. However, I was frustrated when I recently tried to use it. Maybe it was just my own ignorance. I was reading lines of text and converting each line into a  data record defined by a particular class. I figured I'd use Option. However, I found that if the text was invalid, I still needed to return an instance of the data record class at some point. So I eventually had to define a "null" version of each data record type to satisfy the type system -- and then I didn't need Option.

Russ P.


On Wed, Jul 14, 2010 at 4:21 PM, boris pezzatti <boris.pezzatti@wsl.ch> wrote:

Calculating indices from parameters of meteorological stations (like Temperature, rainfall, snowcover 0/1, ...), which can  be missing (measurement failures,...).
Those indices are often based on values of the previous day, so I need be consistent if the result does make sense (a value) or not (NaN). In case of NaN, the index can again be calculated only if the initialization conditions are met again ...

The most simple is probably to handle every input parameter as a Double (even if it is not) and use Double.NaN for missing values ... but I was wondering if a "purer" approach could be applied.

 

On 07/15/2010 01:02 AM, Kevin Wright wrote:

What's your use-case?

On 14 July 2010 23:59, boris pezzatti <boris.pezzatti@wsl.ch> wrote:

I would like to have something similar to Double.NaN (not available number) also for Int, Long  and Boolean ... but as far as I know it doesn't exist (does somebody know why?).

Does anybody know a solution?

I think the use of Option could be a possibility. What I was asking myself about the use of Option is:

- is there a significant performance drop or bigger memory consumption when using a List[Option[Int]] instead of a List[Int]  (with many values)?
- is there already an implementation of the operators (+,-,*,/,<,>,=) which manage the Option[] inputs?

Boris




--
P Please consider the environment before deciding to print this e-mail.
_________________________________________________________
Boris Pezzatti
Swiss Federal Research Institute WSL
Research unit Ecosystem Boundaries
Team Insubric Ecosystems
via Belsoggiorno 22
CH-6500 Bellinzona
Switzerland

phone direct ++41 91 821 52 32
phone ++41 91 821 52 30
fax ++41 91 821 52 39
boris.pezzatti@wsl.ch
http://www.wsl.ch

On Wed, Jul 14, 2010 at 4:21 PM, boris pezzatti <boris.pezzatti@wsl.ch> wrote:

Calculating indices from parameters of meteorological stations (like Temperature, rainfall, snowcover 0/1, ...), which can  be missing (measurement failures,...).
Those indices are often based on values of the previous day, so I need be consistent if the result does make sense (a value) or not (NaN). In case of NaN, the index can again be calculated only if the initialization conditions are met again ...

The most simple is probably to handle every input parameter as a Double (even if it is not) and use Double.NaN for missing values ... but I was wondering if a "purer" approach could be applied.

The 'standard' approach for science data is to select a missing/invalid data value outside of the valid data range and use that. For example if you're working with Air temp your valid range might be -80 to 60C, you could use a missing value of -9999. Of course, it's recommended that you attach this tidbit of metadata to your data so that it's recorded somewhere. Here's references that might be helpful:
http://ferret.wrc.noaa.gov/noaa_coop/coop_cdf_profile.htmlhttp://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch02s05.html#missing-data http://hdfeos.org/forums/archive/index.php?t-226.html
Cheers--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining@gmail.com

In case of primary type, here's piece of code that I use in my project:

object Null {
 val Byte    = java.lang.Byte      MIN_VALUE   // -128 ~ 127
 val Short   = java.lang.Short     MIN_VALUE   // -32768 ~ 32767
 val Char    = java.lang.Character MIN_VALUE   // 0(\u0000) ~ 65535(\uffff)
 val Int     = java.lang.Integer   MIN_VALUE   // -2,147,483,648 ~ 2,147,483,647
 val Long    = java.lang.Long      MIN_VALUE   // -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807
 val Float   = java.lang.Float     NaN
 val Double  = java.lang.Double    NaN
 val Boolean = false

 def is(v: Byte)    = v == Byte
 def is(v: Short)   = v == Short
 def is(v: Char)    = v == Char
 def is(v: Int)     = v == Int
 def is(v: Long)    = v == Long
 def is(v: Float)   = java.lang.Float. isNaN(v)
 def is(v: Double)  = java.lang.Double.isNaN(v)
 def is(v: Boolean) = v == Boolean

 def not(v: Byte)    = v != Byte
 def not(v: Short)   = v != Short
 def not(v: Char)    = v != Char
 def not(v: Int)     = v != Int
 def not(v: Long)    = v != Long
 def not(v: Float)   = !java.lang.Float. isNaN(v)
 def not(v: Double)  = !java.lang.Double.isNaN(v)
 def not(v: Boolean) = v != Boolean

 def getNullVal[T](implicit m: Manifest[T]): T = {
   val value = m.toString match {
     case "Byte"    => Null.Byte   // -128 ~ 127
     case "Short"   => Null.Short  // -32768 ~ 32767
     case "Char"    => Null.Char   // 0(\u0000) ~ 65535(\uffff)
     case "Int"     => Null.Int    // -2,147,483,648 ~ 2,147,483,647
     case "Long"    => Null.Long   // -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807
     case "Float"   => Null.Float
     case "Double"  => Null.Double
     case "Boolean" => Null.Boolean
     case _ => null
   }
   value.asInstanceOf[T]
 }
}


-Caoyuan
On Thu, Jul 15, 2010 at 10:00 AM, Brian Schlining <bschlining@gmail.com> wrote:
>> On Wed, Jul 14, 2010 at 4:21 PM, boris pezzatti <boris.pezzatti@wsl.ch>
>> wrote:
>>>
>>> Calculating indices from parameters of meteorological stations (like
>>> Temperature, rainfall, snowcover 0/1, ...), which can  be missing
>>> (measurement failures,...).
>>> Those indices are often based on values of the previous day, so I need be
>>> consistent if the result does make sense (a value) or not (NaN). In case of
>>> NaN, the index can again be calculated only if the initialization conditions
>>> are met again ...
>>>
>>> The most simple is probably to handle every input parameter as a Double
>>> (even if it is not) and use Double.NaN for missing values ... but I was
>>> wondering if a "purer" approach could be applied.
>
> The 'standard' approach for science data is to select a missing/invalid data
> value outside of the valid data range and use that. For example if you're
> working with Air temp your valid range might be -80 to 60C, you could use a
> missing value of -9999. Of course, it's recommended that you attach this
> tidbit of metadata to your data so that it's recorded somewhere. Here's
> references that might be helpful:
> http://ferret.wrc.noaa.gov/noaa_coop/coop_cdf_profile.html
> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch02s05.html#missing-data
> http://hdfeos.org/forums/archive/index.php?t-226.html
> Cheers
> --
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> Brian Schlining
> bschlining@gmail.com
>

Thank a lot for your answers.
I'm still evaluating if to use the Option approach or the aproach proposed by Caoyuan, which also seems quite flexible.

Does anybody have an idea of the following (when using Option):

- is there a significant performance drop or bigger memory consumption when using a List[Option[Int]] instead of a List[Int]  (with many values)?

- is there already an implementation of the operators (+,-,*,/,<,>,=) which manage the Option[] inputs for numeric types?
 
e.g. something like  def +(a:Option[Int], b:Option[Int]):Option[Int] =a match{ case Some(x) => b match{case Some(y) => Some(x+y); case _ => None}; case _ => None}
and then implicitely attach this operand to Option[Int]  (if ever possible)

.... this would namely allow substituting Numbers with a corresponding Option[]  and consistently get None if e.g. one of the inputs is None, by simply using   a+b

Regards
boris




On 07/15/2010 06:39 AM, Caoyuan wrote:

AANLkTin7WjO5QQovFxazVdmiLfyfNdzRtz_Iw7DXfPkq [at] mail [dot] gmail [dot] com" type="cite">In case of primary type, here's piece of code that I use in my project:

object Null {
 val Byte    = java.lang.Byte      MIN_VALUE   // -128 ~ 127
 val Short   = java.lang.Short     MIN_VALUE   // -32768 ~ 32767
 val Char    = java.lang.Character MIN_VALUE   // 0(\u0000) ~ 65535(\uffff)
 val Int     = java.lang.Integer   MIN_VALUE   // -2,147,483,648 ~ 2,147,483,647
 val Long    = java.lang.Long      MIN_VALUE   // -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807
 val Float   = java.lang.Float     NaN
 val Double  = java.lang.Double    NaN
 val Boolean = false

 def is(v: Byte)    = v == Byte
 def is(v: Short)   = v == Short
 def is(v: Char)    = v == Char
 def is(v: Int)     = v == Int
 def is(v: Long)    = v == Long
 def is(v: Float)   = java.lang.Float. isNaN(v)
 def is(v: Double)  = java.lang.Double.isNaN(v)
 def is(v: Boolean) = v == Boolean

 def not(v: Byte)    = v != Byte
 def not(v: Short)   = v != Short
 def not(v: Char)    = v != Char
 def not(v: Int)     = v != Int
 def not(v: Long)    = v != Long
 def not(v: Float)   = !java.lang.Float. isNaN(v)
 def not(v: Double)  = !java.lang.Double.isNaN(v)
 def not(v: Boolean) = v != Boolean

 def getNullVal[T](implicit m: Manifest[T]): T = {
   val value = m.toString match {
     case "Byte"    => Null.Byte   // -128 ~ 127
     case "Short"   => Null.Short  // -32768 ~ 32767
     case "Char"    => Null.Char   // 0(\u0000) ~ 65535(\uffff)
     case "Int"     => Null.Int    // -2,147,483,648 ~ 2,147,483,647
     case "Long"    => Null.Long   // -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807
     case "Float"   => Null.Float
     case "Double"  => Null.Double
     case "Boolean" => Null.Boolean
     case _ => null
   }
   value.asInstanceOf[T]
 }
}


-Caoyuan
On Thu, Jul 15, 2010 at 10:00 AM, Brian Schlining <bschlining [at] gmail [dot] com" rel="nofollow">bschlining@gmail.com> wrote:
>> On Wed, Jul 14, 2010 at 4:21 PM, boris pezzatti <boris [dot] pezzatti [at] wsl [dot] ch" rel="nofollow">boris.pezzatti@wsl.ch>
>> wrote:
>>>
>>> Calculating indices from parameters of meteorological stations (like
>>> Temperature, rainfall, snowcover 0/1, ...), which can  be missing
>>> (measurement failures,...).
>>> Those indices are often based on values of the previous day, so I need be
>>> consistent if the result does make sense (a value) or not (NaN). In case of
>>> NaN, the index can again be calculated only if the initialization conditions
>>> are met again ...
>>>
>>> The most simple is probably to handle every input parameter as a Double
>>> (even if it is not) and use Double.NaN for missing values ... but I was
>>> wondering if a "purer" approach could be applied.
>
> The 'standard' approach for science data is to select a missing/invalid data
> value outside of the valid data range and use that. For example if you're
> working with Air temp your valid range might be -80 to 60C, you could use a
> missing value of -9999. Of course, it's recommended that you attach this
> tidbit of metadata to your data so that it's recorded somewhere. Here's
> references that might be helpful:
> http://ferret.wrc.noaa.gov/noaa_coop/coop_cdf_profile.html
> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch02s05.html#missing-data
> http://hdfeos.org/forums/archive/index.php?t-226.html
> Cheers
> --
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> Brian Schlining
> bschlining [at] gmail [dot] com" rel="nofollow">bschlining@gmail.com
>

--
P Please consider the environment before deciding to print this e-mail.
_________________________________________________________
Boris Pezzatti
Swiss Federal Research Institute WSL
Research unit Ecosystem Boundaries
Team Insubric Ecosystems
via Belsoggiorno 22
CH-6500 Bellinzona
Switzerland

phone direct ++41 91 821 52 32
phone ++41 91 821 52 30
fax ++41 91 821 52 39
boris.pezzatti@wsl.ch
http://www.wsl.ch

That sounds like a job for Applicative Functors!

scala> import scalaz._
import scalaz._

scala> import Scalaz._
import Scalaz._

scala> val (a, b, c) = (1.some, 2.some, none[Int])
a: Option[Int] = Some(1)
b: Option[Int] = Some(2)
c: Option[Int] = None

scala> (a |@| b) { _ + _ }
res0: Option[Int] = Some(3)

scala> (a |@| b |@| c) { _ + _ - _ }
res1: Option[Int] = None

You can also use the Option Monad without Scalaz, with for-comprehensions:

scala> for { a <- a; b <- b } yield a + b
res2: Option[Int] = Some(3)

scala> for { a <- a; b <- b; c <- c } yield a + b - c
res3: Option[Int] = None

-jason

On Thu, Jul 15, 2010 at 9:11 AM, boris pezzatti wrote:
> - is there already an implementation of the operators (+,-,*,/,<,>,=) which
> manage the Option[] inputs for numeric types?
>
> e.g. something like  def +(a:Option[Int], b:Option[Int]):Option[Int] =a
> match{ case Some(x) => b match{case Some(y) => Some(x+y); case _ => None};
> case _ => None}
> and then implicitely attach this operand to Option[Int]  (if ever possible)
>
> .... this would namely allow substituting Numbers with a corresponding
> Option[]  and consistently get None if e.g. one of the inputs is None, by
> simply using   a+b

On Thu, Jul 15, 2010 at 09:11:12AM +0200, boris pezzatti wrote:
> - is there already an implementation of the operators (+,-,*,/,<,>,=)
> which manage the Option[] inputs for numeric types?

I did this a while ago. I have no idea where I left it. I might have
emailed it to the list. It's not difficult.

There's something else I've been meaning to try out forever and finally
did just now, and here it is. I wonder how expensive it would be to use
this for real. At worst it's a good "can your language do this" demo.

class Malleable[T: Numeric] {
private val num = implicitly[Numeric[T]]
import num._

def sum(x1: T, x2: T): T = x1 + x2
}

scala> val m = new math.Malleable[Int]
m: scala.math.Malleable[Int] = scala.math.Malleable@549f9afb

scala> m.sum(Int.MaxValue / 2, Int.MaxValue / 2)
res0: Int = 2147483646

scala> m.sum(Int.MaxValue / 2, Int.MaxValue / 2 + 5)
res1: Int = -2147483645

scala> import math.Overflow._
import math.Overflow._

scala> val m = new math.Malleable[Int]
m: scala.math.Malleable[Int] = scala.math.Malleable@621f6c18

scala> m.sum(Int.MaxValue / 2, Int.MaxValue / 2)
res2: Int = 2147483646

scala> m.sum(Int.MaxValue / 2, Int.MaxValue / 2 + 5)
scala.math.Overflow$SafeInt$OverflowException: Whoa man! Those things are TOO BIG! 1073741823 + 1073741828
at scala.math.Overflow$SafeInt$.onError(Numeric.scala:205)
at scala.math.Overflow$SafeInt$$anonfun$plus$1.apply(Numeric.scala:190)

On Thu, Jul 15, 2010 at 12:11 AM, boris pezzatti <boris.pezzatti@wsl.ch> wrote:

Thank a lot for your answers.
I'm still evaluating if to use the Option approach or the aproach proposed by Caoyuan, which also seems quite flexible.

As far as I can tell, the advantage of using Option is that the compiler forces you to check for a valid value. In all the other approaches (including the idea of setting an invalid index to -1, which I suggested), the user/client must know and remember to check for an invalid value. If you forget to check, your program could crash or give bogus results. In some cases, that extra level of safety is important, and in others it isn't. If you are really want to be rigorous, using Option is a good idea. But if the type that you are checking is not a basic numeric type, you may need a "null" instance of the type to satisfy the type system.

Russ P.

Russ Paielli skrev 2010-07-15 09:57:
> As far as I can tell, the advantage of using Option is that the compiler
> forces you to check for a valid value. In all the other approaches
> (including the idea of setting an invalid index to -1, which I
> suggested), the user/client must know and remember to check for an
> invalid value. If you forget to check, your program could crash or give
> bogus results. In some cases, that extra level of safety is important,
> and in others it isn't. If you are really want to be rigorous, using
> Option is a good idea.

Safety is important in all programs. The only excuses for not using
Option is performance and memory use, but then you have to present some
hard evidence to backup your decision.

/Jesper Nordenberg

On Thu, Jul 15, 2010 at 1:28 AM, Jesper Nordenberg <megagurka@yahoo.com> wrote:

Russ Paielli skrev 2010-07-15 09:57:

As far as I can tell, the advantage of using Option is that the compiler
forces you to check for a valid value. In all the other approaches
(including the idea of setting an invalid index to -1, which I
suggested), the user/client must know and remember to check for an
invalid value. If you forget to check, your program could crash or give
bogus results. In some cases, that extra level of safety is important,
and in others it isn't. If you are really want to be rigorous, using
Option is a good idea.

Safety is important in all programs.

No, it isn't. If I'm writing a quick little throwaway script to analyze some data, safety isn't important. It may be desirable, but it isn't important. And I don't need an excuse for not using Option in every possible case that it can be used.

Having said that, I agree that Option is a good feature that should be used often.

Russ P.

--
http://RussP.us

Russ Paielli skrev 2010-07-15 10:37:
> No, it isn't. If I'm writing a quick little throwaway script to analyze
> some data, safety isn't important. It may be desirable, but it isn't
> important.

I don't agree. Even if you run a program only once you want it to run
correctly that time, so you want to make use of as much static type
checking as possible. If you don't care what the result of running your
program is then static type checking would be rather unimportant, but
those programs are few and far between.

/Jesper Nordenberg

in my current project, i use option if a method is allowed to return nothing and it still makes sense. example:
every human has a father. there is no option, the method father always returns a father and never null.
but if the method's name would be firstChild, the result would be Option[Child], because it's possible not to have a child.
if null is returned, i can say with 100% certainty that it is a bug. null is simply not allowed anywhere as a result or parameter of a method. the only exception i allow is Array[Whateever] because Array[Option[Whateever]] feels weird.

and there's another advantage besides safety:
you can skip lots of "if x != null"-checks:
father.firstChild.map(_.friends).flatMap(_.parents)

and you got None or Option[List[Humans]], all thanks to implicit None-checks inside the Option's methods

-------- Original-Nachricht --------

> Datum: Thu, 15 Jul 2010 10:28:41 +0200
> Von: Jesper Nordenberg
> An: scala-user@listes.epfl.ch
> CC: boris pezzatti , public-scala-user-soYaJrOCGFRsFbksJNLsAg@lo.gmane.org
> Betreff: [scala-user] Re: is there a way to have NaN for Int, Long, Boolean ...?

> Russ Paielli skrev 2010-07-15 09:57:
> > As far as I can tell, the advantage of using Option is that the compiler
> > forces you to check for a valid value. In all the other approaches
> > (including the idea of setting an invalid index to -1, which I
> > suggested), the user/client must know and remember to check for an
> > invalid value. If you forget to check, your program could crash or give
> > bogus results. In some cases, that extra level of safety is important,
> > and in others it isn't. If you are really want to be rigorous, using
> > Option is a good idea.
>
> Safety is important in all programs. The only excuses for not using
> Option is performance and memory use, but then you have to present some
> hard evidence to backup your decision.
>
> /Jesper Nordenberg

+10 to tony's comment

- Josh

On Jul 14, 2010, at 9:12 PM, Tony Morris wrote:

>
>
> Russ Paielli wrote:
>> What are the valid indices? If they cannot be negative, then why not
>> just use -1 to represent an invalid index. That approach is widely
>> used. For example, if you ask for the index of a character in a
>> String, but it is not found, you get -1. I believe that approach is
>> called "in-band signaling," since -1 is a valid integer.
> Do not do this.
>

secret codes are evil and make code hard to understand. explicit retun types are good

-------- Original-Nachricht --------
> Datum: Thu, 15 Jul 2010 06:40:49 -0400
> Von: Josh Suereth
> An: Tony Morris
> CC: Russ Paielli , "scala-user@listes.epfl.ch"
> Betreff: Re: [scala-user] is there a way to have NaN for Int, Long, Boolean ...?

> +10 to tony's comment
>
> - Josh
>
> On Jul 14, 2010, at 9:12 PM, Tony Morris wrote:
>
> >
> >
> > Russ Paielli wrote:
> >> What are the valid indices? If they cannot be negative, then why not
> >> just use -1 to represent an invalid index. That approach is widely
> >> used. For example, if you ask for the index of a character in a
> >> String, but it is not found, you get -1. I believe that approach is
> >> called "in-band signaling," since -1 is a valid integer.
> > Do not do this.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >

On Wed, Jul 14, 2010 at 8:12 PM, Tony Morris <tonymorris@gmail.com> wrote:

Russ Paielli wrote:
> What are the valid indices? If they cannot be negative, then why not
> just use -1 to represent an invalid index. That approach is widely
> used. For example, if you ask for the index of a character in a
> String, but it is not found, you get -1. I believe that approach is
> called "in-band signaling," since -1 is a valid integer.
Do not do this.

unless you have to.

Le 15/07/2010 10:37, Russ Paielli a écrit :

AANLkTilzh4bK_F_g3XsJ-A-sLY7fgM5SSznfUplS1h4E [at] mail [dot] gmail [dot] com" type="cite">On Thu, Jul 15, 2010 at 1:28 AM, Jesper Nordenberg <megagurka [at] yahoo [dot] com" rel="nofollow">megagurka@yahoo.com> wrote:

Safety is important in all programs.

No, it isn't. If I'm writing a quick little throwaway script to analyze some data, safety isn't important. It may be desirable, but it isn't important. And I don't need an excuse for not using Option in every possible case that it can be used.

Having said that, I agree that Option is a good feature that should be used often.

I can't help seeing a parallel between writing safe programs and writing correctly. Some people claim that they don't need to write correctly because they're just chatting (or writing SMS). However writing correctly as well as writing safe programs have to become reflexes. So, by default you would write safe programs and only if there is a good reason you would have to force yourself to write unsafe programs.

Sylvain

Since nobody seems to have answered this directly:
On Thu, Jul 15, 2010 at 9:11 AM, boris pezzatti <boris.pezzatti@wsl.ch> wrote:

- is there a significant performance drop or bigger memory consumption when using a List[Option[Int]] instead of a List[Int]  (with many values)?

 How many are many? :-)If you use an Array[Int], you use 4 bytes per element (4 for the 32-bit integer), and writing an element to a cell is an extremely fast operation. If you use a List[Int], you will need 32 bytes per element (16 for the cons, 16 for the boxed integer), and adding an element involves 2 object creations.If you use a List[Option[Int]], you will need 48 bytes per element (16 for the cons, 16 for the Option, 16 for the boxed integer)
This is if you use a 64-bit processor.
When Scala gets a specialized version of Option and List, you will only need 4, 16 and 32 bytes, respectively, per element.Also, I'd recommend using Seq[...] instead of List[...], because then Scala will choose a good sequence implementation for you (List for short sequences, Vector for longer sequences, GenericArray (I think) for extremely long sequences)

So then you do agree.

Safety is important in all programs.

 

 No, it isn't.

 

 those programs are few and far between.

No contradiction!


On Thu, Jul 15, 2010 at 4:50 AM, Jesper Nordenberg <megagurka@yahoo.com> wrote:

Russ Paielli skrev 2010-07-15 10:37:

No, it isn't. If I'm writing a quick little throwaway script to analyze
some data, safety isn't important. It may be desirable, but it isn't
important.

I don't agree. Even if you run a program only once you want it to run correctly that time, so you want to make use of as much static type checking as possible. If you don't care what the result of running your program is then static type checking would be rather unimportant, but those programs are few and far between.

/Jesper Nordenberg

On Wed, Jul 14, 2010 at 9:39 PM, Caoyuan <dcaoyuan@gmail.com> wrote:

In case of primary type, here's piece of code that I use in my project:

object Null {
 val Byte    = java.lang.Byte      MIN_VALUE   // -128 ~ 127
 val Short   = java.lang.Short     MIN_VALUE   // -32768 ~ 32767
 val Char    = java.lang.Character MIN_VALUE   // 0(\u0000) ~ 65535(\uffff)
 val Int     = java.lang.Integer   MIN_VALUE   // -2,147,483,648 ~ 2,147,483,647
 val Long    = java.lang.Long      MIN_VALUE   // -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807
 val Float   = java.lang.Float     NaN
 val Double  = java.lang.Double    NaN
 val Boolean = false

 def is(v: Byte)    = v == Byte
 def is(v: Short)   = v == Short
 def is(v: Char)    = v == Char
 def is(v: Int)     = v == Int
 def is(v: Long)    = v == Long
 def is(v: Float)   = java.lang.Float. isNaN(v)
 def is(v: Double)  = java.lang.Double.isNaN(v)
 def is(v: Boolean) = v == Boolean

 def not(v: Byte)    = v != Byte
 def not(v: Short)   = v != Short
 def not(v: Char)    = v != Char
 def not(v: Int)     = v != Int
 def not(v: Long)    = v != Long
 def not(v: Float)   = !java.lang.Float. isNaN(v)
 def not(v: Double)  = !java.lang.Double.isNaN(v)
 def not(v: Boolean) = v != Boolean

 def getNullVal[T](implicit m: Manifest[T]): T = {
   val value = m.toString match {
     case "Byte"    => Null.Byte   // -128 ~ 127
     case "Short"   => Null.Short  // -32768 ~ 32767
     case "Char"    => Null.Char   // 0(\u0000) ~ 65535(\uffff)
     case "Int"     => Null.Int    // -2,147,483,648 ~ 2,147,483,647
     case "Long"    => Null.Long   // -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807
     case "Float"   => Null.Float
     case "Double"  => Null.Double
     case "Boolean" => Null.Boolean
     case _ => null
   }
   value.asInstanceOf[T]
 }
}

That's quite an elaborate scheme. After thinking about it a little, I realized that "Option" is intended precisely to eliminate the need for this sort of bookeeping. And it works automatically for all types, not just the numeric types addressed by your scheme. As a bonus, it automatically reminds the user of the object to check for validity (by refusing to compile otherwise). All in all, Option is a very nice feature. After getting some clues on another thread about how to use it, I now fully appreciate its usefulness. Hey, what can I say? I'm wiser than I thought I was for choosing Scala!

Russ P.

thanks a lot!
this is useful to me.

Cheers,
boris

On 07/15/2010 10:28 PM, David Flemström wrote:

AANLkTimf2hZlgN7oOy-jOPVBORQFv6PRi-8fX7Q4tTiO [at] mail [dot] gmail [dot] com" type="cite"> Since nobody seems to have answered this directly:
On Thu, Jul 15, 2010 at 9:11 AM, boris pezzatti <boris [dot] pezzatti [at] wsl [dot] ch" rel="nofollow">boris.pezzatti@wsl.ch> wrote:

- is there a significant performance drop or bigger memory consumption when using a List[Option[Int]] instead of a List[Int]  (with many values)?

  How many are many? :-) If you use an Array[Int], you use 4 bytes per element (4 for the 32-bit integer), and writing an element to a cell is an extremely fast operation. If you use a List[Int], you will need 32 bytes per element (16 for the cons, 16 for the boxed integer), and adding an element involves 2 object creations. If you use a List[Option[Int]], you will need 48 bytes per element (16 for the cons, 16 for the Option, 16 for the boxed integer)
This is if you use a 64-bit processor.
When Scala gets a specialized version of Option and List, you will only need 4, 16 and 32 bytes, respectively, per element. Also, I'd recommend using Seq[...] instead of List[...], because then Scala will choose a good sequence implementation for you (List for short sequences, Vector for longer sequences, GenericArray (I think) for extremely long sequences)

--
P Please consider the environment before deciding to print this e-mail.
_________________________________________________________
Boris Pezzatti
Swiss Federal Research Institute WSL
Research unit Ecosystem Boundaries
Team Insubric Ecosystems
via Belsoggiorno 22
CH-6500 Bellinzona
Switzerland

phone direct ++41 91 821 52 32
phone ++41 91 821 52 30
fax ++41 91 821 52 39
boris.pezzatti@wsl.ch
http://www.wsl.ch

IMHO:

null, NaN and None have the semantics of "error", but play in different
leagues.

NaN vs. None:

NaN is an instance of Double or Float and as that behaves like one. We can
use
NaN in any Operation, which always results in NaN. So an error stays an
error,
that's fine!

None does not represent an instance of the class in question. You always
need this
annoying unboxing from Some(x) to get the valid value x vs. no unboxing to
get the
invalid None. Tolerable but not really nice (when I see all the related
discussions!)

So Option is an artificial add-on to operations of any class, not integrated
in a
specific class.

But classes – not only Double and Float – which are not value objects, i.e.
have
meaningful operations, which may fail, should have an "error" object, which
behaves
somehow similar to NaN. Life would be much easier.

And null? Just a kind of unsave None, but may be used as a valid value for
all AnyRef
types, which leads to these infamous exceptions at runtime.

So all in all: Integral numbers also need a NaN, as any class O should have
a NaO!

regards
friedrich

I'm just being curiouse what would you do if you need to turn a
integral part into a string then format this into some other type and
then use the result of that to print it to the user?

val opt = Option[Int] = Some(1)
println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrElse("Nothing
to show"))
Works with val opt = None as well!!!!

Now how would I do this with NaO?

-Stefan

2010/7/16 friedrich :
>
> IMHO:
>
> null, NaN and None  have the semantics of "error", but play in different
> leagues.
>
> NaN vs. None:
>
> NaN is an instance of Double or Float and as that behaves like one. We can
> use
> NaN in any Operation, which always results in NaN. So an error stays an
> error,
> that's fine!
>
> None does not represent an instance of the class in question. You always
> need this
> annoying unboxing from Some(x) to get the valid value x vs. no unboxing to
> get the
> invalid None. Tolerable but not really nice (when I see all the related
> discussions!)
>
> So Option is an artificial add-on to operations of any class, not integrated
> in a
> specific class.
>
> But classes – not only Double and Float – which are not value objects, i.e.
> have
> meaningful operations, which may fail, should have an "error" object, which
> behaves
> somehow similar to NaN. Life would be much easier.
>
> And null? Just a kind of unsave None, but may be used as a valid value for
> all AnyRef
> types, which leads to these infamous exceptions at runtime.
>
> So all in all:  Integral numbers also need a NaN, as any class O should have
> a NaO!
>
> regards
> friedrich
>
>
>
>
>
> --
> View this message in context: http://scala-programming-language.1934581.n4.nabble.com/is-there-a-way-t...
> Sent from the Scala - User mailing list archive at Nabble.com.
>

what about an implicit unboxing of options in predef? that would simplify it

-------- Original-Nachricht --------
> Datum: Fri, 16 Jul 2010 14:27:21 +0200
> Von: Stefan Langer
> An: friedrich
> CC: scala-user@listes.epfl.ch
> Betreff: Re: [scala-user] Re: is there a way to have NaN for Int, Long, Boolean ...?

> I'm just being curiouse what would you do if you need to turn a
> integral part into a string then format this into some other type and
> then use the result of that to print it to the user?
>
> val opt = Option[Int] = Some(1)
> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrElse("Nothing
> to show"))
> Works with val opt = None as well!!!!
>
> Now how would I do this with NaO?
>
> -Stefan
>
> 2010/7/16 friedrich :
> >
> > IMHO:
> >
> > null, NaN and None  have the semantics of "error", but play in
> different
> > leagues.
> >
> > NaN vs. None:
> >
> > NaN is an instance of Double or Float and as that behaves like one. We
> can
> > use
> > NaN in any Operation, which always results in NaN. So an error stays an
> > error,
> > that's fine!
> >
> > None does not represent an instance of the class in question. You always
> > need this
> > annoying unboxing from Some(x) to get the valid value x vs. no unboxing
> to
> > get the
> > invalid None. Tolerable but not really nice (when I see all the related
> > discussions!)
> >
> > So Option is an artificial add-on to operations of any class, not
> integrated
> > in a
> > specific class.
> >
> > But classes – not only Double and Float – which are not value
> objects, i.e.
> > have
> > meaningful operations, which may fail, should have an "error" object,
> which
> > behaves
> > somehow similar to NaN. Life would be much easier.
> >
> > And null? Just a kind of unsave None, but may be used as a valid value
> for
> > all AnyRef
> > types, which leads to these infamous exceptions at runtime.
> >
> > So all in all:  Integral numbers also need a NaN, as any class O should
> have
> > a NaO!
> >
> > regards
> > friedrich
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://scala-programming-language.1934581.n4.nabble.com/is-there-a-way-t...
> > Sent from the Scala - User mailing list archive at Nabble.com.
> >

Oh yes! With a check for None that would throw a NullPointerException

Le 16/07/2010 14:55, Dennis Haupt a écrit :
> what about an implicit unboxing of options in predef? that would simplify it
>
> -------- Original-Nachricht --------
>> Datum: Fri, 16 Jul 2010 14:27:21 +0200
>> Von: Stefan Langer
>> An: friedrich
>> CC: scala-user@listes.epfl.ch
>> Betreff: Re: [scala-user] Re: is there a way to have NaN for Int, Long, Boolean ...?
>> I'm just being curiouse what would you do if you need to turn a
>> integral part into a string then format this into some other type and
>> then use the result of that to print it to the user?
>>
>> val opt = Option[Int] = Some(1)
>> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrElse("Nothing
>> to show"))
>> Works with val opt = None as well!!!!
>>
>> Now how would I do this with NaO?
>>
>> -Stefan
>>
>> 2010/7/16 friedrich:
>>> IMHO:
>>>
>>> null, NaN and None have the semantics of "error", but play in
>> different
>>> leagues.
>>>
>>> NaN vs. None:
>>>
>>> NaN is an instance of Double or Float and as that behaves like one. We
>> can
>>> use
>>> NaN in any Operation, which always results in NaN. So an error stays an
>>> error,
>>> that's fine!
>>>
>>> None does not represent an instance of the class in question. You always
>>> need this
>>> annoying unboxing from Some(x) to get the valid value x vs. no unboxing
>> to
>>> get the
>>> invalid None. Tolerable but not really nice (when I see all the related
>>> discussions!)
>>>
>>> So Option is an artificial add-on to operations of any class, not
>> integrated
>>> in a
>>> specific class.
>>>
>>> But classes – not only Double and Float – which are not value
>> objects, i.e.
>>> have
>>> meaningful operations, which may fail, should have an "error" object,
>> which
>>> behaves
>>> somehow similar to NaN. Life would be much easier.
>>>
>>> And null? Just a kind of unsave None, but may be used as a valid value
>> for
>>> all AnyRef
>>> types, which leads to these infamous exceptions at runtime.
>>>
>>> So all in all: Integral numbers also need a NaN, as any class O should
>> have
>>> a NaO!
>>>
>>> regards
>>> friedrich
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>> http://scala-programming-language.1934581.n4.nabble.com/is-there-a-way-t...
>>> Sent from the Scala - User mailing list archive at Nabble.com.
>>>

now that i think about it, this is exactly what java already can do... null references

-------- Original-Nachricht --------
> Datum: Fri, 16 Jul 2010 14:56:34 +0200
> Von: Sylvain HENRY
> An: scala-user@listes.epfl.ch
> Betreff: Re: [scala-user] Re: is there a way to have NaN for Int, Long, Boolean ...?

> Oh yes! With a check for None that would throw a NullPointerException
>
> Le 16/07/2010 14:55, Dennis Haupt a écrit :
> > what about an implicit unboxing of options in predef? that would
> simplify it
> >
> > -------- Original-Nachricht --------
> >> Datum: Fri, 16 Jul 2010 14:27:21 +0200
> >> Von: Stefan Langer
> >> An: friedrich
> >> CC: scala-user@listes.epfl.ch
> >> Betreff: Re: [scala-user] Re: is there a way to have NaN for Int, Long,
> Boolean ...?
> >> I'm just being curiouse what would you do if you need to turn a
> >> integral part into a string then format this into some other type and
> >> then use the result of that to print it to the user?
> >>
> >> val opt = Option[Int] = Some(1)
> >>
> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrElse("Nothing
> >> to show"))
> >> Works with val opt = None as well!!!!
> >>
> >> Now how would I do this with NaO?
> >>
> >> -Stefan
> >>
> >> 2010/7/16 friedrich:
> >>> IMHO:
> >>>
> >>> null, NaN and None have the semantics of "error", but play in
> >> different
> >>> leagues.
> >>>
> >>> NaN vs. None:
> >>>
> >>> NaN is an instance of Double or Float and as that behaves like one. We
> >> can
> >>> use
> >>> NaN in any Operation, which always results in NaN. So an error stays
> an
> >>> error,
> >>> that's fine!
> >>>
> >>> None does not represent an instance of the class in question. You
> always
> >>> need this
> >>> annoying unboxing from Some(x) to get the valid value x vs. no
> unboxing
> >> to
> >>> get the
> >>> invalid None. Tolerable but not really nice (when I see all the
> related
> >>> discussions!)
> >>>
> >>> So Option is an artificial add-on to operations of any class, not
> >> integrated
> >>> in a
> >>> specific class.
> >>>
> >>> But classes – not only Double and Float – which are not value
> >> objects, i.e.
> >>> have
> >>> meaningful operations, which may fail, should have an "error" object,
> >> which
> >>> behaves
> >>> somehow similar to NaN. Life would be much easier.
> >>>
> >>> And null? Just a kind of unsave None, but may be used as a valid value
> >> for
> >>> all AnyRef
> >>> types, which leads to these infamous exceptions at runtime.
> >>>
> >>> So all in all: Integral numbers also need a NaN, as any class O
> should
> >> have
> >>> a NaO!
> >>>
> >>> regards
> >>> friedrich
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context:
> >>
> http://scala-programming-language.1934581.n4.nabble.com/is-there-a-way-t...
> >>> Sent from the Scala - User mailing list archive at Nabble.com.
> >>>

On Friday 16 July 2010 14:27:21 Stefan Langer wrote:
> I'm just being curiouse what would you do if you need to turn a
> integral part into a string then format this into some other type and
> then use the result of that to print it to the user?
>
> val opt = Option[Int] = Some(1)
> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrEl
>se("Nothing to show"))
> Works with val opt = None as well!!!!
>
> Now how would I do this with NaO?

You would need some rules to handle these. One could look at R
how they handle their special cases, which I would love to see also
in scala standardized for the primitive types. (maybe Caoyuans post goes into
this direction).
There you have in addition to NaN als NA denoting missing observations and
Inf and -Inf.

Converting NaN to string and back is already possible in scala
scala> List(1,Double.NaN) map (_.toString) map (_.toDouble) map (_.toString)
res8: List[java.lang.String] = List(1.0, NaN)

One could extend this to the Na/NaN for Int.

The bigger problem is that other functions that do more useful things (eg.
mean, sd) have to think about handling NA, NaN etc. in a configurable way.

R:
> v = c(NA,NaN,Inf,-Inf,1)
> as.logical(v)
[1] NA NA TRUE TRUE TRUE
> as.double(v)
[1] NA NaN Inf -Inf 1
> v + 1
[1] NA NaN Inf -Inf 2

mean(x, trim = 0, na.rm = FALSE, ...)
so one has to decide what happens with missing observations.

best,
ido

I think Jason gave the best syntax Scala can do right now. Either use
scalaz or use the for-syntax. Both are - of course - more verbose than
just writing an expression in direct style.

But being explicit can be a virtue. It shows that the programmer has
noticed of the fact, that there might be invalid values. Additionally,
the concept NaO (== null) assumes that *all* operations on a type are
not closed over their domain. But in fact there are many operations
which by definition should never return a null value and this is why
many see the concept of nulls as a mistake, because you can't declare
in types that you won't return any nulls and so, you can never be
sure.

I think the real idea when proposing NaO is something like Groovies
safe-dereference operator ?. which propagates a null value over a
chain of selections without throwing an NPE. When speaking about
Option, we have the same: it is Option.map. However, the syntax is
more complicated:

xObject?.length =^= xOption.map(_.length)

But even in Groovy this works only for the one unary operator of
derefence. If you extend the assumption to every unary operators or
even binary (n-ary?) operators, that an operation returns None if any
of the operators is None (*), we can use the for-expression as shown
by Jason. If we now would introduce some syntax sugar to 'derive' or
lift an operation to the Option level we perhaps could do away with
the 'for'-syntax:

For example (taking ^ as the syntax level derivation operator):

val x: Option[String] = ...
x.length_^

would be translated to

for(xv <- x) yield xv.length

val y: Option[Int]
val z: Option[Int]

y +^ z

would be translated to
for { yv <- y; zv <- z } yield yv + zv

This would of cause not only work for Option expressions but in fact
for every expression of a monadic type.

What do you think?

Johannes

(Of course, you could write this lift operation in Scala and scalaz
probably has it defined already, but are there other languages which
have special syntax for this?)

(*) Which is the obvious behaviour but, as Ido said before, not always
the one needed.

On Fri, Jul 16, 2010 at 3:06 PM, Ido M. Tamir wrote:
> On Friday 16 July 2010 14:27:21 Stefan Langer wrote:
>> I'm just being curiouse what would you do if you need to turn a
>> integral part into a string then format this into some other type and
>> then use the result of that to print it to the user?
>>
>> val opt = Option[Int] = Some(1)
>> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrEl
>>se("Nothing to show"))
>> Works with val opt = None as well!!!!
>>
>> Now how would I do this with NaO?
>
> You would need some rules to handle these. One could look at R
> how they handle their special cases, which I would love to see also
> in scala standardized for the primitive types. (maybe Caoyuans post goes into
> this direction).
> There you have in addition to NaN als NA denoting missing observations and
> Inf and -Inf.
>
> Converting NaN to string and back is already possible in scala
> scala> List(1,Double.NaN) map (_.toString) map (_.toDouble) map (_.toString)
> res8: List[java.lang.String] = List(1.0, NaN)
>
> One could extend this to the Na/NaN for Int.
>
> The bigger problem is that other functions that do more useful things (eg.
> mean, sd) have to think about handling NA, NaN etc. in a configurable way.
>
> R:
>> v = c(NA,NaN,Inf,-Inf,1)
>> as.logical(v)
> [1]   NA   NA TRUE TRUE TRUE
>> as.double(v)
> [1]   NA  NaN  Inf -Inf    1
>> v + 1
> [1]   NA  NaN  Inf -Inf    2
>
> mean(x, trim = 0, na.rm = FALSE, ...)
> so one has to decide what happens with missing observations.
>
>
> best,
> ido
>

Tony--you? Imperative style??

On Wed, Jul 14, 2010 at 9:12 PM, Tony Morris <tonymorris@gmail.com> wrote:

Russ Paielli wrote:
> What are the valid indices? If they cannot be negative, then why not
> just use -1 to represent an invalid index. That approach is widely
> used. For example, if you ask for the index of a character in a
> String, but it is not found, you get -1. I believe that approach is
> called "in-band signaling," since -1 is a valid integer.
Do not do this.

--
Tony Morris
http://tmorris.net/

Side note.

x.map(f).map(g)

is better written:

x.map(f compose g)

Stefan Langer wrote:
> I'm just being curiouse what would you do if you need to turn a
> integral part into a string then format this into some other type and
> then use the result of that to print it to the user?
>
> val opt = Option[Int] = Some(1)
> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrElse("Nothing
> to show"))
> Works with val opt = None as well!!!!
>
> Now how would I do this with NaO?
>
> -Stefan
>
> 2010/7/16 friedrich :
>
>> IMHO:
>>
>> null, NaN and None have the semantics of "error", but play in different
>> leagues.
>>
>> NaN vs. None:
>>
>> NaN is an instance of Double or Float and as that behaves like one. We can
>> use
>> NaN in any Operation, which always results in NaN. So an error stays an
>> error,
>> that's fine!
>>
>> None does not represent an instance of the class in question. You always
>> need this
>> annoying unboxing from Some(x) to get the valid value x vs. no unboxing to
>> get the
>> invalid None. Tolerable but not really nice (when I see all the related
>> discussions!)
>>
>> So Option is an artificial add-on to operations of any class, not integrated
>> in a
>> specific class.
>>
>> But classes – not only Double and Float – which are not value objects, i.e.
>> have
>> meaningful operations, which may fail, should have an "error" object, which
>> behaves
>> somehow similar to NaN. Life would be much easier.
>>
>> And null? Just a kind of unsave None, but may be used as a valid value for
>> all AnyRef
>> types, which leads to these infamous exceptions at runtime.
>>
>> So all in all: Integral numbers also need a NaN, as any class O should have
>> a NaO!
>>
>> regards
>> friedrich
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://scala-programming-language.1934581.n4.nabble.com/is-there-a-way-t...
>> Sent from the Scala - User mailing list archive at Nabble.com.
>>
>>
>
>

Hmm.. shouldn't that be x.map(g compose f) ?

Am 16.07.2010 um 23:35 schrieb Tony Morris:

> Side note.
>
> x.map(f).map(g)
>
> is better written:
>
> x.map(f compose g)
>
>
> Stefan Langer wrote:
>> I'm just being curiouse what would you do if you need to turn a
>> integral part into a string then format this into some other type and
>> then use the result of that to print it to the user?
>>
>> val opt = Option[Int] = Some(1)
>> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrElse("Nothing
>> to show"))
>> Works with val opt = None as well!!!!
>>
>> Now how would I do this with NaO?
>>
>> -Stefan
>>
>> 2010/7/16 friedrich :
>>
>>> IMHO:
>>>
>>> null, NaN and None have the semantics of "error", but play in different
>>> leagues.
>>>
>>> NaN vs. None:
>>>
>>> NaN is an instance of Double or Float and as that behaves like one. We can
>>> use
>>> NaN in any Operation, which always results in NaN. So an error stays an
>>> error,
>>> that's fine!
>>>
>>> None does not represent an instance of the class in question. You always
>>> need this
>>> annoying unboxing from Some(x) to get the valid value x vs. no unboxing to
>>> get the
>>> invalid None. Tolerable but not really nice (when I see all the related
>>> discussions!)
>>>
>>> So Option is an artificial add-on to operations of any class, not integrated
>>> in a
>>> specific class.
>>>
>>> But classes – not only Double and Float – which are not value objects, i.e.
>>> have
>>> meaningful operations, which may fail, should have an "error" object, which
>>> behaves
>>> somehow similar to NaN. Life would be much easier.
>>>
>>> And null? Just a kind of unsave None, but may be used as a valid value for
>>> all AnyRef
>>> types, which leads to these infamous exceptions at runtime.
>>>
>>> So all in all: Integral numbers also need a NaN, as any class O should have
>>> a NaO!
>>>
>>> regards
>>> friedrich
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://scala-programming-language.1934581.n4.nabble.com/is-there-a-way-t...
>>> Sent from the Scala - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>

Yes, thanks for that correction.

x.map(f).map(g)

is better written:

x.map(g compose f)

or:

x.map(f andThen g)

Andreas Flierl wrote:
> Hmm.. shouldn't that be x.map(g compose f) ?
>
> Am 16.07.2010 um 23:35 schrieb Tony Morris:
>
>
>> Side note.
>>
>> x.map(f).map(g)
>>
>> is better written:
>>
>> x.map(f compose g)
>>
>>
>> Stefan Langer wrote:
>>
>>> I'm just being curiouse what would you do if you need to turn a
>>> integral part into a string then format this into some other type and
>>> then use the result of that to print it to the user?
>>>
>>> val opt = Option[Int] = Some(1)
>>> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrElse("Nothing
>>> to show"))
>>> Works with val opt = None as well!!!!
>>>
>>> Now how would I do this with NaO?
>>>
>>> -Stefan
>>>
>>> 2010/7/16 friedrich :
>>>
>>>
>>>> IMHO:
>>>>
>>>> null, NaN and None have the semantics of "error", but play in different
>>>> leagues.
>>>>
>>>> NaN vs. None:
>>>>
>>>> NaN is an instance of Double or Float and as that behaves like one. We can
>>>> use
>>>> NaN in any Operation, which always results in NaN. So an error stays an
>>>> error,
>>>> that's fine!
>>>>
>>>> None does not represent an instance of the class in question. You always
>>>> need this
>>>> annoying unboxing from Some(x) to get the valid value x vs. no unboxing to
>>>> get the
>>>> invalid None. Tolerable but not really nice (when I see all the related
>>>> discussions!)
>>>>
>>>> So Option is an artificial add-on to operations of any class, not integrated
>>>> in a
>>>> specific class.
>>>>
>>>> But classes – not only Double and Float – which are not value objects, i.e.
>>>> have
>>>> meaningful operations, which may fail, should have an "error" object, which
>>>> behaves
>>>> somehow similar to NaN. Life would be much easier.
>>>>
>>>> And null? Just a kind of unsave None, but may be used as a valid value for
>>>> all AnyRef
>>>> types, which leads to these infamous exceptions at runtime.
>>>>
>>>> So all in all: Integral numbers also need a NaN, as any class O should have
>>>> a NaO!
>>>>
>>>> regards
>>>> friedrich
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://scala-programming-language.1934581.n4.nabble.com/is-there-a-way-t...
>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>

Since noone seemed to like my proposal, I just went ahead and quickly
hacked together a compiler plugin doing just the promised.

You can get it at

http://github.com/jrudolph/scala-fast-map/downloads

or in sbt with

val virtualVoid = "Virtual-Void repository" at "http://mvn.virtual-void.net"
val fastMap = compilerPlugin("net.virtualvoid" %% "scala-fast-map" % "1.0")

When the plugin is active, every call to a method ending with '^' is
lifted as outlined before to work on any monad by rewriting the
expression into the equivalent of a for-expression.

Here's an example session:

Welcome to Scala version 2.8.0.final (Java HotSpot(TM) 64-Bit Server
VM, Java 1.6.0_20).
Type in expressions to have them evaluated.
Type :help for more information.

scala> val (x,y,z) = (Some(1),Some(2),Some(3))
x: Some[Int] = Some(1)
y: Some[Int] = Some(2)
z: Some[Int] = Some(3)

scala> x + y
:8: error: type mismatch;
found : Some[Int]
required: String
x + y
^

scala> x +^ y
res1: Option[Int] = Some(3)

scala> x +^ y +^ z
res2: Option[Int] = Some(6)

scala> List(1,2,3) +^ List(1)
res3: List[Int] = List(2, 3, 4)

scala> List(1,2,3) +^ List(1,5)
res4: List[Int] = List(2, 6, 3, 7, 4, 8)

scala> Some("test").length_^
res5: Option[Int] = Some(4)

scala> Some("test").length_^ +^ x
res6: Option[Int] = Some(5)

On Fri, Jul 16, 2010 at 3:47 PM, Johannes Rudolph
wrote:
> I think Jason gave the best syntax Scala can do right now. Either use
> scalaz or use the for-syntax. Both are - of course - more verbose than
> just writing an expression in direct style.
>
> But being explicit can be a virtue. It shows that the programmer has
> noticed of the fact, that there might be invalid values. Additionally,
> the concept NaO (== null) assumes that *all* operations on a type are
> not closed over their domain. But in fact there are many operations
> which by definition should never return a null value and this is why
> many see the concept of nulls as a mistake, because you can't declare
> in types that you won't return any nulls and so, you can never be
> sure.
>
> I think the real idea when proposing NaO is something like Groovies
> safe-dereference operator ?. which propagates a null value over a
> chain of selections without throwing an NPE. When speaking about
> Option, we have the same: it is Option.map. However, the syntax is
> more complicated:
>
> xObject?.length =^= xOption.map(_.length)
>
> But even in Groovy this works only for the one unary operator of
> derefence. If you extend the assumption to every unary operators or
> even binary (n-ary?) operators, that an operation returns None if any
> of the operators is None (*), we can use the for-expression as shown
> by Jason. If we now would introduce some syntax sugar to 'derive' or
> lift an operation to the Option level we perhaps could do away with
> the 'for'-syntax:
>
> For example (taking ^ as the syntax level derivation operator):
>
> val x: Option[String] = ...
> x.length_^
>
> would be translated to
>
> for(xv <- x) yield xv.length
>
> val y: Option[Int]
> val z: Option[Int]
>
> y +^ z
>
> would be translated to
> for { yv <- y; zv <- z } yield yv + zv
>
> This would of cause not only work for Option expressions but in fact
> for every expression of a monadic type.
>
> What do you think?
>
> Johannes
>
> (Of course, you could write this lift operation in Scala and scalaz
> probably has it defined already, but are there other languages which
> have special syntax for this?)
>
> (*) Which is the obvious behaviour but, as Ido said before, not always
> the one needed.
>
> On Fri, Jul 16, 2010 at 3:06 PM, Ido M. Tamir wrote:
>> On Friday 16 July 2010 14:27:21 Stefan Langer wrote:
>>> I'm just being curiouse what would you do if you need to turn a
>>> integral part into a string then format this into some other type and
>>> then use the result of that to print it to the user?
>>>
>>> val opt = Option[Int] = Some(1)
>>> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrEl
>>>se("Nothing to show"))
>>> Works with val opt = None as well!!!!
>>>
>>> Now how would I do this with NaO?
>>
>> You would need some rules to handle these. One could look at R
>> how they handle their special cases, which I would love to see also
>> in scala standardized for the primitive types. (maybe Caoyuans post goes into
>> this direction).
>> There you have in addition to NaN als NA denoting missing observations and
>> Inf and -Inf.
>>
>> Converting NaN to string and back is already possible in scala
>> scala> List(1,Double.NaN) map (_.toString) map (_.toDouble) map (_.toString)
>> res8: List[java.lang.String] = List(1.0, NaN)
>>
>> One could extend this to the Na/NaN for Int.
>>
>> The bigger problem is that other functions that do more useful things (eg.
>> mean, sd) have to think about handling NA, NaN etc. in a configurable way.
>>
>> R:
>>> v = c(NA,NaN,Inf,-Inf,1)
>>> as.logical(v)
>> [1]   NA   NA TRUE TRUE TRUE
>>> as.double(v)
>> [1]   NA  NaN  Inf -Inf    1
>>> v + 1
>> [1]   NA  NaN  Inf -Inf    2
>>
>> mean(x, trim = 0, na.rm = FALSE, ...)
>> so one has to decide what happens with missing observations.
>>
>>
>> best,
>> ido
>>
>
>
>
> --
> Johannes
>
> -----------------------------------------------
> Johannes Rudolph
> http://virtual-void.net
>

OK, so that's really cool.

Its kind of like you are dynamically pimping Option[X], so that Option[X] has a "lifted" function for each of X's functions. There's really no way to do any kind of similar meta-programming in Scala except by compiler plugins.

But I have to admit is smells...I dunno...funny? Maybe I'd feel better if I was at all versed in Scala compiler plugins.

Brian Maso


On Mon, Jul 19, 2010 at 2:22 PM, Johannes Rudolph <johannes.rudolph@googlemail.com> wrote:

Since noone seemed to like my proposal, I just went ahead and quickly
hacked together a compiler plugin doing just the promised.

You can get it at

http://github.com/jrudolph/scala-fast-map/downloads

or in sbt with

 val virtualVoid = "Virtual-Void repository" at "http://mvn.virtual-void.net"
 val fastMap = compilerPlugin("net.virtualvoid" %% "scala-fast-map" % "1.0")

When the plugin is active, every call to a method ending with '^' is
lifted as outlined before to work on any monad by rewriting the
expression into the equivalent of a for-expression.

Here's an example session:

Welcome to Scala version 2.8.0.final (Java HotSpot(TM) 64-Bit Server
VM, Java 1.6.0_20).
Type in expressions to have them evaluated.
Type :help for more information.

scala> val (x,y,z) = (Some(1),Some(2),Some(3))
x: Some[Int] = Some(1)
y: Some[Int] = Some(2)
z: Some[Int] = Some(3)

scala> x + y
<console>:8: error: type mismatch;
 found   : Some[Int]
 required: String
      x + y
          ^

scala> x +^ y
res1: Option[Int] = Some(3)

scala> x +^ y +^ z
res2: Option[Int] = Some(6)

scala> List(1,2,3) +^ List(1)
res3: List[Int] = List(2, 3, 4)

scala> List(1,2,3) +^ List(1,5)
res4: List[Int] = List(2, 6, 3, 7, 4, 8)

scala> Some("test").length_^
res5: Option[Int] = Some(4)

scala> Some("test").length_^ +^ x
res6: Option[Int] = Some(5)


On Fri, Jul 16, 2010 at 3:47 PM, Johannes Rudolph
<johannes.rudolph@googlemail.com> wrote:
> I think Jason gave the best syntax Scala can do right now. Either use
> scalaz or use the for-syntax. Both are - of course - more verbose than
> just writing an expression in direct style.
>
> But being explicit can be a virtue. It shows that the programmer has
> noticed of the fact, that there might be invalid values. Additionally,
> the concept NaO (== null) assumes that *all* operations on a type are
> not closed over their domain. But in fact there are many operations
> which by definition should never return a null value and this is why
> many see the concept of nulls as a mistake, because you can't declare
> in types that you won't return any nulls and so, you can never be
> sure.
>
> I think the real idea when proposing NaO is something like Groovies
> safe-dereference operator ?. which propagates a null value over a
> chain of selections without throwing an NPE. When speaking about
> Option, we have the same: it is Option.map. However, the syntax is
> more complicated:
>
> xObject?.length =^= xOption.map(_.length)
>
> But even in Groovy this works only for the one unary operator of
> derefence. If you extend the assumption to every unary operators or
> even binary (n-ary?) operators, that an operation returns None if any
> of the operators is None (*), we can use the for-expression as shown
> by Jason. If we now would introduce some syntax sugar to 'derive' or
> lift an operation to the Option level we perhaps could do away with
> the 'for'-syntax:
>
> For example (taking ^ as the syntax level derivation operator):
>
> val x: Option[String] = ...
> x.length_^
>
> would be translated to
>
> for(xv <- x) yield xv.length
>
> val y: Option[Int]
> val z: Option[Int]
>
> y +^ z
>
> would be translated to
> for { yv <- y; zv <- z } yield yv + zv
>
> This would of cause not only work for Option expressions but in fact
> for every expression of a monadic type.
>
> What do you think?
>
> Johannes
>
> (Of course, you could write this lift operation in Scala and scalaz
> probably has it defined already, but are there other languages which
> have special syntax for this?)
>
> (*) Which is the obvious behaviour but, as Ido said before, not always
> the one needed.
>
> On Fri, Jul 16, 2010 at 3:06 PM, Ido M. Tamir <tamir@imp.ac.at> wrote:
>> On Friday 16 July 2010 14:27:21 Stefan Langer wrote:
>>> I'm just being curiouse what would you do if you need to turn a
>>> integral part into a string then format this into some other type and
>>> then use the result of that to print it to the user?
>>>
>>> val opt = Option[Int] = Some(1)
>>> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrEl
>>>se("Nothing to show"))
>>> Works with val opt = None as well!!!!
>>>
>>> Now how would I do this with NaO?
>>
>> You would need some rules to handle these. One could look at R
>> how they handle their special cases, which I would love to see also
>> in scala standardized for the primitive types. (maybe Caoyuans post goes into
>> this direction).
>> There you have in addition to NaN als NA denoting missing observations and
>> Inf and -Inf.
>>
>> Converting NaN to string and back is already possible in scala
>> scala> List(1,Double.NaN) map (_.toString) map (_.toDouble) map (_.toString)
>> res8: List[java.lang.String] = List(1.0, NaN)
>>
>> One could extend this to the Na/NaN for Int.
>>
>> The bigger problem is that other functions that do more useful things (eg.
>> mean, sd) have to think about handling NA, NaN etc. in a configurable way.
>>
>> R:
>>> v = c(NA,NaN,Inf,-Inf,1)
>>> as.logical(v)
>> [1]   NA   NA TRUE TRUE TRUE
>>> as.double(v)
>> [1]   NA  NaN  Inf -Inf    1
>>> v + 1
>> [1]   NA  NaN  Inf -Inf    2
>>
>> mean(x, trim = 0, na.rm = FALSE, ...)
>> so one has to decide what happens with missing observations.
>>
>>
>> best,
>> ido
>>
>
>
>
> --
> Johannes
>
> -----------------------------------------------
> Johannes Rudolph
> http://virtual-void.net
>



--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

"Smart" metaprogramming/macros would be very interesting.

On Mon, Jul 19, 2010 at 11:47 PM, Brian Maso <brian@blumenfeld-maso.com> wrote:

OK, so that's really cool.

Its kind of like you are dynamically pimping Option[X], so that Option[X] has a "lifted" function for each of X's functions. There's really no way to do any kind of similar meta-programming in Scala except by compiler plugins.

But I have to admit is smells...I dunno...funny? Maybe I'd feel better if I was at all versed in Scala compiler plugins.

Brian Maso


On Mon, Jul 19, 2010 at 2:22 PM, Johannes Rudolph <johannes.rudolph@googlemail.com> wrote:

Since noone seemed to like my proposal, I just went ahead and quickly
hacked together a compiler plugin doing just the promised.

You can get it at

http://github.com/jrudolph/scala-fast-map/downloads

or in sbt with

 val virtualVoid = "Virtual-Void repository" at "http://mvn.virtual-void.net"
 val fastMap = compilerPlugin("net.virtualvoid" %% "scala-fast-map" % "1.0")

When the plugin is active, every call to a method ending with '^' is
lifted as outlined before to work on any monad by rewriting the
expression into the equivalent of a for-expression.

Here's an example session:

Welcome to Scala version 2.8.0.final (Java HotSpot(TM) 64-Bit Server
VM, Java 1.6.0_20).
Type in expressions to have them evaluated.
Type :help for more information.

scala> val (x,y,z) = (Some(1),Some(2),Some(3))
x: Some[Int] = Some(1)
y: Some[Int] = Some(2)
z: Some[Int] = Some(3)

scala> x + y
<console>:8: error: type mismatch;
 found   : Some[Int]
 required: String
      x + y
          ^

scala> x +^ y
res1: Option[Int] = Some(3)

scala> x +^ y +^ z
res2: Option[Int] = Some(6)

scala> List(1,2,3) +^ List(1)
res3: List[Int] = List(2, 3, 4)

scala> List(1,2,3) +^ List(1,5)
res4: List[Int] = List(2, 6, 3, 7, 4, 8)

scala> Some("test").length_^
res5: Option[Int] = Some(4)

scala> Some("test").length_^ +^ x
res6: Option[Int] = Some(5)


On Fri, Jul 16, 2010 at 3:47 PM, Johannes Rudolph
<johannes.rudolph@googlemail.com> wrote:
> I think Jason gave the best syntax Scala can do right now. Either use
> scalaz or use the for-syntax. Both are - of course - more verbose than
> just writing an expression in direct style.
>
> But being explicit can be a virtue. It shows that the programmer has
> noticed of the fact, that there might be invalid values. Additionally,
> the concept NaO (== null) assumes that *all* operations on a type are
> not closed over their domain. But in fact there are many operations
> which by definition should never return a null value and this is why
> many see the concept of nulls as a mistake, because you can't declare
> in types that you won't return any nulls and so, you can never be
> sure.
>
> I think the real idea when proposing NaO is something like Groovies
> safe-dereference operator ?. which propagates a null value over a
> chain of selections without throwing an NPE. When speaking about
> Option, we have the same: it is Option.map. However, the syntax is
> more complicated:
>
> xObject?.length =^= xOption.map(_.length)
>
> But even in Groovy this works only for the one unary operator of
> derefence. If you extend the assumption to every unary operators or
> even binary (n-ary?) operators, that an operation returns None if any
> of the operators is None (*), we can use the for-expression as shown
> by Jason. If we now would introduce some syntax sugar to 'derive' or
> lift an operation to the Option level we perhaps could do away with
> the 'for'-syntax:
>
> For example (taking ^ as the syntax level derivation operator):
>
> val x: Option[String] = ...
> x.length_^
>
> would be translated to
>
> for(xv <- x) yield xv.length
>
> val y: Option[Int]
> val z: Option[Int]
>
> y +^ z
>
> would be translated to
> for { yv <- y; zv <- z } yield yv + zv
>
> This would of cause not only work for Option expressions but in fact
> for every expression of a monadic type.
>
> What do you think?
>
> Johannes
>
> (Of course, you could write this lift operation in Scala and scalaz
> probably has it defined already, but are there other languages which
> have special syntax for this?)
>
> (*) Which is the obvious behaviour but, as Ido said before, not always
> the one needed.
>
> On Fri, Jul 16, 2010 at 3:06 PM, Ido M. Tamir <tamir@imp.ac.at> wrote:
>> On Friday 16 July 2010 14:27:21 Stefan Langer wrote:
>>> I'm just being curiouse what would you do if you need to turn a
>>> integral part into a string then format this into some other type and
>>> then use the result of that to print it to the user?
>>>
>>> val opt = Option[Int] = Some(1)
>>> println(opt.map(_.toString).map(_.toSomeOtherValue).map(_.toString).getOrEl
>>>se("Nothing to show"))
>>> Works with val opt = None as well!!!!
>>>
>>> Now how would I do this with NaO?
>>
>> You would need some rules to handle these. One could look at R
>> how they handle their special cases, which I would love to see also
>> in scala standardized for the primitive types. (maybe Caoyuans post goes into
>> this direction).
>> There you have in addition to NaN als NA denoting missing observations and
>> Inf and -Inf.
>>
>> Converting NaN to string and back is already possible in scala
>> scala> List(1,Double.NaN) map (_.toString) map (_.toDouble) map (_.toString)
>> res8: List[java.lang.String] = List(1.0, NaN)
>>
>> One could extend this to the Na/NaN for Int.
>>
>> The bigger problem is that other functions that do more useful things (eg.
>> mean, sd) have to think about handling NA, NaN etc. in a configurable way.
>>
>> R:
>>> v = c(NA,NaN,Inf,-Inf,1)
>>> as.logical(v)
>> [1]   NA   NA TRUE TRUE TRUE
>>> as.double(v)
>> [1]   NA  NaN  Inf -Inf    1
>>> v + 1
>> [1]   NA  NaN  Inf -Inf    2
>>
>> mean(x, trim = 0, na.rm = FALSE, ...)
>> so one has to decide what happens with missing observations.
>>
>>
>> best,
>> ido
>>
>
>
>
> --
> Johannes
>
> -----------------------------------------------
> Johannes Rudolph
> http://virtual-void.net
>



--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

Hello,

On Tue, Jul 20, 2010 at 1:22 AM, Johannes Rudolph
wrote:
> scala> x +^ y
> res1: Option[Int] = Some(3)
>
> scala> x +^ y +^ z
> res2: Option[Int] = Some(6)
>
> scala> List(1,2,3) +^ List(1)
> res3: List[Int] = List(2, 3, 4)
>
> scala> List(1,2,3) +^ List(1,5)
> res4: List[Int] = List(2, 6, 3, 7, 4, 8)
>
> scala> Some("test").length_^
> res5: Option[Int] = Some(4)
>
> scala> Some("test").length_^ +^ x
> res6: Option[Int] = Some(5)

these are looking good to me, but why not to stick with more
Haskell-like notation for monads — do-like notation?