(я всё к тому, что получился ну какой-то супербессвязный набор слов, ну да ладно)

Отправка автора в рид-онли на сутки вошла во второй раунд

Но с неожиданным витком — заговорили о continue / break.

Подскажите, можно ли как-то прочекать в геттере переменной её значение не уходя в рекурсию?

мдэ...

Удивительно. Отловил ошибку. Пишу lu[row, col] /= luDiag - ошибка генерации байт-кода, пишу lu[row, col] = lu[row, col] / luDiag - работает. Все тут: https://youtrack.jetbrains.com/issue/KT-27469

Подскажите, можно ли как-то прочекать в геттере переменной её значение не уходя в рекурсию?

field

Подскажите, можно ли как-то прочекать в геттере переменной её значение не уходя в рекурсию?

спецпеременная с именем field

Подскажите, можно ли как-то прочекать в геттере переменной её значение не уходя в рекурсию?

field

спецпеременная с именем field

И если у меня переменная null, то в field получается тоже будет null?

а то!

Найс, спасибо

Удивительно. Отловил ошибку. Пишу lu[row, col] /= luDiag - ошибка генерации байт-кода, пишу lu[row, col] = lu[row, col] / luDiag - работает. Все тут: https://youtrack.jetbrains.com/issue/KT-27469

Все хочу спросить, как вообще линейная алгебра пишется на котлине? Не много ли теряется в производительности? В том же lapack люди угорают по пространственной и временной оптимизации кэша, loop tiling, интринсикам для векторных инструкций итп оптимизациям. Есть смысл, кроме фана?

на ассемблере завсегда быстрее

Все хочу спросить, как вообще линейная алгебра пишется на котлине? Не много ли теряется в производительности? В том же lapack люди угорают по пространственной и временной оптимизации кэша, loop tiling, интринсикам для векторных инструкций итп оптимизациям. Есть смысл, кроме фана?

Ну никто не обязывает писать все на чистой котлине. Пишу дефолтную реализацию, чтобы работала везде, а потом будут платформные реализации, в том числе тот самый лапак, которые будут использвоаться на конкретной платформе при подключении конкретного модуля

Проблема с математическими либами в том, что нет общего интерфейса. Они все написаны во времена, когда было только процедурное программирование и про интерфейсы вообще слыхом не слыхивали

Проблема с математическими либами в том, что нет общего интерфейса. Они все написаны во времена, когда было только процедурное программирование и про интерфейсы вообще слыхом не слыхивали

Странно. Функциональные ЯП в академической среде очень давно существуют.

Пример?

В котлине хвостовая рекурсия кастрированная: 1. Требует явно прописать tailrec 2. Не работает для взаимных хвостовых вызовов. В том виде, в котором она есть, практически малополезна.

Кто-то из ФП мира говорил что ему наоборот нравится этот кейворд т.к. он явно декларирует что тут будет оптимизация и компилятор проверит что она действительно возможна. И при этом при поддержке кода ее в этом месте не сломают.

Кто-то из ФП мира говорил что ему наоборот нравится этот кейворд т.к. он явно декларирует что тут будет оптимизация и компилятор проверит что она действительно возможна. И при этом при поддержке кода ее в этом месте не сломают.

да, удобно, помню в скале пользовался

Странно. Функциональные ЯП в академической среде очень давно существуют.

А что в фп принято интерфесить ?

Всем привет! А кто корутинами пользуется? Вопрос такой - как мне оптимальнее с разных методов (например онклик на два разные кнопки) отменять действие, скажем, запроса - и посылать последнее изменение без предыдущих? Первый вариант который я накопал - это через job.cancel() - new Job() . Но я думаю есть что то более лучшее, никто не подскажет? Пример кода или ссылочку на почитать. Первый вариант: private var jobRequest = Job() fun someMethod1() { jobRequest.cancel() jobRequest = Job() launch(UI + jobRequest) { delay(3000) // do something 1 fun someMethod2() { jobRequest.cancel() jobRequest = Job() launch(UI + jobRequest) { delay(3000) // time msec // do something 2 } }

Странно. Функциональные ЯП в академической среде очень давно существуют.

Есть только С++, и там используются либы напрямую переписанные с фортрана один в один.

В котлине хвостовая рекурсия кастрированная: 1. Требует явно прописать tailrec 2. Не работает для взаимных хвостовых вызовов. В том виде, в котором она есть, практически малополезна.

Из-за виртуализации методов 2-ой пункт крайне сложно реализуем, разве что в кейсе с private final функциями, которые можно без зазрения совести убить на компайл тайме

https://paperpaper.ru/papernews/2018/10/09/jetbrains-i-politeh-zapustili-sovmestnyj-onla/

Всем привет! А кто корутинами пользуется? Вопрос такой - как мне оптимальнее с разных методов (например онклик на два разные кнопки) отменять действие, скажем, запроса - и посылать последнее изменение без предыдущих? Первый вариант который я накопал - это через job.cancel() - new Job() . Но я думаю есть что то более лучшее, никто не подскажет? Пример кода или ссылочку на почитать. Первый вариант: private var jobRequest = Job() fun someMethod1() { jobRequest.cancel() jobRequest = Job() launch(UI + jobRequest) { delay(3000) // do something 1 fun someMethod2() { jobRequest.cancel() jobRequest = Job() launch(UI + jobRequest) { delay(3000) // time msec // do something 2 } }

https://gist.github.com/indrih17/b85b66ae46010fa9ddbb64e60aa6a8c9 по типу такого можно

https://gist.github.com/indrih17/b85b66ae46010fa9ddbb64e60aa6a8c9 по типу такого можно

ты что то непонятное скинул, что это? )

ты что то непонятное скинул, что это? )

Ой, сорри, сек, поправлю

ты что то непонятное скинул, что это? )

Поправил

ты что то непонятное скинул, что это? )

