ponder-lab / Hybridize-Functions-Refactoring / #3012
85%
main: 86%

LAST BUILD BRANCH: 2c4d795b88915285b87716ac91db86fd2deb1195
DEFAULT BRANCH: main
Ran
Jobs 1
Files 42
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 85.334%. Remained the same
#3012

push

github

web-flow 
Pin where a parameter's dtype is read from (#932)

* Pin where a parameter's dtype is read from

A parameter's dtype comes from the allocation of the array it receives,
not from the arrays it is passed alongside and not from a value assigned
into it. NumPy casts to the destination on assignment, so an int64 array
filled from a float64 source stays int64, and an emission naming any
other dtype rejects the calls the function receives.

The cases make the three candidates distinct on purpose: the destination
says int64, the partners say float32, and the assigned value says
float64, so a wrong emission names its own source instead of being
ambiguous between two of them. They vary how far the value travels
before landing, since an allocation is easiest to lose across a
container boundary, and all of the plain, tuple-indexed, and generator
forms are read correctly.

The spelling of the dtype argument is a separate axis and is not.
Resolution is per-spelling and incomplete: `np.int`, `np.long`, and the
builtin `bool` all fall back to float64, while `int`, `np.int32`,
`np.bool`, and `np.bool_` resolve. No rule separates those, since
`np.bool` resolves where `bool` does not and `int` resolves where
`np.int` does not, so they are listed rather than characterized. Each
miss names float64 definitely rather than degrading to unknown, so
nothing downstream can tell a resolved float64 from an unresolved one.
`np.float` is pinned as the case where the fallback and the intended
dtype coincide, which is the spelling under which this is invisible.

The misses are pinned as today's behavior, not endorsed.

* Pin two spellings that are neither alias nor builtin

The model defines a field for `uint8` and none for `int16`, and int16
differs from the value a miss falls back to, so this is a spelling whose
failure is visible without being a deprecated alias or a builtin. Both
were predicted from the field list before being run and both landed
where predicted, which is what ma... (continued)

3590 of 4207 relevant lines covered (85.33%)

0.85 hits per line

Jobs
ID Job ID Ran Files Coverage
1 #3012.1 42
85.33
Source Files on build #3012