Le mardi 09 février 2016 à 20:28 -0800, Michael Landis a écrit :
> missed a paren above (for the people that are going to past the code into a
> shell and try it out) - something that I am not doing. Still, this is closer:
>
> # wishful thinking...
> using Dates;
> leapDay = isleapyear(yr) ? Dat
The problem is not so much when you are (potentially) generating and handling
null dates in your own code, but how one interacts with library code that may
or may not return a null. Especially in a dynamically typed language, in the
absence of a Nullable type the only way to determine if a metho
Why couldn't you do something like this? It is type stable:
using Base.Dates
leapDay = isleapyear(yr) ? Date(yr, 2, 29) : Date()
if leapDay != Date()
doy = dayofyear( leapDay )
end
Again, Date() returns this: *0001-01-01*
It works nicely as a "null" date.
Chris
On Tuesday, February 9, 201
missed a paren above (for the people that are going to past the code into a
shell and try it out) - something that I am not doing. Still, this is
closer:
# wishful thinking...
using Dates;
leapDay = isleapyear(yr) ? Date(yr,2,29) : nothing
if ! leapDay
doy = dayofyear( leapDay )
... clean a
# wishful thinking...
using Dates;
leapDay = isleapyear(yr) ? Date(yr,2,29) : nothing
if ! leapDay
dow = dayofyear( leapDay )
... clean and concise (thought that was the point), but we get
leapDay = isleapyear(yr) ? Nullable{Date}( Date(yr,2,29) : Nullable{Date}()
if ! isnull( leapDay )
do
If you don't want to use a typed-nullable, you always have this (older) option
available:
LeapDay(yr) = isLeapYr(yr) ? Date(yr,2,29) : nothing
The whole point of Nullable is to provide a means to prevent type-instability
problems. If you don't want to think about types (and don't care about
To be fair, writing code like this is perfectly fine, if you're not
concerned about performance (in the area of code that this is written in).
I find for my own code that I'll typically write something in a clean but
possibly inefficient way, and the profile and optimize where I find
bottlenecks.
Why can't there be a base type upon which all others are based (perhaps by
default)? The base class could handle the Nullable situation and
everything else would magically inherit that capability. Making a union of
a NULL and the actual type is pretty painful for the programmer. Weren't
we g
The problem with that proposition is that it introduces type instability.
i.e. the user would be tempted to write code like Michael's original
example like
LeapDay(yr) = isLeapYr(yr) ? Date(yr,2,29) : Nullable{Date}()
where the function `LeapDay` can actually return two different, distinct
types:
I really like that construction!
On Monday, February 8, 2016 at 10:49:41 PM UTC-5, Greg Plowman wrote:
>
> If only Nullables can be null, could we formally define this?
>
> isnull(x::Nullable) = x.isnull # already defined in nullable.jl
> isnull(x) = false # extra definition f
If only Nullables can be null, could we formally define this?
isnull(x::Nullable) = x.isnull # already defined in nullable.jl
isnull(x) = false # extra definition for everything else
> isnull( lp15 ) --> true
> isnull( lp16 ) --> MethodError: `isnull` has no method matchin
ah, cool. Missed that. Thanks. The pain in returning a Nullable{Date} is
that now I have to unpack it for things like dayofyear(). Nullable
introduces a rat's nest of unnecessary complications.
On Mon, Feb 8, 2016 at 7:35 PM, Christopher Alexander
wrote:
> For a null date, I usually just use
For a null date, I usually just use Date() (Dates.Date()), which returns
Jan 1, 0001. Also, you know that there is already a method to check
whether or not a year is a leap year right?
Dates.isleapyear(y), returns a Bool.
http://docs.julialang.org/en/release-0.4/manual/dates/
On Monday, Feb
13 matches
Mail list logo