Понятно, что класс будет другим, но реализация ± такая

@Gabrodih ну то есть тоже по сути через new Job - job.cancel() ?

@Gabrodih ну то есть тоже по сути через new Job - job.cancel() ?

По сути да.) Но тут ещё для удобства можно переопределить coroutineContext

Все запущенные корутины в наследниках этого класса будут автоматически его использовать

Можно будет явно указать другой контекст

Но по дефолту Main

@Gabrodih понятно. Прикольно. Я слышал еще способ через actor , но пока не смог разобраться как это может выглядеть

https://gist.github.com/indrih17/b85b66ae46010fa9ddbb64e60aa6a8c9 по типу такого можно

спасибо.

https://gist.github.com/indrih17/b85b66ae46010fa9ddbb64e60aa6a8c9 по типу такого можно

а что за пляски с _view?

а что за пляски с _view?

backing property называется

а зачем?

а зачем?

а как иначе?

а как иначе?

приватный сеттер чем хуже? какую проблему не решает?

приватный сеттер чем хуже? какую проблему не решает?

nullability

nullability

да с этим беда

nullability

Можно обойтись через объект заглушку с интерфейсом View, поопрятнее будет имхо и ссылку на настоящий View не будем держать

Можно обойтись через объект заглушку с интерфейсом View, поопрятнее будет имхо и ссылку на настоящий View не будем держать

Пустую реализацию там держать? Чтобы при ошибке вместо крэша ничего не происходило?

Пустую реализацию там держать? Чтобы при ошибке вместо крэша ничего не происходило?

ну можно в реализации throw исключения накидать

Кто-то из ФП мира говорил что ему наоборот нравится этот кейворд т.к. он явно декларирует что тут будет оптимизация и компилятор проверит что она действительно возможна. И при этом при поддержке кода ее в этом месте не сломают.

Ну главная проблема - отсутствие оптимизации при взаимных хвостовых вызовах, а сам кейворд пожалуй даже хорош. Дополнительное ограничение декларирует. Хотя ничего он не декларирует. Вполне может быть функция, у которой только часть рекурсии хвостовая.

Ну главная проблема - отсутствие оптимизации при взаимных хвостовых вызовах, а сам кейворд пожалуй даже хорош. Дополнительное ограничение декларирует. Хотя ничего он не декларирует. Вполне может быть функция, у которой только часть рекурсии хвостовая.

Ну если совсем не станет хвостовой рекурсии tailrec скажет, не уверен как можно этот момент лучше сделать

Аннотировать сам вызов разве что

А что в фп принято интерфесить ?

Ну в статически типизированном (Hindley–Milner based) ФП принято typeclass использовать. typeclass - тот же интерфейс, даже получше в плане функциональности.

Из-за виртуализации методов 2-ой пункт крайне сложно реализуем, разве что в кейсе с private final функциями, которые можно без зазрения совести убить на компайл тайме

Я не говорил, что это легко реализовать. Я говорил, что без такой оптимизации tailrec малополезен.

Ну если совсем не станет хвостовой рекурсии tailrec скажет, не уверен как можно этот момент лучше сделать

Никак не улучшить особо. Просто убрать ключевое слово, раз уж оно гарантий не даёт, и пытаться оптимизировать все рекурсивные вызовы.

Я не говорил, что это легко реализовать. Я говорил, что без такой оптимизации tailrec малополезен.

Почему он мало полезен то? В голову не очень как раз приходят кейсы взаиморекрсии

Вот мне кажется, что это самое непопулярное ключевое слово. Проблема может возникнуть тогда, когда его сломают, а заметит только 1.5 человека. После релиза.

Никак не улучшить особо. Просто убрать ключевое слово, раз уж оно гарантий не даёт, и пытаться оптимизировать все рекурсивные вызовы.

Как-то очень жёстко, кажется что пользы больше чем потенциального вреда.

Почему он мало полезен то? В голову не очень как раз приходят кейсы взаиморекрсии

Реализация state machine на лямбдах, это если с ходу пример. Каждая лямбда кодирует одно из состояний, хвостовые вызовы - переход в другое состояние.

Да и вообще как-то странно раздувать стек возврата хвостовыми вызовами.

Реализация state machine на лямбдах, это если с ходу пример. Каждая лямбда кодирует одно из состояний, хвостовые вызовы - переход в другое состояние.

Но... ведь... это и через одну функцию ок делается с tailrec

Но... ведь... это и через одну функцию ок делается с tailrec

Ну любую взаимную хвостовую рекурсию можно развернуть в просто хвостовую, да и в цикл - тоже. Только читаемость хуже становится. Так-то можно трамплин написать, который сам это разворачивает, и на нём делать взаимную рекурсию.

Ну любую взаимную хвостовую рекурсию можно развернуть в просто хвостовую, да и в цикл - тоже. Только читаемость хуже становится. Так-то можно трамплин написать, который сам это разворачивает, и на нём делать взаимную рекурсию.

Ну это я к слову о бесполезности

Только всё одно, с трамплином немного более громоздко по коду получается, плюс хвостовые вызовы долгие будут и в куче будет много короткоживущих объектов.

В языке, в котором есть циклы, вообще можно отказаться от хвостовой рекурсии. Рекурсивными делать только вызовы не сводящиеся к хвостовым. Опять же, читаемость потеряется, так как вычисления будут "размазаны" по коду, который их организует, но принципиальных проблем нет. Вот в чистых ФП языках - да, без оптимизации никак. Там же кроме рекурсии нет других способов реализовать итеративные вычисления.

Всем привет, подскажите момент с дженериками: есть такое наследование HouseCardAdapter : BaseCardAdapter<House> BaseCardAdapter<R : Realty> : ArrayAdapter<R> House : Realty и как мне описать глобальный филд adapter, когда пишу так var arrayAdapter : ArrayAdapter<Realty>, то при создании arrayAdapter = HouseCardAdapter() получаю compile-time error

вопрос как правильно описать глобальный филд, чтобы он работал с разными адаптерами

ERROR: S client not available

в будущем будет LandCardAdapter : BaseCardAdapter<Land>

надо чтобы я могу инитить его и HouseCardAdapter и LandCardAdapter

https://twitter.com/kotlin/status/1049657568413540357/photo/1

Всем привет, подскажите момент с дженериками: есть такое наследование HouseCardAdapter : BaseCardAdapter<House> BaseCardAdapter<R : Realty> : ArrayAdapter<R> House : Realty и как мне описать глобальный филд adapter, когда пишу так var arrayAdapter : ArrayAdapter<Realty>, то при создании arrayAdapter = HouseCardAdapter() получаю compile-time error

не хотелось бы иметь 2 разных адаптера и юзать в одной ситуации один, а в другой - другой

а иметь бы одну переменную

Всем привет, подскажите момент с дженериками: есть такое наследование HouseCardAdapter : BaseCardAdapter<House> BaseCardAdapter<R : Realty> : ArrayAdapter<R> House : Realty и как мне описать глобальный филд adapter, когда пишу так var arrayAdapter : ArrayAdapter<Realty>, то при создании arrayAdapter = HouseCardAdapter() получаю compile-time error

У вас ArrayAdapter и BaseCardAdapter должны быть ковариантны по параметру R: interface Realty interface ArrayAdapter<out R> interface BaseCardAdapter<out R : Realty> : ArrayAdapter<R> class House: Realty class HouseCardAdapter : BaseCardAdapter<House> val fld: ArrayAdapter<Realty> = HouseCardAdapter()

ну вообще всё так же

кроме out

но ошибка

Точнее даже не так. Достаточно, чтобы ArrayAdapter был ковариантен.

Ну так out и есть ковариантность

ArrayAdapter стандартный джавовский - андройдовский

похоже туда out не впилить

это не мой класс я от него только наследуюсь

Тогда никак. Дженерики инвариантны по умолчанию.

эх..

придется что ли 2 переменные держать

Ну или val fld: ArrayAdapter<*> = HouseCardAdapter()

так не работает тоже, метод есть там addAll

который принимает коллекцию

и вот он ругается, n&r^ звездочка непоределенная коллекция

который принимает коллекцию

Тогда вы хотите странного. У вас тип поля не может гарантировать, что вы в HouseCardAdapter не начнёте пихать Land

Поэтому система типов вам такое и не даёт

а если переопределить у каждого addAll

метод

может помочь как-то ?

а если переопределить у каждого addAll

Нет.

я вроде понимаю в чем дело, просто андройдовский ArrayAdapter просто <T> то есть он держит массив каких-то элементов, может чистить его, добавлять, принимать

странно что не получается сделать какой-то адаптер которому неважно чем его инитить лишь бы наследниками ArrayAdapter

точнее это сделать можно через *

но вот как сделать добавление чтобы работало